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