Re: [PATCH] usb: core: add USB_QUIRK_CONFIG_DESC_READ_255 for Razer BlackShark V3 Pro

It was indeed AI assisted. It's hard to tell if this is sloppy QA,
obviously, but initially I thought it was an actual lockdown in the
firmware to prevent non-Razer software from accessing the device.
Turns out you're probably right.
---
Charles D’Aoust

On Wed, Aug 5, 2026 at 1:54 AM Michal Pecio <[email protected]> wrote:
>
> On Mon, 20 Jul 2026 11:01:26 -0400, Charles Daoust wrote:
> > From: Charles D'Aoust <[email protected]>
> >
> > The Razer BlackShark V3 Pro wireless headset dongle (1532:0577)
> > fingerprints its host during the first enumeration after power-on: if
> > the first GET_DESCRIPTOR(CONFIGURATION) request asks for 255 bytes, as
> > Windows does, the dongle enables its vendor HID command channel; if it
> > sees the 9-byte header-only read that Linux issues, it disables that
> > channel for the rest of the power session.  Audio still works in that
> > state, but battery reporting and all vendor commands are silently
> > ignored, and nothing short of removing power recovers the device:
> > resets, re-enumerations and byte-exact replays of complete Windows
> > control sessions were all verified not to help.
> >
> > Both read lengths are spec-compliant (the device truncates the reply
> > to wLength); the firmware was evidently only validated against the
> > larger request.
>
> Hmm, so is it fingerprinting of the host or sloppy QA? ;)
> Out of curiosity, was this patch AI-generated?
>
> >  The kernel already accommodates this class of
> > firmware assumption during enumeration: hub_port_init() reads the
> > device descriptor with a 64-byte request because that is what Windows
> > does and what many devices expect.
> >
> > Add USB_QUIRK_CONFIG_DESC_READ_255, which makes usb_get_configuration()
> > request 255 bytes for the initial configuration descriptor read rather
> > than USB_DT_CONFIG_SIZE, apply it to 1532:0577, and expose it as
> > runtime quirk letter 'r'.  Devices without the quirk are unaffected.
> >
> > The trigger was isolated by single-variable bisection on otherwise
> > unmodified kernels: with only the widened initial read, the dongle's
> > vendor channel comes up enabled on a cold plug with no interface
> > drivers bound (bare enumeration only); without it, it never does.
> >
> > Cc: [email protected]
> > Signed-off-by: Charles D'Aoust <[email protected]>
>
> But anyway, FYI an equivalent quirk is now sitting in Greg KH's queue
> of fixes for (presumably) the 7.2 release.
>
> I suspect that Greg would accept one more patch to enable the quirk
> by default on your device ID.
>
> Regards,
> Michal