Detailed explanation of the platform bus of Linux driver

1. Introduction to platform bus

1.1. Separation and layering of Linux drivers

1.1.1. Separation of Linux drivers

Let's talk about the separation of Linux drivers first. The Linux operating system supports running on various types of CPUs. Because each CPU has different device drivers, a large amount of code has accumulated in the Linux kernel. These codes have roughly the same description of the same device, which makes the kernel code very redundant. Take the CPU controlling MPU6050 through I2C as an example:

From the figure, we can see that each platform has a set of host drivers and a set of device drivers. Because the I2C controller of each platform is different, each platform must have its own host driver. However, the MPU6050 used by everyone is the same, so it is completely possible to share a set of device driver codes. The improved framework is as follows:

Of course, this is only for the MPU6050 device under I2C. In actual situations, many devices will definitely be mounted under I2C. Based on this idea, we can get the framework as follows:

In actual development, the I2C host driver will be written by the semiconductor manufacturer, and the device driver will also be written by the device manufacturer. We only need to provide device information, such as which I2C interface the device is connected to and what the I2C speed is. This is equivalent to stripping the device information from the device driver, and the device driver will also use standard methods to obtain device information (such as obtaining device information from the device tree). This is equivalent to the driver being only responsible for driving, and the device (information) being only responsible for the device. All you need to do is find a way to match the two. The bus is the one that does this matching work, which constitutes the bus-driver-device model in Linux. The structure diagram is as follows:

1.2. Platform-driven model

Above we talked about the separation of device drivers and obtained the bus-driver-device model. This bus is what I usually call I2C, SPI, USB and other buses. But the problem is that some devices do not need to go through a certain bus, which is where the platform bus comes in.

It should be noted here that the platform bus is a virtual bus that is different from buses such as USB, SPI, and I2C. It is called virtual because the SoC and some peripherals such as LEDs, timers, and buzzers are addressed through the memory addressing space, so the CPU does not need a bus to communicate with these devices, so there is no such bus in the hardware. However, the kernel has a need for unified management of these devices, so a virtual platform bus is created for these devices that are directly addressed through memory, and all devices that are directly addressed through memory are mapped to this virtual bus.

Advantages of platform bus:

1. Through the platform bus, you can traverse all devices mounted on the platform bus;

2. Separate the device and the driver. Through the platform bus, the device and the driver are registered separately. Because there is a probe function, the driver matching the device can be detected at any time. If the match is successful, the driver will be registered with the kernel.

3. One driver can be used by several devices of the same type. This function is achieved because there is an operation of traversing devices during the driver registration process.

2. Platform framework

2.1、Platform Bus

The Linux kernel uses the bus_type structure to represent the bus. The I2C, SPI, and USB we use are all defined using this structure. The structure is as follows:

/* include/linux/device.h */
 
struct bus_type {
    const char *name; /* bus name*/
    const char *dev_name; 
    struct device *dev_root;
    struct device_attribute *dev_attrs;
    const struct attribute_group **bus_groups; /* bus attributes*/
    const struct attribute_group **dev_groups; /* Device attributes*/
    const struct attribute_group **drv_groups; /* driver attributes*/
 
    int (*match)(struct device *dev, struct device_driver *drv); /* Device driver matching function*/
    int (*uevent)(struct device *dev, struct kobj_uevent_env *env);
    int (*probe)(struct device *dev);
    int (*remove)(struct device *dev);
    void (*shutdown)(struct device *dev);
 
    int (*online)(struct device *dev);
    int (*offline)(struct device *dev);
    int (*suspend)(struct device *dev, pm_message_t state);
    int (*resume)(struct device *dev);
    const struct dev_pm_ops *pm;
    const struct iommu_ops *iommu_ops;
    struct subsys_private *p;
    struct lock_class_key lock_key;
};

The platform bus is a constant of type bus_type. It is called a constant because this variable has been assigned a value by the Linux kernel, and the functions corresponding to its structure members have also been written in the kernel.

The definition is as follows:

/* drivers/base/platform.c */
 
struct bus_type platform_bus_type = {
    .name = "platform",
    .dev_groups = platform_dev_groups,
    .match = platform_match, /* Matching function */
    .uevent = platform_uevent,
    .pm = &platform_dev_pm_ops,
};

The platform_match in platform_bus_type is the function we mentioned earlier for matching drivers and devices. The function is defined as follows:

/* drivers/base/platform.c */
 
