kernel/linux.git/drivers/misc/mei, branch v6.18.34

mei: me: add nova lake point H DID

2026-05-07T04:12:00+00:00

[ Upstream commit a5a1804332afc7035d5c5b880548262e81d796bc ] Add Nova Lake H device id. Cc: stable Co-developed-by: Tomas Winkler Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260405141758.1634556-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mei: me: use PCI_DEVICE_DATA macro

2026-05-07T04:12:00+00:00

[ Upstream commit 9e7a2409ecf4d411b7cc91615b08f6a7576f0aaa ] Drop old local MEI_PCI_DEVICE macro and use common PCI_DEVICE_DATA instead. Update defines to adhere to current naming convention. Suggested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260201094358.1440593-2-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: a5a1804332af ("mei: me: add nova lake point H DID") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

mei: me: reduce the scope on unexpected reset

2026-04-11T12:26:41+00:00

commit 8c27b1bce059a11a8d3c8682984e13866f0714af upstream. After commit 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected") some devices started to show long resume times (5-7 seconds). This happens as mei falsely detects unready hardware, starts parallel link reset flow and triggers link reset timeouts in the resume callback. Address it by performing detection of unready hardware only when driver is in the MEI_DEV_ENABLED state instead of blacklisting states as done in the original patch. This eliminates active waitqueue check as in MEI_DEV_ENABLED state there will be no active waitqueue. Reviewed-by: Rafael J. Wysocki (Intel) Reported-by: Todd Brandt Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221023 Tested-by: Todd Brandt Fixes: 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected") Cc: stable Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260330083830.536056-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

mei: trace: treat reg parameter as string

2026-01-30T09:32:25+00:00

commit 06d5a7afe1d0b47102936d8fba568572c2b4b941 upstream. The commit afd2627f727b ("tracing: Check "%s" dereference via the field and not the TP_printk format") forbids to emit event with a plain char* without a wrapper. The reg parameter always passed as static string and wrapper is not strictly required, contrary to dev parameter. Use the string wrapper anyway to check sanity of the reg parameters, store it value independently and prevent internal kernel data leaks. Since some code refactoring has taken place, explicit backporting may be needed for kernels older than 6.10. Cc: stable@vger.kernel.org # v6.11+ Fixes: a0a927d06d79 ("mei: me: add io register tracing") Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20260111145125.1754912-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: me: add nova lake point S DID

2026-01-17T15:35:11+00:00

commit 420f423defcf6d0af2263d38da870ca4a20c0990 upstream. Add Nova Lake S device id. Cc: stable Co-developed-by: Tomas Winkler Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20251215105915.1672659-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: gsc: add dependency on Xe driver

2026-01-02T11:57:15+00:00

commit 5d92c3b41f0bddfa416130c6e1b424414f3d2acf upstream. INTEL_MEI_GSC depends on either i915 or Xe and can be present when either of above is present. Cc: stable Fixes: 87a4c85d3a3e ("drm/xe/gsc: add gsc device support") Tested-by: Baoli Zhang Signed-off-by: Junxiao Chang Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20251109153533.3179787-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: Fix error handling in mei_register

2026-01-02T11:57:15+00:00

commit a6dab2f61d23c1eb32f1d08fa7b4919a2478950b upstream. mei_register() fails to release the device reference in error paths after device_initialize(). During normal device registration, the reference is properly handled through mei_deregister() which calls device_destroy(). However, in error handling paths (such as cdev_alloc failure, cdev_add failure, etc.), missing put_device() calls cause reference count leaks, preventing the device's release function (mei_device_release) from being called and resulting in memory leaks of mei_device. Found by code review. Cc: stable Fixes: 7704e6be4ed2 ("mei: hook mei_device on class device") Signed-off-by: Ma Ke Acked-by: Alexander Usyskin Link: https://patch.msgid.link/20251104020133.5017-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman

mei: fix error flow in probe

2025-11-03T01:02:04+00:00

