kernel/linux.git/drivers/usb/core, branch master

USB: of: Simplify with scoped for each OF child loop

2026-04-07T11:49:48+00:00

Use scoped for-each loop when iterating over device nodes to make code a bit simpler. Signed-off-by: Hans Zhang <18255117159@163.com> Link: https://patch.msgid.link/20260407013122.1296818-1-18255117159@163.com Signed-off-by: Greg Kroah-Hartman

usb: core: config: reverse the size check of the SSP isoc endpoint descriptor

2026-04-07T11:48:13+00:00

Reverse the check of the size of the usb_ssp_isoc_ep_comp_descriptor structure to be done before accessing the structure itself. Functionally, this doesn't really do anything as the buffer is all internal to the kernel, and reading off the end is just fine, but static checking tools get picky when noticing that a potential read could be made "outside" of an allocated buffer. Not a bugfix, but a cleanup to keep tools from tripping over this constantly and annoying me with their pointless reports. Link: https://patch.msgid.link/2026040630-graded-postwar-760f@gregkh Signed-off-by: Greg Kroah-Hartman

Merge tag 'v7.0-rc7' into usb-next

2026-04-06T07:06:39+00:00

We need the USB fixes in here to build on and for testing Signed-off-by: Greg Kroah-Hartman

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: port: add delay after usb_hub_set_port_power()

2026-03-18T15:03:58+00:00

When a port is disabled, an attached device will be disconnected. This causes a port-status-change event, which will race with hub autosuspend (if the disabled port was the only connected port on its hub), causing an immediate resume and a second autosuspend. Both of these can be avoided by adding a short delay after the call to usb_hub_set_port_power(). Below log shows what is happening: $ echo 1 > usb1-port1/disable [ 37.958239] usb 1-1: USB disconnect, device number 2 [ 37.964101] usb 1-1: unregistering device [ 37.970070] hub 1-0:1.0: hub_suspend [ 37.971305] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0002 [ 37.974412] usb usb1: bus auto-suspend, wakeup 1 [ 37.988175] usb usb1: suspend raced with wakeup event <--- [ 37.993947] usb usb1: usb auto-resume [ 37.998401] hub 1-0:1.0: hub_resume [ 38.105688] usb usb1-port1: status 0000, change 0000, 12 Mb/s [ 38.112399] hub 1-0:1.0: state 7 ports 1 chg 0000 evt 0000 [ 38.118645] hub 1-0:1.0: hub_suspend [ 38.122963] usb usb1: bus auto-suspend, wakeup 1 [ 38.200368] usb usb1: usb wakeup-resume [ 38.204982] usb usb1: usb auto-resume [ 38.209376] hub 1-0:1.0: hub_resume [ 38.213676] usb usb1-port1: status 0101 change 0001 [ 38.321552] hub 1-0:1.0: state 7 ports 1 chg 0002 evt 0000 [ 38.327978] usb usb1-port1: status 0101, change 0000, 12 Mb/s [ 38.457429] usb 1-1: new high-speed USB device number 3 using ci_hdrc Then, port change bit will be fixed to the final state and usb_clear_port_feature() can correctly clear it after this period. This will also avoid usb runtime suspend routine to run because usb_autopm_put_interface() not run yet. Fixes: f061f43d7418 ("usb: hub: port: add sysfs entry to switch port power") Cc: stable@kernel.org Signed-off-by: Xu Yang Link: https://patch.msgid.link/20260316095042.1559882-1-xu.yang_2@nxp.com Signed-off-by: Greg Kroah-Hartman

usb: core: allow ACPI-managed hard-wired ports to power off

2026-03-18T15:03:55+00:00

USB core only relaxes the default PM_QOS_FLAG_NO_POWER_OFF policy when an upstream hub reports switchable port power. That misses internal ports whose power is managed by platform firmware instead of the USB hub descriptor. Allow the port-poweroff policy to be exposed for hard-wired ports with an ACPI-managed power resource. The existing runtime PM path still requires the child usage count to drop and remote wakeup to be clear before it will power the port down. This lets internal devices such as CNVi Bluetooth use the existing USB ACPI runtime power path even when the root hub reports no USB-standard port power switching. Signed-off-by: Sean Rhodes Link: https://patch.msgid.link/20260315223433.23452-1-sean@starlabs.systems Signed-off-by: Greg Kroah-Hartman