Re: USB: Request for guidance investigating configuration descriptor enumeration failure

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

On Sun, 7 Jun 2026 21:34:37 -0400, Alan Stern wrote:
> On Sun, Jun 07, 2026 at 11:25:35PM +0200, Michal Pecio wrote:
> > Ipad is interesting because the single Device request must be a
> > high-speed optimization, or they hacked their xHC to ignore short
> > packets and keep reissuing IN tokens until the URB is filled.  
> 
> I would guess it's the former.  The only real reason for having a
> short request first is because for full-speed connections, the host
> doesn't know what the ep0 maxpacket length is until it sees the
> descriptor.

I wouldn't 100% rule out Apple being nuts enough to do the latter too
to squeeze out the last few ms of enumeration latency. But of course
it's impossible on any standard HC and only of academic interest.

I found that OSX 14 for Intel Macs in QEMU does an initial 8 byte
request at FS but omits it at HS and SS. And it uses the 9/wTotalLength
config sequence seen in iPad.

So they migrated away from 8/wTotalLength and it's interesting that
they chose to ape Linux rather than Windows. Is Android the new
Microsoft? The Windows scheme seems more efficient, its only drawback
being risk of buggy devices.

> > Linux has been doing the initial 8 or 64 byte read at LS and HS
> > since forever and I found no explanation besides nobody daring to
> > touch it.  
> 
> That's the explanation.  Originally Linux always did the 8-byte read.
> But some devices didn't like it, and we saw that Windows used a
> 64-byte read.  So we copied the Windows behavior, with a fallback to
> the original behavior (which is what the spec recommends) when
> needed.  Even for LS and HS, because that's what Windows does.
> 
> > Though I wonder if it wouldn't make sense to skip this at SS,
> > because Windows does (in my QEMU tests) and very likely Apple too.  
> 
> I'd be fine with that.  OTOH, if it's not broken, you don't need to
> fix it.

Actually it's partly broken - xhci-hcd completely ignores udev->ep0.desc
of SuperSpeed devices and uses 512 as per spec. So the request only
exists for its side effects, if any, and it's somewhat unique to Linux.

And of coures there are totally broken cases: devices which disconnect
when queried for BOS by Linux but don't disconnect on Windows (which
likely queries them too). And I have one device which returns broken
descriptors depending on how fast I insert the plug (seriously) and of
course it doesn't have this problem in Windows.

The former does look like something that descriptor request size and
ordering might fix, but I don't have that HW.

For the latter, I tried without high expectations nor any success yet:

e079d3125493 usb: core: Issue Set Isochronous Delay later
49475308741e usb: core: Fetch the Configuration Descriptor with 255 length
7606f13ab0d1 usb: core: Don't fetch SuperSpeed Device Descriptor twice

Currently I get a usb_choose_configuration() crash after moving the
usb_enumerate_device() call from usb_new_device() to hub_port_init()
to reorder it against BOS. Will need to investigate later.

Regards,
Michal