What Happens When a Linux Driver Probes?

In Linux, a device driver is not normally started by manually calling its initialization function for each device. Instead, the driver core matches registered drivers with devices discovered by buses such as platform, I²C, SPI, and PCI. When a match occurs, the driver core can call the driver's probe() callback.

Typical flow

Device is registered / discovered
             ↓
       Driver core matches
             ↓
      Driver's probe() runs
             ↓
 Request resources and configure HW
             ↓
 Register interfaces / start device

What belongs in probe()?

A driver's probe function commonly obtains resources described by firmware (such as Device Tree), maps registers, requests interrupts, initializes the hardware, and registers the appropriate subsystem interface. Exact steps depend on the bus and subsystem.

static int demo_probe(struct platform_device *pdev)
{
    struct resource *res;

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

    /* Obtain and initialize the device's resources here. */
    dev_info(&pdev->dev, "demo device matched\n");
    return 0;
}

Note: This is an illustrative skeleton, not a complete driver. A real driver should generally use managed resource APIs such as devm_platform_ioremap_resource() where appropriate, handle errors, and follow the relevant subsystem's registration model.

Things to remember

• Driver registration and device discovery are separate events; either may happen first.
• The matching mechanism depends on the bus and its ID tables or firmware match data.
• Probe should return an error if the device cannot be initialized.
• Never assume a register address, interrupt, or clock without checking the platform description and documentation.

Use this page as a starting note, then expand it with tested examples for a specific bus or kernel version.

Editorial note: validate all code against your target kernel version before using it in a real driver.