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?

Solution 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.

Solution 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.

Solution 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'"

Comments

[Brian Redbeard]

Which embedded type is this? Does it have UDEV? If so, UDEV is your best bet (and I can help further with that).

[Amr Bekhit]

Worked perfectly, thanks. Should be the accepted answer.

[Bram]

Just wondering: if I change my mind, and i don't want this vid/pid to use the ftdi_sio driver but another one, how do I revert this step?

[robbat2]

Write the vid/pid to remove_id to undo the echo to new_id.

[robbat2]

@trycatch can you please accept the answer?

[kay]

@robbat2 I need to remove an id from new_id. remove_id is not in that directory. Is there anything I can do to revert this?

[robbat2]

@kay new_id/remove_id is only for removing dynamically added IDs. If I understand what you want to do: you want to prevent a specific driver from loading for some device.

[kay]

yes @robbat2 . I have a question that I've recently asked if that would be a more appropriate location for help

[nebulous]

For future travelers trying to get a HUSBZB-1 stick to work, here is a udev file which will link the cp210x driver as mentioned above, and symlink the tty devices to /dev/zigbee and /dev/z-wave ACTION=="add", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="8a2a", RUN+="/sbin/modprobe cp210x" RUN+="/bin/sh -c 'echo 10c4 8a2a > /sys/bus/usb-serial/drivers/cp210x/new_id'" SUBSYSTEM=="tty", ATTRS{interface}=="HubZ Z-Wave Com Port", SYMLINK+="zwave" SUBSYSTEM=="tty", ATTRS{interface}=="HubZ ZigBee Com Port", SYMLINK+="zigbee"

[James Nelson]

GREAT ANSWER!!! Thank you, this worked perfectly to resolve issue with data cable for github.com/JENkt4k/glucometerutils

[James Nelson]

Maybe consider adding the "lsusb" vendor and product id mapping for your solution like the answer from @OlegKokorin shown below

[Sjoerd Timmer]

Not a kernel expert but I was looking into this recently: The first digit is the bus. The Digits between - and : (separated by dots) are the port numbers on the hubs. After the : there are two mode numbers. The first is what is known as the configuration and the second is the interface. As far as I understood it, linux does not support multi-configuration usb devices so it is indeed safe to assume the number is always 1. There can be multiple interfaces on the same endpoint, one example that comes to mind are dual-port and quad-port usb-serial chips from ftdi, and mouse/keyboard combinations