Documentation/driver-api/usb/hotplug.rst

   1 USB hotplugging
   2 ~~~~~~~~~~~~~~~
   3
   4 Linux Hotplugging
   5 =================
   6
   7
   8 In hotpluggable busses 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 :c:type:`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``.