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

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

[Johannes Brüderl]

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
Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>
---
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.
[   11.152244] usb 2-2: New USB device found, idVendor=0fd9, idProduct=009c

After (device enumerates correctly at SuperSpeed Plus):

[    3.297159] usb 2-2: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[    3.354248] usb 2-2: skipping BOS descriptor
[    3.432917] usb 2-2: New USB device found, idVendor=0fd9, idProduct=009b
[    3.432927] usb 2-2: Product: Elgato 4K X

 drivers/usb/core/config.c  | 5 +++++
 drivers/usb/core/quirks.c  | 3 +++
 include/linux/usb/quirks.h | 3 +++
 3 files changed, 11 insertions(+)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index baf5bc844b6f..8fa3a486d038 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -1040,6 +1040,11 @@ int usb_get_bos_descriptor(struct usb_device *dev)
 	__u8 cap_type;
 	int ret;

+	if (dev->quirks & USB_QUIRK_NO_BOS) {
+		dev_dbg(ddev, "skipping BOS descriptor\n");
+		return 0;
+	}
+
 	bos = kzalloc(sizeof(*bos), GFP_KERNEL);
 	if (!bos)
 		return -ENOMEM;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 47f589c4104a..69ec914e5f45 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -581,6 +581,9 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* INTEL VALUE SSD */
 	{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },

+	/* Elgato 4K X - BOS descriptor fetch hangs at SuperSpeed Plus */
+	{ USB_DEVICE(0x0fd9, 0x009b), .driver_info = USB_QUIRK_NO_BOS },
+
 	{ }  /* terminating entry must be last */
 };

diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 59409c1fc3de..2f7bd2fdc616 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -75,4 +75,7 @@
 /* short SET_ADDRESS request timeout */
 #define USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT	BIT(16)

+/* skip BOS descriptor request */
+#define USB_QUIRK_NO_BOS			BIT(17)
+
 #endif /* __LINUX_USB_QUIRKS_H */
--
2.52.0

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

[Greg KH]

On Sun, Dec 07, 2025 at 01:00:07AM +0100, Johannes Brüderl wrote:
> 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
> Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>
> ---
> 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.
> [   11.152244] usb 2-2: New USB device found, idVendor=0fd9, idProduct=009c
> 
> After (device enumerates correctly at SuperSpeed Plus):
> 
> [    3.297159] usb 2-2: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
> [    3.354248] usb 2-2: skipping BOS descriptor

This feels like a USB spec violation :(

> [    3.432917] usb 2-2: New USB device found, idVendor=0fd9, idProduct=009b
> [    3.432927] usb 2-2: Product: Elgato 4K X
> 
>  drivers/usb/core/config.c  | 5 +++++
>  drivers/usb/core/quirks.c  | 3 +++
>  include/linux/usb/quirks.h | 3 +++
>  3 files changed, 11 insertions(+)
> 
> diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
> index baf5bc844b6f..8fa3a486d038 100644
> --- a/drivers/usb/core/config.c
> +++ b/drivers/usb/core/config.c
> @@ -1040,6 +1040,11 @@ int usb_get_bos_descriptor(struct usb_device *dev)
>  	__u8 cap_type;
>  	int ret;
> 
> +	if (dev->quirks & USB_QUIRK_NO_BOS) {
> +		dev_dbg(ddev, "skipping BOS descriptor\n");
> +		return 0;
> +	}

What is the downside of claiming to successfully reading the BOS
descriptor, yet not having done that at all?  Can we tear down the
device properly?  Show the information correctly through userspace
tools?  Shouldn't we return something like -ENOMSG instead?

thanks,

greg k-h

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

[Johannes Brüderl]

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
Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>
---
v2: Return -ENOMSG instead of 0 to properly indicate no BOS data.

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

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.
[   11.152244] usb 2-2: New USB device found, idVendor=0fd9, idProduct=009c

After (device enumerates correctly at SuperSpeed Plus):

[    3.297159] usb 2-2: new SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[    3.354248] usb 2-2: skipping BOS descriptor
[    3.432917] usb 2-2: New USB device found, idVendor=0fd9, idProduct=009b
[    3.432927] usb 2-2: Product: Elgato 4K X

lsusb -t output:
/:  Bus 002.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 002: Dev 003, If 0, Class=Video, Driver=uvcvideo, 10000M

 drivers/usb/core/config.c  | 5 +++++
 drivers/usb/core/quirks.c  | 3 +++
 include/linux/usb/quirks.h | 3 +++
 3 files changed, 11 insertions(+)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index baf5bc844b6f..2bb1ceb9d621 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -1040,6 +1040,11 @@ int usb_get_bos_descriptor(struct usb_device *dev)
 	__u8 cap_type;
 	int ret;

+	if (dev->quirks & USB_QUIRK_NO_BOS) {
+		dev_dbg(ddev, "skipping BOS descriptor\n");
+		return -ENOMSG;
+	}
+
 	bos = kzalloc(sizeof(*bos), GFP_KERNEL);
 	if (!bos)
 		return -ENOMEM;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 47f589c4104a..69ec914e5f45 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -581,6 +581,9 @@ static const struct usb_device_id usb_quirk_list[] = {
 	/* INTEL VALUE SSD */
 	{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },

+	/* Elgato 4K X - BOS descriptor fetch hangs at SuperSpeed Plus */
+	{ USB_DEVICE(0x0fd9, 0x009b), .driver_info = USB_QUIRK_NO_BOS },
+
 	{ }  /* terminating entry must be last */
 };

diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 59409c1fc3de..2f7bd2fdc616 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -75,4 +75,7 @@
 /* short SET_ADDRESS request timeout */
 #define USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT	BIT(16)

+/* skip BOS descriptor request */
+#define USB_QUIRK_NO_BOS			BIT(17)
+
 #endif /* __LINUX_USB_QUIRKS_H */
--
2.52.0

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

[Lars Melin]

On 2025-12-07 08:20, Johannes Brüderl wrote:
> 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).

