USB controller enumeration on APU3 is random since the update to kernel 6.6

[Paul D]

I can see this affecting USB network devices.


In my experience of working with p910nd, I used sysfs also. Deterministic probing order is important if the order of discovered USB printers is to remain the same (so that port 9100 always talks to your HP at /dev/usb/lp0, port 9101 always talks to your Brother at /dev/usb/lp1, mutatis mutandis). To prevent soft-bricking when sending a (driver) blob, the script would only send to devices identified using the below properties. While I could not (yet) affect the port ordering of /dev/usb/lpX character device assignments (first detected gets first assignment), I could ensure the right blob went to the right device.


The files below presented in sysfs help to build an unmistakable identity of device type, in this case:

bInterfaceClass
bInterfaceSubClass
idVendor
idProduct

( /sys/bus/usb/devices/*/idVendor )

and also the following if you have multiple identical device types:

iSerialNumber


These files might allow non-deterministic ordering or presentation such that a moved device can still be reconciled. Certain other files at this location might provide better anchoring. Be aware that some USB devices can have multiple connection modes, i.e. bNumConfigurations and bConfigurationValue ( e.g. press button, device mounts file-system with drivers, press button, device then changes config to connect printer etc )

For reconciliation, store contents of several of the files found in /sys/bus/usb/devices/*/ ) for matching, e.g. as a CSV in configuration:

{idVendor},{idProduct},{iSerialNumber},{bInterfaceClass},{bInterfaceSubClass}


Some info:
https://beyondlogic.org/usbnutshell/usb5.shtml
https://openwrt.org/docs/guide-user/base-system/hotplug


Open to suggestions if there's a 'better' way to do this, but this way I think one can disregard a sysfs path and be certain that one has found the same 'device'.




On 2024-07-18 11:53, Florian Eckert wrote:
> Hello Felix
> 
>>> Boot 1:
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:56 2-1.3:1.0 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb2/2-1/2-1.3/2-1.3:1.0
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:56 2-1.3:1.1 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb2/2-1/2-1.3/2-1.3:1.1
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:56 2-1.3:1.2 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb2/2-1/2-1.3/2-1.3:1.2
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:56 2-1.3:1.3 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb2/2-1/2-1.3/2-1.3:1.3
> 
>>> Boot 2:
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:43 1-1.3:1.0 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb1/1-1/1-1.3/1-1.3:1.0
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:43 1-1.3:1.1 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb1/1-1/1-1.3/1-1.3:1.1
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:43 1-1.3:1.2 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb1/1-1/1-1.3/1-1.3:1.2
>>> -> lrwxrwxrwx    1 root     root             0 Jul 17 12:43 1-1.3:1.3 ->
>>> ../../../devices/pci0000:00/0000:00:13.0/usb1/1-1/1-1.3/1-1.3:1.3
> 
>> Oh, right. The main issue here is the fact that the device ids in the
>> path contain the bus number as initial component.
> 
> That is correct. The bus number is incremented with each new USB controller.
> The number assigned to the controller is allocated in the order in which it
> is probed (first come first serve).
> 
>> I guess the syntax
>> could be something like: "pci0000:00/0000:00:12.0%<id>"
>> To resolve it, it would look up the bus number from the controller
>> path and then use /sys/bus/usb/devices/<bus>-<id> as the device path.
> 
> On my APU3 I have four USB busses.
> lrwxrwxrwx    1 root     root             0 Jul 18 11:10 usb1 -> ../../../devices/pci0000:00/0000:00:12.0/usb1
> lrwxrwxrwx    1 root     root             0 Jul 18 11:10 usb2 -> ../../../devices/pci0000:00/0000:00:13.0/usb2
> lrwxrwxrwx    1 root     root             0 Jul 18 11:17 usb3 -> ../../../devices/pci0000:00/0000:00:10.0/usb3
> lrwxrwxrwx    1 root     root             0 Jul 18 11:17 usb4 -> ../../../devices/pci0000:00/0000:00:10.0/usb4
> 
> usb1 an ehci on PCI 0000:00:12.0
> usb2 an ehci on PCI 0000:00:13.0
> usb3 an xhci on PCI 0000:00:10.0
> usb4 an xhci on PCI 0000:00:10.0
> 
> I have an USB modem on PCI 0000:00:13.0 that can be reached under
> either bus number 1 or bus number 2 depending on when the controller
> was proped in the boot sequence. The xhci controllers on PCI
> 0000:00:10.0 always get the bus number 3 and bus number 4.
> The ehci is probed before xhci.
> 
> I found a commit [1] in the Linux kernel that makes the USB
> controller probing asynchronous and therefore not deterministic as
> before. I have reverted the commit on my build and now nothing
> changes in the controller numbering. This is not a solution, but
> I now know what the problem is. With a new kernel, the numbering
> can be completely different again.
> 
> From my point of view, that's a general problem, that USB controller
> does not have a fix sysfs path. In my case, I explicitly refer to
> a USB device sysfs path in the network configuration that the
> modemmanager should use. I can't work with serial number, pid, vid.
> I think also the udev service will also not help there.
> 
> The question is how to get a unambiguous that is the same after every
> boot even if the kernel changes the probing behavior. On the PCI bus
> there is always unambiguous number.
> 
> Best regards
> Florian
> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=69a1c9a9b273271f2a2674bcc117336a9bb0a4b4
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel