| 1 | USB hotplugging
|
| 2 | ~~~~~~~~~~~~~~~
|
| 3 |
|
| 4 | Linux Hotplugging
|
| 5 | =================
|
| 6 |
|
| 7 |
|
| 8 | In hotpluggable buses like USB (and Cardbus PCI), end-users plug devices
|
| 9 | into the bus with power on. In most cases, users expect the devices to become
|
| 10 | immediately 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 |
|
| 24 | This involves a mix of kernel mode and user mode actions. Making devices
|
| 25 | be immediately usable means that any user mode actions can't wait for an
|
| 26 | administrator to do them: the kernel must trigger them, either passively
|
| 27 | (triggering some monitoring daemon to invoke a helper program) or
|
| 28 | actively (calling such a user mode helper program directly).
|
| 29 |
|
| 30 | Those triggered actions must support a system's administrative policies;
|
| 31 | such programs are called "policy agents" here. Typically they involve
|
| 32 | shell scripts that dispatch to more familiar administration tools.
|
| 33 |
|
| 34 | Because some of those actions rely on information about drivers (metadata)
|
| 35 | that is currently available only when the drivers are dynamically linked,
|
| 36 | you get the best hotplugging when you configure a highly modular system.
|
| 37 |
|
| 38 | Kernel Hotplug Helper (``/sbin/hotplug``)
|
| 39 | =========================================
|
| 40 |
|
| 41 | There is a kernel parameter: ``/proc/sys/kernel/hotplug``, which normally
|
| 42 | holds the pathname ``/sbin/hotplug``. That parameter names a program
|
| 43 | which the kernel may invoke at various times.
|
| 44 |
|
| 45 | The /sbin/hotplug program can be invoked by any subsystem as part of its
|
| 46 | reaction to a configuration change, from a thread in that subsystem.
|
| 47 | Only one parameter is required: the name of a subsystem being notified of
|
| 48 | some kernel event. That name is used as the first key for further event
|
| 49 | dispatch; any other argument and environment parameters are specified by
|
| 50 | the subsystem making that invocation.
|
| 51 |
|
| 52 | Hotplug software and other resources is available at:
|
| 53 |
|
| 54 | http://linux-hotplug.sourceforge.net
|
| 55 |
|
| 56 | Mailing list information is also available at that site.
|
| 57 |
|
| 58 |
|
| 59 | USB Policy Agent
|
| 60 | ================
|
| 61 |
|
| 62 | The USB subsystem currently invokes ``/sbin/hotplug`` when USB devices
|
| 63 | are added or removed from system. The invocation is done by the kernel
|
| 64 | hub workqueue [hub_wq], or else as part of root hub initialization
|
| 65 | (done by init, modprobe, kapmd, etc). Its single command line parameter
|
| 66 | is the string "usb", and it passes these environment variables:
|
| 67 |
|
| 68 | ========== ============================================
|
| 69 | ACTION ``add``, ``remove``
|
| 70 | PRODUCT USB vendor, product, and version codes (hex)
|
| 71 | TYPE device class codes (decimal)
|
| 72 | INTERFACE interface 0 class codes (decimal)
|
| 73 | ========== ============================================
|
| 74 |
|
| 75 | If "usbdevfs" is configured, DEVICE and DEVFS are also passed. DEVICE is
|
| 76 | the pathname of the device, and is useful for devices with multiple and/or
|
| 77 | alternate interfaces that complicate driver selection. By design, USB
|
| 78 | hotplugging is independent of ``usbdevfs``: you can do most essential parts
|
| 79 | of USB device setup without using that filesystem, and without running a
|
| 80 | user mode daemon to detect changes in system configuration.
|
| 81 |
|
| 82 | Currently available policy agent implementations can load drivers for
|
| 83 | modules, and can invoke driver-specific setup scripts. The newest ones
|
| 84 | leverage USB module-init-tools support. Later agents might unload drivers.
|
| 85 |
|
| 86 |
|
| 87 | USB Modutils Support
|
| 88 | ====================
|
| 89 |
|
| 90 | Current versions of module-init-tools will create a ``modules.usbmap`` file
|
| 91 | which contains the entries from each driver's ``MODULE_DEVICE_TABLE``. Such
|
| 92 | files can be used by various user mode policy agents to make sure all the
|
| 93 | right driver modules get loaded, either at boot time or later.
|
| 94 |
|
| 95 | See ``linux/usb.h`` for full information about such table entries; or look
|
| 96 | at existing drivers. Each table entry describes one or more criteria to
|
| 97 | be used when matching a driver to a device or class of devices. The
|
| 98 | specific criteria are identified by bits set in "match_flags", paired
|
| 99 | with field values. You can construct the criteria directly, or with
|
| 100 | macros 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 |
|
| 111 | A short example, for a driver that supports several specific USB devices
|
| 112 | and 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 |
|
| 122 | Most USB device drivers should pass these tables to the USB subsystem as
|
| 123 | well as to the module management subsystem. Not all, though: some driver
|
| 124 | frameworks connect using interfaces layered over USB, and so they won't
|
| 125 | need such a struct usb_driver.
|
| 126 |
|
| 127 | Drivers that connect directly to the USB subsystem should be declared
|
| 128 | something 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 |
|
| 145 | When the USB subsystem knows about a driver's device ID table, it's used when
|
| 146 | choosing drivers to probe(). The thread doing new device processing checks
|
| 147 | drivers' device ID entries from the ``MODULE_DEVICE_TABLE`` against interface
|
| 148 | and device descriptors for the device. It will only call ``probe()`` if there
|
| 149 | is a match, and the third argument to ``probe()`` will be the entry that
|
| 150 | matched.
|
| 151 |
|
| 152 | If you don't provide an ``id_table`` for your driver, then your driver may get
|
| 153 | probed for each new device; the third parameter to ``probe()`` will be
|
| 154 | ``NULL``.
|