linux-kernel - nucleo - update kernel ubuntu

incompatibilidad dispositivo-árbol:.probe nunca llamado

Question

Tengo problemas para entender cómo funciona el árbol de dispositivos, o específicamente por qué este controlador no iniciará. Esto está en el kernel de proveedor de rockchip para Android, versión 3.10

drivers / watchdog / rk29_wdt.c (reducido para facilitar la lectura)

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);
}

y esta es la 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";
    };

sin embargo, la función .probe del controlador nunca se llama. Está compilado y se llama a la función __init. ¿Sospecho que tiene algo que hacer si la entrada del árbol del dispositivo no coincide? Tal vez el espacio es un problema?

¿O hay algo más que se ejecute antes de .probe que determine si el controlador debería continuar?

Además, no estoy seguro de cómo funciona un árbol aplanado, así que tal vez esto sea relevante:

arco / brazo / 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

Hay varias formas posibles de que esto suceda, y la mayoría de ellas están muy alejadas del código del controlador. En primer lugar, un fragmento .dtsi por sí solo no cuenta toda la historia: la sintaxis del árbol del dispositivo es jerárquica, por lo que las propiedades (en particular, el status ) aún pueden ser anuladas por los .dts de nivel de tablero que incluyen un archivo SoC .dtsi básico . En segundo lugar, el DTB compilado tampoco es la última palabra, ya que el gestor de arranque puede modificarlo dinámicamente antes de pasarlo al kernel; esto normalmente se hace para los nodos de memoria y los métodos SMP enable, pero podría afectar potencialmente a cualquier cosa.

Este tipo de depuración a menudo se aborda mejor al revés, examinando el estado del sistema arrancado, y luego trabajando hacia atrás para descubrir cómo llegaron las cosas de esa manera: los detalles de esta pregunta particular ya descartan algo de esto, pero por el bien de lo completo:

• Si el kernel sabe sobre el controlador, y está cargado y correctamente inicializado, debería aparecer en algún lugar en / sys / bus / * / drivers / - de lo contrario, puede estar en un módulo que necesita cargarse, o puede haber fallado en inicializar debido a alguna dependencia no satisfecha de algún otro controlador o recurso.
• Si el núcleo conoce el dispositivo, debería aparecer en algún lugar en / sys / bus / * / devices /, y si está correctamente enlazado a un controlador y probado, ambos deberían tener un enlace simbólico entre ellos.
• Si no se encuentra el dispositivo, entonces en un sistema basado en DT el siguiente lugar para verificar sería / proc / device-tree / (depende de CONFIG_PROC_DEVICETREE en núcleos anteriores, y se encuentra canónicamente en / sys / firmware / devicetree / base / en los más nuevos) - esto mostrará la vista del DT como lo encontró el núcleo, y con un poco de hurgar debería dejar en claro los nodos faltantes o las propiedades fuera de lugar, como un nodo deshabilitado que causa el kernel para omitir la creación de un dispositivo completo. Tenga en cuenta que los archivos de propiedades en sí mismos son solo los datos en bruto, por lo que probablemente quiera ir a curiosear con hexdump en lugar de cat, y que todas las celdas numéricas están en orden de bytes big-endian.