Day 71 - Linux Driver Model Fundamentals¶

Today's Goal¶

Understand the Linux Driver Model architecture and the relationship between:

struct device
struct device_driver
struct bus_type

Learn how the Linux Driver Core performs:

Device registration
Driver registration
Device-driver matching
Probe and remove lifecycle
sysfs object hierarchy

What I Learned¶

Linux Driver Model Architecture¶

The Linux Driver Model is built around three core objects:

Device
+
Driver
+
Bus

Where:

struct device
    Represents a hardware device

struct device_driver
    Represents a driver

struct bus_type
    Performs matching between devices and drivers

The driver core coordinates the relationship between these objects.

Device Registration and Driver Registration¶

A device and driver can be registered independently.

The registration order does not matter.

Example:

Device Register
        +
Driver Register
        ↓
      Match
        ↓
      Probe

or

Driver Register
        +
Device Register
        ↓
      Match
        ↓
      Probe

The bus performs matching whenever a new device or driver appears.

Matching and Probe Flow¶

The matching process is controlled by the bus.

Example:

device_register()
        ↓
driver_register()
        ↓
bus.match()
        ↓
probe()

The probe callback is only executed when matching succeeds.

Experiments confirmed:

Matching success triggers probe
Matching failure prevents probe
Registration success does not guarantee probe success

Probe Failure Behavior¶

A driver may register successfully while probe fails.

Example:

driver_register()
        ↓
match()
        ↓
probe()
        ↓
return -EINVAL

Observed behavior:

Driver remains registered
Device is not bound
Remove callback is not called

This demonstrates that:

Driver Registration
!=
Device Binding

Driver Wrapper Abstraction¶

Implemented a custom driver wrapper:

struct demo_driver {
    struct device_driver driver;

    int (*probe)(struct device *dev);
    void (*remove)(struct device *dev);
};

This mimics subsystem-specific driver structures such as:

struct platform_driver
struct i2c_driver
struct spi_driver

and illustrates how Linux extends the generic driver core.

sysfs Hierarchy¶

Observed the generated sysfs hierarchy:

/sys/devices
/sys/bus/demo_bus/devices
/sys/bus/demo_bus/drivers

Verified:

/sys/bus/demo_bus/devices/demo_device
        ↓
symbolic link
        ↓
/sys/devices/demo_device

This demonstrates that:

sysfs
    ↓
represents
    ↓
Linux Device Model

Labs Completed¶

Lab 1 - Basic Driver Core Registration¶

Implemented:

bus_register()
device_register()
driver_register()

Observed:

match()
probe()
remove()

execution flow.

Lab 2 - Driver Wrapper Abstraction¶

Implemented:

struct demo_driver

and bus-level probe/remove forwarding.

Observed:

demo_bus_probe()
        ↓
demo_drv_probe()

and

demo_bus_remove()
        ↓
demo_drv_remove()

flow.

Lab 3 - Match Success and Failure¶

Tested:

Matching success
Matching failure

Verified that probe is only executed when matching succeeds.

Lab 4 - Probe Failure Behavior¶

Forced probe to return:

-EINVAL

Verified:

Driver registration succeeds
Device binding fails
Remove callback is not executed

Lab 5 - sysfs Observation¶

Inspected:

/sys/bus/demo_bus
/sys/devices

Verified device, driver, and bus relationships inside sysfs.

Key Takeaways¶

Linux Driver Model consists of device, driver, and bus objects.
Bus performs matching and controls probe execution.
Probe success establishes device-driver binding.
Driver registration is independent from probe success.
sysfs is a representation of the Linux Device Model.
Platform, I2C, SPI, USB, and PCI subsystems are built on top of the same driver core concepts.

Next Step¶

Day72 - Platform Bus Internals

Topics:

platform_bus_type
platform_device
platform_driver
Device Tree to Platform Device conversion
of_match_table
Compatible matching flow
Platform bus probe lifecycle