Pourriez-vous recommander un moyen de déterminer quel pilote est utilisé pour un périphérique USB? Une sorte d'équivalent usb de lspci -kcommande.

Trouver le (s) pilote (s) du noyau

Le dispositif 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 indiquer au noyau d'utiliser un pilote différent (et dans le cas de mon onduleur APC, nuta).

Méthode 1: Utilisation de usbutils (facile)

Le usbutilspaquet (au moins sur Debian) 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, notamment 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 pas moyen de trouver celui par défaut.

Méthode 2: Utilisation de debugfs (nécessite root)

Si vous avez des debugfs montés, le noyau conserve un fichier dans le même format que celui qui est usb-devicesaffiché à /sys/kernel/debug/usb/devices; vous pouvez voir avec less, etc. Notez que les interfaces de debugfs ne sont pas stables, de sorte que les différentes versions du noyau peuvent imprimer dans un format différent, ou complètement absent du dossier.

Encore une fois, cela ne montre que le pilote actuel, pas le pilote par défaut.

Méthode 3: Utiliser uniquement les utilitaires de base pour lire / sys directement (idéal pour les scripts ou la récupération)

Vous pouvez obtenir les informations hors de /sys, pensé que c'est plus douloureux que lspci. Ces /sysinterfaces doivent être raisonnablement stables. Par conséquent, si vous écrivez un script shell, vous voudrez probablement le faire.

Initialement, lsusbsemble compter les périphériques de 1 /sysà 0. Donc 10-2 est un bon moyen de savoir où trouver l’APC UPS lsusb que le bus 10, périphérique 3. Malheureusement, avec le temps, la cartographie tombe en panne - sysfs réutilise les chiffres même lorsque les numéros d'appareils ne le sont pas. Le devnumcontenu du fichier 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 bien 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 périphérique en catinsérant quelques 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 ( :1c'est la "configuration", .0l'interface — un seul périphérique USB peut faire plusieurs choses et avoir plusieurs pilotes; lsusb -vnous les montrerons), il y a un fichier modalias et un lien symbolique pour les pilotes:

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

Donc, le pilote actuel est usbfs. Vous pouvez trouver le pilote par défaut en posant des questions modinfosur 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 hidpilote, ce qui est correct. Et ses actuellement en utilisant usbfs, ce qui est correct puisque nutl » usbhid-upssurveille il.

Qu'en est-il des pilotes de l'espace utilisateur (usbfs)?

Lorsque le pilote est usbfs, cela signifie fondamentalement qu'un programme en espace utilisateur (non noyau) fonctionne en tant que pilote. Trouver le programme en question nécessite la racine (à moins que le programme ne soit exécuté en tant qu'utilisateur) et est assez simple: quel que soit le programme pour lequel le fichier de périphérique est ouvert.

Nous savons que notre périphérique "victime" est le bus 10, périphérique 3. Le fichier de périphérique est donc /dev/bus/usb/010/003(du moins sur une Debian moderne) et lsoffournit 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 effectivement, c’est usbhid-upscomme prévu (lsof tronque le nom de la commande pour adapter la présentation, si vous avez besoin du nom complet, vous pouvez l’utiliser ps 4951pour l'obtenir, ou probablement certaines options de formatage de la sortie lsof).

lsusblui-même peut vous donner de bons résultats. J'utilise pour les sorties compactes lsusb -t, où -taffiche les périphériques sous forme d'arborescence; Ce format indique é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 une caméra pour laquelle j'ai supprimé le pilote du noyau):

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

Outre ce que derobert a écrit, je me retrouve à utiliser

lsusb -t

Ce qui imprimera une arborescence avec diverses informations sur les périphériques connectés, y compris une partie utile «Pilote».

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 lshwqui é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 identifiants associés:

sudo lshw