Root/
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. |
13 | |
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 | |
36 | When you compile with CONFIG_HOTPLUG, you get a new kernel parameter: |
37 | /proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug". |
38 | That parameter names a program which the kernel may invoke at various times. |
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 |
87 | right driver modules get loaded, either at boot time or later. |
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 | |
108 | static const struct usb_device_id mydriver_id_table = { |
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 */ |
113 | } |
114 | MODULE_DEVICE_TABLE (usb, mydriver_id_table); |
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 | */ |
137 | } |
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 | |
149 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9