Wie kann ich einen Treiber debuggen, der unter Linux nicht an ein Gerät gebunden werden kann?

Ich versuche herauszufinden, warum das folgende Gerät nicht auf seinem Treiber auf meinem Creator CI20 eingerichtet ist . Als Referenz verwende ich einen Linux-Kernel v4.13.0 und führe die Kompilierung lokal durch:

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

Vom laufenden System kann ich sehen:

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

Das Gerät wird also zur Laufzeit vom Kernel gesehen. Das fehlende Teil ist nun, warum der Treiber niemals gebunden wird. Ich hätte so etwas erwartet:

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

Ich habe einige andere Beiträge gefunden, in denen erklärt wird, wie ein laufendes System debuggt wird, wie zum Beispiel:

• /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
• Ist es möglich, die Informationen für einen Gerätebaum mit / sys eines laufenden Kernels abzurufen?

Obwohl die Informationen in diesen Posts korrekt sind, sind sie für mich nicht sehr hilfreich. Da ich meinen Kernel lokal baue (ich habe printkdie Testfunktion des jz4780-rngTreibers hinzugefügt ), lautet meine Frage stattdessen:

• Welche Option sollte ich beim Kompilieren aktivieren, damit der Kernel genaue Informationen darüber druckt, dass die Testfunktion für den jz4780-rngTreiber nicht aufgerufen werden kann ?
• Wie drucke ich insbesondere die vollständige Liste des getesteten Busses / Treibers aus driver_probe_device?

Ich kann printkirgendwo im Code etwas hinzufügen , um dies zu debuggen. Die Frage ist vielmehr: Welche Funktion durchläuft den Gerätebaum und ruft die Probe / Init-Funktion auf?

Als Referenz:

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

kompatibler String wird deklariert als:

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

Und im Fahrer als:

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:

Wenn ich meinen Kernel mit baue CONFIG_DEBUG_DRIVER=y, kann ich Folgendes sehen:

# 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

Aber nur:

# 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

rngNebenbei bemerkt, der Knoten auf oberster Ebene: cguwird hier nicht referenziert, aber es gibt einen jz4780-cguTreiber.

---

Update2:

Wenn ich rngdie Knotendeklaration außerhalb des cguKnotens der obersten Ebene verschiebe , kann ich zumindest sehen, dass endlich eine Bindung stattfindet:

# 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

Verwenden von:

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

Ich kann auch überprüfen:

# 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

Eine funktionierende Lösung, um den Treiber zum Binden an das Gerät zu bewegen, ist:

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

Dies wurde festgestellt, indem andere Beispiele angestarrt wurden. Ich würde eine Lösung bevorzugen, bei der ich eine richtige Diagnose bekomme, warum der vorherige Versuch falsch ist.