Dismantle class device last in probe error flow to avoid accessing freed memory like: [ 87.926774] WARNING: CPU: 9 PID: 518 at kernel/workqueue.c:4234 __flush_work+0x340/0x390 ... [ 87.926912] Workqueue: async async_run_entry_fn [ 87.926918] RIP: e030:__flush_work+0x340/0x390 [ 87.926923] Code: 26 9d 05 00 65 48 8b 15 26 3c ca 02 48 85 db 48 8b 04 24 48 89 54 24 58 0f 85 de fe ff ff e9 f6 fd ff ff 0f 0b e9 77 ff ff ff <0f> 0b e9 70 ff ff ff 0f 0b e9 19 ff ff ff e8 7d 8b 0e 01 48 89 de [ 87.926931] RSP: e02b:ffffc900412ebc00 EFLAGS: 00010246 [ 87.926936] RAX: 0000000000000000 RBX: ffff888103e55090 RCX: 0000000000000000 [ 87.926941] RDX: 000fffffffe00000 RSI: 0000000000000001 RDI: ffffc900412ebc60 [ 87.926945] RBP: ffff888103e55090 R08: ffffffffc1266ec8 R09: ffff8881109076e8 [ 87.926949] R10: 0000000080040003 R11: 0000000000000000 R12: ffff888103e54000 [ 87.926953] R13: ffffc900412ebc18 R14: 0000000000000001 R15: 0000000000000000 [ 87.926962] FS: 0000000000000000(0000) GS:ffff888233238000(0000) knlGS:0000000000000000 [ 87.926967] CS: e030 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 87.926971] CR2: 00007e7923b32708 CR3: 00000001088df000 CR4: 0000000000050660 [ 87.926977] Call Trace: [ 87.926981] [ 87.926987] ? __call_rcu_common.constprop.0+0x11e/0x310 [ 87.926993] cancel_work_sync+0x5e/0x80 [ 87.926999] mei_cancel_work+0x19/0x40 [mei] [ 87.927051] mei_me_probe+0x273/0x2b0 [mei_me] [ 87.927060] local_pci_probe+0x45/0x90 [ 87.927066] pci_call_probe+0x5b/0x180 [ 87.927070] pci_device_probe+0x95/0x140 [ 87.927074] ? driver_sysfs_add+0x57/0xc0 [ 87.927079] really_probe+0xde/0x340 [ 87.927083] ? pm_runtime_barrier+0x54/0x90 [ 87.927087] __driver_probe_device+0x78/0x110 [ 87.927092] driver_probe_device+0x1f/0xa0 [ 87.927095] __driver_attach_async_helper+0x5e/0xe0 [ 87.927100] async_run_entry_fn+0x34/0x130 [ 87.927104] process_one_work+0x18d/0x340 [ 87.927108] worker_thread+0x256/0x3a0 [ 87.927111] ? __pfx_worker_thread+0x10/0x10 [ 87.927115] kthread+0xfc/0x240 [ 87.927120] ? __pfx_kthread+0x10/0x10 [ 87.927124] ? __pfx_kthread+0x10/0x10 [ 87.927127] ret_from_fork+0xf5/0x110 [ 87.927132] ? __pfx_kthread+0x10/0x10 [ 87.927136] ret_from_fork_asm+0x1a/0x30 [ 87.927141] Tested-by: Guenter Roeck Reported-by: Marek Marczykowski-Górecki Closes: https://lore.kernel.org/lkml/aQbYAXPADqfiXUYO@mail-itl/ Reported-by: Guenter Roeck Closes: https://lore.kernel.org/lkml/8deef7c4-ac75-4db8-91b7-02cf0e39e371@roeck-us.net/ Fixes: 7704e6be4ed2 ("mei: hook mei_device on class device") Signed-off-by: Alexander Usyskin Tested-by: Marek Marczykowski-Górecki Link: https://patch.msgid.link/20251102180836.1203314-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: txe: fix initialization order

2025-10-22T06:03:57+00:00

The mei_register() should move before the mei_start() for hook on class device to work. Same change was implemented in mei-me, missed from mei-txe. Fixes: 7704e6be4ed2 ("mei: hook mei_device on class device") Signed-off-by: Alexander Usyskin Link: https://patch.msgid.link/20251019073659.2646791-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman

mei: late_bind: Fix -Wincompatible-function-pointer-types-strict

2025-10-22T06:03:32+00:00

When building with -Wincompatible-function-pointer-types-strict, a warning designed to catch kernel control flow integrity (kCFI) issues at build time, there is an instance in the new mei late binding code originating from the type parameter of mei_lb_push_payload(): drivers/misc/mei/mei_lb.c:211:18: error: incompatible function pointer types initializing 'int (*)(struct device *, u32, u32, const void *, size_t)' (aka 'int (*)(struct device *, unsigned int, unsigned int, const void *, unsigned long)') with an expression of type 'int (struct device *, enum intel_lb_type, u32, const void *, size_t)' (aka 'int (struct device *, enum intel_lb_type, unsigned int, const void *, unsigned long)') [-Werror,-Wincompatible-function-pointer-types-strict] 211 | .push_payload = mei_lb_push_payload, | ^~~~~~~~~~~~~~~~~~~ While 'unsigned int' and 'enum intel_lb_type' are ABI compatible, hence no regular warning from -Wincompatible-function-pointer-types, the mismatch will trigger a kCFI violation when mei_lb_push_payload() is called indirectly. Update the type parameter of mei_lb_push_payload() to be 'u32' to match the prototype in 'struct intel_lb_component_ops', clearing up the warning and kCFI violation. Fixes: 741eeabb7c78 ("mei: late_bind: add late binding component driver") Signed-off-by: Nathan Chancellor Link: https://patch.msgid.link/20250920-drm-xe-fix-wifpts-v1-1-c89b5357c7ba@kernel.org Signed-off-by: Greg Kroah-Hartman