18

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?

  • 1
    Which embedded type is this? Does it have UDEV? If so, UDEV is your best bet (and I can help further with that). – Brian Redbeard Oct 27 '13 at 1:35
17

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.

  • Worked perfectly, thanks. Should be the accepted answer. – Amr Bekhit Jul 20 '14 at 12:05
  • 1
    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? – Bram Feb 8 '16 at 10:11
  • Write the vid/pid to remove_id to undo the echo to new_id. – robbat2 Feb 10 '16 at 1:21
  • @trycatch can you please accept the answer? – robbat2 Oct 5 '17 at 23:14
  • 1
    @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. – robbat2 Aug 18 '18 at 19:53
12

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.

1

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

  • 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" – nebulous Nov 19 '18 at 19:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.