Re: [PATCH 0/4] usb: usbtmc: fix undersized high-speed bulk packets on xHCI

[Michal Pecio]

On Wed, 21 Oct 2026 11:34:19 +0200, Nicolai Buchwitz wrote:
> I checked on Windows 11 (Intel xHCI, WinUSB + libusb): same
> descriptors as on Linux (HS, bulk wMaxPacketSize 64), and a single
> 4096 byte bulk IN read returns the complete 110 byte reply, so it
> seems, that Windows programs the 64 bytes into the endpoint instead
> of forcing 512.

Yes, that's what it seems to be doing. I passed a fake storage device
with weird endpoints to Windows 10 in QEMU and with some debug tracing
(slot/ep context hexdumps are my addition) I see this:

usb_xhci_fetch_trb addr 0x0000000139a3c450, CR_CONFIGURE_ENDPOINT, p 0x000000013a18d000, s 0x00000000, c 0x01003001
usb_xhci_slot_ctx addr 0x000000013a18d020, c 0x68000000 0x00000000 0x00000000 0x00000000
usb_xhci_ep_ctx addr 0x000000013a18d0a0, ep 4, c 0x00000000 0x00400016 0x39a3cc01 0x00000001 0x00000000
usb_xhci_ep_ctx addr 0x000000013a18d1c0, ep 13, c 0x00000000 0x00400036 0x375ff001 0x00000001 0x00000000

The 0x0040 in the second field is packet size, and it becomes 0x0400
when I change to 1024, or 0x0002 with 2050. Windows blindly copies
those eleven bits here and only gets upset if they are all zero, then
it resets and enumerates again a few times.

I don't have any out of spec device, so I tunned a Cypress FX2 into
one - it exactly replays every received packet back to the host. I
found that power of two sizes from 1 to 512 work, except on Etron HCs
which only take 512. Guess we could have an exception for those.

So this seems very viable. I will turn it into a proper patch and see
what the maintainers think. Seems better than patching class drivers.

Regards,
Michal