At 2023-08-20 03:03:05, "Alan Stern" <stern@xxxxxxxxxxxxxxxxxxx> 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
