Manual driver binding and unbinding
In the sysfs tree, every driver now has bind and unbind files associated with it:
$ tree /sys/bus/usb/drivers/ub/ /sys/bus/usb/drivers/ub/ |-- 1-1:1.0 -> ../../../../devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1:1.0 |-- bind |-- module -> ../../../../module/ub `-- unbind
In order to unbind a device from a driver, simply write the bus id of the device to the unbind file:
echo -n "1-1:1.0" > /sys/bus/usb/drivers/ub/unbind
and the device will no longer be bound to the driver:
$ tree /sys/bus/usb/drivers/ub/ /sys/bus/usb/drivers/ub/ |-- bind |-- module -> ../../../../module/ub `-- unbind
To bind a device to a driver, the device must first not be controlled by any other driver. To ensure this, look for the "driver" symlink in the device directory:
$ tree /sys/bus/usb/devices/1-1:1.0 /sys/bus/usb/devices/1-1:1.0 |-- bAlternateSetting |-- bInterfaceClass |-- bInterfaceNumber |-- bInterfaceProtocol |-- bInterfaceSubClass |-- bNumEndpoints |-- bus -> ../../../../../../bus/usb |-- modalias `-- power `-- state
Then, simply write the bus id of the device you wish to bind, into the bind file for that driver:
echo -n "1-1:1.0" > /sys/bus/usb/drivers/usb-storage/bind
And check that the binding was successful:
$ tree /sys/bus/usb/devices/1-1:1.0 /sys/bus/usb/devices/1-1:1.0 |-- bAlternateSetting |-- bInterfaceClass |-- bInterfaceNumber |-- bInterfaceProtocol |-- bInterfaceSubClass |-- bNumEndpoints |-- bus -> ../../../../../../bus/usb |-- driver -> ../../../../../../bus/usb/drivers/usb-storage |-- host2 | `-- power | `-- state |-- modalias `-- power `-- state
As the example above shows, this capability is very useful for switching devices between drivers which handle the same type of device (both the ub and usb-storage drivers handle USB mass storage devices, like flash drives.)
A number of "enterprise" Linux distributions offer multiple drivers of different version levels in their kernel packages. This manual binding feature will allow configuration tools to pick and choose which devices should be bound to which drivers, allowing users to upgrade only specific devices if they wish to.
In order for a device to bind successfully with a driver, that driver
must already support that device. This is why you can not just
arbitrarily bind any device to any driver. To help with the issue of
adding new devices support to drivers after they are built, the PCI
system offers a dynamic_id file in sysfs so that user space
can write in new device ids that the driver should bind too. In the
future, this ability to add new driver IDs to a running kernel will be
moved into the driver core to make it available for all buses.
Index entries for this article | |
---|---|
GuestArticles | Kroah-Hartman, Greg |
Posted Jul 15, 2005 2:59 UTC (Fri)
by mdomsch (guest, #5920)
[Link]
Posted Jul 27, 2005 22:03 UTC (Wed)
by MarkWilliamson (guest, #30166)
[Link]
Posted Nov 25, 2005 3:26 UTC (Fri)
by jik (guest, #34093)
[Link]
Posted Nov 1, 2015 18:00 UTC (Sun)
by Jaimz (guest, #105151)
[Link]
Last paragraph, it's not 'dynamic_id', but should be 'new_id'.Manual driver binding and unbinding
This'll very _very_ handy for USB virtualisation under Xen - we'll be able Manual driver binding and unbinding
to unbind a device from the "host" kernel and plumb it through the USB
virtualising driver and into a guest kernel. Great stuff!
I've got Fedora Core development kernel 2.6.14-1.1707_FC5smp. I tried the directions here to unbind the usbfs driver from my scanner. After doing so, "lsusb" indeed shows "Driver=(none)", but when I look in /sys/bus/usb/devices/1-2:1.0, the directory for the scanner device, I see that it still has a driver link pointing back at the usbfs driver, and /sys/bus/usb/drivers/usbfs still has a link pointing at the device. Furthermore, I still can't open the scanner from inside vmware, so it appears that the unbind didn't completely "take." Any ideas?Manual driver binding and unbinding
Manual driver binding and unbinding