Messages in this thread | | | Date | Sun, 20 Aug 2023 13:29:11 +0800 (CST) | From | "Dingyan Li" <> | Subject | Re:Re: [PATCH v2] USB: Support 20Gbps speed for ioctl USBDEVFS_GET_SPEED |
| |
At 2023-08-20 03:03:05, "Alan Stern" <stern@rowland.harvard.edu> 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
| |