設備樹不匹配：.probe從來沒有調用過

我無法理解設備樹如何工作，或者特別是爲什麼這個驅動程序不會啓動。這是瑞芯供應商內核爲Android，版本號爲3.10設備樹不匹配：.probe從來沒有調用過

司機/看門狗/ 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

弓/臂/引導/ DTS/rk3288.dtsi

watchdog: [email protected] { 
      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之前運行，它決定驅動程序是否應該繼續？

而且我不知道如何扁平樹的作品，所以這也許是相關的：

弓/ ARM /馬赫 - 瑞芯微/ 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

來源

2016-02-23 aep

我假設真正的代碼'of_rk29_wdt_match []'初始化器在末尾有一個sentinel元素？它看起來應該是匹配的，假設''rockchip，watch dog''中的空間確實是設備樹和驅動程序中的空間。 –

雖然在設備名稱中有一個空格是很少見的。我不認爲我以前見過。如果您在兩個位置（驅動程序和設備樹）中刪除空間，它會更好嗎？ –

請注意，單獨使用.dtsi並不足以推斷 - 在板級.dts中，應該是一個壓倒性的'status =「disabled」;或者DTB甚至可能會被引導加載程序重新繪製。就我個人而言，我會首先檢查/ proc/device-tree /並在/ sys /中找出錯誤，以便在瞭解驅動程序可能不會出現的原因之前，確定DT節點，驅動程序和設備本身是否真實無誤。綁定到設備。 – Notlikethat

有許多的可能發生這種情況的方式，其中大部分遠離驅動程序代碼本身。首先，一個.dtsi片段本身並不能說明整個故事 - 設備樹語法是分層的，所以屬性（特別是status）仍可能被板級.dts覆蓋，其中包含一個基本的SoC .dtsi文件。其次，編譯的DTB也不是最後一個詞，因爲引導加載程序可能會在將其傳遞給內核之前動態修改它 - 這通常是針對內存節點和SMP啓用方法完成的，但可能會影響任何內容。

這種調試通常可以通過檢查啓動系統的狀態，然後反向工作來弄清楚事情是如何得到的 - 這個特定問題的細節已經規定了一些，但反向處理最好，但是爲了完整起見：

如果內核知道的驅動程序，它的加載和正確地設定初始，就應該在某處/ SYS /總線顯示/ * /司機/ - 否則，它可能是一個需要加載的模塊，或者由於某些其他驅動程序或資源的未滿足依賴性，可能無法初始化。
如果內核知道設備，它應該顯示在/ sys/bus/*/devices /中的某個地方，如果它正確綁定到驅動程序並進行探測，那麼它們應該都有一個符號鏈接。
如果無法找到設備，那麼在基於DT的系統上，下一個要檢查的地方是/ proc/device-tree /（依賴於舊內核上的CONFIG_PROC_DEVICETREE，並且可以在/ sys/firmware/devicetree/base /在較新的版本上） - 這將顯示DT在內核找到它時的視圖，並且在那裏戳一下應該有希望清除任何缺失的節點或不在位的屬性，例如禁用的節點導致內核完全跳過創建一個設備。注意屬性文件本身就是原始數據 - 所以你可能想用hexdump而不是cat來監聽 - 並且所有的數字單元格都是big-endian字節順序的。

來源

2016-02-24 23:09:21 Notlikethat

設備樹不匹配：.probe從來沒有調用過

回答

相關問題