[PATCH] usb: xhci: Relax high-speed bulk max packet size rules

[PATCH] usb: xhci: Relax high-speed bulk max packet size rules

[Michal Pecio]

Nicolai reported multiple dodgy high-speed devices still being made
which declare out-of-spec bulk wMaxPacketSize and actually require
the host to use it for correct operation. Apparently, Windows copies
this field to the EP Context verbatim and other Linux HCDs like EHCI
and DWC2 do similar things for compatibility's sake.

We are also aware of devices like astronomical cameras which use 1KB
to reduce protocol overhead, and audio devices with MIDI endpoints
that specify unusual MPS like 8 or 4 (the latter was full-speed) and
work with larger sizes just fine because they never do multi-packet
transfers where MPS really matters.

I found that sensible (power of two, 8 - 512) MPS are usable on many
xHCI controllers from vendors like AMD, ASMedia, Fresco, NEC/Renesas,
and VIA. Nicolai also tested two Raspberry Pi SBCs and a modern Intel
machine running Windows 11 and 64B endpoints worked.

OTOH, Etron rejects Configure Endpoint if MPS != 512. For such cases,
commit e4f47e3675e6 ("USB: xHCI: override bogus bulk wMaxPacketSize
values") sets HS bulk MPS to 512, which obviously breaks those dodgy
devices that perform multi-packet transfers with other size.

Problematic devices known so far use power of two MPS of at least 64,
so try to recognize them with this heuristic. Non power of two or
small MPS seems to indicate a clueless device which treats bulk like
interrupt and specifies intended transfer size; we will use standard
MPS here to avoid trouble with potential other HCs like Etron.

Reported-by: Nicolai Buchwitz <nb@tipi-net.de>
Closes: https://lore.kernel.org/linux-usb/20261020-fix-usbtmc-short-packets-v1-0-903f4d029193@tipi-net.de/
Link: https://lore.kernel.org/linux-usb/93d5aeb4-f1c7-9342-7bc5-4b277b4ec55e@veikia.lt/
Link: https://lore.kernel.org/alsa-devel/CAE-xCyPhrS6pgY0T9SG0TCubSi0CE2Yd5H=ttOzBmvgrR8fTPA@mail.gmail.com/
Link: https://lore.kernel.org/linux-usb/348c50de-f922-8295-ef87-cf5cdea5c7f4@gmail.com/
Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
---
 drivers/usb/host/xhci-mem.c | 18 +++++++++++++++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 83ed26c4f9e4..bbde39ccc4f9 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1473,10 +1473,22 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
 	/* Allow 3 retries for everything but isoc, set CErr = 3 */
 	if (!usb_endpoint_xfer_isoc(&ep->desc))
 		err_count = 3;
-	/* HS bulk max packet should be 512, FS bulk supports 8, 16, 32 or 64 */
+
 	if (usb_endpoint_xfer_bulk(&ep->desc)) {
-		if (udev->speed == USB_SPEED_HIGH)
-			max_packet = 512;
+		/*
+		 * HS MPS should be 512, but Windows lets devices use anything.
+		 * Etron rejects MPS != 512, many HCs dislike >512 and a few <8.
+		 * Non power of 2 troubles Fresco, hopefully it means the device
+		 * uses single-packet transfers only and 512 will work. Some 64B
+		 * endpoints (shared FS / HS logic?) use multi-packet transfers,
+		 * so MPS must be exact. 1KB EPs are unlikely to tolerate less.
+		 */
+		if (udev->speed == USB_SPEED_HIGH) {
+			if ((xhci->quirks & XHCI_ETRON_HOST) ||
+			    !is_power_of_2(max_packet) || max_packet < 64)
+				max_packet = 512;
+		}
+		/* FS bulk supports 8, 16, 32 or 64 */
 		if (udev->speed == USB_SPEED_FULL) {
 			max_packet = rounddown_pow_of_two(max_packet);
 			max_packet = clamp_val(max_packet, 8, 64);
-- 
2.48.1

Re: [PATCH] usb: xhci: Relax high-speed bulk max packet size rules

[sashiko-bot]

> Nicolai reported multiple dodgy high-speed devices still being made
> which declare out-of-spec bulk wMaxPacketSize and actually require
> the host to use it for correct operation. Apparently, Windows copies
> this field to the EP Context verbatim and other Linux HCDs like EHCI
> and DWC2 do similar things for compatibility's sake.
> 
> We are also aware of devices like astronomical cameras which use 1KB
> to reduce protocol overhead, and audio devices with MIDI endpoints
> that specify unusual MPS like 8 or 4 (the latter was full-speed) and
> work with larger sizes just fine because they never do multi-packet
> transfers where MPS really matters.
> 
> I found that sensible (power of two, 8 - 512) MPS are usable on many
> xHCI controllers from vendors like AMD, ASMedia, Fresco, NEC/Renesas,
> and VIA. Nicolai also tested two Raspberry Pi SBCs and a modern Intel
> [ ... ]
> Closes: https://lore.kernel.org/linux-usb/20261020-fix-usbtmc-short-packets-v1-0-903f4d029193@tipi-net.de/
> Link: https://lore.kernel.org/linux-usb/93d5aeb4-f1c7-9342-7bc5-4b277b4ec55e@veikia.lt/
> Link: https://lore.kernel.org/alsa-devel/CAE-xCyPhrS6pgY0T9SG0TCubSi0CE2Yd5H=ttOzBmvgrR8fTPA@mail.gmail.com/
> Link: https://lore.kernel.org/linux-usb/348c50de-f922-8295-ef87-cf5cdea5c7f4@gmail.com/
> Signed-off-by: Michal Pecio <michal.pecio@gmail.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261028104329.3d1c8029.michal.pecio@gmail.com?part=1

Re: [PATCH] usb: xhci: Relax high-speed bulk max packet size rules

[Nicolai Buchwitz]

Hi Michal

On Wed, 2026-10-28 at 10:43 +0100, Michal Pecio wrote:
> Nicolai reported multiple dodgy high-speed devices still being made
> which declare out-of-spec bulk wMaxPacketSize and actually require
> the host to use it for correct operation. Apparently, Windows copies
> this field to the EP Context verbatim and other Linux HCDs like EHCI
> and DWC2 do similar things for compatibility's sake.

Thanks for picking this up!

> 
> We are also aware of devices like astronomical cameras which use 1KB
> to reduce protocol overhead, and audio devices with MIDI endpoints
> that specify unusual MPS like 8 or 4 (the latter was full-speed) and
> work with larger sizes just fine because they never do multi-packet
> transfers where MPS really matters.
> 
> I found that sensible (power of two, 8 - 512) MPS are usable on many
> xHCI controllers from vendors like AMD, ASMedia, Fresco, NEC/Renesas,
> and VIA. Nicolai also tested two Raspberry Pi SBCs and a modern Intel
> machine running Windows 11 and 64B endpoints worked.
> 
> OTOH, Etron rejects Configure Endpoint if MPS != 512. For such cases,
> commit e4f47e3675e6 ("USB: xHCI: override bogus bulk wMaxPacketSize
> values") sets HS bulk MPS to 512, which obviously breaks those dodgy
> devices that perform multi-packet transfers with other size.
> 
> Problematic devices known so far use power of two MPS of at least 64,
> so try to recognize them with this heuristic. Non power of two or
> small MPS seems to indicate a clueless device which treats bulk like
> interrupt and specifies intended transfer size; we will use standard
> MPS here to avoid trouble with potential other HCs like Etron.
> 
> Reported-by: Nicolai Buchwitz <nb@tipi-net.de>
> Closes:
> https://lore.kernel.org/linux-usb/20261020-fix-usbtmc-short-packets-v1-0-903f4d029193@tipi-net.de/
> Link:
> https://lore.kernel.org/linux-usb/93d5aeb4-f1c7-9342-7bc5-4b277b4ec55e@veikia.lt/
> Link:
> https://lore.kernel.org/alsa-devel/CAE-xCyPhrS6pgY0T9SG0TCubSi0CE2Yd5H=ttOzBmvgrR8fTPA@mail.gmail.com/
> Link:
> https://lore.kernel.org/linux-usb/348c50de-f922-8295-ef87-cf5cdea5c7f4@gmail.com/
> Signed-off-by: Michal Pecio <michal.pecio@gmail.com>
> ---
> [...]


I ran the patch on a Raspberry Pi CM4S with a Rigol DP832A.
Multi-packet replies up to ~1 KB and writes up to 760 bytes
work fine. dmesg doesn't show anything suspicious.


Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Tested-by: Nicolai Buchwitz <nb@tipi-net.de> # BCM2711 in XHCI mode

Regards,
Nicolai

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