Драйвер для usb linux

Библиотека сайта rus-linux.net

Обнаружение устройства USB в Linux

Независимо от того, есть ли драйвер для устройств USB в Linux системе или его нет, допустимое устройство USB всегда будет обнаруживаться в системе Linux в пространстве аппаратных средств и в пространстве ядра, поскольку система создана (и выполняет обнаружение) в соответствии со спецификациями протокола USB. Обнаружение в аппаратном пространстве осуществляется хост контроллером USB — как правило, соответствующем шинным устройством, аналогичным устройству PCI в системах x86. Соответствующий драйвер хост-контроллера обнаруживает устройство и транслирует информацию низкоуровнего физического слоя в конкретную информацию более высокого уровня протокола USB. Затем информация протокола USB, касающаяся устройства и, имеющая специальный формат, заносится в общий слой ядра USB (драйвер usbcore) в пространстве ядра, что позволяет обнаруживать устройства USB в пространстве ядра даже в том случае, когда отсутствует драйвер конкретного устройства.

Дальше — дело различных драйверов, интерфейсов и приложений (которые различны в различных дистрибутивах Linux) отображать обнаруженные устройства в пользовательском пространстве. На рис.1 показана иерархия подсистемы USB в Linux.

Рис.1: Подсистема USB в Linux

Краткий список всех обнаруженных устройств USB можно получить с помощью команды lsusb , которую следует запустить в роли пользователя root. На рис.2 приведен такой список как для случая с флэш устройством, так и без него. Параметр -v в команде lsusb позволяет получить более подробную информацию.

Рис.2: Информация, выдаваемая командой lsusb

Во многих дистрибутивах Linux, таких как Mandriva, Fedora, . , драйвер usbfs сконфигурирован так, что он загружается по умолчанию. В результате можно с помощью команды cat /proc/bus/usb/devices из директория /proc извлечь конкретную информации об обнаруженном USB-устройстве, представленную в удобном виде. На рис.3 показан типичный пример такой информации, которая находится в специальной секции, описывающей флэш-устройство. В списке обычно присутствует по одному такому разделу для каждого допустимого устройства USB, обнаруженного в системе.

Рис.3: Фрагмент информации из proc, касающейся USB

Разбираемся в секции, описывающей устройство USB

Чтобы дальше разбираться с этими секциями, нужно в первую очередь понять, что такое допустимое устройство USB. Для всех допустимых устройств USB есть одна или несколько конфигураций. Конфигурация устройства USB похожа на профиль, причем в качестве конфигурации, используемой по умолчанию, обычно используется первая конфигурация. Таким образом, в Linux для каждого устройства по умолчанию поддерживается только одна конфигурация. Для каждой конфигурации в устройстве может быть один или несколько интерфейсов. Интерфейс соответствует функции, предоставляемой устройством.

Интерфейсов может быть столько, сколько есть функций, предоставляемых устройством. Так, скажем, устройство МФУ USB-принтер (многофункциональное устройство) может выполнять печать, сканирование и отправку факсов, и, скорее всего, для него будет, по крайней мере, три интерфейса, по одному для каждой из функций. Таким образом, в отличие от других драйверов устройств, драйвер USB устройства, как правило, связывается / пишется отдельно для каждого интерфейса, а не для устройства в целом — это значит, что для устройства USB может быть несколько драйверов устройств, причем для интерфейсов различных устройств может использоваться один и тот же драйвер, — хотя, конечно, для одного интерфейса не может быть более одного драйвера.

Вполне нормальной и достаточно обычной является ситуация, когда для всех интерфейсов устройства USB используется один и тот же драйвер USB. В записи Driver=. для директория proc (рис. 3) показано, что в драйвер отсутствует отображение интерфейса ( none ).

Для каждого интерфейса есть один или несколько источников / приемников данных. Источник / приемник данных (endpoint) похож на конвейер (pipe), используемый для передачи информации в зависимости от функции либо в интерфейс, либо из интерфейса устройства. В зависимости от типа информации, источники / приемники данных могут быть четырех типов: Control, Interrupt, Bulk и Isochronous.

