Linux device driver registration process specific explanation

The Linux driver registration process is broadly divided into two steps:

• Module initialization
• Driver Brochure

The following is a sample code PCI-SKELETON.C, which is provided by the kernel, to illustrate a PCI device driver registration process. Driver code for other devices The process is basically the same, you can check it yourself. The kernel code version number used is 2.6.38.
1. Module Initialization 1.1 Driver entry all device drivers will have the following two lines of code, for example:

1922 Module_init (Netdrv_init_module); 1923 Module_exit (Netdrv_cleanup_module);

Module_init/module_exit is a two macro. Module_init is the driver's entry, and when loading the driver module, the driver starts from the Netdrv_init_module function. When the device corresponding to the driver is deleted, the Netdrv_cleanup_module function is run.
1.2 Module initialization When the driver starts running, the driver's initialization function Netdrv_init_module is first run, with the code such as the following:

1906 static int __init netdrv_init_module (void) 1907 {1908/* When a module, this is printed whether or not devices be fou nd in probe */1909 #ifdef MODULE1910     printk (version) 1911 #endif1912     return Pci_register_driver (&netdrv_ pci_driver); 1913}

Can see that the initialization function is very easy, just run a pci_register_driver function to return. In fact, the initialization of the module is so simple, this is the Linux driver ISO standard process: Module_init-->xx_init_module-->xx_register_driver. I believe you are still confused when you look at this place. Don't worry, we'll take it slow. 2. Driver register what is the driver module? The Pci_register_driver function called in the initialization function described above is the manual driver. Before introducing the registration function, it is necessary to specify the Linux bus device driver model, otherwise the following content is very difficult to describe clearly. 2.1 Linux Bus device driver model for the bus device driver model, very many books have specific explanations, but are very abstract, very difficult to understand (at least I think so). I try to use the simplest method to illustrate the content. The Linux kernel uses the struct bus_type,struct device and the struct device_driver to describe the bus, device and driver respectively. Bus:

The struct Bus_type {     n-const char      *name;     bus_attribute    *bus_attrs;     Attribute *dev_attrs;     driver_attribute *drv_attrs     (*match) (struct device *dev, struct device_driver *drv); 68};

Equipment:

406 struct Device {407     struct device       *parent;408409     struct device_private   *p;410411     struct Kobject kobj;412     const char      *init_name;/* Initial name of the device */413     struct device_type  *type; 414415     struct Mutex        mutex;  /* Mutex to synchronize calls to416                      * Its driver.417                      */418419     struct bus_type *bus;       /* Type of bus device is on */420     struct device_driver *driver;   /* Which driver has allocated this421                        device */... 456457     void    (*release) (struct device *dev); 458};

Driven:

122 struct Device_driver {123     const char      *name;124     struct bus_type     *bus;125126     struct module       *owner;127     const char      *mod_name;  /* used for built-in modules */128129     bool suppress_bind_attrs;   /* Disables Bind/unbind via SYSFS */130131 #if defined (config_of)-     const struct OF_DEVICE_ID   *of_match_ table;133 #endif134135     Int (*probe) (struct device *dev), 136     Int (*remove) (struct device *dev), .... 145};

In the above three structures, I will identify the members that need to be used below, which will be discussed later. In contrast to the above three structures, you will find that both the device and the driver are defined in the bus, there are both bus and driver in the device, and there is also information about the equipment in the driver. What exactly are these three relationships? The relationship between the three is: the kernel requires each occurrence of a device, it is necessary to report to the bus, will say the register; every time a driver appears, it should also report to the bus, or call the registration. For example, when the system initializes, it scans which devices are connected, establishes a struct device variable for each device, and prepares a variable for a struct device_driver structure for each driver. Add these variables to the linked list to form a list of equipment and a drive scale. In this way, the bus can find each device and each driver through the bus. When a struct device is born, the bus goes to the driver list to find the appropriate driver for the device. Suppose you find the driver that runs the device, otherwise wait. Vice versa.
Another area to note: The match function of the Usb_type struct, which has two parameters, one is the driver, and the other is the device. This function is used to infer that the driver on the bus can handle the device. As to when this function is called, how to call, there will be said later.
2.2 The function of the booklet is explained in detail below. The descriptive narrative of the 2.2.1 drive is first seen from the function prototype of the Register function:

896 #define PCI_REGISTER_DRIVER (driver)     897     __pci_register_driver (Driver, This_module, Kbuild_modname) 1103 int __pci_register_driver (struct pci_driver *drv, struct module *owner,1104               const char *mod_name)

The real function __pci_register_driver (), its first parameter is the struct pci_driver type, and then look at the definition of this structure:

 542 struct PCI_   Driver {543 struct list_head node; 544 const char *name; 545 const struct PCI_DEVICE_ID *id_table;  /* Must be non-null-probe to be Calle D */546 int (*probe) (struct Pci_dev *dev, const struct PCI_DEVICE_ID   *ID);   /* New de vice inserted */547 void (*remove) (struct Pci_dev *dev); /* Device removed (NULL if not a hot-plug capable driver) */548 int (*suspend) (struct Pci_dev *dev, pm_message  _t state); /* Device suspended */549 int (*suspend_late) (struct Pci_dev *dev, pm_message_t State); 550 int (*resume_early) (struct Pci_dev *dev);                   551 Int (*resume) (struct Pci_dev *dev); /* Device Woken up */552 void (*shutdown) (struct Pci_dev *dev); 553 struct pci_error_handlers *err_handler; 554 struct Device_driver driver; 555 struct pci_dynids dynids; 556}; 

Looking at this structure in detail, we find that one of the members is the driver structure in the bus device model above us.In fact, in the Linux kernel, the driver definition of all devices is inherited and extended with the struct device_driver as the base class. You're not mistaken, the kernel uses a lot of oo ideas. Then look at the driver description of the NIC I²c device:

143 struct I2c_driver {144     unsigned int class;145 ... 174     struct Device_driver driver;175     const struct I2C_DEVICE_ID *id_table;176177/     * Device detection Callback for automatic device creation */178     int (*detect) (struct i2c_client *, struct i2c_board_info *); 179     Cons T unsigned short *address_list;180     struct List_head clients;181};

Now we know the description of the driver for the PCI device. But here's the question: how do we use such a complex structure? First look at how the instance code is played:

1894 static struct Pci_driver netdrv_pci_driver = {1895     . Name       = modname,1896     . id_table   = Netdrv_pci_ tbl,1897     . Probe      = netdrv_init_one,1898     . Remove     = __devexit_p (netdrv_remove_one), 1899 #ifdef CONFIG _pm1900     . Suspend    = netdrv_suspend,1901     . Resume     = netdrv_resume,1902 #endif/* config_pm */1903};

We can see that not all of the members of the structure we have to operate, we just tube the most critical of a few. What's the difference between the above? Name: Driver module names, this can be ignored. Id_table: The table of this ID is very important, its role is to match the devices supported by the driver. Look at how to use the code in the same way:

221 static define_pci_device_table (NETDRV_PCI_TBL) = {222     {0x10ec, 0x8139, pci_any_id, pci_any_id, 0, 0, RTL8139}, 2     0x10ec, 0x8138, pci_any_id, pci_any_id, 0, 0, NETDRV_CB}, 224     {0x1113, 0x1211, pci_any_id, pci_any_id, 0, 0, SMC1211TX}, 225/*  {0x1113, 0x1211, pci_any_id, pci_any_id, 0, 0, MPX5030},*/226     {0x1500, 0x1360, pci_any_id, P ci_any_id, 0, 0, DELTA8139}, 227     {0x4033, 0x1360, pci_any_id, pci_any_id, 0, 0, ADDTRON8139}, 228     {0,} 229}; 23 0 module_device_table (PCI, NETDRV_PCI_TBL);

This represents the type of device supported by this driver. Probe: This function pointer is equally important. when the driver matches the device, the function is called to drive the device. So being able to say this function is the real entrance to the driver. Remove: Use this function to remove the driver when the appropriate device for the driver has been removed. In general, the id_table and probe functions above seem to be the most important, so let's see how they work. 2.2.2 Driver-device matching above in the description of the probe function said: when the driverMatchAfter the corresponding device is reached, the function is called to drive the device. What does this match mean? How do I make a match? Does it have anything to do with the match function in the bus structure? With these few questions, let's take a look at the register function. Here I will just describe the driver-device matching related content, and the other content seen in the process is not within the scope of the discussion. We will call the process bold and red.

1103 int __pci_register_driver (struct pci_driver *drv, struct module *owner,1104               const char *mod_name) 1105 {1106     int error;11071108/     * Initialize common driver fields */1109     drv->driver.name = drv->name;1110     Drv->driver.bus = &pci_bus_type;1111     drv->driver.owner = owner;1112     drv->driver.mod_name = mod_ name;11131114     Spin_lock_init (&drv->dynids.lock); 1115     Init_list_head (&drv->dynids.list); 11161117/     * Register with core */1118     error = Driver_register (&drv->driver); 1119     if (error) 1120< C12/>goto out;1121 ...         1137}

In the __pci_register_driver function, call driver_register and register the driver on the bus.

222 int driver_register (struct device_driver *drv) 223 {224 int ret;225 struct Device_driver *other;226227 bug_ On (!drv->bus->p); 228229 if (drv->bus->probe && drv->probe) | | (Drv->bus->remove && drv->remove) | | 231 (Drv->bus->shutdown && drv->shutdown)) 232 PRINTK (kern_warning "Driver '%s ' needs UPDA Ting-please use "233" Bus_type methods\n ", drv->name); 234235 other = Driver_find (Drv->name, DRV-&G T;bus) 236 if (other) {237 put_driver (other); 238 printk (Kern_err "Error:driver '%s ' is already regist Ered, "239" aborting...\n ", drv->name); return-ebusy;241}242243 ret = Bus_add_driver (d         RV); 244 if (ret) 245 return ret;246 ret = driver_add_groups (DRV, drv->groups); 247 if (ret) 248 Bus_remove_driver (DRV); 249 return ret;250}

Call Bus_add_driver in Driver_register to add device drivers to the bus.

625 int bus_add_driver (struct device_driver *drv) 626 {......  642     klist_init (&priv->klist_devices, NULL, NULL); 643     priv->driver = DRV; 644     drv->p = Priv; 645     priv->kobj.kset = bus->p->drivers_kset; 646     error = Kobject_init_and_add (&priv->kobj, &driver_ktype, NULL, 647                      "%s", drv->name); 648     if (error) 649         goto out_unregister; 650 651     if (drv->bus->p->drivers_autoprobe) {652         Error = Driver_attach (DRV); 653         if (error) 654             goto out_unregister; 655     } ....... 690}

303 int Driver_attach (struct device_driver *drv) 304 {305     return Bus_for_each_dev (Drv->bus, NULL, DRV, __driver_ attach); 306}

It can be seen that the driver is appended to the bus, and the device is now matched to the driver.

285 int Bus_for_each_dev (struct bus_type *bus, struct device *start, 286              void *data, int (*FN) (struct device *, void * )) 287 {......  295     Klist_iter_init_node (&bus->p->klist_devices, &i, 296                  (start? &start->p->knode _bus:null)); 297     while (dev = next_device (&i)) &&!error) 298         <span style= "color: #ff0000;" >error = fn (dev, data);</span> 299     klist_iter_exit (&i);     return error; 301}

