Podłączanie urządzenia szeregowego USB z niestandardowym PID do ttyUSB0 na wbudowanym

Próbuję uzyskać urządzenie szeregowe USB FTDI z niestandardowym PID, aby automatycznie (lub nawet ręcznie) podłączyć się do ttyUSB% n, bez większego powodzenia. Normalny VID / PID urządzenia to 0403/6001. Po zaprogramowaniu w ten sposób działa idealnie i automatycznie podłącza się do ttyUSB0 po podłączeniu. Nawet po ponownym skompilowaniu sterownika w celu przestrzegania naszego nowego PID, po zaprogramowaniu z niestandardowym ttyUSB0 nie pojawia się, ale rozpoznaje to jako urządzenie ftdi_sio i ładuje sterownik.

Dodałem nasz PID do nagłówka i źródła:

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

Zrekompilowano całe jądro i przebudowano urządzenie. Po podłączeniu urządzenia otrzymuję:

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 pokazuje poprawny niestandardowy VID / PID. Wydaje się, że sterownik rozpoznaje, że powinien używać ftdi_sio, ale nie dołącza go do ttyUSB0, tak jak w przypadku niezmodyfikowanego PID. Wszelkie sugestie co do tego, co robię źle tutaj?

Nie musisz modyfikować jądra tylko raz; możesz to zmienić.

1. Odłącz urządzenie
2. modprobe ftdi_sio
3. echo 0403 6001 >/sys/bus/usb-serial/drivers/ftdi_sio/new_id
4. Podłącz urządzenie

Twoje urządzenie powinno działać.

Inną alternatywą jest użycie bindinterfejsu sysfs; W takim przypadku sugeruję użycie w lsusb -tcelu znalezienia właściwej ścieżki + interfejsu.

Korzystając z częściowego przykładu z mojego systemu, urządzenia pamięci USB (byłoby to bardzo podobne w przypadku 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

Format numeru jest: BUS-PORT(.PORT)+:1.INTERFACE. Jedyną liczbą niewidoczną na wyjściu lsusb jest pierwsza cyfra po dwukropku; i zawsze było to 1z mojego doświadczenia. Ktoś z głębszą wiedzą na temat jądra prawdopodobnie może mi powiedzieć, co to jest i podać kontrprzykład.

Nie musisz modyfikować jądra, możesz zautomatyzować proces w następujący sposób:

1. Dodaj następujący pojedynczy wiersz do /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. Uruchom ponownie lub uruchom, sudo udevadm control --reloadaby pobrać nową regułę.

3. Odłącz urządzenie.

4. Podłącz urządzenie.

absolutnie podobna sytuacja miała miejsce w przypadku płyty ewaluacyjnej od SiLabs - układ CP2102 USB-UART ma nieregularny VID / PID:

lsusb

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

problem rozwiązany przez załadowanie modułu cp210x i wysłanie VID / PID, jak wspomniano wcześniej:

sudo modprobe cp210x

sudo -s

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

odpowiedni plik 99-cp210.rules dla udev wygląda następująco:

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