// snip

>   	/* INTEL VALUE SSD */
>   	{ USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
> 
> +	/* Elgato 4K X - BOS descriptor fetch hangs at SuperSpeed Plus */
> +	{ USB_DEVICE(0x0fd9, 0x009b), .driver_info = USB_QUIRK_NO_BOS },
> +
>   	{ }  /* terminating entry must be last */

Hi Johannes,
it looks like the list was sorted in vid:pid ascending order before you 
added your entry


Lars

[PATCH v3 1/1] usb: core: add USB_QUIRK_NO_BOS for devices that hang on BOS descriptor

[Johannes Brüderl]

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
Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>
---
Hi Lars,
you are right, good catch! This should be correctly sorted now.

v3: Move quirk entry to correct position in sorted VID:PID order.
v2: Return -ENOMSG instead of 0 to properly indicate no BOS data.

BR,
Johannes

 drivers/usb/core/config.c  | 5 +++++
 drivers/usb/core/quirks.c  | 3 +++
 include/linux/usb/quirks.h | 3 +++
 3 files changed, 11 insertions(+)

diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index baf5bc844b6f..2bb1ceb9d621 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -1040,6 +1040,11 @@ int usb_get_bos_descriptor(struct usb_device *dev)
 	__u8 cap_type;
 	int ret;
 
+	if (dev->quirks & USB_QUIRK_NO_BOS) {
+		dev_dbg(ddev, "skipping BOS descriptor\n");
+		return -ENOMSG;
+	}
+
 	bos = kzalloc(sizeof(*bos), GFP_KERNEL);
 	if (!bos)
 		return -ENOMEM;
diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 47f589c4104a..c4d85089d19b 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -450,6 +450,9 @@ static const struct usb_device_id usb_quirk_list[] = {
 	{ USB_DEVICE(0x0c45, 0x7056), .driver_info =
 			USB_QUIRK_IGNORE_REMOTE_WAKEUP },
 
+	/* Elgato 4K X - BOS descriptor fetch hangs at SuperSpeed Plus */
+	{ USB_DEVICE(0x0fd9, 0x009b), .driver_info = USB_QUIRK_NO_BOS },
+
 	/* Sony Xperia XZ1 Compact (lilac) smartphone in fastboot mode */
 	{ USB_DEVICE(0x0fce, 0x0dde), .driver_info = USB_QUIRK_NO_LPM },
 
diff --git a/include/linux/usb/quirks.h b/include/linux/usb/quirks.h
index 59409c1fc3de..2f7bd2fdc616 100644
--- a/include/linux/usb/quirks.h
+++ b/include/linux/usb/quirks.h
@@ -75,4 +75,7 @@
 /* short SET_ADDRESS request timeout */
 #define USB_QUIRK_SHORT_SET_ADDRESS_REQ_TIMEOUT	BIT(16)
 
+/* skip BOS descriptor request */
+#define USB_QUIRK_NO_BOS			BIT(17)
+
 #endif /* __LINUX_USB_QUIRKS_H */
-- 
2.52.0

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

[Greg KH]

On Sun, Dec 07, 2025 at 10:02:20AM +0100, Johannes Brüderl wrote:
> 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
> Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>
> ---
> Hi Lars,
> you are right, good catch! This should be correctly sorted now.
> 
> v3: Move quirk entry to correct position in sorted VID:PID order.
> v2: Return -ENOMSG instead of 0 to properly indicate no BOS data.

Ok, in playing with this some more, I think this is the best thing for
now.  I'll go queue this up now.

thanks,

greg k-h

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

[Michal Pecio]

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?

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

[Johannes Brüderl]

On Sun, Dec 7, 2025 at 8:40 AM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> 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?

Hi Michal,
thanks, I forgot to use root previously when running lsusb -v.

Here's the BOS Descriptor section when running w/ root.
This is without this patch, so it "reconnected" with SuperSpeed (5Gbps).

Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000000
      (Missing must-be-set LPM bit!)
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           0 micro seconds
    bU2DevExitLat           0 micro seconds

(Missing must-be-set LPM bit!) seems to be weird? As it looks like
just nulled data.
The device seems to generally show problematic behavior when it comes
to the BOS, both on SuperSpeed Plus and SuperSpeed.

BR,
Johannes

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

[Michal Pecio]

On Sun, 7 Dec 2025 10:22:41 +0100, Johannes Brüderl wrote:
> Here's the BOS Descriptor section when running w/ root.
> This is without this patch, so it "reconnected" with SuperSpeed (5Gbps).
> 
> Binary Object Store Descriptor:
>   bLength                 5
>   bDescriptorType        15
>   wTotalLength       0x0016
>   bNumDeviceCaps          2
>   USB 2.0 Extension Device Capability:
>     bLength                 7
>     bDescriptorType        16
>     bDevCapabilityType      2
>     bmAttributes   0x00000000
>       (Missing must-be-set LPM bit!)
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x00
>     wSpeedsSupported   0x000e
>       Device can operate at Full Speed (12Mbps)
>       Device can operate at High Speed (480Mbps)
>       Device can operate at SuperSpeed (5Gbps)
>     bFunctionalitySupport   3
>       Lowest fully-functional device speed is SuperSpeed (5Gbps)
>     bU1DevExitLat           0 micro seconds
>     bU2DevExitLat           0 micro seconds
> 
> (Missing must-be-set LPM bit!) seems to be weird? As it looks like
> just nulled data.

OK, so it's broken during enumeration and after enumeration.

But that's the "fallback" case after hanging during SS+ enumeration,
which we would like to prevent from happening. What about 5gbps ports,
does it work correctly at SS or still report zero LPM?

And running at SS+ with the patch applied, does the device produce
sensible BOS descriptor? The previous one did.

What if you extend the patch to also apply at SS? It won't fix LPM
during enumeration, but would it fix the descriptor seen by lsusb?

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

[Johannes Brüderl]

On Sun, Dec 7, 2025 at 10:45 AM Michal Pecio <michal.pecio@gmail.com> wrote:
>
> On Sun, 7 Dec 2025 10:22:41 +0100, Johannes Brüderl wrote:
> > Here's the BOS Descriptor section when running w/ root.
> > This is without this patch, so it "reconnected" with SuperSpeed (5Gbps).
> >
> > Binary Object Store Descriptor:
> >   bLength                 5
> >   bDescriptorType        15
> >   wTotalLength       0x0016
> >   bNumDeviceCaps          2
> >   USB 2.0 Extension Device Capability:
> >     bLength                 7
> >     bDescriptorType        16
> >     bDevCapabilityType      2
> >     bmAttributes   0x00000000
> >       (Missing must-be-set LPM bit!)
> >   SuperSpeed USB Device Capability:
> >     bLength                10
> >     bDescriptorType        16
> >     bDevCapabilityType      3
> >     bmAttributes         0x00
> >     wSpeedsSupported   0x000e
> >       Device can operate at Full Speed (12Mbps)
> >       Device can operate at High Speed (480Mbps)
> >       Device can operate at SuperSpeed (5Gbps)
> >     bFunctionalitySupport   3
> >       Lowest fully-functional device speed is SuperSpeed (5Gbps)
> >     bU1DevExitLat           0 micro seconds
> >     bU2DevExitLat           0 micro seconds
> >
> > (Missing must-be-set LPM bit!) seems to be weird? As it looks like
> > just nulled data.
>
> OK, so it's broken during enumeration and after enumeration.
>
> But that's the "fallback" case after hanging during SS+ enumeration,
> which we would like to prevent from happening. What about 5gbps ports,
> does it work correctly at SS or still report zero LPM?
>
> And running at SS+ with the patch applied, does the device produce
> sensible BOS descriptor? The previous one did.
>
> What if you extend the patch to also apply at SS? It won't fix LPM
> during enumeration, but would it fix the descriptor seen by lsusb?

Hello Michal,

very good questions.. the result was surprising to me.

1) How does it do on 5GBps port?

Without patch:

[ 1522.177297] usb 6-1: new SuperSpeed USB device number 4 using xhci_hcd
[ 1527.440481] usb 6-1: unable to get BOS descriptor or descriptor too short
[ 1527.465514] usb 6-1: unable to read config index 0 descriptor/start: -71
[ 1527.465520] usb 6-1: can't read configurations, error -71
[ 1527.648035] usb 6-1: new SuperSpeed USB device number 5 using xhci_hcd
[ 1527.839295] usb 6-1: LPM exit latency is zeroed, disabling LPM.

Looks like the BOS descriptor cannot be read either.

Any, very interesting:

Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000000
      (Missing must-be-set LPM bit!)
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           0 micro seconds
    bU2DevExitLat           0 micro seconds

Very interesting - even reading it "manually" via lsusb - seems to
fail, even at SS.

2) Does it produce a sensible BOS descriptor post-patch at SS+ ? It
looks like it.
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x002a
  bNumDeviceCaps          3
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x0000f41e
      BESL Link Power Management (LPM) Supported
      Baseline BESL value    400 us
      Deep BESL value      10000 us
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
  SuperSpeedPlus USB Device Capability:
    bLength                20
    bDescriptorType        16
    bDevCapabilityType     10
    bmAttributes         0x00000001
      Sublink Speed Attribute count 2
      Sublink Speed ID count 1
    wFunctionalitySupport   0x1100
      Min functional Speed Attribute ID: 0
      Min functional RX lanes: 1
      Min functional TX lanes: 1
    bmSublinkSpeedAttr[0]   0x000a4030
      Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus
    bmSublinkSpeedAttr[1]   0x000a40b0
      Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus

