Why Is the Probe Method Needed in Linux Device Drivers in Addition to Init

Why is the probe method needed in Linux device drivers in addition to init?

Different device types can have probe() functions. For example, PCI and USB devices both have probe() functions.

If you're talking about PCI devices, I would recommend you read chapter 12 of Linux Device Drivers, which covers this part of driver initialization. USB is covered in chapter 13.

Shorter answer, assuming PCI: The driver's init function calls pci_register_driver() which gives the kernel a list of devices it is able to service, along with a pointer to the probe() function. The kernel then calls the driver's probe() function once for each device.

This probe function starts the per-device initialization: initializing hardware, allocating resources, and registering the device with the kernel as a block or network device or whatever it is.

That makes it easier for device drivers, because they never need to search for devices or worry about finding a device that was hot-plugged. The kernel handles that part and notifies the right driver when it has a device for you to handle.

Does __init is required in case of module?

Actually, in both cases (driver in kernel or as a module) both functions (init and probe) are required.

As you mention it, the probe function is used when there is a device/driver registration (the device/driver kernel subsystem notices that there is a suitable driver for a given device and it "associates" them).

To simplify, in order to be able to achieve this "associtation", the kernel's device/driver subsystem needs a list of the devices on the system and a list of the available drivers (and a way to know if a driver can be "associated" with device, but it's not important for your question).

In a typical module, the init function is the function that initializes the driver to kernel, or to phrase it differently, to register the driver to the kernel's driver/device subsystem so that this new driver can be added to the list of available drivers that can be "associated" with the devices. This also has to be done when the driver is built as a module.

When does the probe function for a Linux kernel driver gets called?

Found the answer after some research, For a "platform" device the probe function is invoked when a platform device is registered and it's device name matchs the name specified on the device driver.

More details here:
http://comments.gmane.org/gmane.linux.kernel.kernelnewbies/37050

Now I just need to figure why the device is not being registered :\

Linux device driver startup dependencies

The device driver's probe function can return -EPROBE_DEFER (after any necessary clean-up) to indicate that a resource it requires is not available yet. The driver core will then add the device to a "deferred probe" list and try to call the probe function after a successful probe of some other device.

See the documentation for further information, and heed the warning about not returning -EPROBE_DEFER if any child devices have been created by the probe function.

devm_gpiod_get_optional and similar devm_gpiod_get_ and gpiod_get_ functions that return a struct gpio_desc * value will return ERR_PTR(-EPROBE_DEFER) if the requested GPIO is not yet available. (This is different to the GPIO not being found, which will result in the _optional variants returning NULL and the non-_optional variants returning ERR_PTR(-ENOENT).) The caller can propogate the -EPROBE_DEFER error to its own caller, but again the warning about not returning -EPROBE_DEFER if any child devices have been created should be heeded.

Linux device driver: probe function not called for compatible device with an address

The .compatible = "exynos" entry in ect_of_device_ids[] does not match the compatible = "exynos,ect"; entry in the device tree. If you change it to "exynos,ect" your probe function should get called:

static struct of_device_id ect_of_device_ids[] = {
    {.compatible = "exynos,ect", },
    {},
}

Also, if you want to support auto-loading of external kernel modules by a hotplug handler in userspace, you need to use the MODULE_DEVICE_TABLE macro to include the necessary information in the module:

#ifdef CONFIG_OF
MODULE_DEVICE_TABLE(of, ect_of_device_ids);
#endif
MODULE_DEVICE_TABLE(platform, ect_plat_device_ids);

Who calls the probe() of driver

Long story short: the probe() function of the driver is called as a result of calling the register_driver for that specific bus. More precisely, it's called by the probe() of that bus_type structure. In your case: i2c_bus_type.

Here's the call chain in your I2C case:

• i2c_register_driver
• driver_register
• bus_add_driver
• driver_attach
• __driver_attach (for your device)
• driver_probe_device
• really_probe
• i2c_device_probe (this is what dev->bus->probe is for an i2c driver)
• your_probe_function

Kernel-space: can .probe be called simultaneously/concurrently?

The answer for my case was simple:

.probe_type = PROBE_FORCE_SYNCHRONOUS

will make kernel call .probes one by one on each of_node found.

.probe_type = PROBE_PREFER_ASYNCHRONOUS

will make kernel call .probes concurrently.

How did I get to it. I couldn't find that information in documentation or on blogs/forums. So I've made one second delay in my .probe function, added two of_nodes with my .compatible to my DT and tested it in both cases (PROBE_FORCE_SYNCHRONOUS and PROBE_PREFER_ASYNCHRONOUS) by measuring time insmod takes to load module.

Results of these test look clear: PROBE_FORCE_SYNCHRONOUS takes two seconds to load module, while PROBE_PREFER_ASYNCHRONOUS takes one second.

So, the answer is: yes, .probes can be called concurrently, but we have mechanism to control it.

BTW, thank you for your replies

---

Related Topics