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>