[Bug 227974] libfdt reverses order of child devices in overlays

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227974

            Bug ID: 227974
           Summary: libfdt reverses order of child devices in overlays
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: arm
          Assignee: freebsd-arm at FreeBSD.org
          Reporter: bobf at mrp3.com

this probably affects more than just arm, but I have only observed it with arm.

When an overlay specifies more than one child device, such as in the example
below:

&{/soc/spi at 7e204000} {
        status = "okay";

        spigen0: spigen0 {
                compatible = "freebsd,spigen";
                reg = <0>;
                status = "okay";
        };
        spigen1: spigen1 {
                compatible = "freebsd,spigen";
                reg = <1>;
                status = "okay";
        };
};

"sysctl -b hw.fdt | dtc -I dtb -O dts" reports:

        spi at 7e204000 {
                compatible = "brcm,bcm2835-spi";
                reg = <0x7e204000 0x1000>;
                interrupts = <0x2 0x16>;
                clocks = <0x4 0x14>;
                #address-cells = <0x1>;
                #size-cells = <0x0>;
                status = "okay";
                pinctrl-names = "default";
                pinctrl-0 = <0x36 0x37>;
                phandle = <0x3b>;
                spigen1 {
                        status = "okay";
                        reg = <0x1>;
                        compatible = "freebsd,spigen";
                };
                spigen0 {
                        status = "okay";
                        reg = <0x0>;
                        compatible = "freebsd,spigen";
                };
        };

In this case, it causes ofw_spibus_attach() in ofw_spibus.c to create the
devices in the order specified in the FDT data, numbering them from 0 to 'n',
even though the devices are specified as 'spigen1' and 'spigen0' in the FDT
data, via the following function call:

    childdev = device_add_child(dev, NULL, -1);

this requires that the overlay child devices be specified in reverse order in
order for them to appear with the specified device names 'spigen0' and
'spigen1'.

specifying spigen at 0 and spigen at 1 only causes the names to change (not the order
reversal), and results in exactly the same problem.

It would seem that this problem would exist in the linux world as well, since
everybody is using the same fdt library.  And changing the behavior of libfdt
is probably a bad idea for this reason.


NOTE:  overlay is being loaded using 'fdt_overlays' in loader.conf


WORKAROUND:  specify child devices in the reverse order you want to create them
in within the overlay.

-- 
You are receiving this mail because:
You are the assignee for the bug.