Dev bus usb linux

Determine USB device file Path

How can i get USB device file path correctly in Linux. I used command: find / -iname «usb» and got the result as below:

/dev/bus/usb /sys/bus/usb /sys/bus/usb/drivers/usb /sys/kernel/debug/usb 

sh-3.2# ls /sys/bus/usb/devices/ 1-0:1.0 1-1:1.0 3-0:1.0 5-0:1.0 usb1 usb3 usb5 1-1 2-0:1.0 4-0:1.0 6-0:1.0 usb2 usb4 usb6 

2:0:0:0 host0 host2 target2:0:0 

So which device file is used for USB? How can i indentify it? I need to make a C program with USB device file. Further more, could you explain to me the number 1-1:1.0? What does it mean? Thank you.

I need to check informations which related to USB device. So i think i will send ioctl to USB device file and read the feedback data? Is this possible?

What do you mean with «read/write verification»? Is this for some specific device? Or are you trying to duplicate lsusb ?

2 Answers 2

So which device file is used for USB? How can i indentify it?

What you see behind /sys/ is mainly configuration/information about devices. /dev/bus/usb is what you are looking for. I think that the following article can help you

Is quite old, but still it can help you. (In the article they speak about /proc/bus/usb , today we have /dev/bus/usb )

Further more, could you explain to me the number 1-1:1.0? What does it mean?

Each field identify the connection point of your device. The first two field are mandatory:

• X is the USB bus of your motherboard where is connected the USB system.
• Y is the port in use on the bus system

So the USB device identified with the string 3-3 is the device connected on the port 3 of the bus 3.

If you connect an USB hub, you are extending the connection capability of a single USB port. The Linux kernel identify this situation by appending the Z field.

So, the USB device identified with the string 1-2.5 is the device connected on the port 5 of the hub connected on the port 2 of the bus 1.

USB specification allow you to connect in cascade more then one USB hub, so the Linux kernel continue to append the port in use on the different hubs. So, the USB device identified with the string 1-2.1.1 is the device connected on the port 1 of the hub connected on the port 1 of the hub connected to the port 2 of the bus 1.

A fast way to retrieve these information is to read the kernel messages (if you can).

$ dmesg | grep usb [. snip . ] [ 2.047950] usb 4-1: new full-speed USB device number 2 using ohci_hcd [ 2.202628] usb 4-1: New USB device found, idVendor=046d, idProduct=c318 [ 2.202638] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2.202643] usb 4-1: Product: Logitech Illuminated Keyboard [ 2.202648] usb 4-1: Manufacturer: Logitech [. snip . ] 

Then, the last two fields of the pattern (after colon) identify an internal section of an USB device :

• A is the configuration number of the device
• B is the interface number of a configuration

So, the string 4-1:1.1 means: the interface 1, on configuration 1 that is connected on the port 1 of the bus 4.

You can retrieve these information with the command lsusb .

Источник

How creation of new USB device file in /dev/bus/usb/001/ directory work?

I noticed that every time I connect a USB device, a new device gets created in the /dev/bus/usb/001/ directory. Further on each reconnection of the same device, the «Device Number» and «ID» change. So, I’d like to know how the creation of new device file (in /dev/bus/usb/001/ ) work? Can I control the behaviour, say limit the device number to 002 , by making changes in some configuration file (if any)? Here’s a the output for reference:

$ ls /dev/bus/usb/001 001 002 $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 0781:5406 SanDisk Corp. Cruzer Micro U3 $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 003: ID 08ec:0015 M-Systems Flash Disk Pioneers Kingston DataTraveler ELITE $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 008: ID 0781:5406 SanDisk Corp. Cruzer Micro U3 $ ls /dev/bus/usb/001/ 001 008 

_{( Also I don’t know why Kingston Flash Disk was shown in the output. I don’t have a Kingston device. Maybe it’s just a glitch, or is it? )}

Another contextual topic of interest:

Источник

USB device detection on /dev directory on Linux

