kernel/linux.git/drivers/usb/core, branch v7.0-rc7

usb: core: use dedicated spinlock for offload state

2026-04-02T07:43:26+00:00

Replace the coarse USB device lock with a dedicated offload_lock spinlock to reduce contention during offload operations. Use offload_pm_locked to synchronize with PM transitions and replace the legacy offload_at_suspend flag. Optimize usb_offload_get/put by switching from auto-resume/suspend to pm_runtime_get_if_active(). This ensures offload state is only modified when the device is already active, avoiding unnecessary power transitions. Cc: stable Fixes: ef82a4803aab ("xhci: sideband: add api to trace sideband usage") Signed-off-by: Guan-Yu Lin Tested-by: Hailong Liu Acked-by: Mathias Nyman Link: https://patch.msgid.link/20260401123238.3790062-2-guanyulin@google.com Signed-off-by: Greg Kroah-Hartman

USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam

2026-04-02T07:30:44+00:00

The Razer Kiyo Pro (1532:0e05) is a USB 3.0 UVC webcam whose firmware does not handle USB Link Power Management transitions reliably. When LPM is active, the device can enter a state where it fails to respond to control transfers, producing EPIPE (-32) errors on UVC probe control SET_CUR requests. In the worst case, the stalled endpoint triggers an xHCI stop-endpoint command that times out, causing the host controller to be declared dead and every USB device on the bus to be disconnected. This has been reported as Ubuntu Launchpad Bug #2061177. The failure mode is: 1. UVC probe control SET_CUR returns -32 (EPIPE) 2. xHCI host not responding to stop endpoint command 3. xHCI host controller not responding, assume dead 4. All USB devices on the affected xHCI controller disconnect Disabling LPM prevents the firmware from entering the problematic low- power states that precede the stall. This is the same approach used for other webcams with similar firmware issues (e.g., Logitech HD Webcam C270). Cc: stable Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177 Signed-off-by: JP Hein Link: https://patch.msgid.link/20260331003806.212565-2-jp@jphein.com Signed-off-by: Greg Kroah-Hartman

usb: core: phy: avoid double use of 'usb3-phy'

2026-04-02T07:19:31+00:00

Commit 53a2d95df836 ("usb: core: add phy notify connect and disconnect") causes double use of the 'usb3-phy' in certain cases. Since that commit, if a generic PHY named 'usb3-phy' is specified in the device tree, that is getting added to the 'phy_roothub' list of the secondary HCD by the usb_phy_roothub_alloc_usb3_phy() function. However, that PHY is getting added also to the primary HCD's 'phy_roothub' list by usb_phy_roothub_alloc() if there is no generic PHY specified with 'usb2-phy' name. This causes that the usb_add_hcd() function executes each phy operations twice on the 'usb3-phy'. Once when the primary HCD is added, then once again when the secondary HCD is added. The issue affects the Marvell Armada 3700 platform at least, where a custom name is used for the USB2 PHY: $ git grep 'phy-names.*usb3' arch/arm64/boot/dts/marvell/armada-37xx.dtsi | tr '\t' ' ' arch/arm64/boot/dts/marvell/armada-37xx.dtsi: phy-names = "usb3-phy", "usb2-utmi-otg-phy"; Extend the usb_phy_roothub_alloc_usb3_phy() function to skip adding the 'usb3-phy' to the 'phy_roothub' list of the secondary HCD when 'usb2-phy' is not specified in the device tree to avoid the double use. Fixes: 53a2d95df836 ("usb: core: add phy notify connect and disconnect") Cc: stable Signed-off-by: Gabor Juhos Link: https://patch.msgid.link/20260330-usb-avoid-usb3-phy-double-use-v1-1-d2113aecb535@gmail.com Signed-off-by: Greg Kroah-Hartman

usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive

2026-03-30T15:04:28+00:00

Another Silicon Motion flash drive also randomly work incorrectly (lsusb does not list the device) on Huawei hisi platforms during 500 reboot cycles, and the DELAY_INIT quirk fixes this issue. Signed-off-by: Miao Li Cc: stable Link: https://patch.msgid.link/20260319053927.264840-1-limiao870622@163.com Signed-off-by: Greg Kroah-Hartman

