Découvrez quels modules sont associés à un périphérique USB?
Pourriez-vous recommander un moyen de déterminer quel pilote est utilisé pour un périphérique USB. Sorte d'un équivalent USB de lspci -k commande.
Recherche du ou des pilotes du noyau
L'appareil victime
$ 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
Nous allons essayer de savoir quel pilote est utilisé pour l'onduleur APC. Notez qu'il existe deux réponses à cette question: le pilote que le noyau utiliserait et le pilote actuellement utilisé. L'espace utilisateur peut demander au noyau d'utiliser un pilote différent (et dans le cas de mon onduleur APC, nut has).
Méthode 1: Utiliser usbutils (facile)
Le package usbutils (sur Debian, au moins) inclut un script appelé usb-devices. Si vous l'exécutez, il génère des informations sur les périphériques du système, y compris le pilote utilisé:
$ 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
⋮
Notez que cela répertorie le pilote actuel, pas celui par défaut. Il n'y a aucun moyen de trouver celui par défaut.
Méthode 2: utilisation de debugfs (nécessite root)
Si vous avez monté des debugfs, le noyau conserve un fichier au même format que usb-devices imprime à /sys/kernel/debug/usb/devices; vous pouvez afficher avec less, etc. Notez que les interfaces debugfs ne sont pas stables, donc différentes versions du noyau peuvent s'imprimer dans un format différent, ou le fichier peut manquer complètement.
Encore une fois, cela ne montre que le pilote actuel, pas celui par défaut.
Méthode 3: utiliser uniquement des utilitaires de base pour lire/sys directement (idéal pour les scripts ou la récupération)
Vous pouvez obtenir les informations de /sys, pensait que c'était plus douloureux que lspci. Celles-ci /sys les interfaces devraient être raisonnablement stables, donc si vous écrivez un script Shell, c'est probablement comme ça que vous voulez le faire.
Initialement, lsusb semble compter les périphériques à partir de 1, /sys à partir de 0. Donc 10-2 est une bonne estimation de l'endroit où trouver l'onduleur APC que lsusb donne comme bus 10, périphérique 3. Malheureusement, avec le temps, le mappage tombe en panne - sysfs réutilise les numéros même lorsque les numéros de périphérique ne le sont pas. . Le contenu du fichier devnum correspondra au numéro de périphérique donné par lsusb, vous pouvez donc faire quelque chose comme ceci:
$ 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
Donc, dans ce cas, c'est définitivement 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
Nous pouvons être sûrs que c'est le bon appareil en cating quelques-uns des fichiers:
$ cat idVendor idProduct manufacturer product
051d
0002
American Power Conversion
Back-UPS RS 1500 FW:8.g9 .D USB FW:g9
Si vous regardez dans 10-2: 1.0 (:1 est la "configuration", .0 l'interface: un seul périphérique USB peut faire plusieurs choses et avoir plusieurs pilotes; lsusb -v les affichera), il y a un fichier modalias et un lien symbolique de pilote:
$ cat 10-2\:1.0/modalias
usb:v051Dp0002d0106dc00dsc00dp00ic03isc00ip00in00
$ readlink driver
../../../../../../bus/usb/drivers/usbfs
Ainsi, le pilote actuel est usbfs. Vous pouvez trouver le pilote par défaut en demandant à modinfo sur les modalias:
$ /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)
Ainsi, l'onduleur APC utilise par défaut le pilote hid, ce qui est en effet correct. Et il utilise actuellement usbfs, ce qui est correct puisque nut est usbhid-ups le surveille.
Qu'en est-il des pilotes de l'espace utilisateur (usbfs)?
Lorsque le pilote est usbfs, cela signifie essentiellement qu'un programme d'espace utilisateur (non noyau) fonctionne comme pilote. Trouver de quel programme il s'agit nécessite un root (à moins que le programme ne fonctionne en tant qu'utilisateur) et est assez simple: quel que soit le programme sur lequel le fichier de l'appareil est ouvert.
Nous savons que notre périphérique "victime" est le bus 10, périphérique 3. Le fichier du périphérique est donc /dev/bus/usb/010/003 (au moins sur une Debian moderne), et lsof fournit la réponse:
# 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
Et en effet, son usbhid-ups comme prévu (lsof a tronqué le nom de la commande pour adapter la mise en page, si vous avez besoin du nom complet, vous pouvez utiliser ps 4951 pour l'obtenir, ou probablement quelques options de formatage de sortie lsof).
lsusb lui-même peut vous donner de bons résultats. Pour une sortie compacte, j'utilise lsusb -t, où -t montre les périphériques sous forme d'arborescence; ce format signale également le pilote.
Exemple de sortie:
$ 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
...
Si aucun pilote n'est utilisé, la ligne ressemblera à ceci (le périphérique dans mon exemple est un appareil photo pour lequel j'ai supprimé le pilote du noyau):
|__ Port 6: Dev 4, If 1, Class=Video, Driver=, 480M
En plus de ce que Derobert a écrit, je me retrouve à utiliser
lsusb -t
Qui imprimera une arborescence avec diverses informations sur les appareils connectés, y compris une partie "Driver" utile.
et
dmesg | grep driver
qui vous listera les pilotes des derniers périphériques branchés.
L'avantage est que ces deux commandes sont installées avec toutes les distributions.
On peut également utiliser lshw qui énumérera les périphériques sur tous les bus, y compris USB, PCI, etc. afin que vous puissiez voir quel pilote il utilise et ses ID associés:
Sudo lshw