For Linux, I am a USB flash drive (8) bus, device, and driver (on)

In struct bus_type, two linked lists are prepared for devices and drivers. The struct device represents two members, struct bus_type * bus and struct device_driver * driver. Similarly, the struct device_driver that represents the driver also has two members: struct bus_type * bus and struct list_head devices. The definition of struct device and struct device_driver is the same as that of struct bus_type in include/Linux/device. h. A man's intuition tells us that the bus in the struct device records the bus on which the device is connected, and the driver records the driver used by the device. In turn, the bus in struct device_driver represents the bus to which the driver belongs. Devices records the devices supported by the driver. Yes, it is devices (plural), not device (singular ), A driver supports one or more devices. In turn, a device is bound to only one driver.

So we want to know how they establish connections with bus, device, and driver? In other words, how are pointers assigned to these three data structures? What is absolutely impossible is that once a struct bus_type data structure is applied for a bus, it will know what its devices linked list and drivers linked list will contain, these are not inherent. They can only be entered the day after tomorrow. specifically, the USB core is used to complete this task. the USB core code initializes the entire USB system, such as applying for struct bus_type usb_bus_type, and then scans the USB bus to see which USB devices are connected online, or which USB devices are connected to the root hub, for example, a USB keyboard, a struct device is prepared for the device. assign a value to the struct device based on the actual situation, insert the devices linked list. for example, if a common hub is connected to the root hub, in addition to preparing a struct device for the hub itself, you have to continue scanning to see if another device is connected to the hub, if yes, continue to repeat the previous tasks until the entire scan is completed. Finally, the devices linked list in usb_bus_type is created.

What about drivers linked list? In this case, you do not need to take the initiative in the bus, and each driver should register on the bus, or be listed. in the USB system, each driver of a USB device has a struct usb_driver structure. The Code is as follows: Include/Linux/USB. h

485 /*--------------------------------------------------------------------------*/
486
487 /**
488 * struct usb_driver-identifies USB driver to USB core
489 * @ owner: pointer to the module owner of this driver; initialize
490 * it using this_module.
491 * @ name: The driver name shoshould be unique among USB drivers,
492 * And shoshould normally be the same as the module name.
493 * @ Probe: called to see if the driver is willing to manage a participant
494 * interface on a device. If it is, probe returns zero and uses
495 * dev_set_drvdata () to associate driver-specific data with
496 * interface. It may also use usb_set_interface () to specify
497 * appropriate altsetting. If unwilling to manage the interface,
498 * return a negative errno value.
499 * @ disconnect: called when the interface is no longer accessible, usually
500 * because its device has been (or is being) disconnected or
501 * driver module is being unloaded.
502 * @ IOCTL: used for drivers that want to talk to userspace through
503 * The "usbfs" filesystem. This lets devices provide ways
504 * expose information to user space regardless of where they
505 * do (or don't) show up otherwise in the filesystem.
506 * @ suspend: called when the device is going to be suincluded by the system.
507 * @ resume: called when the device is being resumed by the system.
508 * @ id_table: USB drivers use ID table to support hotplugging.
509 * export this with module_device_table (USB,...). This must be set
510 * or your driver's probe function will never get called.
511 * @ DRIVER: The driver model core driver structure.
512 *
513 * USB Drivers must provide a name, probe () and disconnect () methods,
514 * and an id_table. Other driver fields are optional.
515 *
516 * The id_table is used in hotplugging. It holds a set of descriptors,
517 * and specialized data may be associated with each entry. That table
518 * is used by both user and kernel mode hotplugging support.
519 *
520 * the probe () and disconnect () methods are called in a context where
521 * they can sleep, but they shoshould avoid abusing the privilege. Most
522 * Work to connect to a device shocould be done when the device is opened,
523 * and undone at the last close. The disconnect code needs to address
524 * concurrency issues with respect to open () and close () methods,
525 * well as forcing all pending I/O requests to complete (by unlinking
526 * them as necessary, and blocking until the unlinks complete ).
527 */
528 struct usb_driver {
529 struct module * owner;
530
531 const char * Name;
532
533 int (* probe) (struct usb_interface * INTF,
534 const struct usb_device_id * ID );
535
536 void (* disconnect) (struct usb_interface * INTF );
537
538 int (* IOCTL) (struct usb_interface * INTF, unsigned int code, void * BUF );
539
540 int (* suspend) (struct usb_interface * INTF, u32 State );
541 int (* resume) (struct usb_interface * INTF );
542
543 const struct usb_device_id * id_table;
544
545 struct device_driver driver;
546 };
547 # define to_usb_driver (d) container_of (D, struct usb_driver, driver)
It looks like a long time. In fact, it is dominated by annotations. at this moment, we only need to pay attention to the struct device_driver driver member. USB core provides a function for each device driver, insert the struct device_driver driver into the drivers linked list in usb_bus_type. this function is exactly what we saw earlier: usb_register. the corresponding usb_deregister is engaged in the opposite work, removing this struct from the drivers linked list. it can be said that USB core is indeed painstaking, and it has done a lot of work for every USB device driver. Because of this, as an actual USB device driver, it has very little to do in the initialization phase, you can simply call usb_register. in fact, no one should do anything for you, but USB core does. therefore, anyone who writes a USB driver should remember that the USB device driver is not working alone, but behind it is an obscure and indispensable support provided by USB core.