Re: [PATCH 0/2] USB 3.2 initial support

[Adrian Bocaniciu]

On Tue, 13 Mar 2018 17:27:21 +0200
Mathias Nyman  wrote:

> Example for clarification:
> Gen 1x1 = 5Gbps, SuperSpeed, one lane, same as USB3.0, and USB 3.1 Gen1
> Gen 2x1 = 10Gbps, SuperSpeedPlus, one lane, same as USB 3.1 Gen2
> Gen 1x2 = 10Gbps, SuperSpeed, Dual-lane (2 x 5Gbps)
> Gen 2x2 = 20Gbps, SuperSpeedPlus, Dual-lane (2 x 10Gbps)
> 
> 
> 4. Should the "speed" sysfs entry be more accurate? USB 3.1 and later
>can list different supported lane speeds other than the 5Gbps or 10Gbps.
>actual port speed would be lane count * current lane speed in use.
>Or do we just keep it simple and show the maximum signaling
>rate * lane count, i.e. 5000, 1 or 2?
> and show "SSIC" instead of "Gen XxY" for asymetric lane SSIC devices,
> skipping details on rx and tx lane counts.
> 

Please do not compute "signaling rate * count", because it is very misleading 
and that value cannot be used to verify whether the hardware works at its 
maximum available speed or not.

Gen 1x2 is not 5 * 2 = 10 Gbps, but only 8 Gbps (like Gb Ethernet is 1 Gbps, 
not 1.25 Gbps), while Gen 2x1 is very close to 10 Gbps, i.e. significantly 
faster (due to a different encoding), so it would be wrong to display them as 
equivalent.

 Best regards!

--
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: USB-C Devices only show up if connected at boot

[Adrian Bocaniciu]

On Tue, 23 Jan 2018 17:43:27 +
Mike Lothian  wrote:

> Hi
> 
> I've applied all BIOS updates for my laptop including the pulled one
> for Spectre/Meltdown & ME bugs the other week
> http://www.dell.com/support/home/uk/en/ukdhs1/product-support/servicetag/8k5w662/drivers
> 
> If it helps, I don't have this issue in Windows but I rarely have it booted
> 
> I thought it might have something to do with an ACPI failure (see bug
> https://bugzilla.kernel.org/show_bug.cgi?id=198051)
> 
> Regards
> 
> Mike
> --
> 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
> 


Hi Mike,

You did not specify what provides the USB-C port.

I suppose that your USB-C port is actually a Thunderbolt 3 port from an Intel 
controller.

What you describe is a well known bug that affects all Thunderbolt 3 ports and 
this bug has always existed in Linux, including until now.


I also have a Dell laptop, some Intel NUCs and some ATX motherboards with 
Thunderbolt 3 ports, all of which have this bug.

On the other hand, all the USB C ports that I have seen, which are connected to 
other USB controllers, e.g. from ASMedia, those work normally, they do not have 
this bug.

Best regards !









--
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: Type-C port on the Asmedia ASM1142

[Adrian Bocaniciu]

On Fri, 29 Sep 2017 09:06:16 +
David Laight  wrote:

> > The correct names used in the new specification for the 4 speeds that can 
> > be supported by a USB 3
> > interface are: .
> 
> I think I'd add the speed itself as well.
> 
>   David


I was reffering mostly to the identifiers and comments used in the kernel 
source code.

When the speeds are displayed to a user, e.g. in log messages or in the lsusb 
output, you are of course right, the numeric speeds should also be shown.

Nevertheless, there is a problem with that.

The correct speeds would be:
"Gen 1x1 (4 Gb/s)", "Gen 1x2 (8 Gb/s)", "Gen 2x1 (10 Gb/s)",  and "Gen 2x2 (20 
Gb/s)".

But we are forced to show "Gen 1x1 (5 Gb/s)", because this is what most users 
expect.


There is a stupid tradition started by someone at Intel, I suppose from 
marketing, who had the mean idea of presenting SATA 1.0 as 1.5 Gb/s and PCIe 
1.0 as 2.5 Gb/s.

Before that, nobody thought that it would be right to present, e.g. Gigabit 
Ethernet as having a speed of 1.25 Gb/s.

This deceitful method was used since then for all SATA and SAS, and also for 
PCIe 2.0 and for USB 3.0.


In my opinion, we should display the USB 3 speeds so:

"Gen 1x1 (5 Gb/s)", "Gen 1x2 (8 Gb/s)", "Gen 2x1 (10 Gb/s)",  and "Gen 2x2 (20 
Gb/s)".


While this might confuse some users about why Gen 1x2 is not shown as having a 
double speed, I believe that the confusion created by seeing "Gen 1x2 (10 
Gb/s)", i.e. as having the same speed as "Gen 2x1" will be worse, because the 
users would be fooled in believing that a "Gen 1x2" device is worth the same 
money as a "Gen 2x1" device, when in fact the latter is 25% faster.















--
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: Type-C port on the Asmedia ASM1142