usb: hcd: queue wakeup_work to system_freezable_wq workqueue

2026-03-18T15:17:08+00:00

After commit 4fb352df14de ("PM: sleep: Do not flag runtime PM workqueue as freezable"), pm_wq workqueue will be unfreezable during system pm. This brings issue as below: [ 344.255749] ------------[ cut here ]------------ [ 344.277740] URB 000000004aae4ad1 submitted while active [ 344.282996] WARNING: drivers/usb/core/urb.c:379 at usb_submit_urb+0x5a4/0x5e0, CPU#2: kworker/u16:14/964 [ 344.292477] Modules linked in: [ 344.295532] CPU: 2 UID: 0 PID: 964 Comm: kworker/u16:14 Not tainted 7.0.0-rc2-next-20260303-00006-gf03fe0b53b39-dirty #100 PREEMPT [ 344.307341] Hardware name: NXP i.MX943 EVK board (DT) [ 344.312386] Workqueue: async async_run_entry_fn [ 344.316919] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 344.323862] pc : usb_submit_urb+0x5a4/0x5e0 [ 344.328046] lr : usb_submit_urb+0x5a4/0x5e0 [ 344.332217] sp : ffff800083283b30 [ 344.335528] x29: ffff800083283b30 x28: ffff000082631000 x27: 0000000000000000 [ 344.342661] x26: 0000000000000003 x25: 0000000000000c00 x24: 0000000000000000 [ 344.349793] x23: 0000000000000004 x22: 0000000000000010 x21: 0000000000000000 [ 344.356917] x20: 0000000000000002 x19: ffff00008253ce40 x18: ffff000089e4eec0 [ 344.364050] x17: 000000040044ffff x16: 000005d9d87f6289 x15: 0000000000000000 [ 344.371174] x14: ffff000089e4eec0 x13: 6576697463612065 x12: 6c69687720646574 [ 344.378298] x11: 0000000000000058 x10: 0000000000000001 x9 : 0000000000000001 [ 344.385431] x8 : 0000000000000000 x7 : 0000005028dd0800 x6 : 0000000000000002 [ 344.392563] x5 : ffffc48f74e9daf8 x4 : 0000000000000000 x3 : 0000000000000000 [ 344.399696] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000089e4ee40 [ 344.406835] Call trace: [ 344.409280] usb_submit_urb+0x5a4/0x5e0 (P) [ 344.413456] hub_activate+0x268/0x878 [ 344.417116] hub_resume+0x5c/0x10c [ 344.420522] usb_resume_interface.isra.0+0xa8/0x110 [ 344.425393] usb_resume_both+0x10c/0x1e0 [ 344.429310] usb_resume+0x1c/0x70 [ 344.432621] usb_dev_resume+0x14/0x20 [ 344.436278] dpm_run_callback.isra.0+0x38/0xf8 [ 344.440715] device_resume+0xec/0x1e8 [ 344.444373] async_resume+0x20/0x38 [ 344.447848] async_run_entry_fn+0x34/0xe0 [ 344.451852] process_one_work+0x150/0x290 [ 344.455856] worker_thread+0x18c/0x300 [ 344.459600] kthread+0x118/0x124 [ 344.462824] ret_from_fork+0x10/0x20 The reason is if the host controller resume routine xhci_resume() call usb_hcd_resume_root_hub(), wakeup_work will be queued and run immediately. Then usb_autoresume_device() will be called and usb device will exit runtime suspended state (if it was suspended before). For a hub device, hub_resume()/hub_reset_resume() will be called accordingly. After the host controller device system resume is finished, the root hub usb device "usb1" will do system resume too. Then hub_resume() will be called again. Above sequence will cause hub->urb to be submitted twice. To avoid this issue, restore the previous behavior by queuing wakeup_work to system_freezable_wq workqueue. Acked-by: Alan Stern Fixes: 4fb352df14de ("PM: sleep: Do not flag runtime PM workqueue as freezable") Cc: stable Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260316094811.1559471-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman

