1 USB 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 modutils to
9 publish their device (and class) support to user utilities.
10
11 - Bind a driver to that device. That's done using the USB
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
30 KERNEL HOTPLUG HELPER (/sbin/hotplug)
31
32 When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
33 /proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
34 That parameter names a program which the kernel may invoke at various times.
35
36 The /sbin/hotplug program can be invoked by any subsystem as part of its
37 reaction to a configuration change, from a thread in that subsystem.
38 Only one parameter is required: the name of a subsystem being notified of
39 some kernel event. That name is used as the first key for further event
40 dispatch; any other argument and environment parameters are specified by
41 the subsystem making that invocation.
42
43 A reference implementation of a /sbin/hotplug script is available at the
44 http://www.linux-usb.org website, which works USB for but also knows how to
45 delegate to any /etc/hotplug/$TYPE.agent policy agent present.
46
47
48 USB POLICY AGENT
49
50 The USB subsystem currently invokes /sbin/hotplug when USB devices
51 are added or removed from system. The invocation is done by the kernel
52 hub daemon thread [khubd], or else as part of root hub initialization
53 (done by init, modprobe, kapmd, etc). Its single command line parameter
54 is the string "usb", and it passes these environment variables:
55
56 ACTION ... "add", "remove"
57 PRODUCT ... USB vendor, product, and version codes (hex)
58 TYPE ... device class codes (decimal)
59 INTERFACE ... interface 0 class codes (decimal)
60
61 If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is
62 the pathname of the device, and is useful for devices with multiple and/or
63 alternate interfaces that complicate driver selection.
64
65 Currently available policy agent implementations can load drivers for
66 modules, and can invoke driver-specific setup scripts. The newest ones
67 leverage USB modutils support. Later agents might unload drivers.
68
69
70 USB MODUTILS SUPPORT
71
72 Current versions of modutils will create a "modules.usbmap" file which
73 contains the entries from each driver's MODULE_DEVICE_TABLE. Such files
74 can be used by various user mode policy agents to make sure all the right
75 driver modules get loaded, either at boot time or later.
76
77 See <linux/usb.h> for full information about such table entries; or look
78 at existing drivers. Each table entry describes one or more criteria to
79 be used when matching a driver to a device or class of devices.
80
81 A short example, for a driver that supports several specific USB devices
82 and their quirks, might have a MODULE_DEVICE_TABLE like this:
83
84 static const struct usb_device_id mydriver_id_table = {
85 { idVendor: 0x9999, idProduct 0xaaaa, driver_info: QUIRK_X },
86 { idVendor: 0xbbbb, idProduct 0x8888, driver_info: QUIRK_Y|QUIRK_Z },
87 ...
88 { } /* end with an all-zeroes entry */
89 }
90 MODULE_DEVICE_TABLE (usb, mydriver_id_table);
91
92 Most USB device drivers should pass these tables to the USB subsystem as
93 well as to the module management subsystem. Not all, though: some driver
94 frameworks connect using interfaces layered over USB, and so they won't
95 need such a "struct usb_driver".
96
97 Drivers that connect directly to the USB subsystem should be declared
98 something like this:
99
100 static struct usb_driver mydriver = {
101 name: "mydriver",
102 id_table: mydriver_id_table,
103 probe: my_probe,
104 disconnect: my_disconnect,
105
106 /*
107 if using the usb chardev framework:
108 minor: MY_USB_MINOR_START,
109 fops: my_file_ops,
110 if exposing any operations through usbdevfs:
111 ioctl: my_ioctl,
112 */
113 }
114
115 When the USB subsystem knows about a driver's device ID table, it's used when
116 choosing drivers to probe(). The thread doing new device processing checks
117 drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and
118 device descriptors for the device. It will only call probe() if there is a
119 match, and the third argument to probe() will be the entry that matched.
120
121 If you don't provide an id_table for your driver, then your driver may get
122 probed for each new device; the third parameter to probe() will be null.
123
124
This page was automatically generated by the
LXR engine.
Visit the LXR main site for more
information.