8

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?

Sagar Jain
  • 7,475
  • 12
  • 47
  • 83
  • Please, add line numbers in "spi-omap2-mcspi.c" – osgx Mar 28 '14 at 20:33
  • possible duplicate of [Who calls the probe() of driver](http://stackoverflow.com/questions/7578582/who-calls-the-probe-of-driver) – osgx Mar 28 '14 at 21:04
  • 213 /* module_platform_driver() - Helper macro for drivers that don't do 214 * anything special in module init/exit. This eliminates a lot of 215 * boilerplate. Each module may only use this macro once, and 216 * calling it replaces module_init() and module_exit() – Sagar Jain Apr 01 '14 at 04:19

1 Answers1

13

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;
Antoni
  • 176
  • 10
osgx
  • 90,338
  • 53
  • 357
  • 513
  • Thanks for your answer. Can you please explain the call chain? And how does the driver is informed when the device is connected? – Sagar Jain Mar 28 '14 at 20:47
  • 2
    Really I can't. I only can search code or some sites in internet, may be like this: http://www.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)" – osgx Mar 28 '14 at 20:50
  • That's an useful link. Thank you ! – Sagar Jain Mar 28 '14 at 20:52
  • 1
    (it was useful, but bit outdated).. Check also this link ->> https://www.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 Mar 28 '14 at 20:52
  • The http://kernel.org/doc/Documentation/driver-model/platform.txt was the link. I skipped interesting part, so just go to http://kernel.org/doc/Documentation/driver-model/platform.txt and read the "Device Naming and Driver Binding" section – osgx Mar 28 '14 at 20:59
  • This all assumes that the `device_driver` knows its bus/buses. However when being defined in the `platform_driver` in the driver code, the only fields of the `device_driver` being filled out on the spot are the `name` and `of_match_table`, like in the [pcm5102.c](https://github.com/raspberrypi/linux/blob/rpi-5.15.y/sound/soc/codecs/pcm5102a.c), what about all the other info, where/when is it filled out? None of the calls mentioned by you seem to do that. – Antoni May 24 '23 at 10:19