[Adrian Bocaniciu]

On Thu, 28 Sep 2017 14:09:04 +0300
Felipe Balbi  wrote:

> 
> 
> Actually, I think we should go the other way around:
> 
> psic = read_psic_from_register();
> 
> if (psic)
>   setup_supported_speeds_based_on_psic(xhci, psic);
> else
>   setup_supported_speeds_using_default_mappings(xhci);
> 
> This should be enough to sort everything out (assuming no-quirky HW, of
> course). Even if a new spec is released defining a new default mapping
> for 10Gbps and/or adding 0x31 to SBRN, we really don't need to rely on
> that.
> 
> Well, maybe we can rely on SBRN to append a new default
> mapping. Something like (also considering possible quirky hosts):
> 

I also agree with this.


Meanwhile, the USB 3.2 specification has been published.

While much of it was already known, I was curious to see what names will be 
used fothe additional interface speeds.

I really hoped that there will be no inventions of new words, such as 
HyperEnhancedSuperSpeedExtraPlus.

Fortunately, they gave up on such names and they have chosen a more rational 
approach.

Even if the following words are not officially deprecated, we should really 
stop using them, because in the new specification they have become ambiguous 
and their use conveys no useful information: "SuperSpeed", "Enhanced 
SuperSpeed", "SuperSpeedPlus".

The correct names used in the new specification for the 4 speeds that can be 
supported by a USB 3 interface are: "Gen 1x1", "Gen 2x1", "Gen 1x2" and "Gen 
2x2".

In my opinion, when the speed related code from the xHCI driver will be revised 
now, this opportunity should also be used to purge the junk names "SuperSpeed", 
"Enhanced SuperSpeed" and "SuperSpeedPlus" and replace them with the 4 precise 
names for the 4 speeds supported by USB 3.








--
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: Type-C port on the Asmedia ASM1142

[Adrian Bocaniciu]

On Wed, 27 Sep 2017 11:03:41 +0300
Mathias Nyman  wrote:

> Ok, please let me know which register you refer to, I'd like to get this 
> fixed as soon as possible.
> Based on what you say I suspect that you talk about the SBRN (Serial bus 
> release number).
> 
> The early xhci 1.1 spec that was used to write USB3.1 SSP support stated that 
> SBRN contain
> the serial bus specification release, (in hex) with examples of 30h for USB 
> 3.0 and 31h for USB 3.1
> 
> Driver uses this to determine if hosts supports USB 3.0 or usb 3.1
> 
> I see that the current public xhci spec only mention 30h (USB 3.0), and in a 
> way that it can be
> interpreted as 30 being the only option.
> If this is the case then SBRN itself would be completely useless.
> Why have a register with the purpose of telling which serial bus release 
> number the hardware
> supports always forced to 30h?
> 
> Yes, the first Intel Alpine ridge based USB 3.1 SSP 10Gbps xHCI hosts had 
> this as 30,
> Newer Intel USB 3.1 SSP capable 10Gbps xHCI hosts have it set to 31h
> 
> If vendors have interpreted it as "SBRN must equal 30h" then we need to work
> around that in the driver.
> 
> We can check if the host supports USB 3.1 from the ports supported protocol 
> capability,
> see xhci 7.2 xHCI supported protocol capability, major and minor revision 
> fields. These
> should at least contain major=3 and minor=1 for USB 3.1 capable ports.
> 
> That at least is unambiguous in all xhci specs (early, and current public)


Yes, indeed, your guess is correct. I was writing about SBRN.

In the function "xhci_pci_setup", from the file "drivers/usb/host/xhci-pci.c", 
SBRN is read and stored in "xhci->sbrn".

Then, in the function "xhci_gen_setup", from the file 
"drivers/usb/host/xhci.c", the value of "xhci->sbrn" is checked. If it is 0x31, 
then support for 10 Gb/s is assumed.

This check was introduced in a patch from the 1st October 2015. It must have 
worked once, because I have seen some Linux screen shots with the output of 
lsusb showing some xHCI controller with 10 Gb/s support.

I am not aware of any USB 3.1 controllers that existed in 2015 and that could 
have SBRN equal to 0x31, except for some earlier ASMedia controllers. AFAIK, 
there were at least 2 versions before ASM 1142, so one or both of them must 
have had SBRN equal to 0x31.

I have verified on many motherboards that both Alpine Ridge and ASM 1142 have 
SBRN equal to 0x30. Moreover, the ASM 1142 datasheet says clearly that SBRN is 
0x30. Therefore, I believe that ASMedia has understood the xHCI specification 
exactly as it is written, i.e. that SBRN must be 0x30, and they have reverted 
its value from the earlier 0x31 to 0x30. There are at least 2 newer ASMedia USB 
3.1 controllers (2142 & 3142). I do not know what value they use for SBRN, but 
0x30 is likely.


