Come eseguire il debug di un driver che non riesce a collegarsi a un dispositivo su Linux?

Sto cercando di capire perché il seguente dispositivo non è configurato per il suo driver sul mio Creator CI20 . Per riferimento sto usando un kernel Linux v4.13.0 e sto compilando localmente:

make ARCH=mips ci20_defconfig
make -j8 ARCH=mips CROSS_COMPILE=mipsel-linux-gnu- uImage

Dal sistema in esecuzione posso vedere:

ci20@ci20:~# find /sys | grep rng
/sys/firmware/devicetree/base/jz4780-cgu@10000000/rng@d8
/sys/firmware/devicetree/base/jz4780-cgu@10000000/rng@d8/compatible
/sys/firmware/devicetree/base/jz4780-cgu@10000000/rng@d8/name
/sys/bus/platform/drivers/jz4780-rng
/sys/bus/platform/drivers/jz4780-rng/bind
/sys/bus/platform/drivers/jz4780-rng/unbind
/sys/bus/platform/drivers/jz4780-rng/uevent

Quindi il dispositivo viene visualizzato dal kernel in fase di esecuzione, ora il pezzo mancante è perché il driver non è mai associato? Mi sarei aspettato qualcosa del genere:

/sys/bus/platform/drivers/jz4780-rng/100000d8.rng

Ho trovato altri post che spiegano come eseguire il debug di un sistema in esecuzione, come ad esempio:

• /programming/28406776/driver-binding-using-device-tree-without-compatible-string-in-the-driver
• /programming/35580862/device-tree-mismatch-probe-never-called
• /programming/41446737/platform-device-driver-autoloading-mechanism
• È possibile ottenere le informazioni per un albero dei dispositivi usando / sys di un kernel in esecuzione?

Sebbene le informazioni siano accurate su questi post, non sono molto utili per me. Dato che sto compilando localmente il mio kernel (ho aggiunto printkla funzione probe del jz4780-rngdriver), la mia domanda è invece:

• quale opzione dovrei attivare in fase di compilazione in modo che il kernel stampi informazioni accurate sulla sua incapacità di chiamare la funzione probe per il jz4780-rngdriver?
• In particolare, come posso stampare l'elenco completo del bus / driver testato per driver_probe_device?

Sono ok per aggiungere printkovunque nel codice per eseguire il debug di questo. La domanda è piuttosto: quale funzione attraversa l'albero dei dispositivi e chiama la funzione probe / init?

Per riferimento:

$ dtc -I fs -O dts /sys/firmware/devicetree/base | grep -A 1 rng
              rng@d8 {
                      compatible = "ingenic,jz4780-rng";
              };

la stringa compatibile è dichiarata come:

cgu: jz4780-cgu@10000000 {
    compatible = "ingenic,jz4780-cgu", "syscon";
    reg = <0x10000000 0x100>;

    clocks = <&ext>, <&rtc>;
    clock-names = "ext", "rtc";

    #clock-cells = <1>;

    rng: rng@d8 {
        compatible = "ingenic,jz4780-rng";
    };
};

E nell'autista come:

static const struct of_device_id jz4780_rng_dt_match[] = {
    {
        .compatible = "ingenic,jz4780-rng",
    },
    { },
};
MODULE_DEVICE_TABLE(of, jz4780_rng_dt_match);

static struct platform_driver jz4780_rng_driver = {
    .driver     = {
        .name   = "jz4780-rng",
        .of_match_table = jz4780_rng_dt_match,
    },
    .probe      = jz4780_rng_probe,
    .remove     = jz4780_rng_remove,
};
module_platform_driver(jz4780_rng_driver);

Update1:

Quando compilo il mio kernel CONFIG_DEBUG_DRIVER=y, ecco cosa posso vedere:

