The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Michal Pecio <michal.pecio@gmail.com>
To: Charles Daoust <charles.daoust@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	stable@vger.kernel.org
Subject: Re: [PATCH] usb: core: add USB_QUIRK_CONFIG_DESC_READ_255 for Razer BlackShark V3 Pro
Date: Wed, 5 Aug 2026 07:54:29 +0200	[thread overview]
Message-ID: <20260805075429.08416607.michal.pecio@gmail.com> (raw)
In-Reply-To: <20260720150207.1963786-1-charles.daoust@gmail.com>

On Mon, 20 Jul 2026 11:01:26 -0400, Charles Daoust wrote:
> From: Charles D'Aoust <charles.daoust@gmail.com>
> 
> 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: stable@vger.kernel.org
> Signed-off-by: Charles D'Aoust <charles.daoust@gmail.com>

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

  parent reply	other threads:[~2026-08-05  5:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 15:01 [PATCH] usb: core: add USB_QUIRK_CONFIG_DESC_READ_255 for Razer BlackShark V3 Pro Charles Daoust
2026-07-20 16:04 ` Alan Stern
2026-07-20 19:12   ` Charles D'Aoust
2026-08-05  5:54 ` Michal Pecio [this message]
2026-08-05  6:48   ` Charles D'Aoust

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260805075429.08416607.michal.pecio@gmail.com \
    --to=michal.pecio@gmail.com \
    --cc=charles.daoust@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox