设备树不匹配:.probe从未调用 [英] device-tree mismatch: .probe never called

问题描述

我在理解设备树的工作方式时遇到了麻烦，或者特别是为什么该驱动程序无法启动的原因.这是在适用于Android 3.10版的Rockchip供应商内核中

I'm having trouble understanding how device-tree works, or specifically why this driver won't init. This is in the rockchip vendor kernel for android, version 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

and this is the 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函数.我怀疑它与设备树条目不匹配有关系吗?也许空间是个问题?

however, the .probe function of the driver is never called. It is compiled in and the __init function is called. I suspect it has something to do witch the device tree entry not matching? Maybe the space is an issue?

还是在.probe之前运行的其他任何操作决定了驱动程序是否应该继续运行?

我也不确定展平的树如何工作，所以也许这是相关的:

Also i'm not sure how a flattened tree works, so maybe this is relevant:

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

推荐答案

有许多可能的方法可能会发生这种情况，其中大多数与驱动程序代码本身相距甚远.首先，仅.dtsi片段并不能说明全部-设备树语法是分层的，因此属性(尤其是status)可能仍会被包含基本SoC的板级.dts覆盖. dtsi文件.其次，编译后的DTB也不是硬道理，因为引导加载程序可以在将其传递给内核之前对其进行动态修改-这通常是针对内存节点和SMP启用方法完成的，但可能会影响任何事情.

There are a number of possible ways this might happen, and most of them are well away from the driver code itself. Firstly, a .dtsi fragment alone doesn't tell the whole story - the device tree syntax is hierarchical, so the properties (in particular the status) might still be overridden by the board-level .dts which includes a basic SoC .dtsi file. Secondly, the compiled DTB isn't the last word either, since the bootloader may dynamically modify it before passing it to the kernel - this is typically done for memory nodes and SMP enable methods, but could potentially affect anything.

通常最好以相反的方式解决这种调试问题，方法是检查启动系统的状态，然后进行反向工作以弄清楚事情是如何实现的-这个特定问题的细节已经排除了其中一些问题，但是对于为了完整性:

This kind of debugging is often best tackled in reverse, by examining the state of the booted system, then working backwards to figure out how things got that way - the specifics of this particular question rule some of this out already, but for the sake of completeness:

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

这篇关于设备树不匹配:.probe从未调用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！