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@xxxxxxxxxxxx> > > > > 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. -- 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