3) What if I apply the patch to SS as well?

Connect:
[    3.293251] usb 6-1: new SuperSpeed USB device number 2 using xhci_hcd
[    3.349030] usb 6-1: skipping BOS descriptor
[    3.429817] usb 6-1: New USB device found, idVendor=0fd9,
idProduct=009c, bcdDevice= 0.02
[    3.429825] usb 6-1: New USB device strings: Mfr=6, Product=7, SerialNumber=3
[    3.429828] usb 6-1: Product: Elgato 4K X
[    3.429830] usb 6-1: Manufacturer: Elgato
[    3.429833] usb 6-1: SerialNumber: A7SNB517214G5K
[    9.019651] usb 6-1: 3:2: failed to get current value for ch 0 (-22)
[    9.028103] usb 6-1: Found UVC 1.00 device Elgato 4K X (0fd9:009c)

sudo lsusb -v -d 0fd9:009c
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x0016
  bNumDeviceCaps          2
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000000
      (Missing must-be-set LPM bit!)
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   3
      Lowest fully-functional device speed is SuperSpeed (5Gbps)
    bU1DevExitLat           0 micro seconds
    bU2DevExitLat           0 micro seconds

Again (Missing must-be-set LPM bit!).

So.. if i summarize it correctly: on SS, BOS fetch seems to fail
immediately when connecting, but also "later" when I use lsusb.
But, on SS+, if i skip BOS fetch on connect, it works when done later...

