1USB_MATCH_ID(9) USB Core APIs USB_MATCH_ID(9)
2
6 usb_match_id - find first usb_device_id matching device or interface
7
9 const struct usb_device_id *
10 usb_match_id(struct usb_interface * interface,
11 const struct usb_device_id * id);
12
14 interface
15 the interface of interest
16 id
18 array of usb_device_id structures, terminated by zero entry
19
21 usb_match_id searches an array of usb_device_id's and returns the first
22 one matching the device or interface, or null. This is used when
23 binding (or rebinding) a driver to an interface. Most USB device
24 drivers will use this indirectly, through the usb core, but some
25 layered driver frameworks use it directly. These device tables are
26 exported with MODULE_DEVICE_TABLE, through modutils, to support the
27 driver loading functionality of USB hotplugging.
28
30 The first matching usb_device_id, or NULL.
31
33 The “match_flags” element in a usb_device_id controls which members are
34 used. If the corresponding bit is set, the value in the device_id must
35 match its corresponding member in the device or interface descriptor,
36 or else the device_id does not match.
37 “driver_info” is normally used only by device drivers, but you can
39 create a wildcard “matches anything” usb_device_id as a driver's
40 “modules.usbmap” entry if you provide an id with only a nonzero
41 “driver_info” field. If you do this, the USB device driver's probe
42 routine should use additional intelligence to decide whether to bind to
43 the specified interface.
44
46 The match algorithm is very simple, so that intelligence in driver
47 selection must come from smart driver id records. Unless you have good
48 reasons to use another selection policy, provide match elements only in
49 related groups, and order match specifiers from specific to general.
50 Use the macros provided for that purpose if you can.
51 The most specific match specifiers use device descriptor data. These
53 are commonly used with product-specific matches; the USB_DEVICE macro
54 lets you provide vendor and product IDs, and you can also match against
55 ranges of product revisions. These are widely used for devices with
56 application or vendor specific bDeviceClass values.
57 Matches based on device class/subclass/protocol specifications are
59 slightly more general; use the USB_DEVICE_INFO macro, or its siblings.
60 These are used with single-function devices where bDeviceClass doesn't
61 specify that each interface has its own class.
62 Matches based on interface class/subclass/protocol are the most
64 general; they let drivers bind to any interface on a multiple-function
65 device. Use the USB_INTERFACE_INFO macro, or its siblings, to match
66 class-per-interface style devices (as recorded in bInterfaceClass).
67 Note that an entry created by USB_INTERFACE_INFO won't match any
69 interface if the device class is set to Vendor-Specific. This is
70 deliberate; according to the USB spec the meanings of the interface
71 class/subclass/protocol for these devices are also vendor-specific, and
72 hence matching against a standard product class wouldn't work anyway.
73 If you really want to use an interface-based match for such a device,
74 create a match record that also specifies the vendor ID. (Unforunately
75 there isn't a standard macro for creating records like this.)
76 Within those groups, remember that not all combinations are meaningful.
78 For example, don't give a product version range without vendor and
79 product IDs; or specify a protocol without its associated class and
80 subclass.
81
83Kernel Hackers Manual 3.10 June 2019 USB_MATCH_ID(9)