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