For what it's worth: I've recorded a few hours of Gameplay with the
patch, and rebooted a couple times, it seems to do the trick.

BR,
Johannes

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

[Greg KH]

On Sun, Dec 07, 2025 at 11:47:34AM +0100, Johannes Brüderl wrote:
> On Sun, Dec 7, 2025 at 10:45 AM Michal Pecio <michal.pecio@gmail.com> wrote:
> >
> > On Sun, 7 Dec 2025 10:22:41 +0100, Johannes Brüderl wrote:
> > > Here's the BOS Descriptor section when running w/ root.
> > > This is without this patch, so it "reconnected" with SuperSpeed (5Gbps).
> > >
> > > Binary Object Store Descriptor:
> > >   bLength                 5
> > >   bDescriptorType        15
> > >   wTotalLength       0x0016
> > >   bNumDeviceCaps          2
> > >   USB 2.0 Extension Device Capability:
> > >     bLength                 7
> > >     bDescriptorType        16
> > >     bDevCapabilityType      2
> > >     bmAttributes   0x00000000
> > >       (Missing must-be-set LPM bit!)
> > >   SuperSpeed USB Device Capability:
> > >     bLength                10
> > >     bDescriptorType        16
> > >     bDevCapabilityType      3
> > >     bmAttributes         0x00
> > >     wSpeedsSupported   0x000e
> > >       Device can operate at Full Speed (12Mbps)
> > >       Device can operate at High Speed (480Mbps)
> > >       Device can operate at SuperSpeed (5Gbps)
> > >     bFunctionalitySupport   3
> > >       Lowest fully-functional device speed is SuperSpeed (5Gbps)
> > >     bU1DevExitLat           0 micro seconds
> > >     bU2DevExitLat           0 micro seconds
> > >
> > > (Missing must-be-set LPM bit!) seems to be weird? As it looks like
> > > just nulled data.
> >
> > OK, so it's broken during enumeration and after enumeration.
> >
> > But that's the "fallback" case after hanging during SS+ enumeration,
> > which we would like to prevent from happening. What about 5gbps ports,
> > does it work correctly at SS or still report zero LPM?
> >
> > And running at SS+ with the patch applied, does the device produce
> > sensible BOS descriptor? The previous one did.
> >
> > What if you extend the patch to also apply at SS? It won't fix LPM
> > during enumeration, but would it fix the descriptor seen by lsusb?
> 
> Hello Michal,
> 
> very good questions.. the result was surprising to me.
> 
> 1) How does it do on 5GBps port?
> 
> Without patch:
> 
> [ 1522.177297] usb 6-1: new SuperSpeed USB device number 4 using xhci_hcd
> [ 1527.440481] usb 6-1: unable to get BOS descriptor or descriptor too short
> [ 1527.465514] usb 6-1: unable to read config index 0 descriptor/start: -71
> [ 1527.465520] usb 6-1: can't read configurations, error -71
> [ 1527.648035] usb 6-1: new SuperSpeed USB device number 5 using xhci_hcd
> [ 1527.839295] usb 6-1: LPM exit latency is zeroed, disabling LPM.
> 
> Looks like the BOS descriptor cannot be read either.
> 
> Any, very interesting:
> 
> Binary Object Store Descriptor:
>   bLength                 5
>   bDescriptorType        15
>   wTotalLength       0x0016
>   bNumDeviceCaps          2
>   USB 2.0 Extension Device Capability:
>     bLength                 7
>     bDescriptorType        16
>     bDevCapabilityType      2
>     bmAttributes   0x00000000
>       (Missing must-be-set LPM bit!)
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x00
>     wSpeedsSupported   0x000e
>       Device can operate at Full Speed (12Mbps)
>       Device can operate at High Speed (480Mbps)
>       Device can operate at SuperSpeed (5Gbps)
>     bFunctionalitySupport   3
>       Lowest fully-functional device speed is SuperSpeed (5Gbps)
>     bU1DevExitLat           0 micro seconds
>     bU2DevExitLat           0 micro seconds
> 
> Very interesting - even reading it "manually" via lsusb - seems to
> fail, even at SS.
> 
> 2) Does it produce a sensible BOS descriptor post-patch at SS+ ? It
> looks like it.
> Binary Object Store Descriptor:
>   bLength                 5
>   bDescriptorType        15
>   wTotalLength       0x002a
>   bNumDeviceCaps          3
>   USB 2.0 Extension Device Capability:
>     bLength                 7
>     bDescriptorType        16
>     bDevCapabilityType      2
>     bmAttributes   0x0000f41e
>       BESL Link Power Management (LPM) Supported
>       Baseline BESL value    400 us
>       Deep BESL value      10000 us
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x00
>     wSpeedsSupported   0x000e
>       Device can operate at Full Speed (12Mbps)
>       Device can operate at High Speed (480Mbps)
>       Device can operate at SuperSpeed (5Gbps)
>     bFunctionalitySupport   1
>       Lowest fully-functional device speed is Full Speed (12Mbps)
>     bU1DevExitLat          10 micro seconds
>     bU2DevExitLat        2047 micro seconds
>   SuperSpeedPlus USB Device Capability:
>     bLength                20
>     bDescriptorType        16
>     bDevCapabilityType     10
>     bmAttributes         0x00000001
>       Sublink Speed Attribute count 2
>       Sublink Speed ID count 1
>     wFunctionalitySupport   0x1100
>       Min functional Speed Attribute ID: 0
>       Min functional RX lanes: 1
>       Min functional TX lanes: 1
>     bmSublinkSpeedAttr[0]   0x000a4030
>       Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus
>     bmSublinkSpeedAttr[1]   0x000a40b0
>       Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus
> 
> 3) What if I apply the patch to SS as well?
> 
> Connect:
> [    3.293251] usb 6-1: new SuperSpeed USB device number 2 using xhci_hcd
> [    3.349030] usb 6-1: skipping BOS descriptor
> [    3.429817] usb 6-1: New USB device found, idVendor=0fd9,
> idProduct=009c, bcdDevice= 0.02
> [    3.429825] usb 6-1: New USB device strings: Mfr=6, Product=7, SerialNumber=3
> [    3.429828] usb 6-1: Product: Elgato 4K X
> [    3.429830] usb 6-1: Manufacturer: Elgato
> [    3.429833] usb 6-1: SerialNumber: A7SNB517214G5K
> [    9.019651] usb 6-1: 3:2: failed to get current value for ch 0 (-22)
> [    9.028103] usb 6-1: Found UVC 1.00 device Elgato 4K X (0fd9:009c)
> 
> sudo lsusb -v -d 0fd9:009c
> Binary Object Store Descriptor:
>   bLength                 5
>   bDescriptorType        15
>   wTotalLength       0x0016
>   bNumDeviceCaps          2
>   USB 2.0 Extension Device Capability:
>     bLength                 7
>     bDescriptorType        16
>     bDevCapabilityType      2
>     bmAttributes   0x00000000
>       (Missing must-be-set LPM bit!)
>   SuperSpeed USB Device Capability:
>     bLength                10
>     bDescriptorType        16
>     bDevCapabilityType      3
>     bmAttributes         0x00
>     wSpeedsSupported   0x000e
>       Device can operate at Full Speed (12Mbps)
>       Device can operate at High Speed (480Mbps)
>       Device can operate at SuperSpeed (5Gbps)
>     bFunctionalitySupport   3
>       Lowest fully-functional device speed is SuperSpeed (5Gbps)
>     bU1DevExitLat           0 micro seconds
>     bU2DevExitLat           0 micro seconds
> 
> Again (Missing must-be-set LPM bit!).
> 
> So.. if i summarize it correctly: on SS, BOS fetch seems to fail
> immediately when connecting, but also "later" when I use lsusb.
> But, on SS+, if i skip BOS fetch on connect, it works when done later...
> 
> For what it's worth: I've recorded a few hours of Gameplay with the
> patch, and rebooted a couple times, it seems to do the trick.

