Tag: platform bus linux

Learn Platform Devices and Drivers in Linux from scratch with clear explanations, device tree examples, driver code, testing steps, and real-world insights.

If you are getting into Linux device drivers, especially embedded Linux, you will keep hearing one phrase again and again: Platform Devices and Drivers.

At first, it sounds complicated. Platform bus, platform_device, platform_driver, device tree, probe function, resources, matching. It feels like too many moving parts.

But once you understand the why behind platform devices and drivers, everything starts to click.

This guide is written for beginners, but with expert depth, so it also helps during interviews and real projects.

What Are Platform Devices and Drivers in Linux?

In simple words:

Platform Devices and Drivers are used in Linux to handle on-chip hardware that is not discoverable automatically.

That single sentence explains 80 percent of the concept.

Unlike PCI or USB devices, many embedded peripherals are:

• Built directly into the SoC
• Always present
• Not hot-pluggable
• Not discoverable by scanning a bus

Examples include:

• GPIO controllers
• I2C controllers
• SPI controllers
• UARTs
• Timers
• Watchdogs
• On-chip ADCs

Linux still needs a clean way to represent these hardware blocks. That is where Platform Devices and Drivers come in.

Why Platform Devices and Drivers Exist

To understand platform drivers, first understand what Linux expects from hardware.

Linux follows a simple model:

• A device describes hardware
• A driver knows how to control that hardware
• The kernel matches them and binds them

For PCI or USB, the kernel can discover devices automatically. For embedded hardware, there is no discovery mechanism.

So Linux needed:

• A way to describe fixed hardware
• A bus that does not rely on enumeration
• A matching mechanism that still feels clean

That solution is the platform bus.

What Is the Platform Bus?

The platform bus is a virtual bus inside the Linux kernel.

It is not a real hardware bus like I2C or SPI.

Think of it as a logical meeting place where:

• Platform devices are registered
• Platform drivers are registered
• The kernel matches them by name or device tree

This bus makes sure Linux can treat on-chip hardware the same way it treats external devices.

Platform Device vs Platform Driver

This confusion is very common, especially for beginners.

Let us clear it properly.

Platform Device

A platform device represents the hardware.

It describes things like:

• Base memory address
• IRQ number
• DMA channels
• Clock names
• Device name

The platform device does not contain logic. It only describes what exists.

Platform Driver

A platform driver contains the software logic.

It knows:

• How to initialize the hardware
• How to read and write registers
• How to handle interrupts
• How to expose functionality to user space

The driver does the actual work.

How Platform Devices Were Defined Earlier

Before device tree became common, platform devices were defined in board files.

Example idea:

static struct platform_device uart_device = {
    .name = "my_uart",
    .id = -1,
    .resource = uart_resources,
};

This worked but had problems:

• Board specific code lived inside the kernel
• Kernel had to be recompiled for hardware changes
• Not scalable

This is why Device Tree replaced board files.

Role of Device Tree in Platform Devices and Drivers

Today, Device Tree is the most common way platform devices are created.

The device tree:

• Describes hardware in a hardware-agnostic way
• Is loaded by the bootloader
• Is parsed by the kernel
• Automatically creates platform devices

So now, you usually do not manually register platform devices in C code.

How Device Tree Creates Platform Devices

When the kernel boots:

1. Bootloader loads kernel + device tree blob
2. Kernel parses the device tree
3. Each compatible node becomes a platform device
4. Kernel looks for a matching platform driver

That is the entire flow.

Example Device Tree Node

uart0: serial@48020000 {
    compatible = "vendor,my-uart";
    reg = <0x48020000 0x1000>;
    interrupts = <32>;
    status = "okay";
};

This node creates a platform device automatically.

The kernel then looks for a platform driver with:

.compatible = "vendor,my-uart"

How Platform Device and Driver Matching Works

Linux supports multiple matching mechanisms, but device tree is the most common.

Matching Using of_match_table

