Descobrir quais módulos estão associados a um dispositivo USB?


35

Você poderia recomendar uma maneira de descobrir qual driver está sendo usado para um dispositivo USB. Tipo de um equivalente usb de lspci -kcomando.

Respostas:


57

Localizando o (s) Driver (s) do Kernel

O dispositivo vítima

$ lsusb 
Bus 010 Device 002: ID 046d:c01e Logitech, Inc. MX518 Optical Mouse
Bus 010 Device 003: ID 051d:0002 American Power Conversion Uninterruptible Power Supply

Vamos tentar descobrir qual driver é usado para o APC UPS. Observe que existem duas respostas para esta pergunta: O driver que o kernel usaria e o driver que está atualmente em uso. O espaço do usuário pode instruir o kernel a usar um driver diferente (e, no caso do meu APC UPS, nutpossui).

Método 1: Usando usbutils (fácil)

O usbutilspacote (no Debian, pelo menos) inclui um script chamado usb-devices. Se você executá-lo, ele gera informações sobre os dispositivos no sistema, incluindo qual driver é usado:

$ usb-devices
⋮
T:  Bus=10 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=1.5 MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=051d ProdID=0002 Rev=01.06
S:  Manufacturer=American Power Conversion
S:  Product=Back-UPS RS 1500 FW:8.g9 .D USB FW:g9 
S:  SerialNumber=XXXXXXXXXXXX  
C:  #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr=24mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=03(HID  ) Sub=00 Prot=00 Driver=usbfs
⋮

Observe que isso lista o driver atual, não o padrão. Não há como encontrar o padrão.

Método 2: usando debugfs (requer raiz)

Se você possui os debugfs montados, o kernel mantém um arquivo no mesmo formato que o usb-devicesimpresso em /sys/kernel/debug/usb/devices; você pode ver com less, etc. Observe que as interfaces debugfs não são estáveis; portanto, versões diferentes do kernel podem ser impressas em um formato diferente ou estar faltando o arquivo completamente.

Mais uma vez, isso mostra apenas o driver atual, não o padrão.

Método 3: usando apenas utilitários básicos para ler / sys diretamente (melhor para scripts ou recuperação)

Você pode obter as informações /sys, achou mais doloroso do que isso lspci. Essas /sysinterfaces devem ser razoavelmente estáveis; portanto, se você estiver escrevendo um script de shell, provavelmente é assim que deseja fazê-lo.

Inicialmente, lsusbparece contar dispositivos de 1 a /sys0. Portanto, 10-2 é um bom palpite sobre onde encontrar o APC UPS lsusb fornece como barramento 10, dispositivo 3. Infelizmente, com o tempo, esse mapeamento é interrompido - o sysfs reutiliza números mesmo quando os números do dispositivo não são. O devnumconteúdo do arquivo corresponderá ao número do dispositivo fornecido por lsusb, para que você possa fazer algo assim:

$ grep -l '^3$' /sys/bus/usb/devices/10-*/devnum     # the ^ and $ to prevent also matching 13, 31, etc.
/sys/bus/usb/devices/10-2/devnum

Então, neste caso, é definitivamente 10-2.

$ cd /sys/bus/usb/devices/10-2
$ ls
10-2:1.0             bDeviceClass     bMaxPower           descriptors  ep_00         maxchild   remove     urbnum
authorized           bDeviceProtocol  bNumConfigurations  dev          idProduct     power      serial     version
avoid_reset_quirk    bDeviceSubClass  bNumInterfaces      devnum       idVendor      product    speed
bcdDevice            bmAttributes     busnum              devpath      ltm_capable   quirks     subsystem
bConfigurationValue  bMaxPacketSize0  configuration       driver       manufacturer  removable  uevent

Podemos ter certeza de que este é o dispositivo certo, catinserindo alguns dos arquivos:

$ cat idVendor idProduct manufacturer product 
051d
0002
American Power Conversion
Back-UPS RS 1500 FW:8.g9 .D USB FW:g9 

Se você procurar em 10-2: 1.0 ( :1é a "configuração", .0a interface - um único dispositivo USB pode fazer várias coisas e ter vários drivers; lsusb -vmostrará isso), há um arquivo modalias e um link simbólico de driver:

