Re: [PATCH v2] usb: core: add USB_QUIRK_NO_BOS for devices that hang on BOS descriptor

[Michal Pecio <michal.pecio@gmail.com>]

On Sun,  7 Dec 2025 02:20:59 +0100, Johannes Brüderl wrote:
> v2: Return -ENOMSG instead of 0 to properly indicate no BOS data.

Probably good idea.
 
> Tested unbind/rebind via /sys/bus/usb/drivers/usb/unbind - works
> correctly. Userspace tools (lsusb) handle missing BOS gracefully
> (no BOS section shown).

I thought that lsusb never shows BOS, unless you run it as root, and
then it issues control requests to the device to fetch it directly?

And the other user tried it and reported that it worked just fine.
Do you see the same behavior on yours?

> Before (device hangs at SuperSpeed Plus, then re-enumerates at lower speed
> with different product ID 009c):
> 
> [    3.284990] usb 2-2: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
> [    8.574542] usb 2-2: unable to get BOS descriptor or descriptor too short
> [    8.600018] usb 2-2: unable to read config index 0 descriptor/start: -71
> [    8.600027] usb 2-2: can't read configurations, error -71
> [    8.998412] usb 2-2: Device not responding to setup address.
> [    9.215157] usb 2-2: Device not responding to setup address.
> [    9.422737] usb 2-2: device not accepting address 3, error -71
> [   10.990897] usb 2-2: new SuperSpeed USB device number 5 using xhci_hcd
> [   11.065869] usb 2-2: LPM exit latency is zeroed, disabling LPM.

I wonder if this means that the BOS descriptor returned during
SuperSpeed enumeration is bogus?

What BOS shows up if you run 'lsusb -v' as root after the device
completes enumeratation at SuperSpeed?