static const struct of_device_id my_uart_of_match[] = {
    { .compatible = "vendor,my-uart" },
    {}
};

When the kernel sees a platform device with the same compatible string, it binds the driver.

Basic Structure of a Platform Driver

A minimal platform driver looks like this:

static int my_driver_probe(struct platform_device *pdev)
{
    return 0;
}

static int my_driver_remove(struct platform_device *pdev)
{
    return 0;
}

static struct platform_driver my_driver = {
    .probe = my_driver_probe,
    .remove = my_driver_remove,
    .driver = {
        .name = "my_driver",
        .of_match_table = my_driver_of_match,
    },
};

This structure is the backbone of Platform Devices and Drivers in Linux.

What Happens in the Probe Function

The probe() function is the heart of a platform driver.

This is where you:

• Get memory resources
• Map registers using ioremap
• Request IRQs
• Initialize hardware
• Register character device or subsystem

If probe fails, the device is not usable.

Getting Resources from Platform Device

Example:

struct resource *res;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

This resource came directly from the device tree reg property.

Mapping Registers

void __iomem *base;
base = devm_ioremap_resource(&pdev->dev, res);

This maps physical memory into kernel virtual address space.

Interrupt Handling in Platform Drivers

int irq = platform_get_irq(pdev, 0);
request_irq(irq, my_isr, 0, "my_driver", dev);

Again, IRQ info comes from device tree.

Power Management in Platform Drivers

Platform drivers integrate nicely with Linux power management.

You can implement:

• Suspend
• Resume

This is important for battery-powered embedded devices.

How Platform Drivers Expose Functionality

Platform drivers usually expose functionality using:

• Character devices
• sysfs
• procfs
• Input subsystem
• Network stack

Example for character device:

alloc_chrdev_region(...)
cdev_add(...)

How to Write Platform Devices and Drivers in Linux Step by Step

Here is a clean beginner flow.

Step 1: Identify Hardware

• Base address
• IRQ number
• Clock source

Step 2: Write Device Tree Node

Describe hardware correctly.

Step 3: Write Platform Driver Skeleton

• probe
• remove
• match table

Step 4: Handle Resources

• Memory
• IRQ
• Clocks

Step 5: Initialize Hardware

• Reset
• Configure registers

Step 6: Expose Interface

• Char device or sysfs

Common Mistakes Beginners Make

• Forgetting of_match_table
• Wrong compatible string
• Not handling error paths
• Hardcoding addresses
• Ignoring device tree

Avoid these and your driver becomes clean and reusable.

Platform Devices and Drivers vs Character Drivers

This is a popular interview question.

A platform driver is about how the driver binds to hardware.

A character driver is about how user space interacts.

Many platform drivers internally register a character driver.

They are not mutually exclusive.

Testing and Verifying Platform Drivers

Testing is where most tutorials stop. This one does not.

Check Device Creation

ls /sys/bus/platform/devices

Check Driver Binding

ls /sys/bus/platform/drivers

Check Kernel Logs

dmesg | grep my_driver

Verify Probe Execution

Add logs:

dev_info(&pdev->dev, "Probe successful\n");

Verify Resource Mapping

Check /proc/iomem.

Debugging Tips for Platform Drivers

• Use dev_dbg()
• Enable dynamic debug
• Validate device tree addresses
• Double-check IRQ numbers
• Use ftrace if needed

Debugging is part of learning. Do not avoid it.

Real-World Use of Platform Devices and Drivers

Almost every embedded Linux system relies on platform drivers:

• Automotive ECUs
• Medical devices
• Industrial controllers
• Consumer electronics
• IoT gateways

If you work in embedded Linux, you will write or debug platform drivers.

Platform Driver Implementation From Scratch (Linux)

What we are building

We will create a basic platform driver that:

• Matches a device tree node
• Gets MMIO memory
• Maps registers
• Logs success

