<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/usb/core, branch v6.6.134</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.134</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.6.134'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-04-11T12:19:29+00:00</updated>
<entry>
<title>usb: quirks: add DELAY_INIT quirk for another Silicon Motion flash drive</title>
<updated>2026-04-11T12:19:29+00:00</updated>
<author>
<name>Miao Li</name>
<email>limiao@kylinos.cn</email>
</author>
<published>2026-03-19T05:39:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a6f374ba81ddefd01005030b07159203bcd8047a'/>
<id>urn:sha1:a6f374ba81ddefd01005030b07159203bcd8047a</id>
<content type='text'>
commit dd36014ec6042f424ef51b923e607772f7502ee7 upstream.

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 &lt;limiao@kylinos.cn&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://patch.msgid.link/20260319053927.264840-1-limiao870622@163.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: core: add NO_LPM quirk for Razer Kiyo Pro webcam</title>
<updated>2026-04-11T12:19:27+00:00</updated>
<author>
<name>JP Hein</name>
<email>jp@jphein.com</email>
</author>
<published>2026-03-31T00:38:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=624e292e74769adad674631367ebf89cc1575977'/>
<id>urn:sha1:624e292e74769adad674631367ebf89cc1575977</id>
<content type='text'>
commit 8b7a42ecdcdeb55580d9345412f7f8fc5aca3f6c upstream.

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 &lt;stable@kernel.org&gt;
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2061177
Signed-off-by: JP Hein &lt;jp@jphein.com&gt;
Link: https://patch.msgid.link/20260331003806.212565-2-jp@jphein.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: core: new quirk to handle devices with zero configurations</title>
<updated>2026-04-02T11:07:16+00:00</updated>
<author>
<name>Jie Deng</name>
<email>dengjie03@kylinos.cn</email>
</author>
<published>2026-02-27T08:49:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=56bc8de780720d033ee68e88dff3050308dcdd27'/>
<id>urn:sha1:56bc8de780720d033ee68e88dff3050308dcdd27</id>
<content type='text'>
[ Upstream commit 9f6a983cfa22ac662c86e60816d3a357d4b551e9 ]

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 &lt;dengjie03@kylinos.cn&gt;
Link: https://patch.msgid.link/20260227084931.1527461-1-dengjie03@kylinos.cn
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>USB: core: Limit the length of unkillable synchronous timeouts</title>
<updated>2026-03-25T10:05:49+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2026-02-18T03:10:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=659c0c7d50a4b0f6aa197c4c098cfd91daf63862'/>
<id>urn:sha1:659c0c7d50a4b0f6aa197c4c098cfd91daf63862</id>
<content type='text'>
commit 1015c27a5e1a63efae2b18a9901494474b4d1dc3 upstream.

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 &lt;stern@rowland.harvard.edu&gt;
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 &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: usbcore: Introduce usb_bulk_msg_killable()</title>
<updated>2026-03-25T10:05:49+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2026-02-18T03:07:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fc26e98b6cb829d50c6736fb57cf13df26e59158'/>
<id>urn:sha1:fc26e98b6cb829d50c6736fb57cf13df26e59158</id>
<content type='text'>
commit 416909962e7cdf29fd01ac523c953f37708df93d upstream.

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 &lt;stern@rowland.harvard.edu&gt;
Suggested-by: Oliver Neukum &lt;oneukum@suse.com&gt;
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 &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: core: don't power off roothub PHYs if phy_set_mode() fails</title>
<updated>2026-03-25T10:05:49+00:00</updated>
<author>
<name>Gabor Juhos</name>
<email>j4g8y7@gmail.com</email>
</author>
<published>2026-02-18T20:21:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=24aa4caf7f9588d7c0a7443cbce99a4fa4267715'/>
<id>urn:sha1:24aa4caf7f9588d7c0a7443cbce99a4fa4267715</id>
<content type='text'>
commit e293015ba76eb96ce4ebed7e3b2cb1a7d319f3e9 upstream.

Remove the error path from the usb_phy_roothub_set_mode() function.
The code is clearly wrong, because phy_set_mode() calls can't be
balanced with phy_power_off() calls.

Additionally, the usb_phy_roothub_set_mode() function is called only
from usb_add_hcd() before it powers on the PHYs, so powering off those
makes no sense anyway.

Presumably, the code is copy-pasted from the phy_power_on() function
without adjusting the error handling.

