RE: Type-C port on the Asmedia ASM1142

[David Laight]

From: Adrian Bocaniciu
> Sent: 30 September 2017 09:18
> 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.
> 
> I was reffering mostly to the identifiers and comments used in the kernel 
> source code.

So was I, don't assume that people reading the code know all about
the interface definitions.

Naming the constants USB_GEN_1x1_4G (or similar) makes things clearer.

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

Or 10MHz ethernet as 20MHz :-)

Although the physical bit rate has been used before.
Can't quite remember what for though - might have been ATM.
Actually, isn't it GE - which is only 800MHz ??

David

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

[sonofagun]

I agree with you, you are right in everything you wrote! It is annoying to see 
theoretic numbers and not the actual numbers the hardware implementing the 
specification can support but something else is in my mind 
too...N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

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

[David Laight]

From: Adrian Bocaniciu
> Sent: 28 September 2017 20:25
..
> 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".

I think I'd add the speed itself as well.

David

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

[Felipe Balbi]

Hi,

Mathias Nyman  writes:

[snip]

>> 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.
>>
>
> To sum it up:
>
> Ways to deduce host controller capable speeds:
>
> 1. From SBRN
>  Good: + easy, the current way
>
>  Bad: - unreliable, public spec currently forces value to be 30h
>  (USB 3.0) so many vendors (30h) for 3.1 SSP capable hosts
>
>  Bad: - PCI centric, SBRN is in pci config space, platform devices
>  need their own way to set xhci->sbrn value
>
>  Bad: - assumes host vendors only use 3.1 (30h) for 10Gbps SSP
>  hosts.
>
>  Bad: - assumes a future spec revision always implies new
>  mandatory supported speeds
>
> 2. From xHCI supported protocol capability (extended capability for
> xHCI ports) major and minor revision number
>  Good: + spec is clear on this issue, can't be interpreted in
>  different ways.
>
>  Bad: - assumes host vendors only use 3.1 (30h) for 10Gbps SSP
>  capable hosts. (seems true so far for hosts)
>
>  Bad: - assumes a future spec release always implies new mandatory
>  supported speeds
>
> 3. From xHCI supported protocol capability (extended capability for
> xHCI ports) PSI Dwords
>  Good: +spec is clear on this issue, can't be interpreted in
>  different ways.
>
>  Good: +get actual real numerical value of supported speed, like
>  5830Mb/s
>
>  Bad: -PSI Dwords are optional, many vendors don't have them.

Indeed, they are optional. However if PSIC is 0, then the default
mapping *must* be assumed. Default mapping, on public spec, only species
up to 5Gbps. So this means that SSP hosts *must* have PSIC > 0.

> I already wrote xhci support for parsing PSI Dwords for xHCI and
> create the usb 3.1 root hub descriptor out of it.
>
> If hosts doesnt have PSI Dwords then driver uses the default USB speed
> ID mappings for root hub (xhci 7.2.2.1.)

which only define speeds up to 5Gbps

> To me it looks like first step is to use xHCI supported protocol
> capability major and minor fields to get USB release number, and also
> set initial supported speed.
>
> After this we can check if we a PSI Dwords list exists, and tune the
> supported speed for the host (and root hub)

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

static bool xhci_30_supports_ssp(struct xhci_hcd *xhci)
{
sbrn = read_sbrn_maybe(xhci);
if (!sbrn)
return false;

if (sbrn == 0x30 && xhci->quirks & XHCI_SBRN30_SUPPORTS_SSP)
return true;

return false;
}

static void setup_supported_speeds_using_default_mappings(struct xhci_hcd *xhci)
{
[...]

sbrn = read_sbrn_maybe(xhci);
if (!sbrn)
return;

/*
 * xhci revision foo.bar defines a new SBRN of 0x31 for USB3.1
 * hosts.
 *
 * That same spec revision, also defines a new default mapping
 * for 10Gbps. Let's append it.
 *
 * Note that there are known quirky hosts which have SBRN equals
 * to 0x30, but are, indeed, 10Gbps-capable hosts which PSIC
 * equal to 0. Also handle these cases.
 */
if (sbrn == 0x31 || xhci_30_supports_ssp(xhci))
append_10gbps_default_mapping(xhci);

[...]
}

> Other things to consider is that we assume PSI IDs 1,2,3,4 always maps
> to Full, Low, High and SuperSpeed.

That's the default mapping. If PSIC > 0 you don't need default
mapping. Or rather, shouldn't need. Imagine the following situation:

Currently xhci always adds default mapping. Now say PSIC is > 0 and ID 3
is, according to PSI Dwords, used for 10Gbps. Now you're gonna have ID 3
being used for 10Gbps and 480Mbps.

IMHO, the first step should be extracting all the current magic (without
changing it in any way) to a separate function. Then you can start
reasoning about how to best parse/decode it.

> I haven't seen those mapped any other way, but I think PSI Dwords
> don't force this mapping.

they don't appear to, no. Only default mapping forces that.

-- 
balbi


signature.asc
Description: PGP signature

Re: Type-C port on the Asmedia ASM1142

[Mathias Nyman]

On 27.09.2017 23:15, Adrian Bocaniciu wrote:

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.



To sum it up:

Ways to deduce host controller capable speeds:

1. From SBRN
Good: + easy, the current way
Bad:  - unreliable, public spec currently forces value to be 

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

[Mathias Nyman]

On 26.09.2017 22:08, Adrian Bocaniciu wrote:

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 !



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)

-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

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

[Will Trives]

On Tue, 26 Sep 2017 05:55:17 +
Adrian Bocaniciu  wrote:

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