This is the foundation of all real platform drivers (GPIO, UART, I2C, SPI, etc.).

Step 1: Understand the Flow

Before code, understand this flow:

Device Tree
     ↓
Platform Device created by kernel
     ↓
Platform Driver registered
     ↓
Matching via compatible string
     ↓
probe() called
     ↓
Hardware initialized

If this flow is clear, platform drivers become easy.

Step 2: Device Tree Node (Hardware Description)

This is mandatory in modern Linux.

Example Device Tree Node

Add this to your .dts file:

my_device@10000000 {
    compatible = "nish,my-platform-device";
    reg = <0x10000000 0x1000>;
    status = "okay";
};

What this means

Property	Meaning
compatible	Used for driver matching
reg	Base address + size
status	Enable device

This node automatically creates a platform device.

Step 3: Platform Driver Skeleton (Core Code)

Create a file:

my_platform_driver.c

Include Required Headers

#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/io.h>

Step 4: Device Tree Match Table

This is how Linux connects device ↔ driver

static const struct of_device_id my_platform_of_match[] = {
    { .compatible = "nish,my-platform-device" },
    { }
};
MODULE_DEVICE_TABLE(of, my_platform_of_match);

Compatible string must exactly match device tree.

Step 5: Private Driver Data Structure

struct my_platform_dev {
    void __iomem *base_addr;
};

This stores mapped register base.

Step 6: Probe Function (Most Important Part)

static int my_platform_probe(struct platform_device *pdev)
{
    struct resource *res;
    struct my_platform_dev *dev;

    dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
    if (!dev)
        return -ENOMEM;

    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    if (!res) {
        dev_err(&pdev->dev, "Memory resource not found\n");
        return -ENODEV;
    }

    dev->base_addr = devm_ioremap_resource(&pdev->dev, res);
    if (IS_ERR(dev->base_addr))
        return PTR_ERR(dev->base_addr);

    platform_set_drvdata(pdev, dev);

    dev_info(&pdev->dev, "Platform driver probed successfully\n");

    return 0;
}

What happens here (simple words)

Step	Explanation
platform_get_resource()	Gets address from DT
ioremap()	Maps physical → virtual
platform_set_drvdata()	Saves private data
probe()	Hardware is now usable

Step 7: Remove Function

static int my_platform_remove(struct platform_device *pdev)
{
    dev_info(&pdev->dev, "Platform driver removed\n");
    return 0;
}

Cleanup is automatic because we used devm_ APIs.

Step 8: Platform Driver Structure

static struct platform_driver my_platform_driver = {
    .probe  = my_platform_probe,
    .remove = my_platform_remove,
    .driver = {
        .name = "my_platform_driver",
        .of_match_table = my_platform_of_match,
    },
};

Step 9: Module Init and Exit

module_platform_driver(my_platform_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Nish");
MODULE_DESCRIPTION("Platform Driver from Scratch");

This macro handles init and exit automatically.

Step 10: Complete Driver Code (Final)

#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/io.h>

struct my_platform_dev {
    void __iomem *base_addr;
};

static const struct of_device_id my_platform_of_match[] = {
    { .compatible = "nish,my-platform-device" },
    { }
};
MODULE_DEVICE_TABLE(of, my_platform_of_match);

static int my_platform_probe(struct platform_device *pdev)
{
    struct resource *res;
    struct my_platform_dev *dev;

    dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL);
    if (!dev)
        return -ENOMEM;

    res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    if (!res)
        return -ENODEV;

    dev->base_addr = devm_ioremap_resource(&pdev->dev, res);
    if (IS_ERR(dev->base_addr))
        return PTR_ERR(dev->base_addr);

    platform_set_drvdata(pdev, dev);

    dev_info(&pdev->dev, "Platform driver probed\n");
    return 0;
}

static int my_platform_remove(struct platform_device *pdev)
{
    dev_info(&pdev->dev, "Platform driver removed\n");
    return 0;
}

