Re: [RFC] devicetree: new FDT format version

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

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

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