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

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). Commented Oct 27, 2013 at 1:35

3 Answers 3


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
    Commented Jul 20, 2014 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
    Commented Feb 8, 2016 at 10:11
  • Write the vid/pid to remove_id to undo the echo to new_id.
    – robbat2
    Commented Feb 10, 2016 at 1:21
  • @trycatch can you please accept the answer?
    – robbat2
    Commented Oct 5, 2017 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
    Commented Aug 18, 2018 at 19:53

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.

  • GREAT ANSWER!!! Thank you, this worked perfectly to resolve issue with data cable for github.com/JENkt4k/glucometerutils Commented Jan 22, 2020 at 17:12
  • Maybe consider adding the "lsusb" vendor and product id mapping for your solution like the answer from @OlegKokorin shown below Commented Jan 22, 2020 at 17:14

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


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
    Commented Nov 19, 2018 at 19:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .