[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230901215625.lzazscyhkmb4ggdi@synopsys.com>
Date: Fri, 1 Sep 2023 21:56:33 +0000
From: Thinh Nguyen <Thinh.Nguyen@...opsys.com>
To: "07c821ae-2391-474c-aec9-65f47d3fecf2@...land.harvard.edu"
<07c821ae-2391-474c-aec9-65f47d3fecf2@...land.harvard.edu>
CC: "stern@...land.harvard.edu" <stern@...land.harvard.edu>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"mathias.nyman@...el.com" <mathias.nyman@...el.com>,
"pawell@...ence.com" <pawell@...ence.com>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
"brcm80211-dev-list.pdl@...adcom.com"
<brcm80211-dev-list.pdl@...adcom.com>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"mina86@...a86.com" <mina86@...a86.com>,
"clemens@...isch.de" <clemens@...isch.de>,
"ruslan.bilovol@...il.com" <ruslan.bilovol@...il.com>,
"balbi@...com" <balbi@...com>,
"bigeasy@...utronix.de" <bigeasy@...utronix.de>,
"treding@...dia.com" <treding@...dia.com>,
"oneukum@...e.com" <oneukum@...e.com>,
"laurent.pinchart@...asonboard.com"
<laurent.pinchart@...asonboard.com>,
"nic_swsd@...ltek.com" <nic_swsd@...ltek.com>,
"marcel@...tmann.org" <marcel@...tmann.org>
Subject: Re: [PATCH v3] USB: Extend usb_device_speed with new value
USB_SPEED_SUPER_PLUS_BY2
Hi,
Please Cc me for changes related to dwc3.
On Sat, Sep 02, 2023, Dingyan Li wrote:
> Currently there are there major generations when speaking of
> USB_SPEED_SUPER_PLUS devices. However, they actually stands
> for different physical speeds. GEN_2x2 means 20Gbps, while
> the others mean 10Gbps. So in order to confirm 20Gbps, both
> speed and generation need ti be checked. This causes a trouble
> for ioctl USBDEVFS_GET_SPEED since it can only return speed
> value to userspace.
>
> In order not to add a new ioctl to get ssp generation, extending
> usb_device_speed is a good option. The side effect is that
> USB_SPEED_SUPER_PLUS has been used in lots of places and
> it also takes some effort to go through all of them and check
> whether the new speed should be used too.
>
> Besides, as suggested by Alen, ssp_rate is not a proper name,
> change it to ssp_gen. And change all functions/struct fileds
> ended with ssp_rate to ssp_gen. And there is also some code
> refactor to reduce duplicate definition of strings and increase
> the utilization of commonly defined utilities.
>
> Signed-off-by: Dingyan Li <18500469033@....com>
Why not spell out the whole thing instead of USB_SPEED_SUPER_PLUS_BY2
(ie. USB_SPEED_SUPER_PLUS_GEN_2x2) as you intended instead of just the
lane count.
There are SuperSpeed Plus generation _and_ lane count. That's why I
didn't name "usb_ssp_gen" that only reflects the generation and not the
lane count. Also, I didn't extend usb_device_speed because gen XxY are
all a single speed: SuperSpeed Plus.
If you're planning to do it this way, why not add the other speeds (such
as gen 1x2) to usb_device_speed enum too? Then we can drop the
usb_ssp_rate enum. If we're going to check multiple enum for SuperSpeed
Plus, we probably need a usb_device_is_superspeed_plus() function.
Now we need to audit all the greater/lesser speed checks that use < or >
to make sure that they are used how they were intended to.
Since these changes are not simple and will touch on multiple places,
please split this patch out.
Thanks,
Thinh
Powered by blists - more mailing lists