I am USB in Linux. I am a USB flash drive (9) bus, device, and driver (bottom)

The two linked lists on the bus record every device and driver. How is the connection between the device and the driver? At this moment, the problem must be thrown out. Is there a device or a driver first?

In the past, there were first devices. Each device to be used was plugged in before the computer started, put it in the location where it should be, then the computer started, and then the operating system started initialization, the bus starts scanning the device. Each time a device is found, a struct device structure is applied for it and mounted to the devices linked list in the bus. Then, each driver starts initialization and registers its struct device_driver structure, then it goes to the devices linked list of the bus to find (traverse) each device that has not been bound with a driver, that is, the struct device_driver pointer in the struct device is still null, then it will observe the characteristics of such a device to see if it is a device that he supports. If so, it will call a function called device_bind_driver, and then it will become better for Qin Jin. In other words, point the struct device_driver driver in the struct device to this driver, while the struct device_driver adds the struct device to its struct list_head devices linked list. In this way, the bus, device, and driver, or the two of them, are connected. If you know one of them, you can find the other two. The loss is always high.

But now the situation has changed, and a new term "Hot swapping" emerged ". The device can be inserted or pulled out after the computer is started. Therefore, it is difficult to say whether there is a device or a driver first. Because it is possible. The device can appear at any time, and the driver can be loaded at any time. Therefore, whenever a struct device is born, it will go to the drivers linked list of the bus to find its other half. On the contrary, whenever one structdevice_driver is born, it goes to the devices linked list of the bus to find its devices. If appropriate, call device_bind_driver to bind the device. If it cannot be found, it does not matter. Wait.

In fact, perfecting this triangular relationship is one of the important missions completed in each device driver initialization phase. Let's go back to the code. The usb_register function is called, but what is the parameter passed to it?

We noticed that the code for calling the usb_register function is as follows:

1073/* registerthe driver, return usb_register return code if error */

1074 retval = usb_register (& usb_storage_driver );

Yes, I passed a guy named usb_storage_driver. What is this? In the same file:

1055 static struct usb_driver usb_storage_driver = {

1056. Name = "USB-storage ",

1057. Probe = storage_probe,

1058. Disconnect = storage_disconnect,

1059 # ifdef config_pm

1060. Suspend = storage_suspend,

1061. Resume = storage_resume,

1062 # endif

1063. pre_reset = storage_pre_reset,

1064. post_reset = storage_post_reset,

1065. id_table = storage_usb_ids,

1066 };

We can see that this defines a struct variable of struct usb_driver, usb_storage_driver. We have mentioned about usb_driver in the previous section. At that time, we mainly talked about the member driver, now we will talk about several other members. First, the owner is used to count the module. Every module is used in this way, and the value assignment is always this_module. The name is the name of this module, and USB core will process it. Therefore, if this module is loaded normally, you can use the lsmod command to see a module name called USB-storage. Config_pm is related to power management. Next we will focus on the introduction of. Probe and. Disconnect and this id_table.