summaryrefslogtreecommitdiff
path: root/drivers/misc/mei
AgeCommit message (Collapse)Author
2026-04-06mei: me: add nova lake point H DIDAlexander Usyskin
Add Nova Lake H device id. Cc: stable <stable@kernel.org> Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260405141758.1634556-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-06mei: lb: add late binding version 2Alexander Usyskin
The second Late Binding version allows to send payload bigger than client MTU by splitting it to chunks and uses separate firmware client for transfer. The component interface is unchanged and driver doing all splitting. Only one Late Binding version is supported by firmware. When Late binding version 2 is supported, the new client is advertised by firmware and existing MKHI will have version 2. This helps driver to select the right mode of work. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260405112326.1535208-3-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-06mei: bus: add mei_cldev_uuidAlexander Usyskin
Add mei_cldev_uuid API on mei bus to allow client to query what UUID it bound to. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260405112326.1535208-2-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-06Merge tag 'v7.0-rc7' into char-misc-nextGreg Kroah-Hartman
We need the char/misc/iio/comedi fixes in here as well for testing Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: csc: wake device while reading firmware statusAlexander Usyskin
The CSC has firmware status registers in MMIO and they may be unaccessible while device is suspended. Wake device while reading firmware status via sysfs. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-8-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: csc: support controller with separate PCI deviceAlexander Usyskin
Intel PCI driver for chassis controller embedded in Intel graphics devices. An MEI device here called CSC can be embedded in discrete Intel graphics devices having separate PCI device, to support a range of chassis tasks such as graphics card firmware update and security tasks. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-7-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: convert PCI error to common errnoAlexander Usyskin
Ensure that callers receive only < 0 return value on error. Convert PCI error returned by pci_read_config_dword() to common errno before returning from function. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-6-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: trace: print return value of pci_cfg_readAlexander Usyskin
Extend debug capabilities. Add return value print in the trace_mei_pci_cfg_read(). Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-5-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: me: move trace into firmware status readAlexander Usyskin
Move register trace near it actual read in the firmware status callback and make it adhere to the actual read type. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-4-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: fix idle print specifiersAlexander Usyskin
%01d is equal to %d, simplify the format. Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-3-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-04-02mei: me: use PCI_DEVICE_DATA macroAlexander Usyskin
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 <andriy.shevchenko@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260201094358.1440593-2-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-31misc/mei: INTEL_MEI should depend on X86 or DRM_XEGeert Uytterhoeven
The Intel Management Engine Interface is only present on x86 platforms and Intel Xe graphics cards. Hence add a dependency on X86 or DRM_XE, to prevent asking the user about this driver when configuring a kernel for a non-x86 architecture and without Xe graphics support. Fixes: 25f9b0d35155 ("misc/mei: Allow building Intel ME interface on non-x86") Cc: stable <stable@kernel.org> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/8e2646fb71b148b3d38beb13f19b14e3634a1e1a.1769541024.git.geert+renesas@glider.be Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-03-31mei: me: reduce the scope on unexpected resetAlexander Usyskin
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) <rafael@kernel.org> Reported-by: Todd Brandt <todd.e.brandt@linux.intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221023 Tested-by: Todd Brandt <todd.e.brandt@linux.intel.com> Fixes: 2cedb296988c ("mei: me: trigger link reset if hw ready is unexpected") Cc: stable <stable@kernel.org> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260330083830.536056-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-02-21Convert more 'alloc_obj' cases to default GFP_KERNEL argumentsLinus Torvalds
This converts some of the visually simpler cases that have been split over multiple lines. I only did the ones that are easy to verify the resulting diff by having just that final GFP_KERNEL argument on the next line. Somebody should probably do a proper coccinelle script for this, but for me the trivial script actually resulted in an assertion failure in the middle of the script. I probably had made it a bit _too_ trivial. So after fighting that far a while I decided to just do some of the syntactically simpler cases with variations of the previous 'sed' scripts. The more syntactically complex multi-line cases would mostly really want whitespace cleanup anyway. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21Convert 'alloc_obj' family to use the new default GFP_KERNEL argumentLinus Torvalds
This was done entirely with mindless brute force, using git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' | xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/' to convert the new alloc_obj() users that had a simple GFP_KERNEL argument to just drop that argument. Note that due to the extreme simplicity of the scripting, any slightly more complex cases spread over multiple lines would not be triggered: they definitely exist, but this covers the vast bulk of the cases, and the resulting diff is also then easier to check automatically. For the same reason the 'flex' versions will be done as a separate conversion. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2026-02-21treewide: Replace kmalloc with kmalloc_obj for non-scalar typesKees Cook
This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook <kees@kernel.org>
2026-01-26Merge 6.19-rc7 into char-misc-nextGreg Kroah-Hartman
We need the char/misc/iio fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-16mei: trace: treat reg parameter as stringAlexander Usyskin
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 <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20260111145125.1754912-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-16misc/mei: gsc_proxy: add dependency on Xe driverSimon Richter
This driver is useful if at least one DRM driver registers an auxiliary device for the ME interface. With the addition of Xe, this is no longer just i915. Cc: Usyskin, Alexander <alexander.usyskin@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Link: https://patch.msgid.link/20260107182615.488194-5-Simon.Richter@hogyros.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-16misc/mei: Allow building standalone for compile testingSimon Richter
While this is not a particularly useful configuration, the MEI code should compile even when no drivers for a GPU containing a management engine are built. Cc: Usyskin, Alexander <alexander.usyskin@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Link: https://patch.msgid.link/20260107182615.488194-4-Simon.Richter@hogyros.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-16misc/mei: Decouple ME interfaces from GPU driversSimon Richter
These are enumerated via an auxiliary bus, so there is no functional dependency between these drivers, therefore allow compiling MEI as builtin even when i915/xe are built as modules. Cc: Usyskin, Alexander <alexander.usyskin@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Link: https://patch.msgid.link/20260107182615.488194-3-Simon.Richter@hogyros.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2026-01-16misc/mei: Allow building Intel ME interface on non-x86Simon Richter
The xe driver supports dGPUs which can be plugged into non-x86 machines, and exposes a MEI GSC interface, so this driver is no longer x86 only. Cc: Usyskin, Alexander <alexander.usyskin@intel.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Simon Richter <Simon.Richter@hogyros.de> Link: https://patch.msgid.link/20260107182615.488194-2-Simon.Richter@hogyros.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-29mei: me: add nova lake point S DIDAlexander Usyskin
Add Nova Lake S device id. Cc: stable <stable@kernel.org> Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20251215105915.1672659-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-06Merge tag 'char-misc-6.19-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc/IIO driver updates from Greg KH: "Here is the big set of char/misc/iio driver updates for 6.19-rc1. Lots of stuff in here including: - lots of IIO driver updates, cleanups, and additions - large interconnect driver changes as they get converted over to a dynamic system of ids - coresight driver updates - mwave driver updates - binder driver updates and changes - comedi driver fixes now that the fuzzers are being set loose on them - nvmem driver updates - new uio driver addition - lots of other small char/misc driver updates, full details in the shortlog All of these have been in linux-next for a while now" * tag 'char-misc-6.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (304 commits) char: applicom: fix NULL pointer dereference in ac_ioctl hangcheck-timer: fix coding style spacing hangcheck-timer: Replace %Ld with %lld hangcheck-timer: replace printk(KERN_CRIT) with pr_crit uio: Add SVA support for PCI devices via uio_pci_generic_sva.c dt-bindings: slimbus: fix warning from example intel_th: Fix error handling in intel_th_output_open misc: rp1: Fix an error handling path in rp1_probe() char: xillybus: add WQ_UNBOUND to alloc_workqueue users misc: bh1770glc: use pm_runtime_resume_and_get() in power_state_store misc: cb710: Fix a NULL vs IS_ERR() check in probe() mux: mmio: Add suspend and resume support virt: acrn: split acrn_mmio_dev_res out of acrn_mmiodev greybus: gb-beagleplay: Fix timeout handling in bootloader functions greybus: add WQ_PERCPU to alloc_workqueue users char/mwave: drop typedefs char/mwave: drop printk wrapper char/mwave: remove printk tracing char/mwave: remove unneeded fops char/mwave: remove MWAVE_FUTZ_WITH_OTHER_DEVICES ifdeffery ...
2025-11-26mei: Fix error handling in mei_registerMa Ke
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 <stable@kernel.org> Fixes: 7704e6be4ed2 ("mei: hook mei_device on class device") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Acked-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20251104020133.5017-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-26mei: gsc: add dependency on Xe driverJunxiao Chang
INTEL_MEI_GSC depends on either i915 or Xe and can be present when either of above is present. Cc: stable <stable@kernel.org> Fixes: 87a4c85d3a3e ("drm/xe/gsc: add gsc device support") Tested-by: Baoli Zhang <baoli.zhang@intel.com> Signed-off-by: Junxiao Chang <junxiao.chang@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20251109153533.3179787-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-26mei: Remove redundant pm_runtime_mark_last_busy() callsSakari Ailus
pm_runtime_put_autosuspend(), pm_runtime_put_sync_autosuspend(), pm_runtime_autosuspend() and pm_request_autosuspend() now include a call to pm_runtime_mark_last_busy(). Remove the now-reduntant explicit call to pm_runtime_mark_last_busy(). Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Acked-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20251027114118.390775-1-sakari.ailus@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-11-03mei: fix error flow in probeAlexander Usyskin
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] <TASK> [ 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] </TASK> Tested-by: Guenter Roeck <groeck@google.com> Reported-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Closes: https://lore.kernel.org/lkml/aQbYAXPADqfiXUYO@mail-itl/ Reported-by: Guenter Roeck <linux@roeck-us.net> 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 <alexander.usyskin@intel.com> Tested-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Link: https://patch.msgid.link/20251102180836.1203314-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-22mei: txe: fix initialization orderAlexander Usyskin
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 <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20251019073659.2646791-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-22mei: late_bind: Fix -Wincompatible-function-pointer-types-strictNathan Chancellor
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 <nathan@kernel.org> Link: https://patch.msgid.link/20250920-drm-xe-fix-wifpts-v1-1-c89b5357c7ba@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-22mei: me: add wildcat lake P DIDAlexander Usyskin
Add Wildcat Lake P device id. Cc: stable@vger.kernel.org Co-developed-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Tomas Winkler <tomasw@gmail.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://patch.msgid.link/20251016125912.2146136-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-10-04Merge tag 'char-misc-6.18-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull Char/Misc/IIO/Binder updates from Greg KH: "Here is the big set of char/misc/iio and other driver subsystem changes for 6.18-rc1. Loads of different stuff in here, it was a busy development cycle in lots of different subsystems, with over 27k new lines added to the tree. Included in here are: - IIO updates including new drivers, reworking of existing apis, and other goodness in the sensor subsystems - MEI driver updates and additions - NVMEM driver updates - slimbus removal for an unused driver and some other minor updates - coresight driver updates and additions - MHI driver updates - comedi driver updates and fixes - extcon driver updates - interconnect driver additions - eeprom driver updates and fixes - minor UIO driver updates - tiny W1 driver updates But the majority of new code is in the rust bindings and additions, which includes: - misc driver rust binding updates for read/write support, we can now write "normal" misc drivers in rust fully, and the sample driver shows how this can be done. - Initial framework for USB driver rust bindings, which are disabled for now in the build, due to limited support, but coming in through this tree due to dependencies on other rust binding changes that were in here. I'll be enabling these back on in the build in the usb.git tree after -rc1 is out so that developers can continue to work on these in linux-next over the next development cycle. - Android Binder driver implemented in Rust. This is the big one, and was driving a huge majority of the rust binding work over the past years. Right now there are two binder drivers in the kernel, selected only at build time as to which one to use as binder wants to be included in the system at boot time. The binder C maintainers all agreed on this, as eventually, they want the C code to be removed from the tree, but it will take a few releases to get there while both are maintained to ensure that the rust implementation is fully stable and compliant with the existing userspace apis. All of these have been in linux-next for a while" * tag 'char-misc-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (320 commits) rust: usb: keep usb::Device private for now rust: usb: don't retain device context for the interface parent USB: disable rust bindings from the build for now samples: rust: add a USB driver sample rust: usb: add basic USB abstractions coresight: Add label sysfs node support dt-bindings: arm: Add label in the coresight components coresight: tnoc: add new AMBA ID to support Trace Noc V2 coresight: Fix incorrect handling for return value of devm_kzalloc coresight: tpda: fix the logic to setup the element size coresight: trbe: Return NULL pointer for allocation failures coresight: Refactor runtime PM coresight: Make clock sequence consistent coresight: Refactor driver data allocation coresight: Consolidate clock enabling coresight: Avoid enable programming clock duplicately coresight: Appropriately disable trace bus clocks coresight: Appropriately disable programming clocks coresight: etm4x: Support atclk coresight: catu: Support atclk ...
2025-09-18mei: late_bind: add late binding component driverAlexander Usyskin
Introduce a new MEI client driver to support Late Binding firmware upload/update for Intel discrete graphics platforms. Late Binding is a runtime firmware upload/update mechanism that allows payloads, such as fan control and voltage regulator, to be securely delivered and applied without requiring SPI flash updates or system reboots. This driver enables the Xe graphics driver and other user-space tools to push such firmware blobs to the authentication firmware via the MEI interface. The driver handles authentication, versioning, and communication with the authentication firmware, which in turn coordinates with the PUnit/PCODE to apply the payload. This is a foundational component for enabling dynamic, secure, and re-entrant configuration updates on platforms like Battlemage. Cc: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250905154953.3974335-3-badal.nilawar@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-18mei: bus: add mei_cldev_mtu interfaceAlexander Usyskin
Add a new helper function that allows MEI client drivers to query the maximum transmission unit (MTU) for a connected MEI client. This is useful for clients that need to transmit large payloads, such as firmware blobs, allowing them to determine the maximum message size that can be safely sent before starting transmission and size of the buffer to allocate when receiving data. Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250905154953.3974335-2-badal.nilawar@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2025-09-18Merge patch series "mei: connect to card in D3cold"Greg Kroah-Hartman
Alexander Usyskin <alexander.usyskin@intel.com> says: When discrete graphic card enters D3cold th CSC engine is powered down. On wakeup from the D3cold full HECI link reset is required. The driver should detect that firmware requests link reset and initiate the link reset flow. In the usual flow the connect IOCTL will trigger the wake from D3cold and corresponding link reset. The MEI driver invalidates all open handles on link reset including the one that triggered the wake rendering this connection unusable. To break this loop make connect detect that it is interrupted by link reset and retry connect attempt after reset was completed. Link: https://lore.kernel.org/r/20250918130435.3327400-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-18mei: gsc: demote unexpected reset printAlexander Usyskin
Discrete graphic card can go to D3cold. On the exit from D3cold the link reset is performed. Driver did not expect such link reset and print warning. Print debug message for unexpected reset in discrete graphic case and remove infrastructure to print warning is some cases. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250918130435.3327400-6-alexander.usyskin@intel.com
2025-09-18mei: bus: demote error on connectAlexander Usyskin
There are flows, like exit from D3cold where connect via bus can fail. Demote error print to debug level to unclutter dmesg. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250918130435.3327400-5-alexander.usyskin@intel.com
2025-09-18mei: retry connect if interrupted by link resetAlexander Usyskin
When device is in D3cold the connect message will wake device and cause link reset. Link reset flow cleans all queues and wakes all waiters. Retry the connect flow if connect is failed and link reset is detected. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250918130435.3327400-4-alexander.usyskin@intel.com
2025-09-18mei: make a local copy of client uuid in connectAlexander Usyskin
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 <alexander.usyskin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250918130435.3327400-3-alexander.usyskin@intel.com
2025-09-18mei: me: trigger link reset if hw ready is unexpectedAlexander Usyskin
Driver can receive HW not ready interrupt unexpectedly. E.g. for cards that go donwn to D3cold. Trigger link reset in this case to synchronize driver and firmware state. No need to do that sync if driver is going down or interrupt is received before driver started initial link reset sequence. Introduce UNINITIALIZED device state to allow interrupt handler to ignore interrupts before first init. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20250918130435.3327400-2-alexander.usyskin@intel.com
2025-09-18mei: gsc: fix remove operations orderAlexander Usyskin
The mei disconnect should be the last operation in remove flow. Otherwise the device is used after destruction. Fix minor free flow that happens after device destruction too. The fault leads to the following oops in Intel Gfx CI: <4>[ 267.871331] Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#1] SMP NOPTI ... <4>[ 267.871410] RIP: 0010:mei_gsc_remove+0x44/0x90 [mei_gsc] ... <4>[ 267.871555] Call Trace: <4>[ 267.871562] <TASK> <4>[ 267.871570] auxiliary_bus_remove+0x1b/0x30 <4>[ 267.871589] device_remove+0x43/0x80 <4>[ 267.871604] device_release_driver_internal+0x215/0x280 <4>[ 267.871619] device_release_driver+0x12/0x20 <4>[ 267.871630] bus_remove_device+0xdc/0x150 <4>[ 267.871645] device_del+0x15f/0x3b0 <4>[ 267.871656] ? bus_unregister_notifier+0x37/0x50 <4>[ 267.871672] gsc_destroy_one.isra.0+0x44/0x210 [i915] <4>[ 267.872295] intel_gsc_fini+0x28/0x50 [i915] <4>[ 267.872860] intel_gt_driver_unregister+0x2c/0x80 [i915] <4>[ 267.873300] i915_driver_remove+0x6e/0x150 [i915] <4>[ 267.873694] i915_pci_remove+0x1e/0x40 [i915] <4>[ 267.874095] pci_device_remove+0x3e/0xb0 <4>[ 267.874111] device_remove+0x43/0x80 <4>[ 267.874126] device_release_driver_internal+0x215/0x280 <4>[ 267.874137] ? bus_find_device+0xa5/0xe0 <4>[ 267.874153] device_driver_detach+0x14/0x20 <4>[ 267.874164] unbind_store+0xac/0xc0 <4>[ 267.874178] drv_attr_store+0x21/0x50 <4>[ 267.874190] sysfs_kf_write+0x4a/0x80 <4>[ 267.874204] kernfs_fop_write_iter+0x188/0x240 <4>[ 267.874222] vfs_write+0x283/0x540 <4>[ 267.874241] ksys_write+0x6f/0xf0 <4>[ 267.874253] __x64_sys_write+0x19/0x30 <4>[ 267.874264] x64_sys_call+0x79/0x26a0 <4>[ 267.874277] do_syscall_64+0x93/0xd50 <4>[ 267.874291] ? do_syscall_64+0x1a2/0xd50 <4>[ 267.874301] ? do_syscall_64+0x1a2/0xd50 <4>[ 267.874313] ? do_syscall_64+0x1a2/0xd50 <4>[ 267.874324] ? clear_bhb_loop+0x30/0x80 <4>[ 267.874336] ? clear_bhb_loop+0x30/0x80 <4>[ 267.874349] entry_SYSCALL_64_after_hwframe+0x76/0x7e Fixes: 7704e6be4ed2 ("mei: hook mei_device on class device") Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250915124554.2263330-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-09-06mei: hook mei_device on class deviceAlexander Usyskin
mei_device lifetime was managed by devm procedure of parent device. But such memory is freed on device_del. Mei_device object is used by client object that may be alive after parent device is removed. It may lead to use-after-free if discrete graphics driver unloads mei_gsc auxiliary device while user-space holds open handle to mei character device. Connect mei_device structure lifteme to mei class device lifetime by adding mei_device free to class device remove callback. Move exising parent device pointer to separate field in mei_device to avoid misuse. Allocate character device dynamically and allow to control its own lifetime as it may outlive mei_device structure while character device closes after parent device is removed from the system. Leave power management on parent device as we overwrite pci runtime pm procedure and user-space is expecting it there. Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14201 Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250826125617.1166546-1-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-19mei: more prints with client prefixAlexander Usyskin
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 <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250717141112.1696482-3-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-19mei: bus: use cldev in printsAlexander Usyskin
For unifomity, print using client device on bus where possible. Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com> Link: https://lore.kernel.org/r/20250717141112.1696482-2-alexander.usyskin@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24mei: bus: Check for still connected devices in mei_cl_bus_dev_release()Hans de Goede
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 <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-11-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24mei: vsc: Fix "BUG: Invalid wait context" lockdep errorHans de Goede
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: <IRQ> ... __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) ... </IRQ> 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 <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-10-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24mei: vsc: Run event callback from a workqueueHans de Goede
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 <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-9-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24mei: vsc: Unset the event callback on remove and probe errorsHans de Goede
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 <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-8-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24mei: vsc: Event notifier fixesHans de Goede
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 <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-7-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-24mei: vsc: Destroy mutex after freeing the IRQHans de Goede
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 <hansg@kernel.org> Link: https://lore.kernel.org/r/20250623085052.12347-6-hansg@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>