macros and dtc

Kumar Gala galak at kernel.crashing.org
Tue Feb 20 06:28:33 EST 2007


On Feb 19, 2007, at 12:07 PM, Dan Malek wrote:

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

Well, I was thinking one useful place would be the PCI range macro.   
Without reading the PCI OF spec 3 or 4 times, its pretty confusing to  
parse what's going on there.

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

Agreed, I'm think some simple SOC block's like TSEC would be useful.

I think its something we need to play with and see how it works out.

- k





More information about the Linuxppc-dev mailing list