From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Gibson Subject: Re: [RFC] devicetree: new FDT format version Date: Sat, 27 Jan 2018 20:00:23 +1100 Message-ID: <20180127090023.GB12900@umbus> References: <20180123124232.GA14832@umbus> <20328477-e511-e875-7dc4-253640f2219e@gmail.com> <20180125122912.GB2099@umbus> <83008da0-7383-ba2d-a239-e11ad7d1327d@gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="KFztAG8eRSV9hGtP" Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1517043638; bh=aZ02yKOWQXE9XcVlUZWU2iBH+WmgLwy5pWxLVLjv7FE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=a90B8uzFuRtQgUORztkbfVvpuVovD8oK162l4eHxXPFaOtVDySXk88PLgUXPWYyS6 aeWzn8o2/95jffZDHUPXtqq/xCd8coy1LFoPNi3uKcgYbrh5Xd9vNJrVOoHGuMZiQK Cu6tMBJuXEUTo1RqoSgS5hUH3RHuQxdrqKyE9h4c= Content-Disposition: inline In-Reply-To: <83008da0-7383-ba2d-a239-e11ad7d1327d-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Sender: devicetree-spec-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: To: Frank Rowand Cc: Geert Uytterhoeven , Rob Herring , Devicetree Compiler , "devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Jon Loeliger , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pantelis Antoniou , "Pantelis Antomarek.vasut-Re5JQEeQqe/2sr8fMPgRzw@public.gmane.org" , Grant Likely , Marek =?utf-8?B?VmHFoXV0?= , Tom Rini , Kyle Evans , Alan Tull , Michael Ellerman --KFztAG8eRSV9hGtP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 26, 2018 at 02:08:08PM -0800, Frank Rowand wrote: > On 01/26/18 00:56, Geert Uytterhoeven wrote: > > On Thu, Jan 25, 2018 at 1:29 PM, David Gibson > > wrote: > >> On Wed, Jan 24, 2018 at 04:22:15PM -0800, Frank Rowand wrote: > >>> On 01/24/18 13:16, Frank Rowand wrote: > >>>> What you say makes sense. So I'll reverse myself and say that for > >>>> Linux, we should update the FDT read code to scan all chained > >>>> overlay FDT(s) as well as the base FDT. > >>> > >>> < snip > > >>> > >>> What I wrote was somewhat ambiguous. What I meant by "FDT read > >>> code" was functions that check for existence of nodes in the > >>> FDT or read property values from the FDT. > >> > >> Oh.. not just FDT unflattening code. > >> > >> The trouble with this is that scanning for a specific node or property > >> in a set of chained overlays is highly nontrivial. Even if you set > >> aside the arguably self-imposed design constraints in libfdt, you > >> can't just do the same lookup in each fragment: along the way you need > >> to resolve the path at which each fragment applies. That in itself is > >> non-trivial. If you have overlays applying on top of other overlays, > >> that could involve recursive lookups of things from previous overlays. > >> It's spectacularly complicated and we have to do it on *every single* > >> read operation. > >> > >> Either fully applying the overlay in flattened form, or (even > >=20 > > Applying the overlays in flattened form sounds like a good idea to me. >=20 > I'm having trouble envisioning what "apply an overlay in flattened form" > means. Uh.. exactly what fdt_overlay_apply() does right now. > I'll provide a simple example to illustrate. >=20 > - Base devicetree contains one non-root node which contains one propert= y. > - Overlay devicetree adds one property to that same node. >=20 > The before and after dt_struct block of the FDTs would contain (vastly > simplified, ignoring tags, not notating nesting of nodes, ignoring > root node, etc): >=20 > (1) base FDT dt_struct: > [node1] [prop1 value length] [prop1 name offset] [prop1 value] >=20 > (2) overlay FDT dt_struct: > [fragment 1 node] [__overlay__ node (for node1)] [prop2 value length] [= prop2 name offset] [prop2 value] >=20 > (3) resulting FDT after applying overlay to base: >=20 > [node1] [prop1 value length] [prop1 name offset] [prop1 value] [prop2 v= alue length] [prop2 name offset] [prop2 value] >=20 > - dt_string block updated to add the string for prop2 name (if not alre= ady in block) > - prop2 name offset updated for offset in updated dt_string block >=20 > Is creating (3) from (1) and (2) what is meant by "apply an overlay > in flattened form"? >=20 > Getting from (1) and (2) to (3) does not look trivial. Am I missing > something? It's not trivial, but it's not awful. Maxime Ripard already implemented it for libfdt. --=20 David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson --KFztAG8eRSV9hGtP Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEdfRlhq5hpmzETofcbDjKyiDZs5IFAlpsP6cACgkQbDjKyiDZ s5I5QhAAnBHdPASvvmvj+MSBV7wWsAb3Fw3TYiNh3ej5BTAA8gJKTP1kCL3SpwdY 0SYiR+1cTmzwuq6hsUxqaLTklm46xY/64JRoGc72VOA2QSrjImlzwbYGErfQ1n70 Gh0xkMfR9sTGdszR29/gvlxUT2DV6DQMbMYHF/FtJGqWDsCT+BFKi7syR7+IN+Gn B6MeKAy271s7IsUUVBh/pE1gc9Wlyi8DgoaufIKYSTD7Z8r23P8qLlnsRsGha1AE rEYrLDrDZ71AWp50f0YRibNeRNG2lKKb4FWgjPmuCQVPy0DKbCdGP1LD6LIZbnaN exjbpM+vrByUzjOnsLf05ztLU8KJDN5n7RoI1ZPOZSGK78OB1jN/33LfyYIYbr2U D4+iVOBv+VyJnym3Do8W2xCwyu2knpRZwawuyXOZhMi14gdBsFJKTtRk2PjKOJNE PI+RSTZPDXx3cJd1WlEnlg03leGz1Bez3s8s249GzG2J44ogyr59POKHnlVP0LhJ 87LbI1M3nuerJg6Gr9ZV6si9sUW7xKDXfd8nHFZXscS0mVL4AJinJEADxcCOsYc5 CG2pJGIygIPoq5IuxO/PpTLFO7ig4K2L5inXlohXK/FwgZIt2FyW6IOWGMGZCnrH dYmWxGpvnhQsG+aF/uhCB1GNBZ615CBC/kMP7N9C/O1SknvFrGM= =hPsP -----END PGP SIGNATURE----- --KFztAG8eRSV9hGtP--