usb/hotplug.txt: convert to ReST and add to driver-api book

LINUX HOTPLUGGING

USB hotplugging

~~~~~~~~~~~~~~~

Linux Hotplugging

=================

In hotpluggable busses like USB (and Cardbus PCI), end-users plug devices

into the bus with power on.  In most cases, users expect the devices to become

that is currently available only when the drivers are dynamically linked,

you get the best hotplugging when you configure a highly modular system.

Kernel Hotplug Helper (``/sbin/hotplug``)

=========================================

KERNEL HOTPLUG HELPER (/sbin/hotplug)

There is a kernel parameter: /proc/sys/kernel/hotplug, which normally

holds the pathname "/sbin/hotplug".  That parameter names a program

There is a kernel parameter: ``/proc/sys/kernel/hotplug``, which normally

holds the pathname ``/sbin/hotplug``.  That parameter names a program

which the kernel may invoke at various times.

The /sbin/hotplug program can be invoked by any subsystem as part of its

Mailing list information is also available at that site.

--------------------------------------------------------------------------

USB Policy Agent

================

USB POLICY AGENT

The USB subsystem currently invokes /sbin/hotplug when USB devices

The USB subsystem currently invokes ``/sbin/hotplug`` when USB devices

are added or removed from system.  The invocation is done by the kernel

hub workqueue [hub_wq], or else as part of root hub initialization

(done by init, modprobe, kapmd, etc).  Its single command line parameter

is the string "usb", and it passes these environment variables:

    ACTION ... "add", "remove"

    PRODUCT ... USB vendor, product, and version codes (hex)

    TYPE ... device class codes (decimal)

    INTERFACE ... interface 0 class codes (decimal)

========== ============================================

ACTION     ``add``, ``remove``

PRODUCT    USB vendor, product, and version codes (hex)

TYPE       device class codes (decimal)

INTERFACE  interface 0 class codes (decimal)

========== ============================================

If "usbdevfs" is configured, DEVICE and DEVFS are also passed.  DEVICE is

the pathname of the device, and is useful for devices with multiple and/or

alternate interfaces that complicate driver selection.  By design, USB

hotplugging is independent of "usbdevfs":  you can do most essential parts

hotplugging is independent of ``usbdevfs``:  you can do most essential parts

of USB device setup without using that filesystem, and without running a

user mode daemon to detect changes in system configuration.

leverage USB module-init-tools support.  Later agents might unload drivers.

USB MODUTILS SUPPORT

USB Modutils Support

====================

Current versions of module-init-tools will create a "modules.usbmap" file

which contains the entries from each driver's MODULE_DEVICE_TABLE.  Such

Current versions of module-init-tools will create a ``modules.usbmap`` file

which contains the entries from each driver's ``MODULE_DEVICE_TABLE``.  Such

files can be used by various user mode policy agents to make sure all the

right driver modules get loaded, either at boot time or later.

See <linux/usb.h> for full information about such table entries; or look

See ``linux/usb.h`` for full information about such table entries; or look

at existing drivers.  Each table entry describes one or more criteria to

be used when matching a driver to a device or class of devices.  The

specific criteria are identified by bits set in "match_flags", paired

with field values.  You can construct the criteria directly, or with

macros such as these, and use driver_info to store more information.

macros such as these, and use driver_info to store more information::

    USB_DEVICE (vendorId, productId)

	... matching devices with specified vendor and product ids

	... matching specified device class info

A short example, for a driver that supports several specific USB devices

and their quirks, might have a MODULE_DEVICE_TABLE like this:

and their quirks, might have a MODULE_DEVICE_TABLE like this::

    static const struct usb_device_id mydriver_id_table[] = {

	{ USB_DEVICE (0x9999, 0xaaaa), driver_info: QUIRK_X },

Most USB device drivers should pass these tables to the USB subsystem as

well as to the module management subsystem.  Not all, though: some driver

frameworks connect using interfaces layered over USB, and so they won't

need such a "struct usb_driver".

need such a struct :c:type:`usb_driver`.

Drivers that connect directly to the USB subsystem should be declared

something like this:

something like this::

    static struct usb_driver mydriver = {

	.name		= "mydriver",

When the USB subsystem knows about a driver's device ID table, it's used when

choosing drivers to probe().  The thread doing new device processing checks

drivers' device ID entries from the MODULE_DEVICE_TABLE against interface and

device descriptors for the device.  It will only call probe() if there is a

match, and the third argument to probe() will be the entry that matched.

If you don't provide an id_table for your driver, then your driver may get

probed for each new device; the third parameter to probe() will be null.

drivers' device ID entries from the ``MODULE_DEVICE_TABLE`` against interface

and device descriptors for the device.  It will only call ``probe()`` if there

is a match, and the third argument to ``probe()`` will be the entry that

matched.

If you don't provide an ``id_table`` for your driver, then your driver may get

probed for each new device; the third parameter to ``probe()`` will be

``NULL``.

   callbacks

   dma

   power-management

   hotplug

   error-codes

   writing_usb_driver

   writing_musb_glue_layer