Nevertheless, even if we ignore this history of unpredictable SBRN values, it 
is wrong to believe that any USB 3.1 controller supports 10 Gb/s operation. The 
evidence for this is all the b*s*t advertising about "USB 3.1 Gen 1", i.e. 5 
Gb/s (4 Gb/s actually) speed.

Moreover, very soon USB 3.2 devices will appear. USB 3.2 introduces 2 more 
speeds, so a USB 3.2 xHCI controller will support some or all of 4 speeds: 1 * 
5 Gb/s (actually 4 Gb/s), 2 * 5 Gb/s (actually 8 Gb/s), 1 * 10 Gb/s (i.e. 10 
Gb/s) and 2 * 10 Gb/s (i.e. 20 Gb/s). It is very likely that some USB 3.2 xHCI 
controllers will not support all speeds, especially because the 2-lane speeds 
are possible only over Type C connectors, so the same controller will support 
all speeds on some motherboards but only some of them when used with Type A 
connectors.

In conclusion, the supported speeds must be detected independently of the USB 
release number.

The xHCI Specification describes an appropriate source for this information, at 
the "xHCI Supported Protocol Capability", in the "Protocol Speed ID" Dwords.

There are chances that I might have time during this weekend to test some USB 
3.1 xHCI controllers to see how this works.

If you can work on this sooner, you are welcome.


While reading the extra capability registers should be easy, what should be 
thought carefully is how to change the existing structures which store 
information about the xHCI controller, to accomodate the extra speeds that will 
be available soon and the fact that the set of supported speeds is not 
necessarily determined by the USB version number.

Like I said, while I patched my kernel and now my xHCI controllers are 
recognized as supporting 10 Gb/s, the SSDs with USB-SATA bridges that I have 
connected are still not recognized as also supporting 10 Gb/s. I believe that 
the problem is caused by other parts of the xHCI specification that are not 
implemented, but I did not have time yet to identify them.


Best regards !






























--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to 

Re: Type-C port on the Asmedia ASM1142

[Adrian Bocaniciu]

On Tue, 26 Sep 2017 09:53:23 +0300
Mathias Nyman  wrote:

> 
> Do you have any more details, logs or documentation about these 10Gbps 
> ASM1142 bugs in xHCI driver?
> I'd be interested in getting that fixed
> 
> Thanks
> Mathias

I know exactly what must be changed in the XHCI driver, but I did not have time 
to implement it. If I will succeed soon to have a weekend in which I will not 
be busy, I could submit a complete patch. I can test the support for 10 Gb/s on 
6 different kinds of motherboards, 2 with ASM 1142 and 4 with the USB 3.1 
controllers from Intel Thunderbolt 3, and also with 3 or 4 different kinds of 
USB 10 GB/s to SATA 6 Gb/s bridges.


The problem in the current XHCI driver was created by a patch from 2 years ago, 
which added SuperSpeedPlus detection. However, the method used is wrong, 
according to both the Intel XHCI specification and the ASMedia datasheets.

The only explanation for the origin of the wrong detection method that I can 
imagine is that probably this method was correct for some of the first ASMedia 
USB 3.1 controllers, maybe for ASM 1042. I suppose that the first ASMedia XHCI 
controllers did not implement correctly the XHCI specification, but later they 
were corrected, at least starting with ASM 1142. Of course, the Intel USB 3.1 
controllers must have implemented the Intel specification since the beginning.

So the status is that the current Linux XHCI driver cannot detect the 
SuperSpeedPlus support in any not very old motherboard, i.e. any motherboard 
with ASM 1142 or newer, or any motherboard with Intel Thunderbolt 3. (The 
current XHCI driver tries to read a "3.1" value from a register that according 
to all specifications and datasheets and also according to my experiments can 
have only the "3.0" value, even in USB 3.1 controllers. The correct 
SuperSpeedPlus detection involves other registers and it is more complex.)


In have already implemented the part that detects the capabilities of the XHCI 
controller but there are also some changes that must be done to detect 
correctly the capabilities of a SuperSpeedPlus device after it is connected to 
a USB 3.1 port, otherwise the 10 Gb/s link is not established.

Best regards !

--
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: Type-C port on the Asmedia ASM1142

[Adrian Bocaniciu]

On Mon, 25 Sep 2017 17:29:10 +1000
Will  wrote:

> Hello,
> 
> Basically I'm just sending this to see if anyone can confirm whether
> they can get SuperSpeed devices working properly through the Type-C port
> on an Asmedia ASM1142 controller with Linux (i've tried even with latest
> usb-next branch)

I have 2 different motherboards with ASM1142 and USB type C (a Gigabyte BRIX 
and a Zotac Nano).

On both of them SuperSpeed (5 Gb/s) and UASP work perfectly OK with various 
SSDs.

Therefore, you either have a bad cable (there are many USB 2.0 cables with Type 
C connectors) or your motherboard/BIOS has some weird behavior.

On the other hand, SuperSpeedPlus (10 Gb/s) does not work on ASM1142 in Linux, 
because of bugs in the XHCI driver.

Best regards !




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