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@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. 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. -Frank -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html