static struct platform_driver my_platform_driver = {
    .probe  = my_platform_probe,
    .remove = my_platform_remove,
    .driver = {
        .name = "my_platform_driver",
        .of_match_table = my_platform_of_match,
    },
};

module_platform_driver(my_platform_driver);

MODULE_LICENSE("GPL");
MODULE_AUTHOR("Nish");
MODULE_DESCRIPTION("Platform Driver From Scratch");

Step 11: Makefile

obj-m += my_platform_driver.o

Step 12: Build the Driver

make -C /lib/modules/$(uname -r)/build M=$PWD modules

Step 13: Insert and Test

sudo insmod my_platform_driver.ko
dmesg | tail

Expected output:

Platform driver probed

Step 14: Verify Binding

ls /sys/bus/platform/devices
ls /sys/bus/platform/drivers/my_platform_driver

If your device appears → success

Key Interview Points

• Platform drivers are for non-discoverable devices
• Device tree creates platform devices
• Matching happens via compatible
• probe() initializes hardware
• devm_ APIs simplify cleanup

What You Should Do Next

If you want real mastery, next steps:

1. Add character device interface
2. Add IRQ handling
3. Add sysfs attributes
4. Convert to GPIO / LED driver
5. Learn power management callbacks

Why Platform Devices and Drivers Matter for Your Career

Understanding Platform Devices and Drivers shows that you:

• Understand Linux internals
• Can work close to hardware
• Can read device tree files
• Can debug kernel issues

This skill separates application developers from embedded engineers.

FAQ: Platform Devices and Drivers in Linux

1. What are platform devices and drivers in Linux?

Platform devices and drivers in Linux are used to manage hardware that is built directly into the system, such as GPIO controllers, UARTs, and timers. These devices cannot be auto-detected, so Linux uses the platform bus and device tree to describe and bind them to drivers.

2. Why are platform drivers needed in embedded Linux?

Platform drivers are needed in embedded Linux because most on-chip peripherals do not support hardware discovery. The platform driver framework allows Linux to cleanly separate hardware description from driver logic using device tree.

3. What is the difference between a platform device and a platform driver?

A platform device represents the hardware information like memory address and interrupts, while a platform driver contains the code that controls the hardware. Linux matches them and calls the driver’s probe function.

4. How does device tree work with platform devices and drivers?

The device tree describes hardware in a structured format. During boot, the Linux kernel parses the device tree and automatically creates platform devices, which are then matched with platform drivers using compatible strings.

5. What is the platform bus in Linux?

The platform bus is a virtual bus inside the Linux kernel that connects platform devices with platform drivers. It is mainly used for fixed hardware present on the SoC.

6. How does Linux match a platform driver to a platform device?

Linux matches a platform driver to a platform device using the compatible string defined in the device tree and the of_match_table in the driver code.

7. What happens inside the probe function of a platform driver?

The probe function is called when the driver matches a device. It initializes hardware, maps registers, requests interrupts, and prepares the device for use.

8. Is a platform driver the same as a character driver?

No. A platform driver defines how the driver binds to hardware, while a character driver defines how user space interacts with the driver. A platform driver can internally register a character driver.

9. Do platform drivers always require a device tree?

In modern Linux systems, platform drivers usually rely on device tree. Older systems used board files, but device tree is now the standard and recommended approach.

10. How can I test if my platform driver is working correctly?

You can test a platform driver by checking kernel logs using dmesg, verifying device creation in /sys/bus/platform, and confirming that the probe function is executed successfully.

11. What are common mistakes when writing platform devices and drivers?

Common mistakes include mismatched compatible strings, incorrect memory addresses in device tree, forgetting the of_match_table, and improper resource handling in the probe function.

12. Where are platform devices and drivers used in real projects?

Platform devices and drivers are widely used in automotive systems, industrial controllers, IoT devices, medical equipment, and consumer electronics running embedded Linux.

Read More : Char Driver Model in Linux