Your driver's probe() is never called — how do you debug it?

This is one of the most common embedded Linux driver development issues, and the debugging approach is systematic. Start by verifying that the device tree node exists and is enabled: check ls /proc/device-tree/ (or /sys/firmware/devicetree/base/) to confirm your node appears, and verify that its status property is "okay", not "disabled". If the node is missing, the DTB was not updated — rebuild and reflash it.

Next, check the compatible string match. Print the device tree node's compatible string with cat /sys/firmware/devicetree/base/your-node/compatible and compare it character-by-character against your driver's of_match_table. Common mistakes include typos, missing vendor prefixes (e.g., "uart" instead of "vendor,uart"), and forgetting to terminate the match table with an empty entry {}. Also verify that the driver's of_match_table is actually referenced in the platform_driver structure — a common copy-paste bug is defining the table but not assigning it to .driver.of_match_table.

Then verify the driver is loaded: check lsmod if it is a module, or confirm it is built-in (=y in .config, not =m). If it is a module, is it present in the rootfs and loaded? Check dmesg for any errors during module loading. Finally, check for deferred probing: if your driver depends on a resource (clock, regulator, GPIO) provided by another driver that has not probed yet, the kernel returns -EPROBE_DEFER and retries later. Check cat /sys/kernel/debug/devices_deferred to see if your device is stuck in deferral — this usually means a dependency is misconfigured in the device tree.