Приєднання USB-послідовного пристрою із спеціальним PID до ttyUSB0 на вбудованому

Я намагаюся отримати FTDI USB-послідовний пристрій зі спеціальним 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-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

Формат числа є: 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'"