Re: [PATCH v11 5/7] overlay: Documentation for the overlay sugar syntax

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

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

On Tue, Nov 29, 2016 at 08:45:16AM -0800, Frank Rowand wrote:
> On 11/28/16 21:10, David Gibson wrote:
> > On Mon, Nov 28, 2016 at 08:36:07PM -0800, Frank Rowand wrote:
> >> On 11/28/16 19:10, David Gibson wrote:
> >>> On Mon, Nov 28, 2016 at 06:05:39PM +0200, Pantelis Antoniou wrote:
> >>>> There exists a syntactic sugar version of overlays which
> >>>> make them simpler to write for the trivial case of a single target.
> >>
> >> It also works for multiple targets.  (See the example I provided in
> >> my comment to v10.)
> >>
> >>
> >>>>
> >>>> Document it in the device tree object internals.
> >>>>
> >>>> Signed-off-by: Pantelis Antoniou <pantelis.antoniou-OWPKS81ov/FWk0Htik3J/w@public.gmane.org>
> >>>
> >>> I'm with Frank that I think this, rather than being regarded mere
> >>> syntactic sugar, should be considered the primary way of describing
> >>> overlays.
> >>>
> >>> Obviously we need to support the fully written out version as well.
> >>
> >> If we need to support the fully written out version, can we make that
> >> a discouraged, non-preferred method?  Maybe require an option to
> >> enable compiling this style of dts?
> > 
> > Yeah.  To avoid further proliferation of options, I'm thinking a
> > single "backwards compat" option which would:
> > 	- Use the dtb magic instead of dtb magic
> > 	- Disable checks which would reject explicit creation of
> > 	  __overlay__ / __symbols__ / __fixups__ nodes
> > 	- Anything other special behaviour we need
> > 	
> >> I can imagine some reasons to support the fully written out version,
> >> but can we document what those reasons are?
> > 
> > I believe the main one is the dts files in this format out in the
> > field.  Mind you, I guess we're already requiring them to tweak how
> > they declare the /plugin/ option.
> 
> It might be easy to write a program that transforms the expanded
> format to the simple format.  I'll try to make some time to see
> how difficult it is.  The transformation is relatively easy to
> do manually, but I don't know how many dts files would need to
> be converted.

It's not totally trivial, because such a program would basically need
a full dts parser.  But.. if we change the dtc internals to work with
a list of overlays rather than a single tree, there's a relatively
obvious path to it: we can implement parsing a dtbo input into a set
of fragments rather than an assembled overlay and dts output in
fragment form.  Then converting from old-dts to dtb and back to dts
would pretty much do what's needed.  At the cost of losing comments,
though :/.

-- 
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: 819 bytes --]