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

[Nicolai Buchwitz <nb@tipi-net.de>]

On 23.10.2026 20:26, Michal Pecio wrote:
> 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.

Thanks! If you need something testing with the devices I have at hand, 
please let me know.

Regards,
Nicolai