$ cat 10-2\:1.0/modalias 
usb:v051Dp0002d0106dc00dsc00dp00ic03isc00ip00in00
$ readlink driver
../../../../../../bus/usb/drivers/usbfs

Então, o driver atual é usbfs. Você pode encontrar o driver padrão perguntando modinfosobre as modalidades:

$ /sbin/modinfo `cat 10-2\:1.0/modalias`
filename:       /lib/modules/3.6-trunk-amd64/kernel/drivers/hid/usbhid/usbhid.ko
license:        GPL
description:    USB HID core driver
author:         Jiri Kosina
author:         Vojtech Pavlik
author:         Andreas Gal
alias:          usb:v*p*d*dc*dsc*dp*ic03isc*ip*in*
depends:        hid,usbcore
intree:         Y
vermagic:       3.6-trunk-amd64 SMP mod_unload modversions 
parm:           mousepoll:Polling interval of mice (uint)
parm:           ignoreled:Autosuspend with active leds (uint)
parm:           quirks:Add/modify USB HID quirks by specifying  quirks=vendorID:productID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp)

Portanto, o no-break da APC é o hiddriver padrão , o que é realmente correto. E está atualmente usando usbfs, o que é correto, já que nuto usbhid-upsestá monitorando.

E os drivers userspace (usbfs)?

Quando o driver está usbfs, significa basicamente que um programa no espaço do usuário (sem kernel) está funcionando como o driver. Encontrar qual programa é requer raiz (a menos que o programa esteja sendo executado como seu usuário) e é bastante fácil: qualquer programa que tenha o arquivo do dispositivo aberto.

Sabemos que nosso dispositivo "vítima" é o barramento 10, dispositivo 3. Portanto, o arquivo do dispositivo é /dev/bus/usb/010/003(pelo menos em um Debian moderno) e lsoffornece a resposta:

# lsof /dev/bus/usb/010/003 
COMMAND    PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
usbhid-up 4951  nut    4u   CHR 189,1154      0t0 8332 /dev/bus/usb/010/003

E, de fato, é usbhid-upsconforme o esperado (lsof truncou o nome do comando para ajustar o layout, se você precisar do nome completo, pode usá ps 4951-lo para obtê-lo ou, provavelmente, algumas opções de formatação de saída lsof).


Definitivamente vou perder meu debate com meu amigo Windows vs Linux com este :). Dará alguns dias para ver se uma solução mais simples aparece. Obrigado pelo esforço.
TheMeaningfulEngineer

@ Alan OK, eu encontrei mais duas maneiras, uma delas é bastante simples. Além disso, esclareci quais das duas respostas possíveis para "qual driver?" cada método fornece.
derobert

Não acho que sua reivindicação sobre a localização do dispositivo /sys/bus/usb/devicesesteja correta. Eu tenho um dispositivo no barramento 1 que usb-devicesdiz ser o dispositivo 12, mas não existe /sys/bus/usb/devices/1-11no meu sistema.
Cerin

@ Cerin realmente não é. Vou colocar uma melhor. Obrigado.
derobert

13

lsusbem si pode obter bons resultados. Para saída compacta eu uso lsusb -t, onde -tmostra os dispositivos como uma árvore; esse formato também informa o driver.

Exemplo de saída:

 $ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/:  Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
...

Se nenhum driver for usado, a linha ficará assim (o dispositivo no meu exemplo é uma câmera para a qual removi o driver do kernel):

    |__ Port 6: Dev 4, If 1, Class=Video, Driver=, 480M

0

Além do que derobert escreveu, eu me vejo usando

lsusb -t

O qual imprimirá uma árvore com várias informações sobre os dispositivos conectados, incluindo uma parte útil «Driver».

e

dmesg | grep driver

que listará os drivers dos dispositivos conectados mais recentes.

A vantagem é que esses dois comandos vêm instalados com todas as distribuições.


0

Pode-se também usar o lshwque enumerará os dispositivos em todos os barramentos, incluindo USB, PCI, etc, para que você possa ver qual driver ele usa e seus IDs associados:

sudo lshw
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.