Using the lsusb command in Linux I have come to know about bus and device numbers, along with its name of newly attached USB devices. But how can I know on which device directory (/dev/*) USB device get attached in Linux using command lines only?

I tried dmesg | tail, It is showing only USB details like VID,PID,product name, manufacturer name etc. I can’t know ?, where udev (device manager) is attaching device under /dev/

2 Answers 2

It isn’t a rule that every device has to show up directly under /dev/, but some device classes will be nested under sub-directories inside /dev/.

USB device drivers are a bit different. If you connect a valid USB device, USB HCI would read the VID:PID and will tell the usb-core that the device with VID:PID combination is connected.

If the usbcore detects any registered driver for the VID:PID combination, it will couple it with the device, and the device file creation would happen accordingly

The device will show in /dev/bus/usb/. even if, the corresponding driver is not present, to indicate that the device was detected.

You need to have the device driver to have the device in action/operation.

You can verify whether a device driver is coupled to the device through

Each detected USB device will have an entry here, and also shows the «Driver=» field, to show which driver is associated with your device.

Now, IFF there is a driver, that makes an entry in appropriate /dev tree, you will find the device there.

NOT every device will show up directly under /dev/ in the first level. say, your mouse/keyboard will not show-up directly under /dev, but inside /dev/input/

Likewise, IF the connected USB device is a char/block device, it MAY show up there, that too have exceptions.

If your device is and ethernet/wifi device, the interface device will NOT show up under /dev/, cross-check with your existing eth0, wlan0, they will not appear directly under /dev/, but will in /proc/net/devices

sda/b/c shows up under /dev directly, because they are block devices and are managed by udev, as such.

Источник

Find out which modules are associated with a usb device?

Could you recommend a way to figure out which driver is being used for a USB device. Sort of a usb equivalent of lspci -k command.

4 Answers 4

Finding the Kernel Driver(s)

The victim device

$ 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 

We’re going to try to find out what driver is used for the APC UPS. Note that there are two answers to this question: The driver that the kernel would use, and the driver that is currently in use. Userspace can instruct the kernel to use a different driver (and in the case of my APC UPS, nut has).

Method 1: Using usbutils (easy)

The usbutils package (on Debian, at least) includes a script called usb-devices . If you run it, it outputs information about the devices on the system, including which driver is used:

$ 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 ⋮ 

Note that this lists the current driver, not the default one. There isn’t a way to find the default one.

Method 2: Using debugfs (requires root)

If you have debugfs mounted, the kernel maintains a file in the same format as usb-devices prints out at /sys/kernel/debug/usb/devices ; you can view with less , etc. Note that debugfs interfaces are not stable, so different kernel versions may print in a different format, or be missing the file entirely.

Once again, this only shows the current driver, not the default.

Method 3: Using only basic utilities to read /sys directly (best for scripting or recovery)

You can get the information out of /sys , thought its more painful than lspci . These /sys interfaces should be reasonably stable, so if you’re writing a shell script, this is probably how you want to do it.

Initially, lsusb seems to count devices from 1, /sys from 0. So 10-2 is a good guess for where to find the APC UPS lsusb gives as bus 10, device 3. Unfortunately, over time that mapping breaks down—sysfs re-uses numbers even when device numbers aren’t. The devnum file’s contents will match the device number given by lsusb, so you can do something like this:

$ 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 

So, in this case, it’s definitely 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 

We can be sure this is the right device by cat ing a few of the files:

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

If you look in 10-2:1.0 ( :1 is the «configuration», .0 the interface—a single USB device can do multiple things, and have multiple drivers; lsusb -v will show these), there is a modalias file and a driver symlink:

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

So, the current driver is usbfs . You can find the default driver by asking modinfo about the 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) 

So, the APC UPS defaults to the hid driver, which is indeed correct. And its currently using usbfs, which is correct since nut ‘s usbhid-ups is monitoring it.

What about userspace (usbfs) drivers?

When the driver is usbfs , it basically means a userspace (non-kernel) program is functioning as the driver. Finding which program it is requires root (unless the program is running as your user) and is fairly easy: whichever program has the device file open.

We know that our «victim» device is bus 10, device 3. So the device file is /dev/bus/usb/010/003 (at least on a modern Debian), and lsof provides the answer:

# 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 

And indeed, its usbhid-ups as expected (lsof truncated the command name to make the layout fit, if you need the full name, you can use ps 4951 to get it, or probably some lsof output formatting options).

Источник