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

["Xuetao (kirin)" <xuetao09@huawei.com>]

在 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