Re: [gentoo-user] Re: new USB question

[Sid Spry]

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.