On Mon, Oct 5, 2020, at 1:33 PM, Jack wrote: > Grant - thanks for the info. > > I'm curious about the pairing by PCI device - it's not clear if the > every root_hub is a real controller, or not. The specs of the board > say USB2: two ports on the back and two USB2 headers (so I don't know > why it claims 10 ports instead of 6) and USB3: three type A and one > Type C ports on the back. Bus 2 is a bit of a mystery, as although the > B350 chipset presumably does have an enhanced superspeed (3.1) > controller, it is not available through the motherboard. If bus 3 is > the unavailable 3.1 controller, then is bus 1 driven by the CPU or the > chipset, and where is the other one? So far, anything plugged into any > of the front ports or rear USB2 ports shows up on bus 1, and anything > plugged into the rear USB3 ports shows up on bus 3. I think my new USB > flash drive is really USB2 and not USB3 as advertised. >
Logically I think the controllers are separate, but they are spawned from the same device. On an ARM64 system there is a single DWC3 device per USB3/2 pair. Intel is moving to DesignWare's IP, and I think existing platforms that split devices are similar. Additionally the xHCI driver is now being used to drive all USB bus types. If you want to test this you can unbind the driver from individual PCIe devices. Check /sys/bus/pci/devices and see what disappears. On a development board I see: $ lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ohci-platform/1p, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-platform/1p, 480M And I happen to know the first 2 lines are the platform device at fe900000. If I disable that device both disappear. However, as I tried to describe earlier, on most x86 systems I have used it is possible to actually plug a USB2 device into a port associated with a USB3 root hub and the output would be rewritten as such: $ lsusb -t /: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M /: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M When all USB2 devices are removed the bus speed returns to 5000M. I suspect you are encountering some variation of this. Can you unplug absolutely everything and see the speeds reported by lsusb -t? Then, plug things in and see if they change. If you've already done this my apologies, it's kind of hard to find the text among all the dmesg. > Later, I'll reboot into Windows to see what that shows, as MSI tech > support refuses to talk about Linux. > It may be worth pointing out the platform implements standards that are divorced from the OS you are running. If it doesn't work with both it can still be their problem. Recently I had to do a differential test using Windows, assuming it'd be more featureful. It is. But Windows has issues with device enumeration. I am wondering if the original link speed problems (USB2 devices slowing down USB3 busses) was a Linux-specific issue, or if it was just only visible to me on Linux. I think I am encountering some variation of your problem, but mine is even weirder. I have control over the device which is USB-C. In one cable orientation it will enumerate with Windows, in the other it will not. In that same orientation it will enumerate against an ARM64 system as USB3. In the other orientation it will enumerate against ARM64/x86 systems as USB2. It seems to be unable to enumerate as a USB3 device on Linux, but I need to do more testing. A friend of mine reports he has a USB-C cable that is not reversible. This may not be the cable's fault. So: Check your cable, and try more than one device. Also there may be bugs in either the kernel's xhci drivers or new USB3 hardware.
