What Is a Platform Device Resource

A pseudo platform bus has no automatic discovery mechanism the way PCI or USB does. Nothing “enumerates” a UART controller soldered onto a board — the kernel has to be told it exists, where its registers sit in memory, and which interrupt line it uses. That description is packaged inside struct platform_device, specifically in an array of struct resource entries.

Think of a resource as a labelled sticky note the board description attaches to a device: “my registers start here and end here”, or “I will raise interrupt number 47 when I need attention”. The driver never guesses these values — it always asks the kernel for them at probe time.

For example, a device named ep_res_demo with num_resources = 3 would carry a resource array shaped like this:

struct resource Fields Explained

Every resource, no matter its type, is represented by the same small structure defined in include/linux/ioport.h:

struct resource {
    resource_size_t start;
    resource_size_t end;
    const char      *name;
    unsigned long   flags;
};

• start / end — for a memory or I/O resource these mark the beginning and end address of the region. For an IRQ or a DMA channel, start and end hold the same number.
• name — a human readable label, useful when a device exposes more than one resource of the same type and you want to fetch a specific one by name.
• flags — a bitmask that tells the kernel what kind of resource this is: memory, IRQ, DMA channel, and so on.

The Six IORESOURCE Types

Kernel 6.x still defines six resource flags in include/linux/ioport.h. Knowing what each one is for prevents a very common beginner mistake: asking for IORESOURCE_MEM when the board description actually supplied IORESOURCE_IO.

How The Kernel Learns About Devices

There are two very different eras of platform resource description, and it helps to know both because you will still meet the old one in legacy code.

The Old, Deprecated Way — Board Files

Before Device Tree existed, every board had a C source file that hand-built an array of struct resource and called platform_device_register(). The driver stayed generic; the board file did all the wiring. This approach does not scale — every new board needs a kernel recompile — and mainline Linux has moved almost entirely away from it.

The Modern Way — Device Tree And ACPI

On kernel 6.x, the overwhelming majority of platform devices are created automatically. A Device Tree node with a reg property and an interrupts property is walked by the of_platform layer, which builds the struct platform_device and its resource array for you before your driver’s probe() is ever called. On ACPI-based systems the equivalent job is done by the ACPI core. Either way, your driver code stays identical — it still calls the same resource-fetching functions you will learn in the next lecture.

The path from firmware description to your driver code follows four steps:

1. A Device Tree node declares its reg and interrupts properties.
2. The of_platform bus layer walks that node during boot.
3. It builds a struct platform_device and populates its resource[] array.
4. Your driver’s probe() function is called with that fully populated device.

Common Mistakes With Platform Device Resources

Summary And Key Takeaways

• A platform device resource describes memory regions, IRQ lines, DMA channels or bus numbers that a driver needs.
• struct resource stores a start/end pair, a name, and a type flag.
• There are six IORESOURCE flags; IORESOURCE_MEM and IORESOURCE_IRQ are the two you will use constantly.
• Modern kernel 6.x systems build the resource array automatically from Device Tree or ACPI — you rarely hand-write it yourself anymore.

In the next lecture you will extract these resources inside probe() using platform_get_resource() and platform_get_irq(), and build an original demo driver, ep_res_demo, that reads them out and prints them to the kernel log.

Frequently Asked Questions