On 26.09.2017 22:08, Adrian Bocaniciu wrote:
On Tue, 26 Sep 2017 09:53:23 +0300
Mathias Nyman <mathias.ny...@linux.intel.com> 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
