Chapter 6: Introduction to Devices, Drivers, and Platform Abstraction

The Linux Device Model (LDM) is a concept that was introduced in the Linux kernel to describe and manage kernel objects (those requiring reference counting, for example, such as files, devices, buses, and even drivers), as well as their hierarchies and how they are bound to others. LDM introduced object life cycle management, reference counting, an object-oriented (OO) programming style in the kernel, and other advantages (such as code reusability and refactoring, automatic resource releasing, and more), which will not be discussed here.

Since reference counting and life cycle management are at the lowest level of LDM, we will discuss higher representations, such as dealing with common kernel data objects and structures, including devices, drivers, and buses.

In this chapter, we will cover the following topics:

• Linux kernel platform abstraction and data structures
• Device and driver matching mechanism...

Linux kernel platform abstraction and data structures

The Linux device model is built on top of some fundamental data structures, including struct device, struct device_driver, and struct bus_type. The first data structure represents the device to be driven, the second is the data structure of each software entity intended to drive the device, and the latter represents the channel between the device and the CPU.

Device base structure

Devices help extract either physical or virtual devices. They are built on top of the struct device structure, which is worth introducing first, as described in include/linux/device.h:

struct device {
    struct device         *parent;
    struct kobject        kobj;
    struct bus_type       *bus;
    struct device_driver  *driver;
 ...

Device and driver matching mechanism explained

Device drivers and devices are always registered with the bus. When it comes to exporting the devices that are supported by the driver, you can use driver.of_match_table, driver.of_match_table, or <bus>_driver.id_table (which is specific to the device type; for example, i2c_device.id_table or platform_device.id_table).

Each bus driver has the responsibility of providing its match function, which is run by the kernel whenever a new device or device driver is registered with this bus. That said, there are three matching mechanisms for platform devices, all of which consist of string comparison. Those matching mechanisms are based on the DT table, ACPI table, device, and driver name. Let's see how the pseudo-platform and i2c buses implement their matching functions using those mechanisms:

static int platform_match(struct device *dev,
               ...

Summary

In this chapter, you learned how to deal with devices and drivers, as well as how they are tied to each other. We have also demystified the matching mechanism. Make sure you understand this before moving on to Chapter 7, Understanding the Concept of Platform Devices and Drivers, Chapter 8, Writing I2C Device Drivers, and Chapter 9, Writing SPI Device Drivers , which will deal with device driver development. This will involve working with devices, drivers, and bus structures.

In the next chapter, we will delve into platform driver development in detail.