On Wed, 27 Sep 2017 11:03:41 +0300 Mathias Nyman <mathias.nyman@xxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
