Подключение устройства USB-Serial с пользовательским PID к ttyUSB0 на встроенном

Я пытаюсь получить устройство FTDI USB-Serial с пользовательским PID для автоматического (или даже ручного) подключения к ttyUSB% n, но без особого успеха. Обычный VID / PID устройства - 0403/6001. При таком программировании он работает отлично и автоматически подключается к ttyUSB0 при подключении. Даже если драйвер перекомпилирован для соблюдения нашего нового PID, при программировании с пользовательским ttyUSB0 не появляется, но он распознает его как устройство ftdi_sio и загружает драйвер.

Я добавил наш PID в заголовок и источник:

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

Перекомпилировал все ядро ​​и перепрошил устройство. Когда я подключаю устройство, я получаю:

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 показывает правильный пользовательский VID / PID. Драйвер, кажется, распознает, что он должен использовать ftdi_sio вместе с ним, но не присоединяет его к ttyUSB0, как это было бы с неизмененным PID. Любые предложения относительно того, что я делаю не так здесь?

Вам не нужно модифицировать ядро ​​только на один раз; Вы можете переопределить это.

1. Отключите устройство
2. modprobe ftdi_sio
3. echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
4. Подключите устройство

И ваше устройство должно работать.

Другой вариант - использовать bindинтерфейс sysfs; Я предлагаю использовать, lsusb -tчтобы выяснить правильный путь + интерфейс в этом случае.

Используя частичный пример из моей системы, устройства хранения USB (это было бы очень похоже на последовательный порт USB).

$ 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

Формат числа является: BUS-PORT(.PORT)+:1.INTERFACE. Единственное число, которое не видно в выводе lsusb - это первая цифра после двоеточия; и это всегда было 1в моем опыте. Кто-то с более глубокими познаниями в ядре, возможно, скажет мне, что это такое, и предоставит контрпример.

Вам не нужно изменять ядро, вы можете автоматизировать процесс следующим образом:

1. Добавьте следующую строку в /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. Либо перезагрузитесь, либо запустите, sudo udevadm control --reloadчтобы выбрать новое правило.

3. Отключите устройство.

4. Подключите устройство.

Совершенно аналогичная ситуация произошла с платой eval от SiLabs - чип USB-UART CP2102, снабженный нерегулярными VID / PID:

lsusb

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

проблема решена загрузкой модуля cp210x и отправкой VID / PID, как упоминалось ранее:

sudo modprobe cp210x

sudo -s

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

соответствующий файл 99-cp210.rules для udev выглядит следующим образом:

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