Probe call
From driver_register:
Int driver_register (struct device_driver * DRV)
{
Klist_init (& DRV-> klist_devices, klist_devices_get, klist_devices_put );
Init_completion (& DRV-> unloaded );
Return bus_add_driver (DRV );
}
Klist_init and init_completion do not care about it. It may be the work of this device model of 2.6. Intuition tells me to go to bus_add_driver.
Bus_add_driver:
All are kobject, klist, ATTR, etc. It is also related to the device model. However, there is one sentence:
Driver_attach (DRV );
The name of a single listener is similar:
Void driver_attach (struct device_driver * DRV)
{
Bus_for_each_dev (DRV-> bus, null, DRV, _ driver_attach );
}
This is familiar with traversing the devices on the bus and using _ driver_attach.
In _ driver_attach, it is mainly like this:
Driver_probe_device (DRV, Dev );
Go to driver_probe_device and check it out:
There is a very important section:
If (DRV-> bus-> match &&! DRV-> bus-> match (Dev, DRV ))
Goto done;
Obviously, it is the match function on the bus that calls the driver. If 1 is returned, continue; otherwise, done is returned.
If the inheritance is executed:
If (DRV-> probe ){
Ret = DRV-> probe (Dev );
If (RET ){
Dev-> driver = NULL;
Goto probefailed;
}
If probe exists, it is called. So far, the probe call has been completed.
The key to this process chain is DRV-> bus-> match, because the registration fails if an error occurs in other places. As long as the registration fails and match returns 1, then it will definitely call the probe of the drive. You can register a bus type and bus, and always return 1 in match. You will find that the probe function is always called as long as the bus type in struct device_driver is correct.
There are two important linked lists hanging on the bus. One is the device linked list, and the other is the driver linked list.
Every time we register a driver from a bus, the procedure is as follows:
Driver_register (struct device_driver * DRV)-> bus_add_driver ()-> driver_attach ()->
Bus_for_each_dev (DRV-> bus, null, DRV, _ driver_attach );
Bus_for_each_dev traverses all the devices on the bus and runs _ driver_attach () to check whether the driver can be associated with a device.
_ Driver_attach ()
-> Driver_probe_device ()
-> DRV-> bus-> match (Dev, DRV), // call the match function of the bus to check that the device and driver do not match. If it matches,
Continue to execute really_probe ().
-> Really_probe ()
-> Driver-> probe (). (If bus-> probe is not empty, call bus-> probe)
Every time we add a hardware to a bus, the procedure is as follows:
Device_add ()
\ Device_add contains a lot of code for operating kobject and registering sysfs to form the hardware hiberarchy structure.
If you forget it, refer to "I'm sysfs" first"
-> Bus_attach_device ()-> device_attach ()-> bus_for_each_drv ()
Bus_for_each_drv is similar to bus_for_each_dev. it traverses all the drivers on the bus and executes _ device_attach () once to check whether the device can be associated with a registered driver.
_ Device_attach ()
-> Driver_probe_device () // the same as above
To sum up, registering a driver for a certain bus is to first link the driver to the bus driver chain table and search for it from the device Chain List of the bus, check whether there are any devices that you can associate. Find probe and bind the two. On the contrary, the same applies to devices.