The FN here is the __driver_attach function, so let's take a look at what it did:

265 static int __driver_attach (struct device *dev, void *data) 266 {267     struct device_driver *drv = data; ... 。。 279     if (!driver_match_device (DRV, dev)) 280         return 0;281282     if (dev->parent)/    * Needed for USB */283         Device_lock (dev->parent); 284     device_lock (dev); 285     if (!dev->driver) 286         Driver_probe_ Device (DRV, dev); 287     Device_unlock (dev); 288     if (dev->parent) 289         device_unlock (dev->parent); 290291     return 0;292}

The Driver_match_device function of line 279 is used to match the device to the driver.

108 Static inline int driver_match_device (struct device_driver *drv,109                       struct device *dev) {111     return drv-& Gt;bus->match? Drv->bus->match (Dev, DRV): 1;112}

This starts by calling the match function of the device_driver in the registration, and the detailed process of matching is not seen. Then go back to the driver_probe_device of the __driver_attach function above.

200 int Driver_probe_device (struct device_driver *drv, struct device *dev) 201 {202 int ret = 0;203204 if (!device_is_regis          tered (Dev)) 205 return-enodev;206207 pr_debug ("Bus: '%s ':%s:matched device%s with driver%s\n", 208 Drv->bus->name, __func__, Dev_name (Dev), drv->name); 209210 pm_runtime_get_noresume (Dev); 211 Pm_runtime_b Arrier (dev); 212 ret = Really_probe (dev, DRV); 213 pm_runtime_put_sync (Dev); 214215 return ret;216} 

