linux-stable.git/drivers/usb/core, branch v6.15.2 Linux kernel stable tree usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE 2025-06-10T11:17:10+00:00 Jiayi Li lijiayi@kylinos.cn 2025-05-08T05:59:47+00:00 fa4b47965c331eb6938d70285094156f3b198b2e commit 19f795591947596b5b9efa86fd4b9058e45786e9 upstream. This device exhibits I/O errors during file transfers due to unstable link power management (LPM) behavior. The kernel logs show repeated warm resets and eventual disconnection when LPM is enabled: [ 3467.810740] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0020 [ 3467.810740] usb usb2-port5: do warm reset [ 3467.866444] usb usb2-port5: not warm reset yet, waiting 50ms [ 3467.907407] sd 0:0:0:0: [sda] tag#12 sense submit err -19 [ 3467.994423] usb usb2-port5: status 02c0, change 0001, 10.0 Gb/s [ 3467.994453] usb 2-5: USB disconnect, device number 4 The error -19 (ENODEV) occurs when the device disappears during write operations. Adding USB_QUIRK_NO_LPM disables link power management for this specific device, resolving the stability issues. Signed-off-by: Jiayi Li <lijiayi@kylinos.cn> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20250508055947.764538-1-lijiayi@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 19f795591947596b5b9efa86fd4b9058e45786e9 upstream.

This device exhibits I/O errors during file transfers due to unstable
link power management (LPM) behavior. The kernel logs show repeated
warm resets and eventual disconnection when LPM is enabled:

[ 3467.810740] hub 2-0:1.0: state 7 ports 6 chg 0000 evt 0020
[ 3467.810740] usb usb2-port5: do warm reset
[ 3467.866444] usb usb2-port5: not warm reset yet, waiting 50ms
[ 3467.907407] sd 0:0:0:0: [sda] tag#12 sense submit err -19
[ 3467.994423] usb usb2-port5: status 02c0, change 0001, 10.0 Gb/s
[ 3467.994453] usb 2-5: USB disconnect, device number 4

The error -19 (ENODEV) occurs when the device disappears during write
operations. Adding USB_QUIRK_NO_LPM disables link power management
for this specific device, resolving the stability issues.

