Commit f88c0c72ff ("mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf
and rx_buf type") changed the type of tx_buf from "void *" to "struct
vsc_tp_packet *" and added a cast to (u32 *) when passing it to
cpu_to_be32_array() and the same change was made for rx_buf.
This triggers the type-check warning in sparse:
vsc-tp.c:327:28: sparse: expected restricted __be32 [usertype] *dst
vsc-tp.c:327:28: sparse: got unsigned int [usertype] *
vsc-tp.c:343:42: sparse: expected restricted __be32 const [usertype] *src
vsc-tp.c:343:42: sparse: got unsigned int [usertype] *
Fix this by casting to (__be32 *) instead.
Note actually changing the type of the buffers to "be32 *" is not an option
this buffer does actually contain a "struct vsc_tp_packet" and is used
as such most of the time. vsc_tp_rom_xfer() re-uses the buffers as just
dumb arrays of 32 bit words to talk to the device before the firmware has
booted, to avoid needing to allocate a separate buffer.
Fixes: f88c0c72ff ("mei: vsc: Use struct vsc_tp_packet as vsc-tp tx_buf and rx_buf type")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202505071634.kZ0I7Va6-lkp@intel.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250507090728.115910-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
gcc 15 honors the __counted_by(len) attribute on vsc_tp_packet.buf[]
and the vsc-tp.c code is using this in a wrong way. len does not contain
the available size in the buffer, it contains the actual packet length
*without* the crc. So as soon as vsc_tp_xfer() tries to add the crc to
buf[] the fortify-panic handler gets triggered:
[ 80.842193] memcpy: detected buffer overflow: 4 byte write of buffer size 0
[ 80.842243] WARNING: CPU: 4 PID: 272 at lib/string_helpers.c:1032 __fortify_report+0x45/0x50
...
[ 80.843175] __fortify_panic+0x9/0xb
[ 80.843186] vsc_tp_xfer.cold+0x67/0x67 [mei_vsc_hw]
[ 80.843210] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90
[ 80.843229] ? lockdep_hardirqs_on+0x7c/0x110
[ 80.843250] mei_vsc_hw_start+0x98/0x120 [mei_vsc]
[ 80.843270] mei_reset+0x11d/0x420 [mei]
The easiest fix would be to just drop the counted-by but with the exception
of the ack buffer in vsc_tp_xfer_helper() which only contains enough room
for the packet-header, all other uses of vsc_tp_packet always use a buffer
of VSC_TP_MAX_XFER_SIZE bytes for the packet.
Instead of just dropping the counted-by, split the vsc_tp_packet struct
definition into a header and a full-packet definition and use a fixed
size buf[] in the packet definition, this way fortify-source buffer
overrun checking still works when enabled.
Fixes: 566f5ca976 ("mei: Add transport driver for IVSC device")
Cc: stable@kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Alexander Usyskin <alexander.usyskin@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20250318141203.94342-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The _CRS ACPI resources table has 2 entries for the host wakeup GPIO,
the first one being a regular GpioIo () resource while the second one
is a GpioInt () resource for the same pin.
The acpi_gpio_mapping table used by vsc-tp.c maps the first Gpio ()
resource to "wakeuphost-gpios" where as the second GpioInt () entry
is mapped to "wakeuphostint-gpios".
Using "wakeuphost" to request the GPIO as was done until now, means
that the gpiolib-acpi code does not know that the GPIO is active-low
as that info is only available in the GpioInt () entry.
Things were still working before due to the following happening:
1. Since the 2 entries point to the same pin they share a struct gpio_desc
2. The SPI core creates the SPI device vsc-tp.c binds to and calls
acpi_dev_gpio_irq_get(). This does use the second entry and sets
FLAG_ACTIVE_LOW in gpio_desc.flags .
3. vsc_tp_probe() requests the "wakeuphost" GPIO and inherits the
active-low flag set by acpi_dev_gpio_irq_get()
But there is a possible scenario where things do not work:
1. - 3. happen as above
4. After requesting the "wakeuphost" GPIO, the "resetfw" GPIO is requested
next, but its USB GPIO controller is not available yet, so this call
returns -EPROBE_DEFER.
5. The gpio_desc for "wakeuphost" is put() and during this the active-low
flag is cleared from gpio_desc.flags .
6. Later on vsc_tp_probe() requests the "wakeuphost" GPIO again, but now it
is not marked active-low.
The difference can also be seen in /sys/kernel/debug/gpio, which contains
the following line for this GPIO:
gpio-535 ( |wakeuphost ) in hi IRQ ACTIVE LOW
If the second scenario is hit the "ACTIVE LOW" at the end disappears and
things do not work.
Fix this by requesting the GPIO through the "wakeuphostint" mapping instead
which provides active-low info without relying on acpi_dev_gpio_irq_get()
pre-populating this info in the gpio_desc.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2316918
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
Tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Fixes: 566f5ca976 ("mei: Add transport driver for IVSC device")
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20250214212425.84021-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The only 2 callers of vsc_tp_reset() are:
1. mei_vsc_hw_reset(), which immediataly calls vsc_tp_intr_disable()
afterwards.
2. vsc_tp_shutdown() which immediately calls free_irq() afterwards.
So neither actually wants the interrupt to be enabled after resetting
the chip and having the interrupt enabled for a short time afer
the reset is undesirable.
Drop the enable_irq() call from vsc_tp_reset(), so that the interrupt
is left disabled after vsc_tp_reset().
Link: https://github.com/intel/ivsc-driver/issues/51
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241106220102.40549-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull char/misc and other driver subsystem updates from Greg KH:
"Here is the big set of char/misc and a number of other driver
subsystem updates for 6.9-rc1. Included in here are:
- IIO driver updates, loads of new ones and evolution of existing ones
- coresight driver updates
- const cleanups for many driver subsystems
- speakup driver additions
- platform remove callback void cleanups
- mei driver updates
- mhi driver updates
- cdx driver updates for MSI interrupt handling
- nvmem driver updates
- other smaller driver updates and cleanups, full details in the
shortlog
All of these have been in linux-next for a long time with no reported
issue, other than a build warning for the speakup driver"
The build warning hits clang and is a gcc (and C23) extension, and is
fixed up in the merge.
Link: https://lore.kernel.org/all/20240321134831.GA2762840@dev-arch.thelio-3990X/
* tag 'char-misc-6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (279 commits)
binder: remove redundant variable page_addr
uio_dmem_genirq: UIO_MEM_DMA_COHERENT conversion
uio_pruss: UIO_MEM_DMA_COHERENT conversion
cnic,bnx2,bnx2x: use UIO_MEM_DMA_COHERENT
uio: introduce UIO_MEM_DMA_COHERENT type
cdx: add MSI support for CDX bus
pps: use cflags-y instead of EXTRA_CFLAGS
speakup: Add /dev/synthu device
speakup: Fix 8bit characters from direct synth
parport: sunbpp: Convert to platform remove callback returning void
parport: amiga: Convert to platform remove callback returning void
char: xillybus: Convert to platform remove callback returning void
vmw_balloon: change maintainership
MAINTAINERS: change the maintainer for hpilo driver
char: xilinx_hwicap: Fix NULL vs IS_ERR() bug
hpet: remove hpets::hp_clocksource
platform: goldfish: move the separate 'default' propery for CONFIG_GOLDFISH
char: xilinx_hwicap: drop casting to void in dev_set_drvdata
greybus: move is_gb_* functions out of greybus.h
greybus: Remove usage of the deprecated ida_simple_xx() API
...
The Intel visual sensing controller (IVSC) device is designed to control
the camera sharing between host IPU for media usage and IVSC for context
sensing (face detection).
IVSC is exposed to HOST as an SPI device and the message protocol over
the SPI BUS for communicating with the IVSC device is implemented. This
is the backend of mei framework for IVSC device, which usually handles
the hardware data transfer. The mei_csi and mei_ace are the clients of
IVSC mei framework.
The firmware downloading for the IVSC device is implemented as well.
Signed-off-by: Wentong Wu <wentong.wu@intel.com>
Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Tested-by: Hao Yao <hao.yao@intel.com>
Acked-by: Tomas Winkler <tomas.winkler@intel.com>
Link: https://lore.kernel.org/r/1701651344-20723-2-git-send-email-wentong.wu@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