Cc: stable@vger.kernel.org # v5.1+
Fixes: b97a31348379 ("usb: core: comply to PHY framework")
Signed-off-by: Gabor Juhos &lt;j4g8y7@gmail.com&gt;
Reviewed-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Link: https://patch.msgid.link/20260218-usb-phy-poweroff-fix-v1-1-66e6831e860e@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: ezcap401 needs USB_QUIRK_NO_BOS to function on 10gbs usb speed</title>
<updated>2026-03-25T10:05:49+00:00</updated>
<author>
<name>Vyacheslav Vahnenko</name>
<email>vahnenko2003@gmail.com</email>
</author>
<published>2026-03-13T12:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2f2418efd49554decefeb53806d80d61dcf2bec0'/>
<id>urn:sha1:2f2418efd49554decefeb53806d80d61dcf2bec0</id>
<content type='text'>
commit d0d9b1f4f5391e6a00cee81d73ed2e8f98446d5f upstream.

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 &lt;vahnenko2003@gmail.com&gt;
Cc: stable &lt;stable@kernel.org&gt;
Link: https://patch.msgid.link/20260313123638.20481-1-vahnenko2003@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb/core/quirks: Add Huawei ME906S-device to wakeup quirk</title>
<updated>2026-03-25T10:05:49+00:00</updated>
<author>
<name>Christoffer Sandberg</name>
<email>cs@tuxedo.de</email>
</author>
<published>2026-03-06T17:28:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9105f4d74762d7d50c213543631659aeee0ecf59'/>
<id>urn:sha1:9105f4d74762d7d50c213543631659aeee0ecf59</id>
<content type='text'>
commit 0326ff28d56b4fa202de36ffc8462a354f383a64 upstream.

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 &lt;stable@kernel.org&gt;
Signed-off-by: Christoffer Sandberg &lt;cs@tuxedo.de&gt;
Signed-off-by: Werner Sembach &lt;wse@tuxedocomputers.com&gt;
Link: https://patch.msgid.link/20260306172817.2098898-1-wse@tuxedocomputers.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>USB: add QUIRK_NO_BOS for video capture several devices</title>
<updated>2026-03-25T10:05:48+00:00</updated>
<author>
<name>A1RM4X</name>
<email>dev@a1rm4x.com</email>
</author>
<published>2026-02-04T19:26:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=551f82df759c81607401909d60baf0d4088ae88f'/>
<id>urn:sha1:551f82df759c81607401909d60baf0d4088ae88f</id>
<content type='text'>
commit 93cd0d664661f58f7e7bed7373714ab2ace41734 upstream.

Several USB capture devices also need the USB_QUIRK_NO_BOS set for them
to work properly, odds are they are all the same chip inside, just
different vendor/product ids.

This fixes up:
  - ASUS TUF 4K PRO
  - Avermedia Live Gamer Ultra 2.1 (GC553G2)
  - UGREEN 35871
to now run at full speed (10 Gbps/4K 60 fps mode.)

Link: https://lore.kernel.org/r/CACy+XB-f-51xGpNQFCSm5pE_momTQLu=BaZggHYU1DiDmFX=ug@mail.gmail.com
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: A1RM4X &lt;dev@a1rm4x.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>usb: core: add USB_QUIRK_NO_BOS for devices that hang on BOS descriptor</title>
<updated>2026-01-30T09:27:27+00:00</updated>
<author>
<name>Johannes Brüderl</name>
<email>johannes.bruederl@gmail.com</email>
</author>
<published>2025-12-07T09:02:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=93f21786487cd282017c291a6b92dbbbc503e349'/>
<id>urn:sha1:93f21786487cd282017c291a6b92dbbbc503e349</id>
<content type='text'>
commit 2740ac33c87b3d0dfa022efd6ba04c6261b1abbd upstream.

Add USB_QUIRK_NO_BOS quirk flag to skip requesting the BOS descriptor
for devices that cannot handle it.

Add Elgato 4K X (0fd9:009b) to the quirk table. This device hangs when
the BOS descriptor is requested at SuperSpeed Plus (10Gbps).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=220027
Cc: stable &lt;stable@kernel.org&gt;
Signed-off-by: Johannes Brüderl &lt;johannes.bruederl@gmail.com&gt;
Link: https://patch.msgid.link/20251207090220.14807-1-johannes.bruederl@gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
