kernel/git/stable/linux-stable.git/drivers/misc/mei, branch linux-6.17.y

mei: make a local copy of client uuid in connect

2025-11-13T20:37:27+00:00

[ Upstream commit bb29fc32ae56393269d8fe775159fd59e45682d1 ] Connect ioctl has the same memory for in and out parameters. Copy in parameter (client uuid) to the local stack to avoid it be overwritten by out parameters fill. Signed-off-by: Alexander Usyskin Signed-off-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20250918130435.3327400-3-alexander.usyskin@intel.com Signed-off-by: Sasha Levin

mei: me: add wildcat lake P DID

2025-10-29T13:10:30+00:00

commit 410d6c2ad4d1a88efa0acbb9966693725b564933 upstream. Add Wildcat Lake P device id. Cc: stable@vger.kernel.org Co-developed-by: Tomas Winkler Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20251016125912.2146136-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: more prints with client prefix

2025-07-19T07:57:55+00:00

Use client-aware print macro instead of usual device print in more places to expand debug-ability. The client-aware print macro prefixes the usual device print with current connection endpoints. Signed-off-by: Alexander Usyskin Link: https://lore.kernel.org/r/20250717141112.1696482-3-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: bus: use cldev in prints

2025-07-19T07:57:53+00:00

For unifomity, print using client device on bus where possible. Signed-off-by: Alexander Usyskin Link: https://lore.kernel.org/r/20250717141112.1696482-2-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: bus: Check for still connected devices in mei_cl_bus_dev_release()

2025-06-24T15:39:02+00:00

mei_cl_bus_dev_release() also frees the mei-client (struct mei_cl) belonging to the device being released. If there are bugs like the just fixed bug in the ACE/CSI2 mei drivers, the mei-client being freed might still be part of the mei_device's file_list and iterating over this list after the freeing will then trigger a use-afer-free bug. Add a check to mei_cl_bus_dev_release() to make sure that the to-be-freed mei-client is not on the mei_device's file_list. Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250623085052.12347-11-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman

mei: vsc: Fix "BUG: Invalid wait context" lockdep error

2025-06-24T15:39:02+00:00

Kernels build with CONFIG_PROVE_RAW_LOCK_NESTING report the following tp-vsc lockdep error: ============================= [ BUG: Invalid wait context ] ... swapper/10/0 is trying to lock: ffff88819c271888 (&tp->xfer_wait){....}-{3:3}, at: __wake_up (kernel/sched/wait.c:106 kernel/sched/wait.c:127) ... Call Trace: ... __raw_spin_lock_irqsave (./include/linux/spinlock_api_smp.h:111) __wake_up (kernel/sched/wait.c:106 kernel/sched/wait.c:127) vsc_tp_isr (drivers/misc/mei/vsc-tp.c:110) mei_vsc_hw __handle_irq_event_percpu (kernel/irq/handle.c:158) handle_irq_event (kernel/irq/handle.c:195 kernel/irq/handle.c:210) handle_edge_irq (kernel/irq/chip.c:833) ... The root-cause of this is the IRQF_NO_THREAD flag used by the intel-pinctrl code. Setting IRQF_NO_THREAD requires all interrupt handlers for GPIO ISRs to use raw-spinlocks only since normal spinlocks can sleep in PREEMPT-RT kernels and with IRQF_NO_THREAD the interrupt handlers will always run in an atomic context [1]. vsc_tp_isr() calls wake_up(&tp->xfer_wait), which uses a regular spinlock, breaking the raw-spinlocks only rule for Intel GPIO ISRs. Make vsc_tp_isr() run as threaded ISR instead of as hard ISR to fix this. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Link: https://lore.kernel.org/linux-gpio/18ab52bd-9171-4667-a600-0f52ab7017ac@kernel.org/ [1] Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250623085052.12347-10-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman

mei: vsc: Run event callback from a workqueue

2025-06-24T15:39:02+00:00

The event_notify callback in some cases calls vsc_tp_xfer(), which checks tp->assert_cnt and waits for it through the tp->xfer_wait wait-queue. And tp->assert_cnt is increased and the tp->xfer_wait queue is woken o from the interrupt handler. So the interrupt handler which is running the event callback is waiting for itself to signal that it can continue. This happens to work because the event callback runs from the threaded ISR handler and while that is running the hard ISR handler will still get called a second / third time for further interrupts and it is the hard ISR handler which does the atomic_inc() and wake_up() calls. But having the threaded ISR handler wait for its own interrupt to trigger again is not how a threaded ISR handler is supposed to be used. Move the running of the event callback from a threaded interrupt handler to a workqueue since a threaded ISR should not wait for events from its own interrupt. This is a preparation patch for moving the atomic_inc() and wake_up() calls to the threaded ISR handler, which is necessary to fix a locking issue. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250623085052.12347-9-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman

mei: vsc: Unset the event callback on remove and probe errors

2025-06-24T15:39:01+00:00

Make mei_vsc_remove() properly unset the callback to avoid a dead callback sticking around after probe errors or unbinding of the platform driver. Fixes: 386a766c4169 ("mei: Add MEI hardware support for IVSC device") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250623085052.12347-8-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman

mei: vsc: Event notifier fixes

2025-06-24T15:39:01+00:00

vsc_tp_register_event_cb() can race with vsc_tp_thread_isr(), add a mutex to protect against this. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250623085052.12347-7-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman

mei: vsc: Destroy mutex after freeing the IRQ

2025-06-24T15:39:01+00:00

The event_notify callback which runs from vsc_tp_thread_isr may call vsc_tp_xfer() which locks the mutex. So the ISR depends on the mutex. Move the mutex_destroy() call to after free_irq() to ensure that the ISR is not running while the mutex is destroyed. Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device") Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20250623085052.12347-6-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman