All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH] dtc: Add support for named constants
@ 2011-08-23 22:43 Stephen Warren
       [not found] ` <1314139400-31984-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Warren @ 2011-08-23 22:43 UTC (permalink / raw)
  To: David Gibson, jdl-CYoMK+44s/E
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Arnaud Lacombe

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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
Note 1: This is against dtc in the Linux kernel. Should this patch be
against upstream dtc, then back-ported to the kernel?

Note 2: I'd prefer the syntax of /define/ to be:

/define/ TWO 2;

but I assume that'd cause the lexing for DT_DEFINEREF to conflict with
that for DT_LABEL?

Note 3: The define syntax only handles integers. Should it be string-
based instead?

Note 4: I'm not sure what to do about re-generating the lex/yacc results;
my local tools aren't the versions used previously, and so introduce some
changes not related to mine.

 scripts/dtc/dtc-lexer.l  |   12 ++++++
 scripts/dtc/dtc-parser.y |   98 +++++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 109 insertions(+), 1 deletions(-)

diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index e866ea5..ff31bbf 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -96,6 +96,12 @@ static int pop_input_file(void);
 			return DT_MEMRESERVE;
 		}
 
+<*>"/define/"	{
+			DPRINT("Keyword: /define/\n");
+			BEGIN_DEFAULT();
+			return DT_DEFINE;
+		}
+
 <*>{LABEL}:	{
 			DPRINT("Label: %s\n", yytext);
 			yylval.labelref = xstrdup(yytext);
@@ -109,6 +115,12 @@ static int pop_input_file(void);
 			return DT_LITERAL;
 		}
 
+<V1>\${LABEL}	{
+			yylval.defineref = xstrdup(yytext + 1);
+			DPRINT("Define: '%s'\n", yylval.defineref);
+			return DT_DEFINEREF;
+		}
+
 <*>\&{LABEL}	{	/* label reference */
 			DPRINT("Ref: %s\n", yytext+1);
 			yylval.labelref = xstrdup(yytext+1);
diff --git a/scripts/dtc/dtc-parser.y b/scripts/dtc/dtc-parser.y
index 5e84a67..50bc10b 100644
--- a/scripts/dtc/dtc-parser.y
+++ b/scripts/dtc/dtc-parser.y
@@ -33,12 +33,18 @@ extern void yyerror(char const *s);
 extern struct boot_info *the_boot_info;
 extern int treesource_error;
 
+static struct define *get_define(const char *s);
+static void set_define(const char *name, unsigned long long value);
+static void set_define_defineref(const char *name, const char *ref);
+static void set_define_literal(const char *name, const char *value);
+static unsigned long long eval_defineref(const char *s, int bits);
 static unsigned long long eval_literal(const char *s, int base, int bits);
 %}
 
 %union {
 	char *propnodename;
 	char *literal;
+	char *defineref;
 	char *labelref;
 	unsigned int cbase;
 	uint8_t byte;
@@ -55,8 +61,10 @@ static unsigned long long eval_literal(const char *s, int base, int bits);
 
 %token DT_V1
 %token DT_MEMRESERVE
+%token DT_DEFINE
 %token <propnodename> DT_PROPNODENAME
 %token <literal> DT_LITERAL
+%token <defineref> DT_DEFINEREF
 %token <cbase> DT_BASE
 %token <byte> DT_BYTE
 %token <data> DT_STRING
@@ -118,13 +126,31 @@ addr:
 		{
 			$$ = eval_literal($1, 0, 64);
 		}
-	  ;
+	| DT_DEFINEREF
+		{
+			$$ = eval_defineref($1, 64);
+		}
+	;
+
+define:
+	  DT_DEFINE DT_DEFINEREF DT_LITERAL ';'
+		{
+			set_define_literal($2, $3);
+		}
+	| DT_DEFINE DT_DEFINEREF DT_DEFINEREF ';'
+		{
+			set_define_defineref($2, $3);
+		}
+	;
 
 devicetree:
 	  '/' nodedef
 		{
 			$$ = name_node($2, "");
 		}
+	| define
+		{
+		}
 	| devicetree '/' nodedef
 		{
 			$$ = merge_nodes($1, $3);
@@ -139,6 +165,9 @@ devicetree:
 				print_error("label or path, '%s', not found", $2);
 			$$ = $1;
 		}
+	| devicetree define
+		{
+		}
 	;
 
 nodedef:
@@ -265,6 +294,10 @@ cellval:
 		{
 			$$ = eval_literal($1, 0, 32);
 		}
+	| DT_DEFINEREF
+		{
+			$$ = eval_defineref($1, 32);
+		}
 	;
 
 bytestring:
@@ -327,6 +360,69 @@ void yyerror(char const *s) {
 	print_error("%s", s);
 }
 
+struct define {
+	const char *name;
+	unsigned long long value;
+	struct define *next;
+};
+static struct define *defines;
+
+static struct define *get_define(const char *s)
+{
+	struct define *define = defines;
+
+	while (define != NULL) {
+		if (streq(s, define->name))
+			return define;
+		define = define->next;
+	}
+
+	return NULL;
+}
+
+static void set_define(const char *name, unsigned long long value)
+{
+	struct define *define;
+
+	if (get_define(name)) {
+		print_error("redefining %s", name);
+		return;
+	}
+
+	define = xmalloc(sizeof(*define));
+	define->name = name;
+	define->value = value;
+	define->next = defines;
+	defines = define;
+}
+
+static void set_define_defineref(const char *name, const char *ref)
+{
+	unsigned long long v = eval_defineref(ref, 64);
+	set_define(name, v);
+}
+
+static void set_define_literal(const char *name, const char *value)
+{
+	unsigned long long v = eval_literal(value, 0, 64);
+	set_define(name, v);
+}
+
+unsigned long long eval_defineref(const char *s, int bits)
+{
+	struct define *define = get_define(s);
+
+	if (define == NULL) {
+		print_error("referenced define %s does not exist", s);
+		return 0;
+	}
+
+	if ((bits < 64) && (define->value >= (1ULL << bits)))
+		print_error("referenced define out of range");
+
+	return define->value;
+}
+
 static unsigned long long eval_literal(const char *s, int base, int bits)
 {
 	unsigned long long val;
-- 
1.7.0.4

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH] dtc: Add support for named constants
       [not found] ` <1314139400-31984-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
