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