Re: [PATCH v2] usbcore: Add quirk for 255-bytes initial config read

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

On Sun, 28 Jun 2026 11:48:36 -0400, Alan Stern wrote:
> > How about "keep unrelated changes out of a stable patch", i.e. always
> > do the delay (if any) after the first request, regardless of size?  
> 
> This is not an unrelated change.  Rather, it's deciding on how to behave 
> in an entirely new control pathway -- the one where the 255-byte quirk 
> flag is set.  The old pathway is completely unaffected.
> 
> I suspect no devices will have both this quirk flag and the DELAY_INIT 
> flag set, which means the location of any delays in the new pathway 
> won't matter at all since they will never be used.

If no devices will have both quirks then new delay added before the
first configuration request will never execute.

If such devices will exist, then it probably won't matter whether the
delay comes after or before the first request. Purpose isn't known,
but it appears to be rate limiting configuration descriptor requests
or delaying other requests after this function returns.

Either way, no known need exists to add another delay before the first
request or alter the existing delay (or its conditions) in any way.

In general, I always object to code which serves no purpose because
such code is easy to add but very hard to remove when it gets in the
way. There are no known users, no test cases, only paranoia.

So I would keep the delay code completely unchaged.

And skip other random changes like error string nitpicking. Reliable
and up to date information about how many bytes are requested,
"expected" (what does it even mean, to somebody reading dmesg?),
received or verified to exist can be gained from source and usbmon.

A stable patch is supposedly supposed to be 100 lines with context ;)

Regards,
Michal