Day72 - Platform Bus Internals¶

Summary¶

Today I learned how the Linux Platform Bus is built on top of the Linux Driver Model and how Device Tree integrates with platform devices and platform drivers.

I explored the relationship between:

platform_bus_type
platform_device
platform_driver
Device Tree
of_match_table
platform_match()

I also verified both name-based matching and Device Tree compatible matching using custom platform devices and Device Tree overlays.

What I Learned¶

Platform Bus and Driver Core¶

The Platform Bus is not a separate framework.

Instead, it is a specific implementation of the Linux Driver Model:

platform_bus_type
    ↓
bus_type

platform_device
    ↓
device

platform_driver
    ↓
device_driver

The registration flow ultimately reaches the generic Driver Core APIs.

Platform Driver Registration¶

A platform driver is registered through:

platform_driver_register()
    ↓
driver_register()

The driver appears under:

/sys/bus/platform/drivers

Registration alone does not guarantee that probe() will be called.

Platform Device Registration¶

A platform device can be created manually:

platform_device_register_simple()

or automatically through Device Tree:

Device Tree
    ↓
of_platform_populate()
    ↓
platform_device

Name Matching¶

I created a platform device and platform driver with the same name.

platform_device_register_simple("demo_platform", ...)

.driver = {
    .name = "demo_platform",
}

The Platform Bus successfully matched the device and driver and invoked probe().

Device Tree Compatible Matching¶

I created a Device Tree Overlay:

demo-platform {
    compatible = "demo,platform-bus";
};

and a matching driver:

static const struct of_device_id demo_of_match[] = {
    { .compatible = "demo,platform-bus" },
    {}
};

The Platform Bus used Device Tree compatible matching and successfully invoked probe().

Match Failure¶

I intentionally modified the compatible string so that it no longer matched the driver's of_match_table.

The result:

platform_device exists
platform_driver exists
probe() not called

This confirmed that successful registration does not imply successful binding.

MODULE_DEVICE_TABLE(of)¶

I verified:

MODULE_DEVICE_TABLE(of, demo_of_match);

using:

modinfo platform_device_driver_demo.ko

The generated OF aliases appeared in the module metadata.

This mechanism supports module auto-loading but is not directly responsible for runtime matching.

Sysfs Observation¶

I inspected real Raspberry Pi 5 platform devices:

/sys/bus/platform/devices
/sys/bus/platform/drivers

I verified:

Device Tree Node
    ↓
platform_device
    ↓
platform_driver

through the following sysfs relationships:

device/of_node
device/driver
driver/device symlink

Key Takeaways¶

Platform Bus Architecture¶

Device Tree
    ↓
of_platform_populate()
    ↓
platform_device
    ↓
platform_match()
    ↓
of_match_table
    ↓
really_probe()
    ↓
platform_probe()
    ↓
driver probe()

Matching Methods¶

Platform Match

1. Device Tree compatible match
2. ACPI match
3. ID table match
4. Name match

Important Understanding¶

Device Tree does not call probe() directly.

Device Tree creates platform_device objects.

The Platform Bus performs matching and
invokes probe() after a successful bind.

Lab Completed¶

Observed real Raspberry Pi 5 Platform Bus devices
Registered a minimal platform driver
Verified driver-only registration behavior
Created platform devices using platform_device_register_simple()
Verified name-based matching
Verified registration order independence
Created a Device Tree Overlay
Verified compatible-based matching
Verified matching failure behavior
Verified MODULE_DEVICE_TABLE(of) aliases
Explored Platform Bus sysfs hierarchy

Next Step¶

Day73 - Platform Driver Development

Topics:

struct resource
platform_get_resource()
platform_get_irq()
devm_ioremap_resource()
devm_request_irq()
platform_set_drvdata()
platform_get_drvdata()
Driver private data management
devm resource management