Re: [RFC] devicetree: new FDT format version

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2828 bytes --]

On Fri, Jan 26, 2018 at 09:56:21AM +0100, Geert Uytterhoeven wrote:
> On Thu, Jan 25, 2018 at 1:29 PM, David Gibson
> <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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.
> It still adds complexity, but handling multiple overlays can be done by a
> simple iteration, not recursion.
> The end result will always consume less memory, and will thus fit in the
> original block of memory allocated for base FDT and overlay FDTs, unless
> the base FDT and overlay FDTs are in FLASH (this assumes chaining really
> means appending, not using an external chaining mechanism).

You will require some temporary stprage though, because you'll need to
expand the base tree enough to apply each overlay before you can
discard it.

> > temporarily) unflattening the tree are better solutions.
> 
> Temporary unflattening sounds like a waste to me:

A waste of what, exactly?  Neither flattening nor unflattening is
terribly difficult or expensive.

> it must be redone again
> later anyway. Applying the FDT overlays early on will make that later step
> simpler (no more overlays to handle).
> So if you need information from an FDT, you can help later steps by
> applying the FDT overlays right away.
> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

-- 
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]