Linux: Buster udev rules for symlinks to serial-to-USB devices ttyUSB broken

[Fuchks]

udev rules for symlinks to serial-to-USB devices ttyUSB will symlink to gpiochip on freshly installed and updated Buster (Raspberry Pi OS Lite).
This issue arises on a Pi2B Rev 1.1 HW 1a01041 with 2x FTDI FT232 adapters.

used udev rule (example)
SUBSYSTEMS=="usb", ATTRS{serial}=="12345678", SYMLINK+="MyUSBDevice"

Discussions on that issue:
https://www.raspberrypi.org/forums/viewtopic.php?t=283585
https://www.indilib.org/forum/ekos/7878-persistent-serial-port-mapping.html

Edit 2020-12-10:
Added to Buster bug report thread

Disabling stock /etc/udev/rules.d/99-com.rules solves the issue partly (not everytime) - or excluding the following lines:

#SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
#SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
#       chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
#       chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
#       chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
#'"

sudo udevadm test $(udevadm info -q path -n /dev/ttyUSBx) will solve the issue everytime for usb device x

[Babbion]

I have the same issue on a Pi3B+ with 4xFTDI Ft232 adapters.
The udev rule create "bad" symlinks in /dev/ and the only way to get them works is send:
udevadm test $(udevadm info -q path -n /dev/ttyUSBx)
for every device connected

[Fuchks]

My workaround as i do not need this gpio stuff:

Exclude the following lines from the stock /etc/udev/rules.d/99-com.rules:

#SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
#SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c '\
#       chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio;\
#       chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio;\
#       chown -R root:gpio /sys$devpath && chmod -R 770 /sys$devpath\
#'"

Add the line to /etc/rc.local: sudo udevadm control --reload-rules && sudo udevadm trigger

Let me know if this works reliable on your system too...

[XECDesign]

Does it work if you change /sys$devpath to /sys/$devpath?

[XECDesign]

To answer my own question, no it doesn't seem to. I was hoping this was a variant of https://github.com/raspberrypi/linux/issues/3779

[XECDesign]

Using SUBSYSTEM=="tty" (note the lack of S) makes your rule work for me. It looks like your rule also applies to gpiochip2, which belongs to the USB device and there's a race between whether ttyUSB0 or gpiochip2 is linked last. Specifying SUBSYSTEM=="tty" ensures that the rule does not apply to gpiochip2.

It looks like the rules in 99-com.rules doesn't directly affect it. If I remove it, I still see the rule applying to gpiochip2. I suspect it just introduces enough of a delay to change the likely outcome of the race described above.

[jsjames]

Hi XECDesign - That suggestion seems to work for me. Thanks for the help here.

[XECDesign]

@vdavy That's unrelated to this issue. Please see https://github.com/raspberrypi/linux/issues/3779 where somebody actually suggested adding the slash as a fix.

[vdavy]

@XECDesign thanks for notifying me.
So I deleted my comment on this issue and migrated it to the issue you mentionned me.

[Fuchks]

Using SUBSYSTEM=="tty" (note the lack of S) makes your rule work for me. It looks like your rule also applies to gpiochip2, which belongs to the USB device and there's a race between whether ttyUSB0 or gpiochip2 is linked last. Specifying SUBSYSTEM=="tty" ensures that the rule does not apply to gpiochip2.

It looks like the rules in 99-com.rules doesn't directly affect it. If I remove it, I still see the rule applying to gpiochip2. I suspect it just introduces enough of a delay to change the likely outcome of the race described above.

Not thorougly tested, but seems to work.
IMO this is only a workaround, as most suggested to create symlinks to usb-devices with serialnr. is:
SUBSYSTEMS=="usb", ATTRS{serial}=="12345678", SYMLINK+="MyUSBDevice"

[XECDesign]

I don't think it's just a workaround, since udev is doing what it's being asked to do. That gpiochip device happens to match the udev rule, so the udev rule needs to be more specific.

[jsjames]

I don't think it's just a workaround, since udev is doing what it's being asked to do. That gpiochip device happens to match the udev rule, so the udev rule needs to be more specific.

I don't believe the gpiochip should have matched the original udev rule because the serial number was listed as part of the udev rule. Here were my original rules where I included the serial number in each line. All of these in buster were mapped to gpiochip - which can't be correct operation.

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A60335LE", SYMLINK+="ttyInsteonPLM"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A5003uIM", SYMLINK+="ttyAD2USB"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="AK05ERIN", SYMLINK+="ttyRS422"

[XECDesign]

The serial number matches the parent USB device gpiochip is on. Why do you believe this to be incorrect behaviour?

[jsjames]

Thanks XECDesign. I had thought the serial number was for the device, not the parent. In looking into this some more, I see what you are saying and why the previous rules would apply to both.

[XECDesign]

It seems to inherit parent attributes. If you run udevadm info --attribute-walk --name=/dev/gpiochip2 (or ttyUSB0), I think you'll see that the serial number is only present on the parent usb device and not any of the children. Since the tty and gpiochip devices are both children of the usb device, both match. I was a bit confused when I saw that as well because that's not how I assumed it worked.