This is really odd.  I just picked one of these devices up and will try
this out next week when I get a chance to connect it to a system that
isn't just my laptop (I don't think my laptop's usb ports are that fast,
but I could be wrong, will try it out later this week...)

thanks,

greg k-h

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

[Greg KH]

On Sun, Dec 07, 2025 at 08:00:53PM +0900, Greg KH wrote:
> On Sun, Dec 07, 2025 at 11:47:34AM +0100, Johannes Brüderl wrote:
> > On Sun, Dec 7, 2025 at 10:45 AM Michal Pecio <michal.pecio@gmail.com> wrote:
> > >
> > > On Sun, 7 Dec 2025 10:22:41 +0100, Johannes Brüderl wrote:
> > > > Here's the BOS Descriptor section when running w/ root.
> > > > This is without this patch, so it "reconnected" with SuperSpeed (5Gbps).
> > > >
> > > > Binary Object Store Descriptor:
> > > >   bLength                 5
> > > >   bDescriptorType        15
> > > >   wTotalLength       0x0016
> > > >   bNumDeviceCaps          2
> > > >   USB 2.0 Extension Device Capability:
> > > >     bLength                 7
> > > >     bDescriptorType        16
> > > >     bDevCapabilityType      2
> > > >     bmAttributes   0x00000000
> > > >       (Missing must-be-set LPM bit!)
> > > >   SuperSpeed USB Device Capability:
> > > >     bLength                10
> > > >     bDescriptorType        16
> > > >     bDevCapabilityType      3
> > > >     bmAttributes         0x00
> > > >     wSpeedsSupported   0x000e
> > > >       Device can operate at Full Speed (12Mbps)
> > > >       Device can operate at High Speed (480Mbps)
> > > >       Device can operate at SuperSpeed (5Gbps)
> > > >     bFunctionalitySupport   3
> > > >       Lowest fully-functional device speed is SuperSpeed (5Gbps)
> > > >     bU1DevExitLat           0 micro seconds
> > > >     bU2DevExitLat           0 micro seconds
> > > >
> > > > (Missing must-be-set LPM bit!) seems to be weird? As it looks like
> > > > just nulled data.
> > >
> > > OK, so it's broken during enumeration and after enumeration.
> > >
> > > But that's the "fallback" case after hanging during SS+ enumeration,
> > > which we would like to prevent from happening. What about 5gbps ports,
> > > does it work correctly at SS or still report zero LPM?
> > >
> > > And running at SS+ with the patch applied, does the device produce
> > > sensible BOS descriptor? The previous one did.
> > >
> > > What if you extend the patch to also apply at SS? It won't fix LPM
> > > during enumeration, but would it fix the descriptor seen by lsusb?
> > 
> > Hello Michal,
> > 
> > very good questions.. the result was surprising to me.
> > 
> > 1) How does it do on 5GBps port?
> > 
> > Without patch:
> > 
> > [ 1522.177297] usb 6-1: new SuperSpeed USB device number 4 using xhci_hcd
> > [ 1527.440481] usb 6-1: unable to get BOS descriptor or descriptor too short
> > [ 1527.465514] usb 6-1: unable to read config index 0 descriptor/start: -71
> > [ 1527.465520] usb 6-1: can't read configurations, error -71
> > [ 1527.648035] usb 6-1: new SuperSpeed USB device number 5 using xhci_hcd
> > [ 1527.839295] usb 6-1: LPM exit latency is zeroed, disabling LPM.
> > 
> > Looks like the BOS descriptor cannot be read either.
> > 
> > Any, very interesting:
> > 
> > Binary Object Store Descriptor:
> >   bLength                 5
> >   bDescriptorType        15
> >   wTotalLength       0x0016
> >   bNumDeviceCaps          2
> >   USB 2.0 Extension Device Capability:
> >     bLength                 7
> >     bDescriptorType        16
> >     bDevCapabilityType      2
> >     bmAttributes   0x00000000
> >       (Missing must-be-set LPM bit!)
> >   SuperSpeed USB Device Capability:
> >     bLength                10
> >     bDescriptorType        16
> >     bDevCapabilityType      3
> >     bmAttributes         0x00
> >     wSpeedsSupported   0x000e
> >       Device can operate at Full Speed (12Mbps)
> >       Device can operate at High Speed (480Mbps)
> >       Device can operate at SuperSpeed (5Gbps)
> >     bFunctionalitySupport   3
> >       Lowest fully-functional device speed is SuperSpeed (5Gbps)
> >     bU1DevExitLat           0 micro seconds
> >     bU2DevExitLat           0 micro seconds
> > 
> > Very interesting - even reading it "manually" via lsusb - seems to
> > fail, even at SS.
> > 
> > 2) Does it produce a sensible BOS descriptor post-patch at SS+ ? It
> > looks like it.
> > Binary Object Store Descriptor:
> >   bLength                 5
> >   bDescriptorType        15
> >   wTotalLength       0x002a
> >   bNumDeviceCaps          3
> >   USB 2.0 Extension Device Capability:
> >     bLength                 7
> >     bDescriptorType        16
> >     bDevCapabilityType      2
> >     bmAttributes   0x0000f41e
> >       BESL Link Power Management (LPM) Supported
> >       Baseline BESL value    400 us
> >       Deep BESL value      10000 us
> >   SuperSpeed USB Device Capability:
> >     bLength                10
> >     bDescriptorType        16
> >     bDevCapabilityType      3
> >     bmAttributes         0x00
> >     wSpeedsSupported   0x000e
> >       Device can operate at Full Speed (12Mbps)
> >       Device can operate at High Speed (480Mbps)
> >       Device can operate at SuperSpeed (5Gbps)
> >     bFunctionalitySupport   1
> >       Lowest fully-functional device speed is Full Speed (12Mbps)
> >     bU1DevExitLat          10 micro seconds
> >     bU2DevExitLat        2047 micro seconds
> >   SuperSpeedPlus USB Device Capability:
> >     bLength                20
> >     bDescriptorType        16
> >     bDevCapabilityType     10
> >     bmAttributes         0x00000001
> >       Sublink Speed Attribute count 2
> >       Sublink Speed ID count 1
> >     wFunctionalitySupport   0x1100
> >       Min functional Speed Attribute ID: 0
> >       Min functional RX lanes: 1
> >       Min functional TX lanes: 1
> >     bmSublinkSpeedAttr[0]   0x000a4030
> >       Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus
> >     bmSublinkSpeedAttr[1]   0x000a40b0
> >       Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus
> > 
> > 3) What if I apply the patch to SS as well?
> > 
> > Connect:
> > [    3.293251] usb 6-1: new SuperSpeed USB device number 2 using xhci_hcd
> > [    3.349030] usb 6-1: skipping BOS descriptor
> > [    3.429817] usb 6-1: New USB device found, idVendor=0fd9,
> > idProduct=009c, bcdDevice= 0.02
> > [    3.429825] usb 6-1: New USB device strings: Mfr=6, Product=7, SerialNumber=3
> > [    3.429828] usb 6-1: Product: Elgato 4K X
> > [    3.429830] usb 6-1: Manufacturer: Elgato
> > [    3.429833] usb 6-1: SerialNumber: A7SNB517214G5K
> > [    9.019651] usb 6-1: 3:2: failed to get current value for ch 0 (-22)
> > [    9.028103] usb 6-1: Found UVC 1.00 device Elgato 4K X (0fd9:009c)
> > 
> > sudo lsusb -v -d 0fd9:009c
> > Binary Object Store Descriptor:
> >   bLength                 5
> >   bDescriptorType        15
> >   wTotalLength       0x0016
> >   bNumDeviceCaps          2
> >   USB 2.0 Extension Device Capability:
> >     bLength                 7
> >     bDescriptorType        16
> >     bDevCapabilityType      2
> >     bmAttributes   0x00000000
> >       (Missing must-be-set LPM bit!)
> >   SuperSpeed USB Device Capability:
> >     bLength                10
> >     bDescriptorType        16
> >     bDevCapabilityType      3
> >     bmAttributes         0x00
> >     wSpeedsSupported   0x000e
> >       Device can operate at Full Speed (12Mbps)
> >       Device can operate at High Speed (480Mbps)
> >       Device can operate at SuperSpeed (5Gbps)
> >     bFunctionalitySupport   3
> >       Lowest fully-functional device speed is SuperSpeed (5Gbps)
> >     bU1DevExitLat           0 micro seconds
> >     bU2DevExitLat           0 micro seconds
> > 
> > Again (Missing must-be-set LPM bit!).
> > 
> > So.. if i summarize it correctly: on SS, BOS fetch seems to fail
> > immediately when connecting, but also "later" when I use lsusb.
> > But, on SS+, if i skip BOS fetch on connect, it works when done later...
> > 
> > For what it's worth: I've recorded a few hours of Gameplay with the
> > patch, and rebooted a couple times, it seems to do the trick.
> 
> This is really odd.  I just picked one of these devices up and will try
> this out next week when I get a chance to connect it to a system that
> isn't just my laptop (I don't think my laptop's usb ports are that fast,
> but I could be wrong, will try it out later this week...)

