Device Tree

platform_driver is common in embedded Linux. SoC internal peripherals such as UART, I2C controllers, SPI controllers, PWM, watchdogs, GPIO controllers, clock controllers, and interrupt controllers often use platform drivers.

When debugging this kind of driver, the most common problem is not a wrong register write. It is that probe never happens.

The Device Tree node exists, and the driver is built in, but why does probe not run?
The compatible string looks right, but why does it not match?
probe runs, but why are resources missing?
What does EPROBE_DEFER in the log mean?

A common Linux device-debugging problem looks like this: the driver code did not change, the kernel boots, but the device never probes. The log may only say probe failed, or the driver may never be entered at all.

The problem is not always in C code.

On many embedded Linux platforms, whether a driver can find a device and obtain register ranges, interrupts, clocks, power supplies, GPIOs, and DMA channels first depends on whether the board description is correct. On ARM, RISC-V, and many embedded platforms, that description is usually Device Tree.