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@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