Ok, I can duplicate this here.  Maybe we just don't ask for the BOS
descriptor if no one needs/asks for it.  I can play with that later and
see if that helps as I'm sure this isn't going to be the only device
that can't handle the BOS descriptor if Windows isn't querying for it,
so we don't want to make a huge quirk table if we don't have to.

thanks,

greg k-h

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

[Michal Pecio]

On Mon, 8 Dec 2025 06:12:15 +0900, Greg KH wrote:
> I'm sure this isn't going to be the only device that can't handle the
> BOS descriptor if Windows isn't querying for it

I speculated in bugzilla that maybe Windows isn't asking for it, but I
doubt it now because BOS is required for LPM. More likely it was simply
WinPCAP failing to capture those queries when I tried.

lsusb works, so something "fixes" this device - maybe just waiting long
enough, maybe using different wLength, mabye getting config descriptors
before BOS or setting configuration first, I don't know.

Windows in a VM may show you how to do it ;)

Regards,
Michal

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

[Oliver Neukum]

On 07.12.25 22:12, Greg KH wrote:
  
> Ok, I can duplicate this here.  Maybe we just don't ask for the BOS
> descriptor if no one needs/asks for it.  I can play with that later and
> see if that helps as I'm sure this isn't going to be the only device
> that can't handle the BOS descriptor if Windows isn't querying for it,
> so we don't want to make a huge quirk table if we don't have to.

