Linux Driver Model

Overview

The Linux Driver Model provides a unified framework for managing:

• Devices
• Drivers
• Buses

and their relationships.

Most Linux driver subsystems are built on top of this architecture, including:

• Platform
• I2C
• SPI
• USB
• PCI

Understanding the Linux Driver Model is essential before studying subsystem-specific drivers.

---

Why the Driver Model Exists

Without a common framework, every subsystem would need to implement:

• Device discovery
• Driver registration
• Device-driver matching
• sysfs integration
• Power management

independently.

The Linux Driver Model centralizes these responsibilities inside the Driver Core.

---

Architecture

The Linux Driver Model consists of three core objects:

Device
+
Driver
+
Bus

Relationship:

            Bus
             │
             ▼
          match()
         /       \
        /         \
   Device       Driver
        \         /
         \       /
           Probe
              │
              ▼
           Binding

---

Core Objects

Device

Represents hardware.

Examples:

• Platform Device
• I2C Device
• SPI Device
• USB Device
• PCI Device

Kernel object:

struct device

---

Driver

Represents software capable of controlling a device.

Kernel object:

struct device_driver

Examples:

• platform_driver
• i2c_driver
• spi_driver

---

Bus

Acts as the matching framework between devices and drivers.

Kernel object:

struct bus_type

Examples:

• platform_bus_type
• i2c_bus_type
• spi_bus_type
• usb_bus_type
• pci_bus_type

---

Registration Flow

The Driver Core supports independent registration.

Device Register
        ↓
Driver Register
        ↓
Match
        ↓
Probe

or

Driver Register
        ↓
Device Register
        ↓
Match
        ↓
Probe

Registration order does not matter.

---

Matching

Matching is performed by the bus.

Different buses use different matching criteria.

Examples:

Bus	Matching Method
Platform	Device Tree compatible string
USB	Vendor ID / Product ID
PCI	Vendor ID / Device ID
I2C	Device ID / Device Tree
SPI	Device ID / Device Tree

---

Probe and Remove Lifecycle

After a successful match:

Match
        ↓
Probe
        ↓
Binding

The probe callback initializes the device and establishes the driver-device relationship.

Removal performs:

Remove
        ↓
Unbind

and releases allocated resources.

---

Driver Wrapper Pattern

Most Linux subsystems extend:

struct device_driver

through wrapper structures.

Example:

struct platform_driver {
    ...
    struct device_driver driver;
};

Benefits:

• Generic Driver Core reuse
• Subsystem-specific callbacks
• Consistent driver architecture

---

sysfs Representation

The Driver Model is exposed through sysfs.

Important locations:

/ sys/devices

Real device hierarchy.

/ sys/bus

Bus-centric view.

/ sys/class

User-oriented functional view.

---

Relationship with Device Tree

Device Tree does not directly create drivers.

Instead:

Device Tree
        ↓
Platform Device
        ↓
Platform Bus Match
        ↓
Platform Driver Probe

The Driver Model sits between Device Tree and Driver implementation.

---

Learning Roadmap

Recommended follow-up topics:

1. Linux Driver Model
2. Platform Bus Internals
3. Platform Driver Matching
4. kobject and sysfs
5. Driver Core
6. Device Tree Integration
7. I2C Subsystem
8. SPI Subsystem

---

Related Notes

• Linux Driver Model Fundamentals

Related Labs

• Day71 - Linux Driver Model Fundamentals

Related APIs

• bus_register()
• bus_unregister()
• device_register()
• device_unregister()
• driver_register()
• driver_unregister()