Attaching USB-Serial device with custom PID to ttyUSB0 on embedded

Question

I'm attempting to get an FTDI USB-Serial device with a custom PID to automatically (or even manually) attach to ttyUSB%n, without much success. The device's normal VID/PID is 0403/6001. When programmed this way, it works perfectly and automatically attaches itself to ttyUSB0 when plugged in. Even with the driver recompiled to respect our new PID, when programmed with the custom one ttyUSB0 does not appear, but it does recognize it as an ftdi_sio device and loads the driver.

I have added our PID to the header and source:

// in ftdi_sio_ids.h
#define FTDI_CUSTOM_PID 0xABCD // not the actual pid

// then in ftdi_sio.c
static struct usb_device_id id_table_combined [] = {
    // devices....
    { USB_DEVICE(FTDI_VID, FTDI_CUSTOM_PID) },
    // ....

Recompiled the entire kernel and reflashed the device. When I plug the device in I get:

usb 1-1: new full-speed USB device number 2 using at91_ohci
usbcore: registered new interface driver usbserial
usbserial: USB Serial Driver core
USB Serial support registered for FTDI USB Serial Device
usbcore: registered new interface driver ftdi_sio
ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

lsusb shows the correct custom VID/PID. The driver seems to recognize that it's supposed to use ftdi_sio with it, but doesn't attach it to ttyUSB0 like it would with the unmodified PID. Any suggestions as to what I'm doing wrong here?

Answer 1

You don't need to modify the kernel to just it just once; you can override it.

1. Unplug the device
2. modprobe ftdi_sio
3. echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
4. Plug in the device

And your device should work.

Your other alternative is to use the bind sysfs interface; I suggest using lsusb -t to figure out the correct path+interface in that case.

Using a partial example from my system, of a usb-storage device (it would be very similar for usb-serial).

$ lsusb -t
...
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
    |__ Port 1: Dev 5, If 0, Class=Hub, Driver=hub/3p, 5000M
        |__ Port 3: Dev 6, If 0, Class=Hub, Driver=hub/3p, 5000M
            |__ Port 3: Dev 7, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
 ...
 $ echo '4-1.3.3:1.0' >/sys/bus/usb/drivers/usb-storage/bind

The format of the number is: BUS-PORT(.PORT)+:1.INTERFACE. The only number that's not visible in the lsusb output is the first digit after the colon; and it's always been a 1 in my experience. Somebody with deeper kernel knowledge can probably tell me what it is and provide a counter-example.

Answer 2

You don't need to modify the kernel, you can automate the process like this:

1. Add the following single line to /etc/udev/rules.d/99-ftdi.rules

   ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", RUN+="/sbin/modprobe ftdi_sio" RUN+="/bin/sh -c 'echo 0403 6001 > /sys/bus/usb-serial/drivers/ftdi_sio/new_id'"

2. Either reboot or run sudo udevadm control --reload to pick up the new rule.

3. Unplug the device.

4. Plug in the device.

Answer 3

absolutely similar situation has happened with the eval board from SiLabs - the USB-UART chip CP2102 being provided with irregular VID/PID:

lsusb

Bus 001 Device 002: ID 10c4:804c Cygnal Integrated Products, Inc.

problem solved by loading module cp210x and sending VID/PID as mentioned before:

sudo modprobe cp210x

sudo -s

echo 10c4 804c > /sys/bus/usb-serial/drivers/cp210x/new_id

corresponding 99-cp210.rules file for the udev looks following:

ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="804c", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 804c > /sys/bus/usb-serial/drivers/cp210x/new_id'"