# grep driver_probe_device syslog
Sep  6 10:08:07 ci20 kernel: [    0.098280] bus: 'platform': driver_probe_device: matched device 10031000.serial with driver ingenic-uart
Sep  6 10:08:07 ci20 kernel: [    0.098742] bus: 'platform': driver_probe_device: matched device 10033000.serial with driver ingenic-uart
Sep  6 10:08:07 ci20 kernel: [    0.099209] bus: 'platform': driver_probe_device: matched device 10034000.serial with driver ingenic-uart
Sep  6 10:08:07 ci20 kernel: [    0.106945] bus: 'platform': driver_probe_device: matched device 1b000000.nand-controller with driver jz4780-nand
Sep  6 10:08:07 ci20 kernel: [    0.107282] bus: 'platform': driver_probe_device: matched device 134d0000.bch with driver jz4780-bch
Sep  6 10:08:07 ci20 kernel: [    0.107470] bus: 'platform': driver_probe_device: matched device 16000000.dm9000 with driver dm9000
Sep  6 10:08:07 ci20 kernel: [    0.165618] bus: 'platform': driver_probe_device: matched device 10003000.rtc with driver jz4740-rtc
Sep  6 10:08:07 ci20 kernel: [    0.166177] bus: 'platform': driver_probe_device: matched device 10002000.jz4780-watchdog with driver jz4740-wdt
Sep  6 10:08:07 ci20 kernel: [    0.170930] bus: 'platform': driver_probe_device: matched device 1b000000.nand-controller with driver jz4780-nand

Ma solo:

# grep rng syslog
Sep  6 10:08:07 ci20 kernel: [    0.166842] bus: 'platform': add driver jz4780-rng
Sep  6 10:08:42 ci20 kernel: [   54.584451] random: crng init done

Come nota a rngmargine , il nodo toplevel: cguqui non si fa riferimento, ma esiste un jz4780-cgudriver.

Update2:

Se sposto la rngdichiarazione del nodo al di fuori del cgunodo di livello superiore, riesco almeno a vedere che sta per accadere un po 'di associazione:

# grep rng /var/log/syslog 
Sep  6 10:30:57 ci20 kernel: [    0.167017] bus: 'platform': add driver jz4780-rng
Sep  6 10:30:57 ci20 kernel: [    0.167033] bus: 'platform': driver_probe_device: matched device 10000000.rng with driver jz4780-rng
Sep  6 10:30:57 ci20 kernel: [    0.167038] bus: 'platform': really_probe: probing driver jz4780-rng with device 10000000.rng
Sep  6 10:30:57 ci20 kernel: [    0.167050] jz4780-rng 10000000.rng: no pinctrl handle
Sep  6 10:30:57 ci20 kernel: [    0.167066] devices_kset: Moving 10000000.rng to end of list
Sep  6 10:30:57 ci20 kernel: [    0.172774] jz4780-rng: probe of 10000000.rng failed with error -22
Sep  6 10:31:32 ci20 kernel: [   54.802794] random: crng init done

usando:

    rng: rng@100000d8 {
        compatible = "ingenic,jz4780-rng";
    };

Posso anche verificare:

# find /sys/ | grep rng
/sys/devices/platform/10000000.rng
/sys/devices/platform/10000000.rng/subsystem
/sys/devices/platform/10000000.rng/driver_override
/sys/devices/platform/10000000.rng/modalias
/sys/devices/platform/10000000.rng/uevent
/sys/devices/platform/10000000.rng/of_node
/sys/firmware/devicetree/base/rng@100000d8
/sys/firmware/devicetree/base/rng@100000d8/compatible
/sys/firmware/devicetree/base/rng@100000d8/status
/sys/firmware/devicetree/base/rng@100000d8/reg
/sys/firmware/devicetree/base/rng@100000d8/name
/sys/bus/platform/devices/10000000.rng
/sys/bus/platform/drivers/jz4780-rng
/sys/bus/platform/drivers/jz4780-rng/bind
/sys/bus/platform/drivers/jz4780-rng/unbind
/sys/bus/platform/drivers/jz4780-rng/uevent

Una soluzione funzionante per convincere il conducente a collegarsi al dispositivo è:

cgublock: jz4780-cgublock@10000000 {
    compatible = "simple-bus", "syscon";

    #address-cells = <1>;
    #size-cells = <1>;

    reg = <0x10000000 0x100>;
    ranges;

    cgu: jz4780-cgu@10000000 {
        compatible = "ingenic,jz4780-cgu";
        reg = <0x10000000 0x100>;

        clocks = <&ext>, <&rtc>;
        clock-names = "ext", "rtc";

        #clock-cells = <1>;
    };

    rng: rng@d8 {
        compatible = "ingenic,jz4780-rng";
        reg = <0x100000d8 0x8>;
    };
};

Questo è stato trovato fissando altri esempi. Preferirei una soluzione in cui ottengo una diagnosi corretta del motivo per cui il tentativo precedente non è corretto.