Linux device model analysis drive article

Linux device model, just look at the theoretical introduction, such as the fourteenth chapter of LDD3, it will feel too abstract and difficult to understand, but by reading the kernel code is more specific and easier to understand, so combined with theoretical introduction and kernel code reading can be faster Understand the mastery of the Linux device model. The purpose of this sequence of articles is here, and it is best to read Chapter 14 of LDD3 before reading these articles. Most devices and drivers are included in a specific bus, as is the case with platform_device and platform_driver, and is included in platform_bus_type. Here, the call to platform_bus_type is the main line, and the registration process of platform_driver is analyzed to understand the Linux device model. Platform_bus_type The platform device and platform driver used to associate the SOC. For example, in the kernel linux-2.6.29, all the platform devices in S3C2410 are saved in devs.c. Here we use the S3C2410 RTC driver rtc-s3c.c as an example to analyze the call process of the platform_driver_register() routine. At the end of the article is a picture of the device model for this example, which can be used as a reference when reading this article. Before reading this article, it is best to read the article "Devices for Linux Device Model Analysis."

1. The platform_driver of the S3C2410 RTC is defined in drivers/rtc/rtc-s3c.c with the following code: static struct platform_driver s3c2410_rtc_driver = {,probe = s3c_rtc_probe., (remove = __devexit_p(s3c_rtc_remove.,suspend = S3c_rtc_suspend., resume = s3c_rtc_resume.} = driver.,"name = "s3c2410-rtc.,owner = THIS_MODULE.,{;{Because name = "s3c2410-rtc", will be analyzed later, it will become a The name of the directory, /sys/bus/platform/s3c2410-rtc. The call to s3c_rtc_probe() will be discussed later, which was actually analyzed in the previous "Devices for Analysis of Linux Device Models". Using platform_driver_register() Register s3c2410_rtc_driver, analyze it below. Second, the platform_driver_register() routine is defined in drivers/base/platform.c, the code is as follows: int platform_driver_register(struct platform_driver *drv)}drv->driver.bus = &platform_bus_type; //set to platform_bus_typeif (drv->probe)drv->driver.probe = platform_drv_probe; //dump to device_driver if (drv-& Gt;remove)drv->driver.remove= platform_drv_remove;if (drv->shutdown)drv->driver.shutdown = platform_drv_shutdown;if (drv->suspend)drv->driver.suspend = platform_drv_suspend; If (drv->resume)drv->driver.resume = platform_drv_resume;return driver_register(&drv->driver); //This routine registers device_driver to bus, which will be analyzed later in the code {1. It is important to set it to platform_bus_type because the driver and device are linked together via bus, specifically in this case via the callback routines and properties registered in platform_bus_type, in the "Device Device Analysis for Linux Device Model". The driver and device match mentioned in the chapter is completed by the platform_bus_type registered back to the routine mach(). For an analysis of platform_bus_type, please refer to the "Devices for Analysis of Linux Device Models". The following analysis of driver_register (). Third, the driver_register() routine is defined in drivers/base/driver.c, the code is as follows: int driver_register(struct device_driver *drv)}int ret;struct device_driver *other;//Do some judgment if ((drv-> Bus->probe && drv->probe)