static int platform_match(struct device *dev, struct device_driver *drv)
{
    struct platform_device *pdev = to_platform_device(dev);
    struct platform_driver *pdrv = to_platform_driver(drv);
 
    /*When driver_override is set, only bind to the matching driver*/
    if (pdev->driver_override)
        return !strcmp(pdev->driver_override, drv->name);
 
    /* The compatible matching table in the of_match_table of the device tree OF type matching driver base class is compared with the compatible attribute of each device node in the device tree. If they are the same, it means the match is successful*/
    if (of_driver_match_device(dev, drv))
        return 1;
 
    /* ACPI matching */
    if (acpi_driver_match_device(dev, drv))
        return 1;
 
    /* id_table matches the id_table array in the platform driver, which will store a lot of id information*/
    if (pdrv->id_table)
        return platform_match_id(pdrv->id_table, pdev) != NULL;
 
    /* Name matching directly and roughly compares the name information in the platform driver and the device*/
    return (strcmp(pdev->name, drv->name) == 0);
}

We might as well keep it a suspense as to when and where this matching function will be used.

2.2 Platform Driver

2.2.1、platform driver definition

The platform driver is represented by the platform_driver structure, the contents of which are:

/* include/linux/platform_device.h */
 
struct platform_driver {
    int (*probe)(struct platform_device *); /* The platform driver will execute this probe function after matching the platform device*/
    int (*remove)(struct platform_device *);
    void (*shutdown)(struct platform_device *);
    int (*suspend)(struct platform_device *, pm_message_t state);
    int (*resume)(struct platform_device *);
    struct device_driver driver; /* driver base class*/
    const struct platform_device_id *id_table; /* id_table table*/
    bool prevent_deferred_probe;
};

The const struct platform_device_id *id_table in platform_driver is the id_table table, which is used when the platform bus matches the driver and the device using the id_table table matching method. This id_table table is actually an array, and each element type in it is platform_device_id. platform_device_id is a structure with the following contents:

struct platform_device_id {
    char name[PLATFORM_NAME_SIZE];
    kernel_ulong_t driver_data;
};

In platform_driver, driver is a driver base class, which is equivalent to the most basic attributes of the driver. The attributes under different buses are stored in the platform_driver structure.

The content of the driver base class structure device_driver is:

/* include/linux/device.h */
 
struct device_driver {
    const char *name; /* The fourth method of matching devices and drivers using the platform bus is to directly and roughly match the name fields of the two*/
    struct bus_type *bus;
    struct module *owner;
    const char *mod_name; 
    bool suppress_bind_attrs; 
    const struct of_device_id *of_match_table; /* Matching table used by the driver when using device tree*/
    const struct acpi_device_id *acpi_match_table;
    int (*probe) (struct device *dev);
    int (*remove) (struct device *dev);
    void (*shutdown) (struct device *dev);
    int (*suspend) (struct device *dev, pm_message_t state);
    int (*resume) (struct device *dev);
    const struct attribute_group **groups;
    const struct dev_pm_ops *pm;
    struct driver_private *p;
};

Of_match_table in driver is also a matching table. This matching table is used by the platform bus to match the driver and the device using the device tree. It is also an array. The array elements are all of_device_id type. The structure of this type is as follows:

/* include/linux/mod_devicetable.h */
 
struct of_device_id {
    char name[32];
    char type[32];
    char compatible[128]; /* When using device tree matching, the compatible attribute value of the device node is compared with the compatible of each item in of_match_table. If they are equal, it means that the device and driver match successfully*/
    const void *data;
};

2.2.2, platform driver registration

After defining the platform driver with the platform_driver structure, use the platform_driver_register function to register the platform driver with the Linux kernel. The general flow of the function is as follows:

platform_driver_register (drv)
    -> __platform_driver_register
        -> drv->driver.probe = platform_drv_probe; /* Assign the platform_drv_probe function to the probe function of the driver base class drier in the platform driver*/
        -> driver_registe (&drv->driver) /* Register the driver base class driver to the Linux kernel */
            -> ...... 
                -> drv->driver->probe /* Finally execute the probe function of the driver base class driver,
                                                            In fact, it is the platform_drv_probe function given above*/
                    -> platform_drv_probe
                        -> drv->probe /* platform_drv_probe function will execute the probe function of platform driver drv*/

In the above analysis, we replaced the step from driver_register (&drv->driver) to drv->driver->probe with ellipsis. Now let's analyze it:

