设备树不匹配：.probe 从未被调用

我无法理解设备树的工作原理，或者具体来说为什么该驱动程序无法初始化。这是在 android 版本 3.10 的 rockchip 供应商内核中

驱动程序/看门狗/rk29_wdt.c（为了可读性而减少）

static const struct of_device_id of_rk29_wdt_match[] = {
    { .compatible = "rockchip,watch dog" }
};
static struct platform_driver rk29_wdt_driver = {
    .probe          = rk29_wdt_probe,
    [..]
            .of_match_table = of_rk29_wdt_match,
            .name   = "rk29-wdt",
    },
};

static int __init watchdog_init(void)
{ 
    printk("watchdog_init\n");
    return platform_driver_register(&rk29_wdt_driver);
}

这是 soc dtsi

拱门/arm/boot/dts/rk3288.dtsi

    watchdog: wdt@2004c000 {
            compatible = "rockchip,watch dog";
            reg = <0xff800000 0x100>;
            clocks = <&pclk_pd_alive>;
            clock-names = "pclk_wdt";
            interrupts = <GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH>;
            rockchip,irq = <0>;
            rockchip,timeout = <2>;
            rockchip,atboot = <1>;
            rockchip,debug = <0>;
            status = "okay";
    };

但是，驱动程序的 .probe 函数永远不会被调用。它被编译并调用 __init 函数。我怀疑这与设备树条目不匹配有关？也许空间是一个问题？

或者是否有其他东西在 .probe 之前运行来确定驱动程序是否应该继续？

另外我不确定扁平树是如何工作的，所以也许这是相关的：

拱门/手臂/mach-rockchip/rk3288

DT_MACHINE_START(RK3288_DT, "Rockchip RK3288 (Flattened Device Tree)")
    .smp            = smp_ops(rockchip_smp_ops),
    .map_io         = rk3288_dt_map_io,
    .init_time      = rk3288_dt_init_timer,
    .dt_compat      = rk3288_dt_compat,
    .init_late      = rk3288_init_late,
    .reserve        = rk3288_reserve,
    .restart        = rk3288_restart,
MACHINE_END

发生这种情况的可能方式有很多种，其中大多数都与驱动程序代码本身相距甚远。首先，.dtsi 片段本身并不能说明整个故事 - 设备树语法是分层的，因此属性（特别是status）可能仍会被包含基本 SoC .dtsi 文件的板级 .dts 覆盖。其次，编译后的 DTB 也不是最后的结论，因为引导加载程序可能会在将其传递到内核之前动态修改它 - 这通常是针对内存节点和 SMP 启用方法完成的，但可能会影响任何内容。

这种调试通常最好反向解决，通过检查启动系统的状态，然后向后工作以找出事情是如何发生的 - 这个特定问题的细节已经排除了其中的一些内容，但为了完整性：

• 如果内核知道驱动程序，并且它已加载并正确初始化，它应该显示在 /sys/bus/*/drivers/ 中的某个位置 - 否则，它可能位于需要加载的模块中，或者可能无法初始化由于对某些其他驱动程序或资源的某些未满足的依赖关系。
• 如果内核知道该设备，它应该显示在 /sys/bus/*/devices/ 中的某个位置，并且如果它正确绑定到驱动程序并进行探测，那么它们应该具有彼此的符号链接。
• 如果无法找到设备，那么在基于 DT 的系统上，下一个要检查的位置将是 /proc/device-tree/ （取决于旧内核上的 CONFIG_PROC_DEVICETREE，并且可以在 /sys/firmware/devicetree/base 中找到） / 在较新的版本上） - 这将显示内核找到它时 DT 的视图，并且在那里进行一些探索应该有望清除任何丢失的节点或不合适的属性，例如导致内核的禁用节点完全跳过创建设备的过程。请注意，属性文件本身只是原始数据 - 因此您可能想使用 hexdump 而不是 cat 进行窥探 - 并且所有数字单元均采用大端字节顺序。