Who calls "probe" function in driver code?

Question

I am trying to understand this driver code of mcspi for omap2 panda board.

I don't understand who calls the probe function and what is the call chain in this driver code?

How does the driver is informed when the device is connected?

Solution

The probe function from spi-omap2-mcspi.c is saved in the static struct platform_driver omap2_mcspi_driver, which is registered with module_platform_driver(omap2_mcspi_driver); (at the end of file). The module_platform_driver macro, defined in platform_device.h will pass the struct to platform_driver_register macro and __platform_driver_register function from drivers/base/platform.c

527 /**
528  * __platform_driver_register - register a driver for platform-level devices
529  * @drv: platform driver structure
530  * @owner: owning module/driver
531  */
532 int __platform_driver_register(struct platform_driver *drv,
533                                 struct module *owner)
534 {
...
536         drv->driver.bus = &platform_bus_type;
537         if (drv->probe)
538                 drv->driver.probe = platform_drv_probe;
...
544         return driver_register(&drv->driver);
545 }
546 EXPORT_SYMBOL_GPL(__platform_driver_register);

The probe now passed to driver_register function from drivers/base/driver.c

139 /**
140  * driver_register - register driver with bus
141  * @drv: driver to register
142  *
143  * We pass off most of the work to the bus_add_driver() call,
144  * since most of the things we have to do deal with the bus
145  * structures.
146  */
147 int driver_register(struct device_driver *drv)
148 {
...
154         if ((drv->bus->probe && drv->probe) ||
...
167         ret = bus_add_driver(drv);
...
178 }

So, now the driver is registered in the bus (platform_bus_type).

Actual call to probe is done via driver_probe_device drivers/base/dd.c, then really_probe (same file line 265):

265 static int really_probe(struct device *dev, struct device_driver *drv)
266 {
...
270         pr_debug("bus: '%s': %s: probing driver %s with device %s\n",
271                  drv->bus->name, __func__, drv->name, dev_name(dev));
...
287         if (dev->bus->probe) {
288                 ret = dev->bus->probe(dev);       /// <<<< HERE
289                 if (ret)
290                         goto probe_failed;
291         } else if (drv->probe) {
292                 ret = drv->probe(dev);            /// <<<< OR HERE
293                 if (ret)
294                         goto probe_failed;
295         }
296 
297         driver_bound(dev);
298         ret = 1;
299         pr_debug("bus: '%s': %s: bound device %s to driver %s\n",
300                  drv->bus->name, __func__, dev_name(dev), drv->name);
301         goto done;

Comments

[Sagar Jain]

Thanks for your answer. Can you please explain the call chain? And how does the driver is informed when the device is connected?

[osgx]

Really I can't. I only can search code or some sites in internet, may be like this: cprogramdevelop.com/1120807 "registration phase: Platform_driver_register() > driver_register() > bus_add_driver() > driver_attach() > bus_for_each_dev (), in each hanging on .. Platform BUS the equipment for __driver_attach(), > driver_probe_device() to determine the drv-> bus-> match() executed successfully, through a pointer to perform platform_match > strncmp (pdev > name, the drv > name, BUS_ID_SIZE) call really_probe (actual corresponding equipment platform_driver > probe (platform_device)"

[Sagar Jain]

That's an useful link. Thank you !

[osgx]

(it was useful, but bit outdated).. Check also this link ->> kernel.org/doc/Documentation/driver-model/platform.txt "Device Naming and Driver Binding...Driver binding is performed automatically by the driver core, invoking driver probe() after finding a match between device and driver. If the probe() succeeds, the driver and device are bound as usual. There are three different ways to find such a match: ...//read this//", also check early_platform_driver_probe()

[osgx]

The kernel.org/doc/Documentation/driver-model/platform.txt was the link. I skipped interesting part, so just go to kernel.org/doc/Documentation/driver-model/platform.txt and read the "Device Naming and Driver Binding" section