USB: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed

2026-03-13T17:19:07+00:00

Add USB_QUIRK_NO_BOS for ezcap401 capture card, without it dmesg will show "unable to get BOS descriptor or descriptor too short" and "unable to read config index 0 descriptor/start: -71" errors and device will not able to work at full speed at 10gbs Signed-off-by: Vyacheslav Vahnenko Cc: stable Link: https://patch.msgid.link/20260313123638.20481-1-vahnenko2003@gmail.com Signed-off-by: Greg Kroah-Hartman

usb/core/quirks: Add Huawei ME906S-device to wakeup quirk

2026-03-11T15:19:21+00:00

Similar to other Huawei LTE modules using this quirk, this version with another vid/pid suffers from spurious wakeups. Setting the quirk fixes the issue for this device as well. Cc: stable Signed-off-by: Christoffer Sandberg Signed-off-by: Werner Sembach Link: https://patch.msgid.link/20260306172817.2098898-1-wse@tuxedocomputers.com Signed-off-by: Greg Kroah-Hartman

usb: core: new quirk to handle devices with zero configurations

2026-03-11T15:17:19+00:00

Some USB devices incorrectly report bNumConfigurations as 0 in their device descriptor, which causes the USB core to reject them during enumeration. logs: usb 1-2: device descriptor read/64, error -71 usb 1-2: no configurations usb 1-2: can't read configurations, error -22 However, these devices actually work correctly when treated as having a single configuration. Add a new quirk USB_QUIRK_FORCE_ONE_CONFIG to handle such devices. When this quirk is set, assume the device has 1 configuration instead of failing with -EINVAL. This quirk is applied to the device with VID:PID 5131:2007 which exhibits this behavior. Signed-off-by: Jie Deng Link: https://patch.msgid.link/20260227084931.1527461-1-dengjie03@kylinos.cn Signed-off-by: Greg Kroah-Hartman

USB: core: Limit the length of unkillable synchronous timeouts

2026-03-11T15:16:56+00:00

The usb_control_msg(), usb_bulk_msg(), and usb_interrupt_msg() APIs in usbcore allow unlimited timeout durations. And since they use uninterruptible waits, this leaves open the possibility of hanging a task for an indefinitely long time, with no way to kill it short of unplugging the target device. To prevent this sort of problem, enforce a maximum limit on the length of these unkillable timeouts. The limit chosen here, somewhat arbitrarily, is 60 seconds. On many systems (although not all) this is short enough to avoid triggering the kernel's hung-task detector. In addition, clear up the ambiguity of negative timeout values by treating them the same as 0, i.e., using the maximum allowed timeout. Signed-off-by: Alan Stern Link: https://lore.kernel.org/linux-usb/3acfe838-6334-4f6d-be7c-4bb01704b33d@rowland.harvard.edu/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") CC: stable@vger.kernel.org Link: https://patch.msgid.link/15fc9773-a007-47b0-a703-df89a8cf83dd@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman

USB: usbcore: Introduce usb_bulk_msg_killable()

2026-03-11T15:16:56+00:00

The synchronous message API in usbcore (usb_control_msg(), usb_bulk_msg(), and so on) uses uninterruptible waits. However, drivers may call these routines in the context of a user thread, which means it ought to be possible to at least kill them. For this reason, introduce a new usb_bulk_msg_killable() function which behaves the same as usb_bulk_msg() except for using wait_for_completion_killable_timeout() instead of wait_for_completion_timeout(). The same can be done later for usb_control_msg() later on, if it turns out to be needed. Signed-off-by: Alan Stern Suggested-by: Oliver Neukum Link: https://lore.kernel.org/linux-usb/3acfe838-6334-4f6d-be7c-4bb01704b33d@rowland.harvard.edu/ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") CC: stable@vger.kernel.org Link: https://patch.msgid.link/248628b4-cc83-4e81-a620-3ce4e0376d41@rowland.harvard.edu Signed-off-by: Greg Kroah-Hartman