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

[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.

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