1. That means we'd let lsusb crash devices. Not a good idea.
2. It is, unfortunately, possible that firmware authors simply
script a detection sequence. That means devices would crash
if you request a descriptor at a time when Windows would not
request it, not just in general.
I am afraid I need to point you at the horrible example
of HID_ALWAYS_POLL

	Regards
		Oliver

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

[Greg KH]

On Mon, Dec 08, 2025 at 09:58:55AM +0100, Oliver Neukum wrote:
> On 07.12.25 22:12, Greg KH wrote:
> > Ok, I can duplicate this here.  Maybe we just don't ask for the BOS
> > descriptor if no one needs/asks for it.  I can play with that later and
> > see if that helps as I'm sure this isn't going to be the only device
> > that can't handle the BOS descriptor if Windows isn't querying for it,
> > so we don't want to make a huge quirk table if we don't have to.
> 
> 1. That means we'd let lsusb crash devices. Not a good idea.

I don't think that it will crash.  hopefully not, as just reading a
descriptor after enumerated shouldn't cause that.  I'll test it out...

> 2. It is, unfortunately, possible that firmware authors simply
> script a detection sequence. That means devices would crash
> if you request a descriptor at a time when Windows would not
> request it, not just in general.
> I am afraid I need to point you at the horrible example
> of HID_ALWAYS_POLL

That is horrible, hopefully we don't have to do that here :(

thanks,

greg k-h

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

[Johannes Brüderl]

