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

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

On Thu, 2 Apr 2026 09:56:51 -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.

Not sure, this could backfire if it turns out that these workarounds
will need to become more elaborate and account for wBytesPerInterval.

These descriptors aren't blatantly invalid. USB3 9.6.7 doesn't require
that wBytesPerInterval == wMaxPacketSize * bMaxBurst * Mult.

Being greater would be blatantly invalid, but this is already being
sanitized by the descriptor parser.

> > However, when parsing the device descriptor, we do not know whether
> > the actual data length transmitted by the peripheral is greater than
> > wBytesPerInterval.  

Indeed. Device is allowed (actually: required) not to send more data
than its wBytesPerInterval on IN endpoints.

UVC driver uses this field to pick isochronous altsetting capable of
transmitting a particular payload each interval. If we overestimate,
there is risk that the device will deliver on its promise and truncate
instead of violating USB3 spec. We should rather pick a larger alt.

OTOH, when a device lies and sends more than specified, this happens.
Some HCs ignore the problem (and may overcommit bandwidth if we enable
million such endpoints), others get pedantic and return Babble Error
(my mistake, Bandwidth Overrun is specific to isochronous).


I think this patch is relatively safe for interrupt, because drivers
generally don't look at endpoint descriptors and submit URBs of class
specific size. Case in point, everything works when you override xHCI
allocation. It also works on HCs ignoring it.

Beind the pedant I am, I would restrict this to bMaxBurst==0 because
that's the known problem case and IDK off-hand what devices might use
bursting interrupt endpoints and what gotchas await there.

Maybe add a comment that it's a questionable, spec-violating hack.

Regards,
Michal