Ramoops driver registration failure causes

When Linux ramoops driver module is used, the driver cannot be loaded after compilation. Why does this happen when the kernel code is directly used?

First, let's take a look at the initialization code of ramoops:

180 static int __init ramoops_init(void)181 {182     return platform_driver_probe(&ramoops_driver, ramoops_probe);183 }184185 static void __exit ramoops_exit(void)186 {187     platform_driver_unregister(&ramoops_driver);188 }189190 module_init(ramoops_init);

Is the ramoops_init function at the beginning of Line 1 a bit strange? The probe function is called directly. The standard platform driver process is as follows:

Why does it seem that platform_device definition and registration are missing? Let's take a look at the document/ramoops.txt instructions:

 38 2. Setting the parameters 39 40 Setting the ramoops parameters can be done in 2 different manners: 41  1. Use the module parameters (which have the names of the variables described 42  as before). 43  For quick debugging, you can also reserve parts of memory during boot 44  and then use the reserved memory for ramoops. For example, assuming a machine 45  with > 128 MB of memory, the following kernel command line will tell the 46  kernel to use only the first 128 MB of memory, and place ECC-protected ramoops 47  region at 128 MB boundary: 48  "mem=128M ramoops.mem_address=0x8000000 ramoops.ecc=1" 49  2. Use a platform device and set the platform data. The parameters can then 50  be set through that platform data. An example of doing that is: 51 52 #include <linux/pstore_ram.h> 53 [...] 54 55 static struct ramoops_platform_data ramoops_data = { 56         .mem_size               = <...>, 57         .mem_address            = <...>, 58         .record_size            = <...>, 59         .dump_oops              = <...>, 60         .ecc                    = <...>, 61 }; 62 63 static struct platform_device ramoops_dev = { 64         .name = "ramoops", 65         .dev = { 66                 .platform_data = &ramoops_data, 67         }, 68 }; 69 70 [... inside a function ...] 71 int ret; 72 73 ret = platform_device_register(&ramoops_dev); 74 if (ret) { 75     printk(KERN_ERR "unable to register platform device\n"); 76     return ret; 77 }

It turns out that platform_device is missing.

Append the platform_device operation is relatively simple, according to the document. The main requirement is the ramoops_dev name. The value of this Member must be "ramoops ". Why? This is because when the platform bus calls its own match function and matches the driver with the device, it is to judge whether the name members in the two struct are equal. The value of the name Member in the platform_driver struct can be seen from the following code that it has been written as "ramoops". If the value in platform_device is different, the driver cannot be loaded.

172 static struct platform_driver ramoops_driver = {173     .remove     = __exit_p(ramoops_remove),174     .driver     = {175         .name   = "ramoops",176         .owner  = THIS_MODULE,177     },178 };

Have you ever wondered why the ramoops driver code cannot be loaded without registering platform_device? Let's look back at the initialization code of ramoops:

180 static int __init ramoops_init(void)181 {182     return platform_driver_probe(&ramoops_driver, ramoops_probe);183 }

As mentioned before, the init function will call the register function in general, and this is a standard process. Let's take a look at the definition of the platform_driver_probe function:

 477 int __init_or_module platform_driver_probe(struct platform_driver *drv, 478         int (*probe)(struct platform_device *)) 479 { 480     int retval, code; 481 482     /* make sure driver won't have bind/unbind attributes */ 483     drv->driver.suppress_bind_attrs = true; 484 485     /* temporary section violation during probe() */ 486     drv->probe = probe; 487     retval = code = platform_driver_register(drv); 488。。。}

Do you see the platform_driver_register function? Previously, the register function was encapsulated into a layer. We can see why the driver fails to load if platform_device is not registered.

What, or don't you know? Then you must have not read the registration process about the Linux Device Driver I wrote before. If you have not understood it yet, it is my problem. Link here: http://blog.csdn.net/tuzhutuzhu/article/details/34847619