Re: [PATCH 1/2] USB: Add support to store lane count used by USB 3.2

2018-03-13 Thread Felipe Balbi

Hi,

Mathias Nyman  writes:

> USB 3.2 specification adds Dual-lane support, doubling the maximum
> SuperSpeedPlus data rate from 10Gbps to 20Gbps.
>
> Dual-lane takes into use a second set of rx and tx wires/pins in the
> Type-C cable and connector.
>
> Add a "lanes" variable to struct usb_device to store the numer of lanes
> in use. Number of lanes can be read using the extended port status hub
> request that was introduced in USB 3.1.
>
> Extended port status rx and tx lane count are zero based, maximum
> lanes supported by usb 3.2 is 2 (dual lane).
> If extended port status is not available then default to one lane.
>
> Signed-off-by: Mathias Nyman 
> ---
>  drivers/usb/core/hub.c | 6 ++
>  include/linux/usb.h| 2 ++
>  2 files changed, 8 insertions(+)
>
> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
> index c5c1f6c..853516d 100644
> --- a/drivers/usb/core/hub.c
> +++ b/drivers/usb/core/hub.c
> @@ -2742,6 +2742,12 @@ static int hub_port_wait_reset(struct usb_hub *hub, 
> int port1,
>   if (!udev)
>   return 0;
>  
> + if (hub_is_superspeedplus(hub->hdev))
> + udev->lanes = ((ext_portstatus &
> + USB_EXT_PORT_STAT_RX_LANES) >> 8) + 1;

should this be udev->rx_lanes instead? We have macros for both TX and RX
lanes:

#define USB_EXT_PORT_STAT_RX_SPEED_ID   0x000f
#define USB_EXT_PORT_STAT_TX_SPEED_ID   0x00f0
#define USB_EXT_PORT_STAT_RX_LANES  0x0f00
#define USB_EXT_PORT_STAT_TX_LANES  0xf000

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH 1/2] USB: Add support to store lane count used by USB 3.2

2018-03-13 Thread Mathias Nyman

On 13.03.2018 17:29, Felipe Balbi wrote:


Hi,

Mathias Nyman  writes:


USB 3.2 specification adds Dual-lane support, doubling the maximum
SuperSpeedPlus data rate from 10Gbps to 20Gbps.

Dual-lane takes into use a second set of rx and tx wires/pins in the
Type-C cable and connector.

Add a "lanes" variable to struct usb_device to store the numer of lanes
in use. Number of lanes can be read using the extended port status hub
request that was introduced in USB 3.1.

Extended port status rx and tx lane count are zero based, maximum
lanes supported by usb 3.2 is 2 (dual lane).
If extended port status is not available then default to one lane.

Signed-off-by: Mathias Nyman 
---
  drivers/usb/core/hub.c | 6 ++
  include/linux/usb.h| 2 ++
  2 files changed, 8 insertions(+)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c5c1f6c..853516d 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2742,6 +2742,12 @@ static int hub_port_wait_reset(struct usb_hub *hub, int 
port1,
if (!udev)
return 0;
  
+	if (hub_is_superspeedplus(hub->hdev))

+   udev->lanes = ((ext_portstatus &
+   USB_EXT_PORT_STAT_RX_LANES) >> 8) + 1;


should this be udev->rx_lanes instead? We have macros for both TX and RX
lanes:

#define USB_EXT_PORT_STAT_RX_SPEED_ID   0x000f
#define USB_EXT_PORT_STAT_TX_SPEED_ID   0x00f0
#define USB_EXT_PORT_STAT_RX_LANES  0x0f00
#define USB_EXT_PORT_STAT_TX_LANES  0xf000



This is one part of the discussion, For non-SSIC devices, the lane count is
symmetric so rx_lanes = tx_lanes.
The USB 3.2 Gen XxY notion seems to only cover symmetric lane counts as
the "Y" part describes one generic "lane count".

See USB 3.2 section 8.5.6.7:
"Asymmetric Lane Types may only be reported by SuperSpeed Interchip (SSIC) 
devices. A
Symmetric link is one that has the same Lane Speed and number of lanes for both 
the Rx and
Tx Sublinks. Enhanced SuperSpeed devices shall only support Symmetric links."

and definition on Gen XxY in section 2. Terms and abbreviations

"X refers to the rate of signaling on the wire (Gen 1, Gen 2, etc.) and Y 
refers to
the number of lanes."

-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html