At 2023-08-20 03:03:05, "Alan Stern" <[email protected]> wrote:
>
>This would make more sense if you kept very clear the distinction
>between the overall speed and the physical communication mechanism. In
>other words, 10000 bps is 10000 bps, no matter whether the underlying
>technology uses one lane carrying 10000 bits per second or two lanes
>each carrying 5000 bits per second.
>
>I'm not sure if anything in the kernel or userspace really cares about
>the number of lanes, as opposed to the total speed. If it turns out
>that nothing does, the usb_ssp_rate enumeration could be removed.
>Besides, it should named something else, like usb_ssp_gen or
>usb_sp_generation, since it isn't just a rate designation. (Whereas as
>enum usb_device_speed _is_ just a rate designation.)
It seems that dwc3 code has a slightly different behaviors between
GEN_1x2 and GEN_2x1, so it's better to keep it. But I agree with you.
In enum usb_device_speed, we only care about overall speed instead of
physical links. And we could rename usb_ssp_rate to a more proper name.
>Regardless of what happens to usb_ssp_rate, usb_device_speed should be
>enlarged to encompass all possible existing speeds. That would
>immediately fix the ioctl problem. Doing this in an upward-compatible
>way might end up being a little awkward but it ought to be possible.
Thanks for the detailed explanation, which makes things more clear.
I'll take your suggestions and try again.
Regards,
Dingyan