108 static int really_probe (struct device *dev, struct device_driver *drv) 109 {$ int ret = 0;111112 Atomic_inc (&probe_c Ount); 113 Pr_debug ("Bus: '%s ':%s:probing driver%s with device%s\n", Drv->bus->name, __func__, Dr     V->name, Dev_name (Dev)); warn_on (!list_empty (&dev->devres_head)); 116117 dev->driver = drv;118 if (dev) {119 printk (kern_err "%s:driver_sysfs_add (%s) failed\n", Driver_sysfs_add __func__, dev_ Name (dev)); 121 goto probe_failed;122}123124 if (dev->bus->probe) {Dev->bus-> ;p Robe (dev); 126 if (ret) 127 goto probe_failed;128} else if (drv->probe) {129 ret = DRV ->probe (Dev), and if (ret) 131 goto probe_failed;132}133 ...... ' 

Here, we finally see the Drv->probe function. The driver's probe function starts running, and the driver's registration is done. 3. Summarize our steps to initialize the device driver: 1. According to the type of equipment, the structure required to describe the narrative drive is constructed. The structure needs to inherit the struct Device_driver structure and initialize several important members. 2. Use the Module_init macro to invoke the driver's initialization function Xx_init_module, and register the driver in the initialization function. 3. The driver traverses the struct device and struct device_driver two linked list on the bus, invokes the match function of the bus, and matches the device to the driver. 4. If the device matches the driver successfully, call the driver's probe function. The implementation of the probe function needs to be based on the function of the driver, which is not covered by this article.

Linux device driver registration process specific explanation