Linux Platform Device/driver (i)

How does 1.platform device "automatically" correlate to platform driver?

Turn to Linux driver some time, some time ago encountered a problem, in the Linux kernel 3.10 drivers/tty/serial/imx.c, registered driver when the call Platform_driver_register ( &serial_imx_driver), Serial_imx_driver type is platform_driver, there is a member variable probe in Serial_imx_driver, this function is called when the driver is registered. But the argument for this function is Platform_device, and there is no variable of type Platform_device in imx.c, and the problem arises.

2. How are the devices, buses, and drivers related?

Later consulted the relevant information, in general, after the linux2.6 kernel, the device and drive structure is divided into devices, buses, drives, devices and drivers are hung on the bus, and they are matched by name, there are two ways of binding: one is to install the driver, then mount the device The other is to mount the device first and then install the driver. But both of them are behind the action to search the bus on the same device as their name or driver to match, that is, to complete the binding.

3. Implementation in the Code

In Imx.c, because the platform is 3.10, so using DTS, the device is pre-mounted such as serial port 0/1/2/3 ..., after the installation of the driver, will invoke the above mentioned Platform_driver_register (&serial_imx_ Driver), in the driver registration process will be matched device, once matched to a device, will call probe to initialize, this probe parameter also has the source. Refer to the following calling procedure :

Do_basic_setup ()->driver_init ()->platform_bus_init ()-> Initialize platform Bus (virtual bus)
When the device registers with the kernel Platform_device_register ()->platform_device_add ()-> The kernel hangs the device under the virtual platform bus
Driver Registration platform_driver_register ()->driver_register ()->bus_add_driver ()->driver_attach () Bus_for_each_dev () for each device that hangs on the virtual platform Bus __driver_attach ()->driver_probe_device ()->drv->bus->match () ==platform_match (), compare strncmp (Pdev->name, Drv->name, bus_id_size), call Platform_drv_probe () if it matches Driver->probe () If the probe succeeds, bind the device to the driver.

The code is as follows : Platform_device does not appear when performing to Driver_attach:

int Driver_attach (struct device_driver *DRV) {    return Bus_for_each_dev (drv- >bus, NULL, DRV, __driver_attach);} EXPORT_SYMBOL_GPL (Driver_attach);

This step begins, the county initializes the device list, then iterates through the properties of the node through Next_device, calls FN, or __driver_attach, andDev also gets the device pointer from Next_device .

intBus_for_each_dev (structBus_type *bus,structDevice *Start,void*data,int(*FN) (structDevice *,void*)){    structKlist_iter i; structDevice *Dev; intError =0; if(!bus | |!bus->p)return-EINVAL; Klist_iter_init_node (&bus->p->klist_devices, &I, (Start? &start->p->knode_bus:null));  while(Dev = next_device (&i)) &&!error) Error=fn (dev, data); Klist_iter_exit (&i); returnerror;} EXPORT_SYMBOL_GPL (Bus_for_each_dev);

The above is just a simple understanding, or not in-depth, so many of the principles are not clear, I hope to have time to calm down the heart of research and research, such as:

1. Equipment, drive, bus design concept, structure mode

2. Mechanism of device and driver to hang on bus

3. linux2.6 before, linux2.6, linux2.6, drivers, equipment changes in these versions, such as the emergence of platform, DTS, etc.

Linux Platform Device/driver (i)