Skip to content

Linux Driver Model Fundamentals

Overview

The Linux Driver Model provides a common framework that manages:

  • Devices
  • Drivers
  • Buses

and coordinates:

  • Device discovery
  • Driver registration
  • Device-driver matching
  • Probe and remove lifecycle
  • Power management
  • sysfs representation

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

  • Platform
  • I2C
  • SPI
  • USB
  • PCI

Core Objects

The Linux Driver Model is centered around three core objects:

Device
+
Driver
+
Bus

struct device

Represents a hardware device.

Examples:

  • Platform device
  • I2C device
  • SPI device
  • USB device
  • PCI device

Typical responsibilities:

  • Device identity
  • Parent-child hierarchy
  • Driver association
  • sysfs representation

Important members:

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

struct device_driver

Represents a driver.

Typical responsibilities:

  • Device matching
  • Probe callback
  • Remove callback

Important members:

struct device_driver {
    const char *name;

    struct bus_type *bus;

    int (*probe)(struct device *dev);

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

struct bus_type

Represents a bus framework.

Examples:

  • platform_bus_type
  • i2c_bus_type
  • spi_bus_type
  • usb_bus_type
  • pci_bus_type

Important responsibilities:

  • Device list management
  • Driver list management
  • Matching logic

Typical definition:

struct bus_type {
    const char *name;

    int (*match)(
        struct device *dev,
        struct device_driver *drv);
};

Registration Flow

Device and driver registration are independent.

The registration order does not matter.

Example:

Device Register
Driver Register
Match
Probe

or

Driver Register
Device Register
Match
Probe

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


Matching

Matching is controlled by the bus.

Example:

Device
Bus Match
Driver

The bus determines whether a driver can manage a particular device.

Examples:

Platform Bus:

compatible string

USB Bus:

VID/PID

PCI Bus:

Vendor ID
Device ID

Probe Lifecycle

After a successful match:

Match
Probe
Binding

The probe callback typically performs:

  • Memory allocation
  • Hardware initialization
  • IRQ registration
  • sysfs creation
  • Device registration

Probe Failure

Probe failure does not imply driver registration failure.

Example:

driver_register()
Match
Probe
Error

Results:

Driver Registered
Device Not Bound

The driver remains available for future matching attempts.


Remove Lifecycle

When a bound device-driver pair is removed:

Remove
Unbind

Typical responsibilities:

  • Release resources
  • Free memory
  • Remove sysfs entries
  • Unregister devices

Driver Wrapper Pattern

Many Linux subsystems extend:

struct device_driver

using wrapper structures.

Example:

struct platform_driver {
    int (*probe)(struct platform_device *);
    void (*remove)(struct platform_device *);

    struct device_driver driver;
};

This pattern allows subsystem-specific callbacks while still integrating with the generic driver core.


sysfs Relationship

The Linux Driver Model is represented through sysfs.

Important locations:

/sys/devices

Real device hierarchy.

/sys/bus

Bus-centric view.

/sys/class

User-oriented functional view.


Example

A platform device may appear in multiple locations:

/sys/devices/platform/mydev

/sys/bus/platform/devices/mydev

/sys/class/myclass/mydev

These entries represent different views of the same device object.


Relationship Diagram

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

Related Topics

  • Platform Bus Internals
  • Device Tree and Platform Device
  • Driver Core
  • kobject and sysfs
  • Platform Driver Matching
  • I2C Subsystem
  • SPI Subsystem