@ 2011-08-30  4:23   ` David Gibson
       [not found]     ` <20110830042316.GH4254-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: David Gibson @ 2011-08-30  4:23 UTC (permalink / raw)
  To: Stephen Warren; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Arnaud Lacombe

On Tue, Aug 23, 2011 at 04:43:20PM -0600, Stephen Warren wrote:
> 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-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---
> Note 1: This is against dtc in the Linux kernel. Should this patch be
> against upstream dtc, then back-ported to the kernel?

Yes, it should.  It's not even really a backport to the kernel, we
can just drop a new upstream version in there.

> Note 2: I'd prefer the syntax of /define/ to be:
> 
> /define/ TWO 2;

Oh goodness, yes.  The dollar signs are revolting.

> but I assume that'd cause the lexing for DT_DEFINEREF to conflict with
> that for DT_LABEL?

Nope, the final colon should distinguish DT_LABEL.  In dts-v1 C-like
identifiers should be lexically distinct in most contexts.  This is
not by accident.  They could be confused with node or property names,
but that shouldn't cause trouble.

> Note 3: The define syntax only handles integers. Should it be string-
> based instead?
> 
> Note 4: I'm not sure what to do about re-generating the lex/yacc results;
> my local tools aren't the versions used previously, and so introduce some
> changes not related to mine.

