Conexión de dispositivo serie USB con PID personalizado a ttyUSB0 en embebido

Estoy intentando obtener un dispositivo FTDI USB-Serial con un PID personalizado para conectar automáticamente (o incluso manualmente) a ttyUSB% n, sin mucho éxito. El VID / PID normal del dispositivo es 0403/6001. Cuando se programa de esta manera, funciona perfectamente y se conecta automáticamente a ttyUSB0 cuando está enchufado. Incluso con el controlador recompilado para respetar nuestro nuevo PID, cuando se programa con el personalizado ttyUSB0 no aparece, pero lo reconoce como un dispositivo ftdi_sio y Carga el conductor.

He agregado nuestro PID al encabezado y fuente:

// 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) },
    // ....

Vuelve a compilar todo el núcleo y vuelve a actualizar el dispositivo. Cuando conecto el dispositivo obtengo:

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 muestra el VID / PID personalizado correcto. El controlador parece reconocer que se supone que debe usar ftdi_sio con él, pero no lo conecta a ttyUSB0 como lo haría con el PID no modificado. ¿Alguna sugerencia sobre lo que estoy haciendo mal aquí?

No necesita modificar el kernel solo una vez; Puedes anularlo.

1. Desconecta el dispositivo
2. modprobe ftdi_sio
3. echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
4. Enchufar el dispositivo

Y tu dispositivo debería funcionar.

Su otra alternativa es usar la bindinterfaz sysfs; Sugiero usar lsusb -tpara descubrir la ruta correcta + interfaz en ese caso.

Usando un ejemplo parcial de mi sistema, de un dispositivo de almacenamiento usb (sería muy similar para 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

El formato del número es: BUS-PORT(.PORT)+:1.INTERFACE. El único número que no es visible en la salida lsusb es el primer dígito después de los dos puntos; y siempre ha sido un 1en mi experiencia. Alguien con un conocimiento más profundo del núcleo probablemente pueda decirme qué es y proporcionar un contraejemplo.

No necesita modificar el kernel, puede automatizar el proceso de esta manera:

1. Agregue la siguiente línea única a /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. Reinicie o ejecute sudo udevadm control --reloadpara recoger la nueva regla.

3. Desconecta el dispositivo.

4. Enchufe el dispositivo.

Una situación absolutamente similar ha sucedido con la placa de evaluación de SiLabs: el chip USB-UART CP2102 se proporciona con VID / PID irregular:

lsusb

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

problema resuelto cargando el módulo cp210x y enviando VID / PID como se mencionó anteriormente:

sudo modprobe cp210x

sudo -s

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

El archivo 99-cp210.rules correspondiente para el udev se ve a continuación:

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