Re: [PATCH] usb: core: Fix bandwidth for devices with invalid wBytesPerInterval

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

On Wed, 22 Apr 2026 21:26:23 +0800, Xuetao (kirin) wrote:
> By adding debug and capturing USB protocol analyzer traces, I have 
> identified the pattern of this issue:
> 
> 1. Why doesn't the Realtek USB 3.0 network adapter have this problem?
> 
> Realtek has two different types of interrupt endpoints:
> (1) wMaxPacketSize = 0x10, bMaxBurst = 0, wBytesPerInterval = 0x8
> (2) wMaxPacketSize = 0x2, bMaxBurst = 0, wBytesPerInterval = 0x2
> 
> The Realtek network adapter uses the r8152.c driver. In
> rtl8152_open() -> usb_submit_urb(tp->intr_urb, GFP_KERNEL), the
> length of tp->intr_urb is fixed at 0x2.
> The Realtek USB 3.0 network adapter uses the endpoint with 
> wBytesPerInterval = 0x2 for network status queries. Since 
> wBytesPerInterval = wMaxPacketSize × (bMaxBurst + 1) = 2, there is no 
> problem.

... until it's switched to its CDC configuration with a kernel patch,
then there is a problem. That CDC endpoint sends more than 8 bytes.

CDC is used as fallback on chip revs not yet supported by r8152 and
we aren't sure if future chips will fix their descriptors.

> 2. The ASIX AX88179 USB 3.0 network adapter exhibits two different
> symptoms:
> 
> ASIX AX88179 has two different interrupt endpoint descriptors:
> (1) wMaxPacketSize = 0x10, bMaxBurst = 0, wBytesPerInterval = 0x0
> (2) wMaxPacketSize = 0x10, bMaxBurst = 0, wBytesPerInterval = 0x8
> 
> The ASIX AX88179 network adapter uses the ax88179_178a.c driver. In 
> usbnet_open() -> usbnet_status_start() ->
> usb_submit_urb(dev->interrupt, mem_flags), the length of
> dev->interrupt is 0x10.
> 
> (1) When wBytesPerInterval = 0x8: When the software submits the INT
> URB, the host controller can normally send an INT IN request. If the
> device returns data length ≤ 8 bytes, the host and device interact
> normally, and the network works.
> However, if the network adapter responds within one interval with a 
> packet carrying 16 bytes of data, a specific host controller reports
> a babble error, causing network failure.
> 
> (2) When wBytesPerInterval = 0x0: The host controller does not
> reserve any bandwidth for the device. When the software submits the
> INT URB, a specific host controller does not issue an INT IN request
> to the device, nor does it report an error to the software.

I think it's a HW bug because USB specs allow zero-length interrupt
transfers, though an inconsequential one if no device uses them.

These patches will work around it, because zero wMaxPacketSize is
disallowed by USB3 spec (though not by earlier ones) so wBPI will
always increase to at least 1.

> Verification results:
> 
> Patch 1:
> In usb_parse_ss_endpoint_companion(), if the interrupt endpoint's 
> wBytesPerInterval is 0, set wBytesPerInterval to wMaxPacketSize × 
> (bMaxBurst + 1).
> 
> Result 1:
> This resolves the issue for ASIX AX88179 adapters with
> wBytesPerInterval = 0. However, for the scenario where
> wBytesPerInterval = 0x8, wMaxPacketSize = 0x10, and the device
> returns a 16-byte data payload, a babble error still occurs.

And it will be same thing for RTL8153 CDC. This is too strict.

> Patch 2:
> In xhci_get_max_esit_payload(), when udev->speed >= USB_SPEED_SUPER,
> for interrupt endpoints return the maximum value between 
> ep->ss_ep_comp.wBytesPerInterval and (max_burst + 1) × max_packet.
> 
> Result 2:
> This resolves both scenarios described above. The only downside is
> that this modification may cause the host to waste a small amount of
> bandwidth.

I wrote a small patch which adds very similar logic to
usb_parse_ss_endpoint_companion(). This has two benefits:

1. Backportability - ESIT payload code has been refactored recently.
2. We can easily log when the tweak is performed, once per device.
   Maybe some HW vendors will notice and clean up their act.

Regards,
Michal