Signed-off-by: Jiayi Li <lijiayi@kylinos.cn>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20250508055947.764538-1-lijiayi@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: quirks: Add delay init quirk for SanDisk 3.2Gen1 Flash Drive 2025-04-15T12:31:38+00:00 Miao Li limiao@kylinos.cn 2025-04-14T06:29:35+00:00 37ffdbd695c02189dbf23d6e7d2385e0299587ca The SanDisk 3.2Gen1 Flash Drive, which VID:PID is in 0781:55a3, just like Silicon Motion Flash Drive: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com also needs the DELAY_INIT quirk, or it will randomly work incorrectly (e.g.: lsusb and can't list this device info) when connecting Huawei hisi platforms and doing thousand of reboot test circles. Cc: stable <stable@kernel.org> Signed-off-by: Miao Li <limiao@kylinos.cn> Signed-off-by: Lei Huang <huanglei@kylinos.cn> Link: https://lore.kernel.org/r/20250414062935.159024-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The SanDisk 3.2Gen1 Flash Drive, which VID:PID is in 0781:55a3,
just like Silicon Motion Flash Drive:
https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com
also needs the DELAY_INIT quirk, or it will randomly work incorrectly
(e.g.: lsusb and can't list this device info) when connecting Huawei
hisi platforms and doing thousand of reboot test circles.

Cc: stable <stable@kernel.org>
Signed-off-by: Miao Li <limiao@kylinos.cn>
Signed-off-by: Lei Huang <huanglei@kylinos.cn>
Link: https://lore.kernel.org/r/20250414062935.159024-1-limiao870622@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USB: VLI disk crashes if LPM is used 2025-04-11T14:26:36+00:00 Oliver Neukum oneukum@suse.com 2025-04-08T13:57:46+00:00 e00b39a4f3552c730f1e24c8d62c4a8c6aad4e5d This device needs the NO_LPM quirk. Cc: stable <stable@kernel.org> Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://lore.kernel.org/r/20250408135800.792515-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This device needs the NO_LPM quirk.

Cc: stable <stable@kernel.org>
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20250408135800.792515-1-oneukum@suse.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: quirks: add DELAY_INIT quirk for Silicon Motion Flash Drive 2025-04-11T14:21:36+00:00 Miao Li limiao@kylinos.cn 2025-04-01T02:30:27+00:00 2932b6b547ec36ad2ed60fbf2117c0e46bb7d40a Silicon Motion Flash Drive connects to Huawei hisi platforms and performs a system reboot test for two thousand circles, it will randomly work incorrectly on boot, set DELAY_INIT quirk can workaround this issue. Signed-off-by: Miao Li <limiao@kylinos.cn> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Silicon Motion Flash Drive connects to Huawei hisi platforms and
performs a system reboot test for two thousand circles, it will
randomly work incorrectly on boot, set DELAY_INIT quirk can workaround
this issue.

Signed-off-by: Miao Li <limiao@kylinos.cn>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20250401023027.44894-1-limiao870622@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
treewide: Switch/rename to timer_delete[_sync]() 2025-04-05T08:30:12+00:00 Thomas Gleixner tglx@linutronix.de 2025-04-05T08:17:26+00:00 8fa7292fee5c5240402371ea89ab285ec856c916 timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org> 
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with coccinelle plus manual fixups where necessary.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
usb: core: Don't use %pK through printk 2025-03-14T08:17:29+00:00 Thomas Weißschuh thomas.weissschuh@linutronix.de 2025-03-10T15:38:23+00:00 f4aa6caa8b420bcc0813fccecbc35f43203297df This is a revert of commit 2f964780c03b ("USB: core: replace %p with %pK"). When the formatting was changed from %p to %pK that was a security improvement, as %p would leak raw pointer values to the kernel log. Since commit ad67b74d2469 ("printk: hash addresses printed with %p") the regular %p has been improved to avoid this issue. On the other hand, restricted pointers ("%pK") were never meant to be used through printk(). They can unintentionally still leak raw pointers or acquire sleeping looks in atomic contexts. Switch back to regular %p again. Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://lore.kernel.org/r/20250310-restricted-pointers-usb-v2-1-a7598e2d47d1@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
This is a revert of
commit 2f964780c03b ("USB: core: replace %p with %pK").

When the formatting was changed from %p to %pK that was a security
improvement, as %p would leak raw pointer values to the kernel log.
Since commit ad67b74d2469 ("printk: hash addresses printed with %p")
the regular %p has been improved to avoid this issue.
On the other hand, restricted pointers ("%pK") were never meant to be used
through printk(). They can unintentionally still leak raw pointers or
acquire sleeping looks in atomic contexts.

Switch back to regular %p again.

Link: https://lore.kernel.org/lkml/20250113171731-dc10e3c1-da64-4af0-b767-7c7070468023@linutronix.de/
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Link: https://lore.kernel.org/r/20250310-restricted-pointers-usb-v2-1-a7598e2d47d1@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge v6.14-rc6 into usb-next 2025-03-10T07:16:31+00:00 Greg Kroah-Hartman gregkh@linuxfoundation.org 2025-03-10T07:16:31+00:00 525b139fb4033a9ba5abd6ca3f6a6baa3b2fe3d4 Resolves the merge conflict with: drivers/usb/typec/ucsi/ucsi_acpi.c Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Resolves the merge conflict with:
	drivers/usb/typec/ucsi/ucsi_acpi.c

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: quirks: Add DELAY_INIT and NO_LPM for Prolific Mass Storage Card Reader 2025-03-06T15:50:24+00:00 Miao Li limiao@kylinos.cn 2025-03-04T07:07:57+00:00 ff712188daa3fe3ce7e11e530b4dca3826dae14a When used on Huawei hisi platforms, Prolific Mass Storage Card Reader which the VID:PID is in 067b:2731 might fail to enumerate at boot time and doesn't work well with LPM enabled, combination quirks: USB_QUIRK_DELAY_INIT + USB_QUIRK_NO_LPM fixed the problems. Signed-off-by: Miao Li <limiao@kylinos.cn> Cc: stable <stable@kernel.org> Link: https://lore.kernel.org/r/20250304070757.139473-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
When used on Huawei hisi platforms, Prolific Mass Storage Card Reader
which the VID:PID is in 067b:2731 might fail to enumerate at boot time
and doesn't work well with LPM enabled, combination quirks:
	USB_QUIRK_DELAY_INIT + USB_QUIRK_NO_LPM
fixed the problems.

Signed-off-by: Miao Li <limiao@kylinos.cn>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/20250304070757.139473-1-limiao870622@163.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: core: replace usb_sndaddr0pipe macro with usb_sndctrlpipe 2025-03-03T09:23:19+00:00 Stefan Eichenberger stefan.eichenberger@toradex.com 2025-02-19T08:36:44+00:00 e4b5f415391a56ec6c5f2158bf25d1d3e7936ccc The usb_sndaddr0pipe macro is only used in the hub_set_address function. Replace it with usb_sndctrlpipe which provides the same functionality but would also consider the endpoint device number. If the device has not been initialised, it is safe to use usb_sndctrlpipe in this context because udev->devnum is set to 0. Therefore, this change does not affect behaviour, but reduces code complexity by reusing the existing macro. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/20250219083745.10406-1-eichest@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The usb_sndaddr0pipe macro is only used in the hub_set_address function.
Replace it with usb_sndctrlpipe which provides the same functionality
but would also consider the endpoint device number.

If the device has not been initialised, it is safe to use
usb_sndctrlpipe in this context because udev->devnum is set to 0.
Therefore, this change does not affect behaviour, but reduces code
complexity by reusing the existing macro.

Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250219083745.10406-1-eichest@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
usb: hub: lack of clearing xHC resources 2025-03-03T09:21:07+00:00 Pawel Laszczak pawell@cadence.com 2025-02-28T07:50:25+00:00 2b66ef84d0d2a0ea955b40bd306f5e3abbc5cf9c The xHC resources allocated for USB devices are not released in correct order after resuming in case when while suspend device was reconnected. This issue has been detected during the fallowing scenario: - connect hub HS to root port - connect LS/FS device to hub port - wait for enumeration to finish - force host to suspend - reconnect hub attached to root port - wake host For this scenario during enumeration of USB LS/FS device the Cadence xHC reports completion error code for xHC commands because the xHC resources used for devices has not been properly released. XHCI specification doesn't mention that device can be reset in any order so, we should not treat this issue as Cadence xHC controller bug. Similar as during disconnecting in this case the device resources should be cleared starting form the last usb device in tree toward the root hub. To fix this issue usbcore driver should call hcd->driver->reset_device for all USB devices connected to hub which was reconnected while suspending. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable <stable@kernel.org> Signed-off-by: Pawel Laszczak <pawell@cadence.com> Reviewed-by: Alan Stern <stern@rowland.harvard.edu> Link: https://lore.kernel.org/r/PH7PR07MB953841E38C088678ACDCF6EEDDCC2@PH7PR07MB9538.namprd07.prod.outlook.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
The xHC resources allocated for USB devices are not released in correct
order after resuming in case when while suspend device was reconnected.

This issue has been detected during the fallowing scenario:
- connect hub HS to root port
- connect LS/FS device to hub port
- wait for enumeration to finish
- force host to suspend
- reconnect hub attached to root port
- wake host

For this scenario during enumeration of USB LS/FS device the Cadence xHC
reports completion error code for xHC commands because the xHC resources
used for devices has not been properly released.
XHCI specification doesn't mention that device can be reset in any order
so, we should not treat this issue as Cadence xHC controller bug.
Similar as during disconnecting in this case the device resources should
be cleared starting form the last usb device in tree toward the root hub.
To fix this issue usbcore driver should call hcd->driver->reset_device
for all USB devices connected to hub which was reconnected while
suspending.

Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Pawel Laszczak <pawell@cadence.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/PH7PR07MB953841E38C088678ACDCF6EEDDCC2@PH7PR07MB9538.namprd07.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>