Прим.пер.: Подробное описание указанных четырех типов источников / приемников данных будет приведено в следующей статье данной серии статей.

Согласно спецификациям протокола USB во всех допустимых устройствах USB должен быть неявно используемый источник / приемник данных с номером 0 (end-point zero) — единственный двунаправленный источник / приемник данных. На рис.4 приведена полная наглядная схема допустимого устройства USB, соответствующее приведенному выше объяснению.

Рис.4: Общий взгляд на устройство USB

Вернемся обратно к секциям устройств USB (рис. 3) — первая буква в каждой строке соответствует различным частям спецификации устройства USB. Например, D — устройству, C — конфигурации, I — интерфейсу, E — источнику / приемнику данных (endpoint) и т.д. Подробнее об этом и о многом другом смотрите в исходном коде ядра в файле Documentation/usb/proc_usb_info.txt .

Регистрация драйвера USB для флеш устройства

«Похоже, для того, чтобы можно было самостоятельно написать первый драйвер USB, потребуется узнать много всего о протоколе USB, — конфигурацию устройства, интерфейсы, конвейеры передачи данных, четыре типа передачи данных, а также многие другие обозначения, например, T, B, S, …, которые есть в спецификации устройств USB» — вздохнула Светлана.

«Да, но ты не беспокойся — со всем этим можно будет разобраться подробнее позже. Давай со всем этим разбираться последовательно — возьмем интерфейс флеш устройства, связанного с драйвером нашего USB-устройства ( pen_register.ko )» — утешил Пагс.

Читайте также: Install win32 kali linux

Как и в любом другом Linux-драйвере, здесь также требуется конструктор и деструктор — используется тот же самый шаблон драйвера, который использовался для всех драйверов. Но содержимое будет другим, поскольку это драйвер слоя аппаратного протокола, т.е. горизонтальный драйвер в отличие от символьного драйвера, который был одним из вертикальных драйверов, рассмотренных ранее. Разница лишь в том, что вместо регистрации и отмены регистрации в VFS, здесь это должно выполняться на уровне соответствующего протокола — в данном случае — в ядре USB; вместо того, чтобы предоставлять интерфейс пользовательского пространства, например, файл устройства, он должен подключиться к реальному устройству в пространстве аппаратных средств.

Интерфейсы API для ядра USB выглядят следующим образом (прототип в ):

int usb_register(struct usb_driver *driver); void usb_deregister(struct usb_driver *);

В структуре usb_driver в соответствующих полях должны быть указаны имя устройства, идентификационная таблица, используемая для автообнаружения конкретного устройства, и две функции обратного вызова, которые вызываются ядром USB при горячем подключении и отключении устройства, соответственно.

Собираем все вместе в файл pen_register.c , который будет выглядеть следующим образом:

#include #include #include static int pen_probe(struct usb_interface *interface, const struct usb_device_id *id) < printk(KERN_INFO "Pen drive (%04X:%04X) plugged\n", id->idVendor, id->idProduct); return 0; > static void pen_disconnect(struct usb_interface *interface) < printk(KERN_INFO "Pen drive removed\n"); >static struct usb_device_id pen_table[] = < < USB_DEVICE(0x058F, 0x6387) >, <> /* Terminating entry */ >; MODULE_DEVICE_TABLE (usb, pen_table); static struct usb_driver pen_driver = < .name = "pen_driver", .id_table = pen_table, .probe = pen_probe, .disconnect = pen_disconnect, >; static int __init pen_init(void) < return usb_register(&pen_driver); >static void __exit pen_exit(void) < usb_deregister(&pen_driver); >module_init(pen_init); module_exit(pen_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Anil Kumar Pugalia "); MODULE_DESCRIPTION("USB Pen Registration Driver");

Затем можно повторить обычные шаги, выполняемые для любого Linux драйвера:

