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>
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>
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>
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>
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
...
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>
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>
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>
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
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