Skip site navigation (1)Skip section navigation (2) 
Date:      Fri, 04 May 2018 17:50:08 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-arm@FreeBSD.org
Subject:   [Bug 227974] libfdt reverses order of child devices in overlays
Message-ID:  <bug-227974-7@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227974

            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@FreeBSD.org
          Reporter: bobf@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@7e204000} {
        status =3D "okay";

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

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

        spi@7e204000 {
                compatible =3D "brcm,bcm2835-spi";
                reg =3D <0x7e204000 0x1000>;
                interrupts =3D <0x2 0x16>;
                clocks =3D <0x4 0x14>;
                #address-cells =3D <0x1>;
                #size-cells =3D <0x0>;
                status =3D "okay";
                pinctrl-names =3D "default";
                pinctrl-0 =3D <0x36 0x37>;
                phandle =3D <0x3b>;
                spigen1 {
                        status =3D "okay";
                        reg =3D <0x1>;
                        compatible =3D "freebsd,spigen";
                };
                spigen0 {
                        status =3D "okay";
                        reg =3D <0x0>;
                        compatible =3D "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 =3D 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@0 and spigen@1 only causes the names to change (not the o=
rder
reversal), and results in exactly the same problem.

It would seem that this problem would exist in the linux world as well, sin=
ce
everybody is using the same fdt library.  And changing the behavior of libf=
dt
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.

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

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-227974-7>