Собираем драйвер (файл .ko ) с помощью запуска команды make .
Загружаем драйвер с помощью команды insmod .
Выдаем список загруженных модулей с помощью команды lsmod .
Выгружаем драйвер с помощью команды rmmod .

Но, что удивительно, результат не будет таким, как ожидалось. Используйте команду dmesg и загляните в директорий proc для просмотра различных журналов и прочих подробностей. Это связано не с тем, что драйвер USB отличается от символьного драйвера, — здесь есть одна проблема. На рис.3 показано, что у флэш-устройства есть один интерфейс (с номером 0), который уже связан с обычным драйвером usb-storage.

Теперь, для того, чтобы связать наш драйвер с этим интерфейсом, нам нужно выгрузить драйвер usb-storage (т. е. выполнить команду rmmod usb-storage ) и переподключить флэш-накопитель. Как только это будет сделано, результаты станут такими, как ожидалось. На рис.5 показан фрагмент информации из журналов и из директория proc . Снова подключите и отключите (в горячем режиме) флеш устройство и пронаблюдайте, как действуют вызовы probe и disconnect.

Читайте также: Кали линукс для хакеров

Рис.5: Флеш устройство в действии

Подведем итог

«Наконец-то! Что-то действует!» — облегченно сказала Светлана. «Но мне кажется, что для того, чтобы собрать полный драйвер устройства USB, здесь есть еще много того, с чем следует разбираться (например, с идентификационной таблицей, обратными вызовами probe и disconnect и т. д.)».

«Да, ты права. Давай разбираться со всем по порядку и с перерывами » — ответил Пагс, прервав самого себя.

Источник

Установка драйвера USB WiFi адаптера в Linux (на примере DEXP WFA-601)

В связи с переездом и нежеланием захламлять дом проводами повесил в прихожей роутер, а для компьютера купил Wi-Fi адаптер DEXP WFA-601.
Пока работал в Windows 10 проблем не было. Однако сгоревший жесткий диск подтолкнул меня к установке Linux (конкретно Kubuntu).

Путь веры

Захожу на официальный сайт производителя и скачиваю драйвер для любой ОС. Результат предсказуем: Linux != «любая ОС».
Роюсь в коробочках и нахожу родной CD-диск от адаптера. Скачиваю драйвер, нахожу «install.sh»:

$ chmod a+x install.sh $ sudo ./install.sh

Драйвер не компилируется, вылетает с ошибкой.

cc1: error: code model kernel does not support PIC mode

Не буду тратить время на описание, боя с ней. В гугле нашел советы персобирать ядро, пересобирать gcc… В общем мой уровень не позволяет такие сложности.

Путь разума

Первым делом решил проверить видит ли железку ядро. Вытаскиваю адаптер и втыкаю его в соседний разъем.

. [ 1498.558445] usb 1-1.1: new high-speed USB device number 6 using ehci-pci [ 1498.667540] usb 1-1.1: New USB device found, idVendor=0bda, idProduct=a811 [ 1498.667544] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 1498.667546] usb 1-1.1: Product: 802.11ac WLAN Adapter [ 1498.667548] usb 1-1.1: Manufacturer: Realtek [ 1498.667550] usb 1-1.1: SerialNumber: 00e04c000001

Ищу название драйвера на лазерном диске от производителя, вот оно: RTL8821AU_Linux_v5.2.6.3_25025_COEX20171103-6c6d.20171106.
Подключаю смартфон в режиме модема и пробую в лоб:

sk@ds:~$ sudo apt install realtek-88xxau-dkms [sudo] password fоr sk: Чтение списков пакетов… Готово Построение дерева зависимостей Чтение информации о состоянии… Готово E: Невозможно найти пакет realtek-88xxau-dkms

Видимо репозиторий моего дистрибутива к такому не готов. Захожу на гитхаб и качаю исправленную версию драйвера.

Распаковываю, нахожу dkms-install.sh, запускаю его. Драйвер установлен.
Не будучи гуру linux не стал разбираться с остановкой и запуском адаптера, ввел:

Источник