[PATCH v2] dtc: Add support for named integer constants

[David Gibson]

On Thu, Sep 08, 2011 at 06:18:21AM -0700, Simon Glass wrote:
> Hi Stephen,
> 
> On Thu, Sep 8, 2011 at 6:09 AM, Simon Glass <sjg at chromium.org> wrote:
> > Hi Stephen,
> >
> > On Fri, Sep 2, 2011 at 11:34 AM, Stephen Warren <swarren at nvidia.com> wrote:
> >> Stephen Warren wrote at Tuesday, August 30, 2011 3:30 PM:
> >>> You may define constants as follows:
> >>>
> >>> /define/ TWO 2;
> >>> /define/ FOUR 4;
> >>> /define/ OTHER FOUR;
> >>>
> >>> And properties may use these values as follows:
> >>>
> >>> foo = <1 TWO 3 FOUR 5>;
> >>>
> >>> Signed-off-by: Stephen Warren <swarren at nvidia.com>
> >>
> >> David, Jon,
> >>
> >> Does this seem reasonable?
> >>
> >> I think the syntax is simple enough it wouldn't interfere with any more
> >> advanced expression/function/... support in the future, and it could be
> >> easily extended to allow e.g.:
> >>
> >> /define/ FOO "BAR";
> >> /define/ BAX [0af8dacb0];
> >> ...
> >
> > This seems very reasonable to me, and very useful. From the syntax it
> > looks like lower case symbols are allowed also, which is fine with me.
> >
> > I hope that this can go into dtc as we would definitely use it.
> >
> > Regards,
> > Simon
> >
> >>
> >> And even arbitrary expressions on the RHS as/when/if support is added
> >> for those more generally:
> >>
> >> /define/ A (B | (C << 2));
> 
> [in a separate email since I don't want to pollute my comments on
> Stephen's nice patch with separate ravings]
> 
> Thinking of bitfields, we already have a problem with the way GPIOs
> are specified. Typically we do something like:
> 
> something = <&gpio 46 5>
> 
> and define the third parameter to be three bits (direction, initial
> value, polarity). It would be nice to be able to do something like:
> 
> something = <&gpio 46 INPUT,ACTIVE_LOW>
> something-else = <&gpio 46 OUTPUT,HIGH>
> 
> instead. That would avoid having to explicitly have expressions
> containing | or define all combinations like this:

I really don't like the idea of adding an extra explicit syntax for
bitfields.  I much prefer just implementing integer expressions, which
would allow the same thing through |.

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