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 > > <david@xxxxxxxxxxxxxxxxxxxxx> 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 > > > > Applying the overlays in flattened form sounds like a good idea to me. > > 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. > > - Base devicetree contains one non-root node which contains one property. > - Overlay devicetree adds one property to that same node. > > 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): > > (1) base FDT dt_struct: > [node1] [prop1 value length] [prop1 name offset] [prop1 value] > > (2) overlay FDT dt_struct: > [fragment 1 node] [__overlay__ node (for node1)] [prop2 value length] [prop2 name offset] [prop2 value] > > (3) resulting FDT after applying overlay to base: > > [node1] [prop1 value length] [prop1 name offset] [prop1 value] [prop2 value length] [prop2 name offset] [prop2 value] > > - dt_string block updated to add the string for prop2 name (if not already in block) > - prop2 name offset updated for offset in updated dt_string block > > Is creating (3) from (1) and (2) what is meant by "apply an overlay > in flattened form"? > > 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. -- 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
Attachment:
signature.asc
Description: PGP signature
