Linux device driver Registration process detailed

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

• Module initialization
• Driver Registration

The following is a sample code provided by the kernel pci-skeleton.c, detailing the registration process for a PCI device driver. The driver code registration process for other devices is basically the same, and you can view them yourself. The kernel code version used is 2.6.38.
1. Module Initialization 1.1 Driver entry all device drivers will have the following two lines of code:

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 the driver module is loaded, the driver executes from the Netdrv_init_module function. When the device corresponding to the driver is deleted, the Netdrv_cleanup_module function is executed.
1.2 Module initialization When the driver starts executing, the driver initialization function netdrv_init_module is executed first, and the code is as follows:

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}

As you can see, the initialization function is simple, and only a pci_register_driver function is executed 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 registration What is the registration of the driver module? The Pci_register_driver function called in the initialization function mentioned above is the registration driver. Before introducing the registration function, it is necessary to explain the bus device driver model of Linux in detail, otherwise the following content is difficult to describe clearly. 2.1 Linux Bus device driver model for the bus device driver model, many books have detailed explanations, but are very abstract, it is difficult to understand (at least I think). Below I try to use the simplest way to explain the relevant 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 identified the members that need to be used below, which are discussed later. Comparing the three structures above, you will find that both the device and the driver are defined in the bus, that both the bus and the driver are in the device, and that the existing bus in the driver has the information about the device. So what 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 registration; each time a driver, also to the bus reporting, or called registration. For example, when the system initializes, it scans which devices are connected, builds a struct device variable for each device, and prepares a variable for each driver for a struct device_driver structure. These variables are added to the linked list to form a list of equipment and a driving scale. In this way, the bus can find every device and every driver through the bus. When a struct device is born, the bus goes to the driver list to find the driver for the device. If you find the driver to execute the device, otherwise wait. Vice versa.
There is one more point 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 determine whether 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 Description of the registration function Let's explain the driver registration function in detail below. The description of the 2.2.1 driver is first viewed 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 register 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}; 

Look closely at this structure and discover that one of the members is the driver structure in the bus device model above us.in fact, in the Linux kernel, all the drivers of the device are defined by the struct device_driver as the base class, inheriting and extending. You are 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 how to describe the driver for a 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 this struct are going to operate, we just have to do the most critical of them. 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. Also look at the usage in the code:

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 also important. when the driver matches the corresponding device, the function is called to drive the device. So it can be said that this function is the real entrance of the driver. Remove: Use this function to remove the driver when the device corresponding to the driver is deleted. 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 only 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 the device driver 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}

As you can see, after the driver is appended to the bus, it now starts to match the device 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}

Here we begin to call the match function registered in Device_driver, and the exact process of matching will not be 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, and the driver's registration is done. 3. Summarize our steps to initialize the device driver: 1. Depending on the type of device, construct the structure required to describe the drive. The structure needs to inherit the struct Device_driver structure and initialize several important members. 2. Register the driver in the initialization function by calling the driver's initialization function Xx_init_module through the MODULE_INIT macro. 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.