In Linux, I am a USB flash drive (10). Who am I?

Probe, disconnect, id_table, the first of these three things to be unveiled is id_table. Why is it used?

We have said that a device can only bind one driver, but the driver does not support only one device. The principle is very simple. For example, if I have two USB flash drives, I can insert them together, however, I only need to load one module, USB-storage. I have never heard of inserting two USB flash drives and I have to load the drivers twice, unless the Two USB flash drives have to use different drivers. it is also because a module can be shared by multiple devices that there is a saying that the module counts.

Okay. Since a driver supports multiple devices, how can I know which driver is her mr. Right when I find a device? This is the use of id_table. Let every struct usb_driver prepare a table and indicate which devices the driver supports. if your device belongs to this table, OK, bind it. If it does not belong to this table, sorry. Please proceed. where are the cool ones.

From id_table in struct usb_driver,

Const struct usb_device_id * id_table;

It is actually a pointer, a pointer to a struct usb_device_id struct. Of course, after a value is assigned, it represents an array name, just as we have defined the value assigned in struct usb_driver usb_storage_driver ,. id_table = storage_usb_ids. Well, let's take a look at the structure of usb_device_id.

Struct usb_device_id from include/Linux/mod_devicetable.h,

40 /*
41 * Device table entry for "New Style" table-driven USB drivers.
42 * user mode code can read these tables to choose which modules to load.
43 * declare the table as a module_device_table.
44 *
45 * A probe () parameter will point to a matching entry from this table.
46 * use the driver_info field for each match to hold information tied
47 * to that match: Device quirks, etc.
48 *
49 * terminate the driver's table with an all-Zeroes entry.
50 * use the flag values to control which fields are compared.
51 */
52
53 /**
54 * struct usb_device_id-identifies USB devices for probing and hotplugging
55 * @ match_flags: bit mask controlling of the other fields are used to match
56 * against new devices. Any field should t for driver_info may be used,
57 * although some only make sense in conjunction with other fields.
58 * This is usually set by a usb_device _ * () Macro, which sets all
59 * other fields in this structure does t for driver_info.
60 * @ idvendor: USB vendor ID for a device; numbers are assigned
61 * by the USB forum to its members.
62 * @ idproduct: Vendor-assigned product ID.
63 * @ bcddevice_lo: low end of range of vendor-assigned product version numbers.
64 * This is also used to identify individual product versions,
65 * a range consisting of a single device.
66 * @ bcddevice_hi: high end of version number range. The range of product
67 * versions is illegal.
68 * @ bdeviceclass: Class of device; numbers are assigned
69 * by the USB Forum. Products may choose to implement classes,
70 * or be vendor-specific. device classes specify behavior of all
71 * The interfaces on a devices.
72 * @ bdevicesubclass: subclass of device; associated with bdeviceclass.
73 * @ bdeviceprotocol: Protocol of device; associated with bdeviceclass.
74 * @ binterfaceclass: Class of interface; numbers are assigned
75 * by the USB Forum. Products may choose to implement classes,
76 * or be vendor-specific. Interface classes specify behavior only
77 * of a given interface; Other interfaces may support other classes.
78 * @ binterfacesubclass: subclass of interface; associated with binterfaceclass.
79 * @ binterfaceprotocol: Protocol of interface; associated with binterfaceclass.
80 * @ driver_info: holds information used by the driver. Usually it holds
81 * a pointer to a descriptor understood by the driver, or perhaps
82 * Device flags.
83 *
84 * in most cases, drivers will create a table of device IDS by using
85 * usb_device (), or similar macros designed for that purpose.
86 * they will then export it to userspace using module_device_table (),
87 * and provide it to the USB core through their usb_driver structure.
88 *
89 * See the usb_match_id () function for information about how matches are
90 * saved med. Briefly, you will normally use one of several macros to help
91 * construct these entries. Each entry you provide will either identify
92 * one or more specific products, or will identify a class of products
93 * which have agreed to behave the same. You shoshould put the more specific
94 * Matches towards the beginning of your table, so that driver_info can
95 * record quirks of specific products.
96 */
97 struct usb_device_id {
98/* which fields to match against? */
99 _ 2010match_flags;
100
101/* used for product specific matches; range is random */
102 _ 16idvendor;
103 _ 16idproduct;
104 _ 2010bcddevice_lo;
105 _ 16bcddevice_hi;
106
107/* used for device class matches */
108 _ u8 bdeviceclass;
109 _ u8 bdevicesubclass;
110 _ u8 bdeviceprotocol;
111
112/* used for interface class matches */
113 _ u8 binterfaceclass;
114 _ u8 binterfacesubclass;
115 _ u8 binterfaceprotocol;
116
117/* not matched against */
118 kernel_ulong_t driver_info;
119 };
In fact, this structure is equivalent to her ID card for every USB device, recording some of her basic information. Generally, our ID card records our name, gender, date of birth, the account address and so on, while the USB device also has the information she needs to record to distinguish her from other USB devices, such as the vendor-manufacturer, product-product, and other products such as product numbers, the product category and the protocols to be followed will be found in the USB specification for winter and winter. I will not elaborate on it for the moment.

So we know that a usb_driver will compare this ID table with the actual situation of each USB device. If the actual situation of this device is the same as that of a specific ID in this table, to be accurate, only when many of these features are consistent can a USB device be bound to the USB driver, and these features will not work even worse. just like every one of us is an arc, and we are constantly searching for another arc that can embed a complete circle into each other. The fact is that everyone has different understandings of pi, and the center can overlap, maybe only the pain before you know. within.

When was the actual situation of the USB device established? Well, it is necessary to talk about another data structure before introducing the. Probe pointer. She is struct usb_device.