How do I get the `/dev/ttyUSB0` from `/dev/bus/usb/006/015`?

Question

Short version:

How, from device information such as /devices/pci0000:00/0000:00:13.1/usb6/6-3 and /dev/bus/usb/006/015, I get a path such as /dev/ttyUSB0 or /dev/serial/by-path/pci-0000:00:13.1-usb-0:3:1.0-port0?

Detailed version:

I have a script which detects that an USB device of a specific type (an Arduino) was plugged in. When the device is connected, it shows a bunch of data about it, such as the device path and name:

DEVPATH: /devices/pci0000:00/0000:00:13.1/usb6/6-3
DEVNAME: /dev/bus/usb/006/015

I want this first script to call the second one which uses the serial communication to interact with the USB device. For now, when I launch this second script by hand, I specify the device using the TTY:

./script2.py --device /dev/ttyUSB0

or:

./script2.py --device /dev/serial/by-path/pci-0000:00:13.1-usb-0:3:1.0-port0

I want instead the second script to be launched automatically by the first one. For this, I need to map the device path and name to either the TTY path or the /dev/serial/by-path one.

How do I do that?

In the by-path, I notice the occurrence of pci-0000:00:13.1 from the DEVPATH, but I see nothing related to 0:3:1.0 or port0 (and I suppose I don't need to build the string myself and that Debian already has a tool to do the conversion for me anyway).

What I have tried:

• lsusb -v doesn't seem to show anything relevant: I suppose that it's much more low-level than TTY devices.

• udevadm info /dev/ttyUSB0 shows, indeed, the path /devices/pci0000:00/0000:00:13.1/usb6/6-3/6-3:1.0/ttyUSB0/tty/ttyUSB0, however, udevadm info /dev/bus/usb/006/015 doesn't show anything related to TTY devices.

Answer 1

DEVPATH actually exists in sysfs, so you can find all child devices under the directory with that name. If you know for sure there's a single TTY device right under your DEVPATH, echo /sys/devices/pci0000:00/0000:00:13.1/usb6/6-3/*/tty/* will reveal its name (ttyUSBx).

However, when your parent device appears and your script is triggered, the discovery of this subdevice may not have completed yet, meaning that this TTY device may not exists yet when you look for it. So you'd better create a udev rule that matches the subdevice itself.