Thanks for that, yeah it's just strange because the cables even have
"SS" written on them. When I look online for a hub, it seems there's a
lot of ones with type-c connectors that only work at usb2/highspeed

Pretty sure it can't be the bios/motherboard becuse I have separate
cards as well. Pcie rev 2.0 4x and a pcie rev 3.0 1x


Regards,

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

[Greg KH]

On Tue, Sep 26, 2017 at 09:30:31AM +1000, Will Trives wrote:
> On Mon, 25 Sep 2017 10:52:10 +0200
> Greg KH  wrote:
> 
> > On Mon, Sep 25, 2017 at 05:29:10PM +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)
> > > 
> > > Any device I use with the cable I have is only able to work at
> > > HighSpeed. So I am wondering if the problem is with the cable or the
> > > controller/driver.
> > > 
> > > I have tested on 2 different PCIe cards and on an integrated Skylake
> > > system.  
> > 
> > What does the kernel logs say when you plug in the device?  And what
> > kernel versions have you tried?
> > 
> > thanks,
> > 
> > greg k-h
> 
> Up to 4.14-rc4 etc
> 
> When I plug things in, they either work fine as a Highspeed device or
> don't work and messages like this appear...
> 
> This is when plugging in a SuperSpeed UAS dock...
> 
> [232782.657551] usb 3-2: new full-speed USB device number 7 using xhci_hcd
> [232791.810878] usb 3-2: new full-speed USB device number 9 using xhci_hcd
> [232792.300861] usb 3-2: new full-speed USB device number 10 using xhci_hcd
> [232793.000854] usb 3-2: new full-speed USB device number 11 using xhci_hcd
> [232800.094199] usb 3-2: new full-speed USB device number 14 using xhci_hcd
> [232800.310903] usb 3-2: device descriptor read/64, error -71
> [232800.607550] usb 3-2: device descriptor read/64, error -71
> [232800.904190] usb 3-2: new full-speed USB device number 15 using xhci_hcd
> [232801.120917] usb 3-2: device descriptor read/64, error -71
> [232801.420958] usb 3-2: device descriptor read/64, error -71
> [232801.717539] usb 3-2: new full-speed USB device number 16 using xhci_hcd
> [232801.743984] usb 3-2: Device not responding to setup address.
> [232801.973966] usb 3-2: Device not responding to setup address.
> [232802.177519] usb 3-2: device not accepting address 16, error -71

Ick, bad device, or cable :(

I'd recommend trying a different cable, USB 3 cables are notoriously
horrid, buy one you "know" should work and try that.

thanks,

greg k-h
--
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

[Mathias Nyman]

On 26.09.2017 08:55, Adrian Bocaniciu wrote:

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.



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

Re: Type-C port on the Asmedia ASM1142

[Will Trives]

> Up to 4.14-rc4 etc

Er that's not out yet.

I mean -rc2 hah
--
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

[Will Trives]

On Mon, 25 Sep 2017 10:52:10 +0200
Greg KH  wrote:

> On Mon, Sep 25, 2017 at 05:29:10PM +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)
> > 
> > Any device I use with the cable I have is only able to work at
> > HighSpeed. So I am wondering if the problem is with the cable or the
> > controller/driver.
> > 
> > I have tested on 2 different PCIe cards and on an integrated Skylake
> > system.  
> 
> What does the kernel logs say when you plug in the device?  And what
> kernel versions have you tried?
> 
> thanks,
> 
> greg k-h

Up to 4.14-rc4 etc

When I plug things in, they either work fine as a Highspeed device or
don't work and messages like this appear...

This is when plugging in a SuperSpeed UAS dock...

[232782.657551] usb 3-2: new full-speed USB device number 7 using xhci_hcd
[232791.810878] usb 3-2: new full-speed USB device number 9 using xhci_hcd
[232792.300861] usb 3-2: new full-speed USB device number 10 using xhci_hcd
[232793.000854] usb 3-2: new full-speed USB device number 11 using xhci_hcd
[232800.094199] usb 3-2: new full-speed USB device number 14 using xhci_hcd
[232800.310903] usb 3-2: device descriptor read/64, error -71
[232800.607550] usb 3-2: device descriptor read/64, error -71
[232800.904190] usb 3-2: new full-speed USB device number 15 using xhci_hcd
[232801.120917] usb 3-2: device descriptor read/64, error -71
[232801.420958] usb 3-2: device descriptor read/64, error -71
[232801.717539] usb 3-2: new full-speed USB device number 16 using xhci_hcd
[232801.743984] usb 3-2: Device not responding to setup address.
[232801.973966] usb 3-2: Device not responding to setup address.
[232802.177519] usb 3-2: device not accepting address 16, error -71
[232802.374243] usb 3-2: new full-speed USB device number 17 using xhci_hcd
[232802.400676] usb 3-2: Device not responding to setup address.
[232802.633995] usb 3-2: Device not responding to setup address.
[232802.837511] usb 3-2: device not accepting address 17, error -71
[232802.837541] usb usb3-port2: unable to enumerate USB device

It could be the cable, i'm just not sure, as far as i'm aware it's
supposed to convert a type c port to type a 

Not a huge deal it's just that one of the cards I have only has 1
type-c port and nothing else.



Regards,

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

[Greg KH]

On Mon, Sep 25, 2017 at 05:29:10PM +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)
> 
> Any device I use with the cable I have is only able to work at
> HighSpeed. So I am wondering if the problem is with the cable or the
> controller/driver.
> 
> I have tested on 2 different PCIe cards and on an integrated Skylake
> system.

What does the kernel logs say when you plug in the device?  And what
kernel versions have you tried?

thanks,

greg k-h
--
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