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

Xuetao (kirin)
2026-04-03T01:20:56Z

在 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