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

[Florian Eckert]

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