driver_register(&drv->driver)
    -> bus_add_driver /* Add driver to bus */
        -> driver_attach 
            -> bus_for_each_dev /* Search for each device under the bus, that is, traversal operation*/ 
                -> __driver_attach /* Each device calls this function*/
                    -> driver_match_device /* Check if it matches */
                        -> Call the match function under bus-> driver_probe_device /* Execute this function after successful matching*/
                        -> really_probe 
                            -> drv->probe /* Execute the probe function under drv*/

According to the driver_register function flow, we know that the bus match function will be traversed and used here, which answers a question we left before: where is the bus match function used? Once the match is successful, it will enter the driver's probe function.

According to the platform_driver_register function flow, we can draw a conclusion: the process of registering the platform driver to the Linux kernel involves a process of traversing the driver and device matching. After a successful match, the platform driver's probe function will eventually be executed. The driver base class driver's probe function and the platform_drv_probe function in the process are just transit functions to achieve this purpose.

It is worth noting that the platform driver probe function that will eventually be executed is written by us, so the initiative is back in our hands.

2.3, platform equipment

2.3.1、platform device definition

If the Linux version we are using supports device tree, then describe the device in the device tree. If it does not support device tree, we need to define the platform device. One point we need to consider here is that the matching function match under the bus first matches the device tree, then the id_table table, and then the name field. When the device tree is supported, you can directly change the device information in the device tree node. When the kernel starts, it will automatically traverse the device tree nodes. If the match is successful, a platform_device will be automatically generated for use in the next step. If it is not a device tree, this platform_device is written by the developer.

Here we don't use the device tree, we define the platform device ourselves. The platform device is represented by the platform_device structure, which is defined as follows:

/* include/linux/platform_device.h */
 
struct platform_device {
    const char *name; /* Device name, must be the same as the name of the corresponding platform driver,
                                           Otherwise the device cannot match the corresponding driver*/
    int id; 
    bool id_auto;
    struct device dev;
    u32 num_resources; 
    struct resource *resource;
    const struct platform_device_id *id_entry;
    char *driver_override; /* Driver name to force a match */
    /* MFD cell pointer */
    struct mfd_cell *mfd_cell;
    /* arch specific additions */
    struct pdev_archdata archdata;
};

2.4. Platform matching process

The process of matching the platform bus to the driver and the device has actually been described in detail above. Now let's summarize it and go over it again.

As mentioned before, the matching of drivers and devices under the bus is achieved through the match function under the bus. The match functions corresponding to different buses are definitely different. We don’t need to worry about this because the kernel will write them. The match function corresponding to the platform bus we use is the platform_match function. Let's analyze this function:

platform_match
    -> of_driver_match_device /* Device tree matching */
    -> acpi_driver_match_device /* ACPI matching */
    -> platform_match_id /* platform_driver->id_table match*/
    -> strcmp(pdev->name, drv->name) /* name matches*/

Through a simple analysis of the above matching function, we know that the matching function matches the device tree first, then the id_table table, and then the name field by brute force. For Linux versions that support device tree, we can just do device tree matching right away. When the device tree is not supported, we have to define the platform device and then use the id_tabale table or name matching. In general, name matching is selected.

Now let's take a closer look at the matching process under the device tree condition:

of_driver_match_device /* of function is generally used for device tree, which also gives us a hint*/
    ->of_match_device (drv->of_match_table, dev)    
        -> of_match_node  
            -> __of_match_node
                -> __of_device_is_compatible
                    -> __of_find_property(device, "compatible", NULL) /* Get the compatible property value*/

From the above analysis, we know that the matching process ultimately compares the compatible property in the of_match_table of the driver base class with the compatible property in the device tree node. This is a mechanism that connects the device tree with the platform bus, thereby achieving the purpose of writing device information in the corresponding node of the device tree and writing the driver separately, which is the driver separation we talked about earlier.

3. Summary

In the actual development process, we do not need to actually write a platform bus model, as it has already been defined for us in the kernel. Our analysis of the platform bus model is mainly to figure out how to match drivers and devices, that is, how we find the corresponding driver when we insert a device or how we find the corresponding device when we insert a driver, and finally call the probe function. In fact, no matter whether the driver comes first and the device comes later, or the device comes first and the driver comes later, the first thing to do after the final match is to execute the driver's probe function, so we can safely ignore the twists and turns of the emotional entanglement in the middle and focus directly on the final probe function.

This is the end of this article about the detailed explanation of the platform bus of the Linux driver. For more relevant content about the platform bus of the Linux driver, please search the previous articles of 123WORDPRESS.COM or continue to browse the related articles below. I hope everyone will support 123WORDPRESS.COM in the future!