All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Dingyan Li <18500469033@163.com>
Cc: "stern@rowland.harvard.edu" <stern@rowland.harvard.edu>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
	"mathias.nyman@intel.com" <mathias.nyman@intel.com>,
	"pawell@cadence.com" <pawell@cadence.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"brcm80211-dev-list.pdl@broadcom.com"
	<brcm80211-dev-list.pdl@broadcom.com>,
	"linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"mina86@mina86.com" <mina86@mina86.com>,
	"clemens@ladisch.de" <clemens@ladisch.de>,
	"ruslan.bilovol@gmail.com" <ruslan.bilovol@gmail.com>,
	"bigeasy@linutronix.de" <bigeasy@linutronix.de>,
	"treding@nvidia.com" <treding@nvidia.com>,
	"oneukum@suse.com" <oneukum@suse.com>,
	"laurent.pinchart@ideasonboard.com"
	<laurent.pinchart@ideasonboard.com>,
	"nic_swsd@realtek.com" <nic_swsd@realtek.com>,
	"marcel@holtmann.org" <marcel@holtmann.org>
Subject: Re: [PATCH v3] USB: Extend usb_device_speed with new value USB_SPEED_SUPER_PLUS_BY2
Date: Fri, 1 Sep 2023 22:33:30 +0000	[thread overview]
Message-ID: <20230901223316.vbnf3zfjsxoogenb@synopsys.com> (raw)
In-Reply-To: <20230901160532.6313-1-18500469033@163.com>

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@163.com>
> ---

Can we 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

  parent reply	other threads:[~2023-09-01 22:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-01 16:05 [PATCH v3] USB: Extend usb_device_speed with new value USB_SPEED_SUPER_PLUS_BY2 Dingyan Li
2023-09-01 21:56 ` Thinh Nguyen
2023-09-01 22:33 ` Thinh Nguyen [this message]
2023-09-03  9:15   ` Dingyan Li
2023-09-07  0:13     ` Thinh Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230901223316.vbnf3zfjsxoogenb@synopsys.com \
    --to=thinh.nguyen@synopsys.com \
    --cc=18500469033@163.com \
    --cc=bigeasy@linutronix.de \
    --cc=brcm80211-dev-list.pdl@broadcom.com \
    --cc=clemens@ladisch.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --cc=mathias.nyman@intel.com \
    --cc=mina86@mina86.com \
    --cc=nic_swsd@realtek.com \
    --cc=oneukum@suse.com \
    --cc=pawell@cadence.com \
    --cc=ruslan.bilovol@gmail.com \
    --cc=stern@rowland.harvard.edu \
    --cc=treding@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.