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
弓/ ARM /开机/ 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之前运行,以确定驱动程序是否应该继续？
此外,我不确定扁平的树是如何工作的,所以这可能是相关的：
拱/臂/马赫 – 瑞芯/ 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
解决方法
这种调试通常最好通过检查启动系统的状态来反过来解决,然后向后工作以弄清楚事情是如何形成的 – 这个特定问题的具体细节已经解决了一些问题,但是为了完整性：
>如果内核知道驱动程序,并且已加载并正确初始化,它应该显示在/ sys / bus / * / drivers /中的某个位置 – 否则,它可能位于需要加载的模块中,或者可能未能由于某些其他驱动程序或资源的未满足依赖性而初始化.>如果内核知道设备,它应该显示在/ sys / bus / * / devices /中的某个地方,如果它正确绑定到驱动程序并进行探测,那么它们应该彼此都有一个符号链接.>如果无法找到设备,那么在基于DT的系统上,下一个要检查的地方是/ proc / device-tree /(取决于旧内核上的CONFIG_PROC_DEVICETREE,并且在/ sys / firmware / devicetree /中规范地找到) base / on newer) – 这将显示内核找到的DT的视图,并且在那里稍微戳一下应该有希望清除任何丢失的节点或不合适的属性,例如禁用的节点导致内核完全跳过创建设备.请注意,属性文件本身只是原始数据 – 所以你可能想要使用hexdump而不是cat来窥探 – 并且所有数字单元都是big-endian字节顺序.
