* [PATCH] usb: xhci: Relax high-speed bulk max packet size rules
@ 2026-10-28 9:43 Michal Pecio
0 siblings, 0 replies; only message in thread
From: Michal Pecio @ 2026-10-28 9:43 UTC (permalink / raw)
To: Mathias Nyman, Greg Kroah-Hartman, Nicolai Buchwitz
Cc: linux-usb, linux-kernel
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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2026-10-28 9:43 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-10-28 9:43 [PATCH] usb: xhci: Relax high-speed bulk max packet size rules Michal Pecio
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®