Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 1 | LINUX HOTPLUGGING |
| 2 | |
| 3 | In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices |
| 4 | into the bus with power on. In most cases, users expect the devices to become |
| 5 | immediately usable. That means the system must do many things, including: |
| 6 | |
| 7 | - Find a driver that can handle the device. That may involve |
| 8 | loading a kernel module; newer drivers can use module-init-tools |
| 9 | to publish their device (and class) support to user utilities. |
| 10 | |
| 11 | - Bind a driver to that device. Bus frameworks do that using a |
| 12 | device driver's probe() routine. |
Andrea Gelmini | b03dbff | 2010-05-23 21:56:42 +0200 | [diff] [blame] | 13 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 14 | - Tell other subsystems to configure the new device. Print |
| 15 | queues may need to be enabled, networks brought up, disk |
| 16 | partitions mounted, and so on. In some cases these will |
| 17 | be driver-specific actions. |
| 18 | |
| 19 | This involves a mix of kernel mode and user mode actions. Making devices |
| 20 | be immediately usable means that any user mode actions can't wait for an |
| 21 | administrator to do them: the kernel must trigger them, either passively |
| 22 | (triggering some monitoring daemon to invoke a helper program) or |
| 23 | actively (calling such a user mode helper program directly). |
| 24 | |
| 25 | Those triggered actions must support a system's administrative policies; |
| 26 | such programs are called "policy agents" here. Typically they involve |
| 27 | shell scripts that dispatch to more familiar administration tools. |
| 28 | |
| 29 | Because some of those actions rely on information about drivers (metadata) |
| 30 | that is currently available only when the drivers are dynamically linked, |
| 31 | you get the best hotplugging when you configure a highly modular system. |
| 32 | |
| 33 | |
| 34 | KERNEL HOTPLUG HELPER (/sbin/hotplug) |
| 35 | |
Stephen Rothwell | 40b3136 | 2013-05-21 13:49:35 +1000 | [diff] [blame] | 36 | There is a kernel parameter: /proc/sys/kernel/hotplug, which normally |
| 37 | holds the pathname "/sbin/hotplug". That parameter names a program |
| 38 | which the kernel may invoke at various times. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 39 | |
| 40 | The /sbin/hotplug program can be invoked by any subsystem as part of its |
| 41 | reaction to a configuration change, from a thread in that subsystem. |
| 42 | Only one parameter is required: the name of a subsystem being notified of |
| 43 | some kernel event. That name is used as the first key for further event |
| 44 | dispatch; any other argument and environment parameters are specified by |
| 45 | the subsystem making that invocation. |
| 46 | |
| 47 | Hotplug software and other resources is available at: |
| 48 | |
| 49 | http://linux-hotplug.sourceforge.net |
| 50 | |
| 51 | Mailing list information is also available at that site. |
| 52 | |
| 53 | |
| 54 | -------------------------------------------------------------------------- |
| 55 | |
| 56 | |
| 57 | USB POLICY AGENT |
| 58 | |
| 59 | The USB subsystem currently invokes /sbin/hotplug when USB devices |
| 60 | are added or removed from system. The invocation is done by the kernel |
| 61 | hub daemon thread [khubd], or else as part of root hub initialization |
| 62 | (done by init, modprobe, kapmd, etc). Its single command line parameter |
| 63 | is the string "usb", and it passes these environment variables: |
| 64 | |
| 65 | ACTION ... "add", "remove" |
| 66 | PRODUCT ... USB vendor, product, and version codes (hex) |
| 67 | TYPE ... device class codes (decimal) |
| 68 | INTERFACE ... interface 0 class codes (decimal) |
| 69 | |
| 70 | If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is |
| 71 | the pathname of the device, and is useful for devices with multiple and/or |
| 72 | alternate interfaces that complicate driver selection. By design, USB |
| 73 | hotplugging is independent of "usbdevfs": you can do most essential parts |
| 74 | of USB device setup without using that filesystem, and without running a |
| 75 | user mode daemon to detect changes in system configuration. |
| 76 | |
| 77 | Currently available policy agent implementations can load drivers for |
| 78 | modules, and can invoke driver-specific setup scripts. The newest ones |
| 79 | leverage USB module-init-tools support. Later agents might unload drivers. |
| 80 | |
| 81 | |
| 82 | USB MODUTILS SUPPORT |
| 83 | |
| 84 | Current versions of module-init-tools will create a "modules.usbmap" file |
| 85 | which contains the entries from each driver's MODULE_DEVICE_TABLE. Such |
| 86 | files can be used by various user mode policy agents to make sure all the |
Andrea Gelmini | b03dbff | 2010-05-23 21:56:42 +0200 | [diff] [blame] | 87 | right driver modules get loaded, either at boot time or later. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 88 | |
| 89 | See <linux/usb.h> for full information about such table entries; or look |
| 90 | at existing drivers. Each table entry describes one or more criteria to |
| 91 | be used when matching a driver to a device or class of devices. The |
| 92 | specific criteria are identified by bits set in "match_flags", paired |
| 93 | with field values. You can construct the criteria directly, or with |
| 94 | macros such as these, and use driver_info to store more information. |
| 95 | |
| 96 | USB_DEVICE (vendorId, productId) |
| 97 | ... matching devices with specified vendor and product ids |
| 98 | USB_DEVICE_VER (vendorId, productId, lo, hi) |
| 99 | ... like USB_DEVICE with lo <= productversion <= hi |
| 100 | USB_INTERFACE_INFO (class, subclass, protocol) |
| 101 | ... matching specified interface class info |
| 102 | USB_DEVICE_INFO (class, subclass, protocol) |
| 103 | ... matching specified device class info |
| 104 | |
| 105 | A short example, for a driver that supports several specific USB devices |
| 106 | and their quirks, might have a MODULE_DEVICE_TABLE like this: |
| 107 | |
Jeremiah Mahler | 31e01f0 | 2014-06-06 12:29:17 -0700 | [diff] [blame^] | 108 | static const struct usb_device_id mydriver_id_table[] = { |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 109 | { USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X }, |
| 110 | { USB_DEVICE (0xbbbb, 0x8888), driver_info: QUIRK_Y|QUIRK_Z }, |
| 111 | ... |
| 112 | { } /* end with an all-zeroes entry */ |
Jeremiah Mahler | 31e01f0 | 2014-06-06 12:29:17 -0700 | [diff] [blame^] | 113 | }; |
| 114 | MODULE_DEVICE_TABLE(usb, mydriver_id_table); |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 115 | |
| 116 | Most USB device drivers should pass these tables to the USB subsystem as |
| 117 | well as to the module management subsystem. Not all, though: some driver |
| 118 | frameworks connect using interfaces layered over USB, and so they won't |
| 119 | need such a "struct usb_driver". |
| 120 | |
| 121 | Drivers that connect directly to the USB subsystem should be declared |
| 122 | something like this: |
| 123 | |
| 124 | static struct usb_driver mydriver = { |
| 125 | .name = "mydriver", |
| 126 | .id_table = mydriver_id_table, |
| 127 | .probe = my_probe, |
| 128 | .disconnect = my_disconnect, |
| 129 | |
| 130 | /* |
| 131 | if using the usb chardev framework: |
| 132 | .minor = MY_USB_MINOR_START, |
| 133 | .fops = my_file_ops, |
| 134 | if exposing any operations through usbdevfs: |
| 135 | .ioctl = my_ioctl, |
| 136 | */ |
Jeremiah Mahler | 31e01f0 | 2014-06-06 12:29:17 -0700 | [diff] [blame^] | 137 | }; |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 138 | |
| 139 | When the USB subsystem knows about a driver's device ID table, it's used when |
| 140 | choosing drivers to probe(). The thread doing new device processing checks |
| 141 | drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and |
| 142 | device descriptors for the device. It will only call probe() if there is a |
| 143 | match, and the third argument to probe() will be the entry that matched. |
| 144 | |
| 145 | If you don't provide an id_table for your driver, then your driver may get |
| 146 | probed for each new device; the third parameter to probe() will be null. |
| 147 | |
| 148 | |