linux/Documentation/usb/hotplug.txt
<<
>>
Prefs
   1LINUX HOTPLUGGING
   2
   3In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices
   4into the bus with power on.  In most cases, users expect the devices to become
   5immediately 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
  19This involves a mix of kernel mode and user mode actions.  Making devices
  20be immediately usable means that any user mode actions can't wait for an
  21administrator to do them:  the kernel must trigger them, either passively
  22(triggering some monitoring daemon to invoke a helper program) or
  23actively (calling such a user mode helper program directly).
  24
  25Those triggered actions must support a system's administrative policies;
  26such programs are called "policy agents" here.  Typically they involve
  27shell scripts that dispatch to more familiar administration tools.
  28
  29Because some of those actions rely on information about drivers (metadata)
  30that is currently available only when the drivers are dynamically linked,
  31you get the best hotplugging when you configure a highly modular system.
  32
  33
  34KERNEL HOTPLUG HELPER (/sbin/hotplug)
  35
  36There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
  37holds the pathname "/sbin/hotplug".  That parameter names a program
  38which the kernel may invoke at various times.
  39
  40The /sbin/hotplug program can be invoked by any subsystem as part of its
  41reaction to a configuration change, from a thread in that subsystem.
  42Only one parameter is required: the name of a subsystem being notified of
  43some kernel event.  That name is used as the first key for further event
  44dispatch; any other argument and environment parameters are specified by
  45the subsystem making that invocation.
  46
  47Hotplug software and other resources is available at:
  48
  49        http://linux-hotplug.sourceforge.net
  50
  51Mailing list information is also available at that site.
  52
  53
  54--------------------------------------------------------------------------
  55
  56
  57USB POLICY AGENT
  58
  59The USB subsystem currently invokes /sbin/hotplug when USB devices
  60are added or removed from system.  The invocation is done by the kernel
  61hub daemon thread [khubd], or else as part of root hub initialization
  62(done by init, modprobe, kapmd, etc).  Its single command line parameter
  63is 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
  70If "usbdevfs" is configured, DEVICE and DEVFS are also passed.  DEVICE is
  71the pathname of the device, and is useful for devices with multiple and/or
  72alternate interfaces that complicate driver selection.  By design, USB
  73hotplugging is independent of "usbdevfs":  you can do most essential parts
  74of USB device setup without using that filesystem, and without running a
  75user mode daemon to detect changes in system configuration.
  76
  77Currently available policy agent implementations can load drivers for
  78modules, and can invoke driver-specific setup scripts.  The newest ones
  79leverage USB module-init-tools support.  Later agents might unload drivers.
  80
  81
  82USB MODUTILS SUPPORT
  83
  84Current versions of module-init-tools will create a "modules.usbmap" file
  85which contains the entries from each driver's MODULE_DEVICE_TABLE.  Such
  86files can be used by various user mode policy agents to make sure all the
  87right driver modules get loaded, either at boot time or later.
  88
  89See <linux/usb.h> for full information about such table entries; or look
  90at existing drivers.  Each table entry describes one or more criteria to
  91be used when matching a driver to a device or class of devices.  The
  92specific criteria are identified by bits set in "match_flags", paired
  93with field values.  You can construct the criteria directly, or with
  94macros 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
 105A short example, for a driver that supports several specific USB devices
 106and 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
 116Most USB device drivers should pass these tables to the USB subsystem as
 117well as to the module management subsystem.  Not all, though: some driver
 118frameworks connect using interfaces layered over USB, and so they won't
 119need such a "struct usb_driver".
 120
 121Drivers that connect directly to the USB subsystem should be declared
 122something 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
 139When the USB subsystem knows about a driver's device ID table, it's used when
 140choosing drivers to probe().  The thread doing new device processing checks
 141drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and
 142device descriptors for the device.  It will only call probe() if there is a
 143match, and the third argument to probe() will be the entry that matched.
 144
 145If you don't provide an id_table for your driver, then your driver may get
 146probed for each new device; the third parameter to probe() will be null.
 147
 148
 149
lxr.linux.no kindly hosted by Redpill Linpro AS, provider of Linux consulting and operations services since 1995.