macros and dtc

[Yoder Stuart-B08248]

> -----Original Message-----
> From: linuxppc-dev-bounces+b08248=freescale.com at ozlabs.org 
> [mailto:linuxppc-dev-bounces+b08248=freescale.com at ozlabs.org] 
> On Behalf Of Dan Malek
> Sent: Monday, February 19, 2007 12:08 PM
> To: Kumar Gala
> Cc: Linux PPC Dev ML; Jon Loeliger; David Gibson
> Subject: Re: macros and dtc
> 
> 
> On Feb 18, 2007, at 11:58 AM, Kumar Gala wrote:
> 
> > After spending some time this weekend cleaning up dts files 
> I figured
> > it would be nice if we can some to consensus on how we are going to
> > do macro support.
> 
> I'm not sure I'd like to use macros.  I can understand the case
> today where we are still changing too many things that a
> macro would be nice, but at some point this has to settle down.
> There isn't that much information in the file, and I prefer to
> see all of it clearly rather than locating macros to wonder
> how they need to be invoked.
> 
> > There is clearly a lot of duplication between
> > dts's and it only gets worse when you add in slight variations for
> > revs of boards.
> 
> Of the few boards for which I've had to create new dts
> files, I wonder how the macros would work.  Although the
> variations are slight, there are many variables.  A macro
> is going to have to allow nearly all of the property information
> as parameters, so what's the big savings?  If you are
> just using them to avoid syntax, then perhaps we should
> have chosen a different syntax? :-)  I think a macro with
> lots of parameters is more confusing than the syntax
> we currently use.
> 
> I could envision using something like cpp with #include
> to get some standard SOC block properties, but macros
> that try to account for board variations could be quite
> complex.

Heavy use of parameterized macros could make reading
device trees more difficult.

But for basic things like #include and #define constants it
would be a good thing.

bus-frequency = <33MHZ> is much better than
bus-frequency = <13ab6680>

Same would go for interrupts, interrupt-map, etc.

There are lot's of hardcoded constants floating around
in the dts files that for clarity should be #defined (or
whatever the m4 equivalent is) at the top of the file.

Stuart