On Mon, Dec 8, 2025 at 9:46 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Dec 08, 2025 at 09:58:55AM +0100, Oliver Neukum wrote:
> > On 07.12.25 22:12, Greg KH wrote:
> > > Ok, I can duplicate this here.  Maybe we just don't ask for the BOS
> > > descriptor if no one needs/asks for it.  I can play with that later and
> > > see if that helps as I'm sure this isn't going to be the only device
> > > that can't handle the BOS descriptor if Windows isn't querying for it,
> > > so we don't want to make a huge quirk table if we don't have to.
> >
> > 1. That means we'd let lsusb crash devices. Not a good idea.
>
> I don't think that it will crash.  hopefully not, as just reading a
> descriptor after enumerated shouldn't cause that.  I'll test it out...
>
> > 2. It is, unfortunately, possible that firmware authors simply
> > script a detection sequence. That means devices would crash
> > if you request a descriptor at a time when Windows would not
> > request it, not just in general.
> > I am afraid I need to point you at the horrible example
> > of HID_ALWAYS_POLL
>
> That is horrible, hopefully we don't have to do that here :(
>
> thanks,
>
> greg k-h

Hello Greg,
I apologize for the "blunt bump" of this topic.
Are you (still) open to considering the quirk ?

A small number of users have started using the Patch, and it seems to
solve a real problem.. (ref:
https://www.reddit.com/r/elgato/comments/1lw1e0v/comment/ntrdjpb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)

Given that the options for 4k60fps recording are very limited for
Linux these days - I suggest it might be worth it. AFAIK, there's no
good other option in terms of hardware as of December 2025.
I understand it's a special quirk for just this device, which is not pretty..

(Note: i've submitted a v3 patch that addressed the feedback).

Thanks and Best Regards,
Johannes

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

[Greg KH]

On Sun, Dec 28, 2025 at 01:54:34PM +0100, Johannes Brüderl wrote:
> On Mon, Dec 8, 2025 at 9:46 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Dec 08, 2025 at 09:58:55AM +0100, Oliver Neukum wrote:
> > > On 07.12.25 22:12, Greg KH wrote:
> > > > Ok, I can duplicate this here.  Maybe we just don't ask for the BOS
> > > > descriptor if no one needs/asks for it.  I can play with that later and
> > > > see if that helps as I'm sure this isn't going to be the only device
> > > > that can't handle the BOS descriptor if Windows isn't querying for it,
> > > > so we don't want to make a huge quirk table if we don't have to.
> > >
> > > 1. That means we'd let lsusb crash devices. Not a good idea.
> >
> > I don't think that it will crash.  hopefully not, as just reading a
> > descriptor after enumerated shouldn't cause that.  I'll test it out...
> >
> > > 2. It is, unfortunately, possible that firmware authors simply
> > > script a detection sequence. That means devices would crash
> > > if you request a descriptor at a time when Windows would not
> > > request it, not just in general.
> > > I am afraid I need to point you at the horrible example
> > > of HID_ALWAYS_POLL
> >
> > That is horrible, hopefully we don't have to do that here :(
> >
> > thanks,
> >
> > greg k-h
> 
> Hello Greg,
> I apologize for the "blunt bump" of this topic.
> Are you (still) open to considering the quirk ?
> 
> A small number of users have started using the Patch, and it seems to
> solve a real problem.. (ref:
> https://www.reddit.com/r/elgato/comments/1lw1e0v/comment/ntrdjpb/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)
> 
> Given that the options for 4k60fps recording are very limited for
> Linux these days - I suggest it might be worth it. AFAIK, there's no
> good other option in terms of hardware as of December 2025.
> I understand it's a special quirk for just this device, which is not pretty..
> 
> (Note: i've submitted a v3 patch that addressed the feedback).

Sorry, I haven't had a chance to dig into this due to travel and the
holidays.  Give me a few days to catch up...

thanks,

greg k-h

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

[Michal Pecio]

On Sun,  7 Dec 2025 01:00:07 +0100, Johannes Brüderl wrote:
> 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
> Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>

IIRC what we found in this bug is that the device will happily respond
to BOS descriptor requests issued by lsusb after it's enumerated.

So it appears that (only when running at 10G, wtf) the device expects
something to happen before it is able to produce this descriptor. And
apparently Linux is doing things in different order than certain other
operating system supported by the vendor.

But the reporter simply applied a patch similar to yours and lost
interest in debugging any further.

And unfortunately WinPCAP fails to capture most of enumeration process,
so I don't know how that other software is doing it.

Regards,
Michal

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

[Greg KH]

On Sun, Dec 07, 2025 at 01:37:34AM +0100, Michal Pecio wrote:
> On Sun,  7 Dec 2025 01:00:07 +0100, Johannes Brüderl wrote:
> > 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
> > Signed-off-by: Johannes Brüderl <johannes.bruederl@gmail.com>
> 
> IIRC what we found in this bug is that the device will happily respond
> to BOS descriptor requests issued by lsusb after it's enumerated.

That's very odd.

> So it appears that (only when running at 10G, wtf) the device expects
> something to happen before it is able to produce this descriptor. And
> apparently Linux is doing things in different order than certain other
> operating system supported by the vendor.

Any ideas what "order" is not the same here?  Should we just not be
reading the BOS descriptor at early enumeration and just wait until
someone actually wants it?

> But the reporter simply applied a patch similar to yours and lost
> interest in debugging any further.

Understood, but I'd like to get to the root of this if possible so that
we don't end up just adding a bunch of devices to this quirk because we
are doing something "odd" that normal USB-IF testing isn't catching.
That feels like a bad overall decision to make.

> And unfortunately WinPCAP fails to capture most of enumeration process,
> so I don't know how that other software is doing it.

usbmon with windows in a virtual machine might catch this?

thanks,

greg k-h