linux-kernel - Re:Re: [PATCH v2] USB: Support 20Gbps speed for ioctl USBDEVFS_GET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <75cfc7cb.b4c.18a116b2e2e.Coremail.18500469033@163.com>
Date:   Sun, 20 Aug 2023 13:29:11 +0800 (CST)
From:   "Dingyan Li" <18500469033@....com>
To:     "Alan Stern" <stern@...land.harvard.edu>
Cc:     gregkh@...uxfoundation.org, hdegoede@...hat.com,
        xiaofanc@...il.com, oneukum@...e.com, lists.tormod@...il.com,
        sebastian.reichel@...labora.com, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re:Re: [PATCH v2] USB: Support 20Gbps speed for ioctl
 USBDEVFS_GET_SPEED


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