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

[Xuetao (kirin)]

在 2026/4/3 9:20, Xuetao (kirin) 写道:
> 在 2026/4/2 22:09, Greg KH 写道:
> > On Thu, Apr 02, 2026 at 09:56:51AM -0400, Alan Stern wrote:
> > > On Thu, Apr 02, 2026 at 02:59:35PM +0800, Xuetao (kirin) wrote:
> > > > 2、Following Alan's suggestion in another email, should I check whether
> > > > wBytesPerInterval is a valid value and handle it in the
> > > > usb_parse_ss_endpoint_companion() ?
> > >
> > > Yes, IMO.
> > >
> > > > However, when parsing the device descriptor, we do not know whether the
> > > > actual data length transmitted by the peripheral is greater than
> > > > wBytesPerInterval.
> > >
> > > Note: wBytesPerInterval is in the endpoint descriptor, not the device
> > > descriptor.
>
> Thank you for your review. I will correct the description in the 
> subsequent patch.
>
> > > > Therefore, would it be sufficient to only add a check for whether
> > > > wBytesPerInterval is 0 in the existing flow, and if it is 0, set
> > > > wBytesPerInterval to cpu_to_le16(max_tx) by default?
> > > >
> > > > For example, modify it in the following way：
> > > >
> > > >       if (le16_to_cpu(desc->wBytesPerInterval) > max_tx ||
> > > > le16_to_cpu(desc->wBytesPerInterval) == 0) {
> > > >          dev_notice(ddev, "%s endpoint with wBytesPerInterval of %d 
> > > > in "
> > > >                  "config %d interface %d altsetting %d ep %d: "
> > > >                  "setting to %d\n",
> > > >                  usb_endpoint_xfer_isoc(&ep->desc) ? "Isoc" : "Int",
> > > >                  le16_to_cpu(desc->wBytesPerInterval),
> > > >                  cfgno, inum, asnum, ep->desc.bEndpointAddress,
> > > >                  max_tx);
> > > >          ep->ss_ep_comp.wBytesPerInterval = cpu_to_le16(max_tx);
> > > >      }
> > > >
> > > >   Could you please give me some advice? Thanks.
> > >
> > > Try it and see if it fixes the problems you see with the network
> > > adapters.
>
> Okay, I will verify the effectiveness of this modification and provide 
> feedback on the results.

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.

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. The device controller never 
receives the INT IN request, so the network fails.


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.

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 guess that for the scenario where wBytesPerInterval is 0, it should be 
> solvable. However, for the scenario where wBytesPerInterval is 8 but the 
> peripheral sends a data length greater than 8 (e.g., 16), there might be 
> an issue. I will test both of the above scenarios.
>
> > > I saw the Greg said not to change the descriptors and just fail the
> > > device, but we already make this sort of change to correct other errors
> > > so there doesn't seem to be any reason not to do it here as well.
> > > Especially if it allows people to use devices that otherwise would not
> > > work.
> >
> > I didn't realize this was on "real" devices, sorry.  I thought this was
> > only a fuzzing thing.  So yes, fix up the broken descriptor after
> > warning about it is the correct thing to do.
> >
> > thanks,
> >
> > greg k-h