sysfs platform bus

Sysfs file system Linux 2.6 kernel introduced sysfs file system. Sysfs can be regarded as a file system of the same category as proc, devfs and devpty. This file system is a virtual file system, which can more conveniently manage system devices. It can generate a hierarchical view of all system hardware, which is very similar to the proc file system that provides process and status information. Sysfs organizes the devices and buses connected to the system into a hierarchical file, which can be accessed by user space and export kernel data structures and their attributes to user space. One of the purposes of sysfs is to show the hierarchical relationship of the components in the device driver model. Its top-level directories include block, bus, drivers, class, power and firmware.

It organizes the devices and buses actually connected to the system into a hierarchical file. User space programs can also use this information to interact with the kernel. The file system is a direct reflection of the actual device tree on the current system. It establishes this information through the kobject subsystem. When a kobject is created, the corresponding files and directories are also created in the relevant directories under /sys. Since each device has a unique corresponding directory in sysfs, it can be read and written by user space. You may not have cared about the mounting process of the sysfs file system. It is mounted like this. mount -t sysfs sysfs /sys

Sysfs is a special file system that does not have a real medium for storing files. The information source of sysfs is the kobject hierarchy. Reading a sysfs file is to dynamically extract information from the kobject structure and generate a file. Of course, the information in it will be gone after a reboot.

The sysfs file system is closely related to the kobject structure. Each kobject object registered in the kernel corresponds to a directory in the sysfs file system. Kobject is a new device management mechanism introduced in Linux 2.6, represented by struct kobject in the kernel. Through this data structure, all devices have a unified interface at the bottom layer. Kobject provides basic object management and is the core structure of the Linux 2.6 device model. Kobject is the basic structure of the device model. Similar to the base class in C++, it is embedded in the object of a larger object to describe the components of the device model. Such as bus, devices, drivers, etc. They are all connected through kobject to form a tree structure. This tree structure corresponds to /sys.

Sysfs is a file system that uses the VFS interface to read and write the kobject hierarchy. The registration and deregistration of the kobject hierarchy is formed by XX_register(). The file system is a very vague and broad concept. Linux regards all resources as files, allowing users to operate files belonging to different file systems through a unified file system operation interface, that is, the same set of system calls. In this way, the implementation details of various file systems can be hidden from user programs, providing a unified, abstract, virtual file system interface for user programs, which is the so-called "VFS (Virtual Filesystem Switch)". This abstract interface is a set of function operations.

To implement a file system, we need to implement a series of interfaces defined by VFS, such as file_operations, dentry_operations, inode_operations, etc., for the upper layer to call. File_operations describes the operation method for each specific file (such as reading and writing), the dentry_operations structure specifies the operation method of all directories of VFS, and inode_operations provides the operation method of all nodes.

For example, if we write a C program, open("hello.c", O_RDONLY), the process of calling the system is as follows:

open() -> system call -> sys_open() -> filp_open()-> dentry_open() -> file_operations->open()         

Different file systems call different file_operations->open(), which is sysfs_open_file() under sysfs.

We use different file systems to abstract their respective file information into dentry and inode. In this way, for the high-level, we don't need to care about the underlying implementation, and we use a series of standard function calls. This is the essence of VFS, which is actually object-oriented.

Note that sysfs is a typical special file. The information it stores is dynamically generated by the system, and it dynamically contains the hardware resources of the entire machine. Reading and writing from sysfs is equivalent to extracting data from the kobject hierarchy.

Linux kernel driver platform mechanism

Introduction to Virtual Bus Platform

　A new driver management and registration mechanism has been introduced since Linux 2.6: platform_device and platform_driver. Most device drivers in Linux can use this mechanism. Devices are represented by platform_device, and drivers are registered with platform_driver.

　Compared with the traditional device driver mechanism (registered through the driver_register function), the Linux platform.driver mechanism has a very obvious advantage in that the platform mechanism registers the device's own resources into the kernel, which is managed uniformly by the kernel. When using these resources in the driver, they are applied for and used through the standard interface provided by platform.device. This improves the independence of driver and resource management, and has better portability and security (these standard interfaces are safe). The platform mechanism itself is not complicated to use, and consists of two parts: platform_device and platform_driver. The general process of developing low-level device drivers through the platform mechanism is shown in the figure.

Introduction to platform_device

The platform virtual bus invented by Linux, the corresponding device is called

platform_device, the corresponding driver is called

platform_driver.

    The platform_device structure describes the device name, resource information, etc. This structure is defined in include/linux/platform_device.h, and the structure prototype is defined as follows:

        struct platform_device {

               const char * name; //Define the name of the platform device

               int id;

               struct device dev;

               u32 num_resources;

               struct resource * resource; //Define the resources of the platform device.

        };

    The most important member is struct resource * resource. Struct resource is defined in include/linux/ioport.h, and its prototype is as follows:

       struct resource {

               resource_size_t start; //Define the starting address of the resource

               resource_size_t end; //Define the end address of the resource

               const char *name; //Define the name of the resource

               unsigned long flags; //Define the type of resource, such as MEM, IO, IRQ, DMA type

               struct resource *parent, *sibling, *child; //Resource list pointer

        };

    Take the RTC driver as an example (why use RTC? RTC is a standard plartform device, the mechanism is the same, but relatively simple)

    Add the plartform_device structure and resources structure of rtc to arch/arm/mach-sep4020/devices.c:

        static struct resource sep4020_rtc_resource[] = {

              [0] = { .start = RTC_BASE_V,

                      .end = RTC_BASE_V + 0x2f,

                      .flags = IORESOURCE_MEM,

                    }

              [1] = {

                      .start = INTSRC_RTC,

                      .end = INTSRC_RTC,

                      .flags = IORESOURCE_IRQ,

                    }

        }; 

        struct platform_device sep4020_device_rtc = {

              .name = "sep4020_rtc",

              .id = -1,

              .num_resources = ARRAY_SIZE(sep4020_rtc_resource),

             .resource = sep4020_rtc_resource,

        };   

    Then register the platform_device structure through the __initdata device array in the 4020.c file: 

        static struct platform_device *devices[] __initdata = {

               &serial_device,

             &sep4020_device_rtc,

               &epson_ohci_device,

               &sep4020_device_usbgadget

        };  

    platform_add_devices(devices, ARRAY_SIZE(devices)); The device is added to the system by calling platform_add_devices(), which internally calls platform_device_register() to register the device. It should be noted that the platform_device device registration process here must be called before the corresponding device driver is loaded, that is, before executing platform_driver_register(), because the driver registration needs to match all registered device names in the kernel. (How the device and driver are connected through the registered name will be described in detail later)

                                                           Introduction to platform_driver

   The prototype definition of the platform_driver structure is in include/linux/platform_device.h. The code is as follows:

         struct platform_driver {

             int (*probe)(struct platform_device *);

             int (*remove)(struct platform_device *);

             void (*shutdown)(struct platform_device *);

             int (*suspend)(struct platform_device *, pm_message_t state);

             int (*suspend_late)(struct platform_device *, pm_message_t state);

             int (*resume_early)(struct platform_device *);

             int (*resume)(struct platform_device *);

             struct device_driver driver;

         };

   The registration function of the platform_driver structure provided by the kernel is platform_driver_register().

   Its prototype is defined in the driver/base/platform.c file, and the specific implementation code is as follows:

         int platform_driver_register(struct platform_driver *drv)

         {

             drv->driver.bus = &platform_bus_type;

             if (drv->probe)  

                 drv->driver.probe = platform_drv_probe;