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:
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:
or
The driver core performs matching whenever a new device or driver appears on the bus.
Matching¶
Matching is controlled by the bus.
Example:
The bus determines whether a driver can manage a particular device.
Examples:
Platform Bus:
USB Bus:
PCI Bus:
Probe Lifecycle¶
After a successful match:
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:
Results:
The driver remains available for future matching attempts.
Remove Lifecycle¶
When a bound device-driver pair is removed:
Typical responsibilities:
- Release resources
- Free memory
- Remove sysfs entries
- Unregister devices
Driver Wrapper Pattern¶
Many Linux subsystems extend:
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:
Real device hierarchy.
Bus-centric view.
User-oriented functional view.
Example¶
A platform device may appear in multiple locations:
These entries represent different views of the same device object.
Relationship Diagram¶
Related Topics¶
- Platform Bus Internals
- Device Tree and Platform Device
- Driver Core
- kobject and sysfs
- Platform Driver Matching
- I2C Subsystem
- SPI Subsystem