> -----Original Message----- > From Geert Uytterhoeven on Wednesday, October 18, 2017 6:22 AM > On Wed, Oct 18, 2017 at 3:18 PM, Alexandre Belloni > wrote: > > On 18/10/2017 at 15:59:00 +0300, Pantelis Antoniou wrote: > >> > On Oct 18, 2017, at 15:14 , Grant Likely > wrote: > >> > On Tue, Oct 17, 2017 at 8:03 PM, Bird, Timothy > wrote: > >> >>> -----Original Message----- > >> >>> From Geert Uytterhoeven on Tuesday, October 17, 2017 10:24 AM > >> >>> On Tue, Oct 17, 2017 at 7:02 PM, Kumar Gala > wrote: > >> >>>> I think this also gets to having bindings described in a structured way > so > >> >>> they can be utilized for validation of dts files. We are doing a little of > this in > >> >>> Zephyr since we are using a structured binding spec to generate code > from > >> >>> .dts (since we don’t utilize a runtime dtb). > >> >>> > >> >>> So you are basically generating board files from .dts? > >> >>> (closing the loop ;-) > >> >> > >> >> I think we ought to do this on Linux, as a size optimization. > >> >> -- Tim > >> >> > >> >> P.S. I think I'll leave it ambiguous whether this was meant as a joke or > not. :-) > >> > >> As crazy that sounds it is possible using the YAML bindings, i.e. C structure > definitions > >> and fill-up from DT automatically. Whether this is a good idea it’s another > question :) > > > > But that doesn't work with any driver parsing custom properties (using > > of_property_read_* and the likes). I would very much like to see what > > are the boot time improvements when doing that ;) > > Unless you override of_property_read_*() to work on the dense C > structures instead? Or turn the property reads into macros that then turn into constant declarations inline in the code. No need stop at dense C structures. Of course you lose all configuration flexibility at runtime. But then that's the kind of trade-off one often makes with embedded software, isn't it? -- Tim