In the Linux driver, when the probe function is called _linux

Source: Internet
Author: User
Tags goto

Recently saw the Linux device-driven model, about Kobject, kset, etc. is not very clear. When I see the struct device_driver this structure, I think of a question: where exactly is its initialization function invoked? PCI driver registration function used in the previous PCI driver can call it, engage in s3c2410 driver as long as the mach-smdk2410.c in the struct Platform_device *smdk2410_devices {} In the device will also be called. But never think of specific driver registration and call the probe process.

So he opened Sourceinsight and tracked it:

From Driver_register look:

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 don't care about it, probably 2.6 of this device model is going to do some work. Intuition tells me to go to bus_add_driver.

In Bus_add_driver:

are some kobject and klist, attr and so on. is also related to the device model. But there is one sentence:

Driver_attach (DRV);

It's like a single name:

void Driver_attach (struct device_driver * drv)
{
    Bus_for_each_dev (Drv->bus, NULL, DRV, __driver_attach);

This is familiar, traversing the device on the bus and setting the __driver_attach.

This is mainly true in the __driver_attach:

Driver_probe_device (DRV, Dev);

Run to the Driver_probe_device to see:

It is important to have a paragraph:

if (Drv->bus->match &&!drv->bus->match (Dev, DRV))
        Goto done;

Obviously, it is called the match function on the drive bus. If you return 1, you can continue, otherwise you are done.

Inheritance execution:

    if (drv->probe) {
        ret = drv->probe (dev);
        if (ret) {
            dev->driver = NULL;
            Goto probefailed;
        }

Called if the probe exists. This completes the probe call.

The key to this process chain is drv->bus->match, because the rest of the error is registered failure, and as long as registration does not fail and match returns 1, then the probe will definitely call the drive. You can register a bus type and bus, and always return 1 in match, and you will find that the probe function is always invoked as long as the struct in the device_driver is correct.

The PCI device has its own bus model, which is estimated to have a judgment condition in its match.

static int Pci_bus_match (struct device *dev, struct device_driver *drv) {struct Pci_dev *pci_dev
    = To_pci_dev (de v);
    struct Pci_driver *pci_drv = To_pci_driver (DRV);
    const struct PCI_DEVICE_ID *found_id;

    found_id = Pci_match_device (Pci_drv, Pci_dev);
    if (found_id) return
        1;

    return 0;
}

Then follow up to know that the main is based on our familiar id_table.

-------------------------------Another solution---------------------------------------------------------------------------------------- -------

From the Driver_register look, here is my here:

int Driver_register (struct device_driver * drv)
{
if (drv->bus->probe && drv->probe) | |
   (Drv->bus->remove && drv->remove) | |
   (Drv->bus->shutdown && Drv->shutdown)) {
  PRINTK (kern_warning "Driver '%s ' needs updating-please use Bus_type methods\n", drv->name);
}
Klist_init (&drv->klist_devices, NULL, NULL);
Return Bus_add_driver (DRV);

Klist_init not related, do not care about him, specifically to see Bus_add_driver:

int bus_add_driver (struct device_driver *drv)
{
//1. First Kobject_set_name (&drv->kobj, "%s", drv-> name);
2. Kobject_register (&drv->kobj)
//3. Then called: Driver_attach (DRV)
}
int Driver_attach (struct device_driver * drv)
{return
Bus_for_each_dev (Drv->bus, NULL, DRV, __driver_ attach);
}

What really works is the __driver_attach:

static int __driver_attach (struct device * dev, void * data)
{
...
if (!dev->driver)
  driver_probe_device (DRV, dev);
...
}

int Driver_probe_device (struct device_driver * drv, struct device * dev)
{
...
1. First determine whether the bus is match:
if (drv->bus->match &&!drv->bus->match (Dev, DRV))
  goto done;
2. Further specific implementation of probe:
ret = really_probe (dev, DRV);
...
}

Really_probe is the function we're looking for:

static int really_probe (struct device *dev, struct device_driver *drv)
{
...
1. First call the probe function of the driver-owned bus:
if (dev->bus->probe) {
  ret = dev->bus->probe (dev);
  if (ret)
  goto probe_failed;

} else if (drv->probe) {
//2. Then call the probe function in your drive:
  ret = Drv->probe ( dev);
  if (ret)
  goto probe_failed;
}
...

}

where Drv->probe (dev) is the specific probe function that really invokes your driver implementation.

That is to say, the probe function is called at this time, according to the title of this article.

The above is the entire content of this article, I hope to help you learn, but also hope that we support the cloud habitat community.

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.