This problem will go away when you work against upstream dtc; it has
bison flex as a build dependency.  We only worry about pre-generating
the lex and yacc output when we import into the kernel.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [RFC PATCH] dtc: Add support for named constants
       [not found]     ` <20110830042316.GH4254-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
@ 2011-08-30 16:37       ` Stephen Warren
       [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF04B3279D55-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  0 siblings, 1 reply; 6+ messages in thread
From: Stephen Warren @ 2011-08-30 16:37 UTC (permalink / raw)
  To: David Gibson; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Arnaud Lacombe

David Gibson wrote at Monday, August 29, 2011 10:23 PM:
> On Tue, Aug 23, 2011 at 04:43:20PM -0600, Stephen Warren wrote:
> > 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>;
...
> > Note 2: I'd prefer the syntax of /define/ to be:
> >
> > /define/ TWO 2;
> 
> Oh goodness, yes.  The dollar signs are revolting.
> 
> > but I assume that'd cause the lexing for DT_DEFINEREF to conflict with
> > that for DT_LABEL?
> 
> Nope, the final colon should distinguish DT_LABEL.  In dts-v1 C-like
> identifiers should be lexically distinct in most contexts.  This is
> not by accident.  They could be confused with node or property names,
> but that shouldn't cause trouble.

OK, I'll take a stab at that and see.

As background, I found the following thread from 2008:

http://lists.ozlabs.org/pipermail/devicetree-discuss/2008-September/000149.html

... where Jon Loeliger was working on much more extensive new syntax,
and it sounded like you had some patches at least for math expressions
in cells etc. The conversation seemed to die off after a few weeks. Did
anything come of that; is anyone else working on e.g. at least the math
expressions and defines part, even if not the scripting stuff?

I see that a little later, Jon pushed:

http://git.jdl.com/gitweb/?p=dtc.git;a=shortlog;h=refs/heads/testing

I'm mainly asking because if /any/ of that is something that's still
useful to pursue, I might want to align this patch with some of that so
as not to preclude any of that being ported to ToT.

Thanks.

-- 
nvpublic

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: [RFC PATCH] dtc: Add support for named constants
       [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF04B3279D55-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
@ 2011-08-30 21:04           ` Paul Walmsley
       [not found]             ` <alpine.DEB.2.00.1108301459340.26173-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
  2011-08-31  3:33           ` David Gibson
  1 sibling, 1 reply; 6+ messages in thread
From: Paul Walmsley @ 2011-08-30 21:04 UTC (permalink / raw)
  To: Stephen Warren, rnayak-l0cyMroinI0, David Gibson
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Arnaud Lacombe

Hi,

On Tue, 30 Aug 2011, Stephen Warren wrote:

> David Gibson wrote at Monday, August 29, 2011 10:23 PM:
> > On Tue, Aug 23, 2011 at 04:43:20PM -0600, Stephen Warren wrote:
> > > 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>;
> ...
> > > Note 2: I'd prefer the syntax of /define/ to be:
> > >
> > > /define/ TWO 2;

Some preprocessing support would be very useful for us on OMAP, where we 
have some register bitfields that we'd like to use symbolic names for.

One question, though.  Documentation/devicetree/booting-without-of.txt[1] 
says:

   It is also suggested that you pipe your source file through cpp (gcc
   preprocessor) so you can use #include's, #define for constants, 
   etc...

Is it no longer recommended to use cpp for this purpose?


- Paul

1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/devicetree/booting-without-of.txt;h=7c1329de0596a34ce81d60f214d46a43933f05c0;hb=HEAD#l1119

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH] dtc: Add support for named constants
       [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF04B3279D55-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
  2011-08-30 21:04           ` Paul Walmsley
@ 2011-08-31  3:33           ` David Gibson
  1 sibling, 0 replies; 6+ messages in thread
From: David Gibson @ 2011-08-31  3:33 UTC (permalink / raw)
  To: Stephen Warren; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Arnaud Lacombe

On Tue, Aug 30, 2011 at 09:37:40AM -0700, Stephen Warren wrote:
> David Gibson wrote at Monday, August 29, 2011 10:23 PM:
> > On Tue, Aug 23, 2011 at 04:43:20PM -0600, Stephen Warren wrote:
> > > 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>;
> ...
> > > Note 2: I'd prefer the syntax of /define/ to be:
> > >
> > > /define/ TWO 2;
> > 
> > Oh goodness, yes.  The dollar signs are revolting.
> > 
> > > but I assume that'd cause the lexing for DT_DEFINEREF to conflict with
> > > that for DT_LABEL?
> > 
> > Nope, the final colon should distinguish DT_LABEL.  In dts-v1 C-like
> > identifiers should be lexically distinct in most contexts.  This is
> > not by accident.  They could be confused with node or property names,
> > but that shouldn't cause trouble.
> 
> OK, I'll take a stab at that and see.
> 
> As background, I found the following thread from 2008:
> 
> http://lists.ozlabs.org/pipermail/devicetree-discuss/2008-September/000149.html
> 
> ... where Jon Loeliger was working on much more extensive new syntax,
> and it sounded like you had some patches at least for math expressions
> in cells etc. The conversation seemed to die off after a few weeks. Did
> anything come of that; is anyone else working on e.g. at least the math
> expressions and defines part, even if not the scripting stuff?
> 
> I see that a little later, Jon pushed:
> 
> http://git.jdl.com/gitweb/?p=dtc.git;a=shortlog;h=refs/heads/testing
> 
> I'm mainly asking because if /any/ of that is something that's still
> useful to pursue, I might want to align this patch with some of that so
> as not to preclude any of that being ported to ToT.

Sigh, yeah.  So I think both Jon and I would really like to get rather
more comprehensive support for this sort of thing into dtc.  However,
we have somewhat different visions of how exactly it would work.  A
combination of that and lac of time to pursue it in depth lead to it
getting shelved at the time.

In the meantime the include and overlay mechanics have been introduced
which allow a limited amount of what people are askinf for in this
area.  Resurrecting that work of Jon's would, amongst other things,
require some reconsideration of how it's affected by those features.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [RFC PATCH] dtc: Add support for named constants
       [not found]             ` <alpine.DEB.2.00.1108301459340.26173-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
@ 2011-08-31  3:37               ` David Gibson
  0 siblings, 0 replies; 6+ messages in thread
From: David Gibson @ 2011-08-31  3:37 UTC (permalink / raw)
  To: Paul Walmsley; +Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Arnaud Lacombe

On Tue, Aug 30, 2011 at 03:04:08PM -0600, Paul Walmsley wrote:
> Hi,
> 
> On Tue, 30 Aug 2011, Stephen Warren wrote:
> 
> > David Gibson wrote at Monday, August 29, 2011 10:23 PM:
> > > On Tue, Aug 23, 2011 at 04:43:20PM -0600, Stephen Warren wrote:
> > > > 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>;
> > ...
> > > > Note 2: I'd prefer the syntax of /define/ to be:
> > > >
> > > > /define/ TWO 2;
> 
> Some preprocessing support would be very useful for us on OMAP, where we 
> have some register bitfields that we'd like to use symbolic names for.
> 
> One question, though.  Documentation/devicetree/booting-without-of.txt[1] 
> says:
> 
>    It is also suggested that you pipe your source file through cpp (gcc
>    preprocessor) so you can use #include's, #define for constants, 
>    etc...
> 
> Is it no longer recommended to use cpp for this purpose?

Yes and now.  I actually prefer the idea of using cpp, or at least
cpp-like processing to handle macros and the like in dts - Jon's
approach was different, instead implementing functions, of a sort, in
dtc itself.

The difficulty with cpp is that # already appears naturally as the
first character in a line in many dts files due to the #address-cells
and #size-cells properties for example.  That makes distinguishing the
cpp directives properly lexically difficult.  It will usually actually
work, with a little fiddling, but what exact fiddling is required
depends on the cpp version which makes it kind of unsuitable as a
general solution.

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-08-31  3:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-08-23 22:43 [RFC PATCH] dtc: Add support for named constants Stephen Warren
     [not found] ` <1314139400-31984-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2011-08-30  4:23   ` David Gibson
     [not found]     ` <20110830042316.GH4254-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org>
2011-08-30 16:37       ` Stephen Warren
     [not found]         ` <74CDBE0F657A3D45AFBB94109FB122FF04B3279D55-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>
2011-08-30 21:04           ` Paul Walmsley
     [not found]             ` <alpine.DEB.2.00.1108301459340.26173-rwI8Ez+7Ko+d5PgPZx9QOdBPR1lH4CV8@public.gmane.org>
2011-08-31  3:37               ` David Gibson
2011-08-31  3:33           ` David Gibson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.