Hi David, > On Nov 30, 2016, at 02:39 , David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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@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. > > 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 :/. > It’s not just the comments. New style dts’es in the kernel now use CPP pre-processed input which make the dts more readable. Converting back to dts is not even close to the original source. You might as well use fdtdump instead. > -- > 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 Regards — Pantelis -- 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
