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

Question

我很难理解设备树是如何工作的，特别是为什么这个驱动程序不会输入它。这是在用于android的rockchip供应商内核中，版本为3.10

drivers/watchdog/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

arch/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之前运行的其他东西可以确定驱动程序是否应该继续？

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

arch/arm/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

Answer 1

有许多可能发生这种情况的方法，其中大多数都远离驱动程序代码本身。首先，仅仅一个.dtsi片段并不能说明整个故事--设备树语法是分层的，因此这些属性(特别是status)仍然可能被包含基本SoC .dtsi文件的板级.dts覆盖。其次，编译的DTB也不是最后一个字，因为引导加载程序在将它传递给内核之前可能会动态地修改它--这通常用于内存节点和SMP启用方法，但可能会影响任何事情。

这种调试通常最好是反向处理，方法是检查引导系统的状态，然后反向工作，找出事情是如何发生的--这个特定问题的具体细节已经排除了其中一些问题，但为了完整起见：

• 如果内核知道驱动程序，并且已经加载并正确初始化，那么它应该出现在/sys/bus/*/ driver /-否则，它可能位于需要加载的模块中，或者由于对其他驱动程序或资源的某种未满足的依赖而无法初始化。
• 如果内核知道设备的情况，它应该出现在/sys/bus/*/设备/中，如果它正确地绑定到驱动程序并被探测，那么它们都应该有一个彼此的符号链接。
• 如果设备在任何地方都找不到，那么在基于DT的系统上，下一个检查位置是/proc/ device -tree/ (依赖于旧内核上的CONFIG_PROC_DEVICETREE，并在/sys/固件/devicetree/base/更新的内核中规范化地找到)--这将显示DT的视图，内核找到了它，在那里稍微戳一下就会发现任何丢失的节点或--位置属性，比如导致内核完全跳过创建设备的禁用节点。请注意，属性文件本身只是原始数据，所以您可能希望使用十六进制而不是cat来窥探，并且所有的数字单元格都是大端字节顺序。

Answer 2

我注意到，在您的定义中，您忽略了数组中所谓的哨兵空结构。请看这里的一个例子：

static const struct of_device_id clk_ids[]  = {
{ .compatible = "sirf,atlas7-clkc" },
{},

}；