Platform devices
Platform devices commonly represent SoC-integrated peripherals such as GPIO controllers, timers, or memory-mapped blocks. Their resources are often described by Device Tree: register ranges, interrupts, clocks, and resets. Drivers use the platform driver model and typically access registers through managed mapping helpers.
I²C devices
I²C devices live behind an I²C controller and are addressed on the bus. A driver uses the I²C client model and SMBus or I²C transfer helpers. The reg property usually represents the device's bus address, not a memory-mapped register base. Register reads often involve a write of a register index followed by a repeated-start read, depending on the device protocol.
SPI devices
SPI devices are selected through chip-select and communicate through full-duplex transfers. A driver uses the SPI framework and message/transfer APIs. Clock mode, maximum frequency, word size, and chip-select timing must match the peripheral datasheet.
Conceptual comparison
| Model | Typical access | Device identity |
|---|---|---|
| Platform | Memory-mapped registers | Firmware node or platform ID |
| I²C | Bus transactions by address | I²C client and compatible/ID |
| SPI | Clocked transfers with chip-select | SPI device and compatible/ID |
Common mistake
Do not choose a driver model based only on the sensor's electrical pins. A sensor connected over I²C should normally use the I²C framework, even if it also has an interrupt GPIO. The GPIO signals an event; it does not change the data bus.
Bring-up sequence
- Verify wiring, power, pin mux, and controller enablement.
- Describe the device correctly in firmware or board data.
- Use the right subsystem APIs and matching table.
- Check bus-level traces and kernel logs before blaming the sensor.
Final takeaway
Low-level engineering is about understanding the contract between hardware, firmware, and the operating system. Start with the specification, form a testable hypothesis, collect evidence, and validate behavior on the target platform.