* [PATCH v2 REPOST] dtc: Add support for named integer constants @ 2011-12-12 20:04 Stephen Warren [not found] ` <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Stephen Warren @ 2011-12-12 20:04 UTC (permalink / raw) To: Jon Loeliger, David Gibson; +Cc: Devicetree Discuss 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> --- I posted this back in early September. I'd like to ask again that this feature be merged into dtc; there are many situations where it'd allow .dts files to be simplified. My earlier posting was blocked by a lack of consensus on the direction of macro/expression support in dtc. I haven't seen any move to resolve this since. Can we please move forward with simple expression support; it seems to be the most immediately useful aspect of any macro/ expression support. The alternative is to either continue to suffer with unreadable integer constants, or perhaps pre-process before passing the .dts file to dtc, thus making any macro support in dtc moot. dtc-lexer.l | 13 +++++++++ dtc-parser.y | 73 +++++++++++++++++++++++++++++++++++++++++++++++++ tests/Makefile.tests | 3 +- tests/identifiers.c | 44 +++++++++++++++++++++++++++++ tests/identifiers.dts | 12 ++++++++ tests/run_tests.sh | 4 +++ 6 files changed, 148 insertions(+), 1 deletions(-) create mode 100644 tests/identifiers.c create mode 100644 tests/identifiers.dts diff --git a/dtc-lexer.l b/dtc-lexer.l index e866ea5..60a0677 100644 --- a/dtc-lexer.l +++ b/dtc-lexer.l @@ -28,6 +28,7 @@ PROPNODECHAR [a-zA-Z0-9,._+*#?@-] PATHCHAR ({PROPNODECHAR}|[/]) LABEL [a-zA-Z_][a-zA-Z0-9_]* +IDENTIFIER [a-zA-Z_][a-zA-Z0-9_]* STRING \"([^\\"]|\\.)*\" WS [[:space:]] COMMENT "/*"([^*]|\*+[^*/])*\*+"/" @@ -96,6 +97,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); @@ -103,6 +110,12 @@ static int pop_input_file(void); return DT_LABEL; } +<V1>{IDENTIFIER} { + DPRINT("identifier: %s\n", yytext); + yylval.identifier = xstrdup(yytext); + return DT_IDENTIFIER; + } + <V1>[0-9]+|0[xX][0-9a-fA-F]+ { yylval.literal = xstrdup(yytext); DPRINT("Literal: '%s'\n", yylval.literal); diff --git a/dtc-parser.y b/dtc-parser.y index 5e84a67..0558c38 100644 --- a/dtc-parser.y +++ b/dtc-parser.y @@ -33,6 +33,9 @@ extern void yyerror(char const *s); extern struct boot_info *the_boot_info; extern int treesource_error; +static struct identifier *get_identifier(const char *s); +static void set_identifier(const char *name, unsigned long long value); +static unsigned long long eval_identifier(const char *name); static unsigned long long eval_literal(const char *s, int base, int bits); %} @@ -40,6 +43,7 @@ static unsigned long long eval_literal(const char *s, int base, int bits); char *propnodename; char *literal; char *labelref; + char *identifier; unsigned int cbase; uint8_t byte; struct data data; @@ -55,7 +59,9 @@ 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 <identifier> DT_IDENTIFIER %token <literal> DT_LITERAL %token <cbase> DT_BASE %token <byte> DT_BYTE @@ -113,6 +119,13 @@ memreserve: } ; +define: + DT_DEFINE DT_IDENTIFIER cellval ';' + { + set_identifier($2, $3); + } + ; + addr: DT_LITERAL { @@ -125,6 +138,10 @@ devicetree: { $$ = name_node($2, ""); } + | define + { + $$ = name_node(build_node(NULL, NULL), ""); + } | devicetree '/' nodedef { $$ = merge_nodes($1, $3); @@ -139,6 +156,10 @@ devicetree: print_error("label or path, '%s', not found", $2); $$ = $1; } + | devicetree define + { + $$ = $1; + } ; nodedef: @@ -265,6 +286,10 @@ cellval: { $$ = eval_literal($1, 0, 32); } + | DT_IDENTIFIER + { + $$ = eval_identifier($1); + } ; bytestring: @@ -327,6 +352,54 @@ void yyerror(char const *s) { print_error("%s", s); } +struct identifier { + const char *name; + unsigned long long value; + struct identifier *next; +}; +static struct identifier *identifiers; + +static struct identifier *get_identifier(const char *name) +{ + struct identifier *identifier = identifiers; + + while (identifier != NULL) { + if (streq(name, identifier->name)) + return identifier; + identifier = identifier->next; + } + + return NULL; +} + +static void set_identifier(const char *name, unsigned long long value) +{ + struct identifier *identifier; + + if (get_identifier(name) != NULL) { + print_error("redefining %s", name); + return; + } + + identifier = xmalloc(sizeof(*identifier)); + identifier->name = name; + identifier->value = value; + identifier->next = identifiers; + identifiers = identifier; +} + +unsigned long long eval_identifier(const char *name) +{ + struct identifier *identifier = get_identifier(name); + + if (identifier == NULL) { + print_error("identifier %s does not exist", name); + return 0; + } + + return identifier->value; +} + static unsigned long long eval_literal(const char *s, int base, int bits) { unsigned long long val; diff --git a/tests/Makefile.tests b/tests/Makefile.tests index c564e72..25d2e3c 100644 --- a/tests/Makefile.tests +++ b/tests/Makefile.tests @@ -15,7 +15,8 @@ LIB_TESTS_L = get_mem_rsv \ extra-terminating-null \ dtbs_equal_ordered \ dtb_reverse dtbs_equal_unordered \ - add_subnode_with_nops path_offset_aliases + add_subnode_with_nops path_offset_aliases \ + identifiers LIB_TESTS = $(LIB_TESTS_L:%=$(TESTS_PREFIX)%) LIBTREE_TESTS_L = truncated_property diff --git a/tests/identifiers.c b/tests/identifiers.c new file mode 100644 index 0000000..a013d00 --- /dev/null +++ b/tests/identifiers.c @@ -0,0 +1,44 @@ +/* + * libfdt - Flat Device Tree manipulation + * Testcase for /define/ + * Copyright (C) 2011 NVIDIA, Inc. + * Derived from code: + * Copyright (C) 2006 David Gibson, IBM Corporation. + * + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public License + * as published by the Free Software Foundation; either version 2.1 of + * the License, or (at your option) any later version. + * + * This library is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with this library; if not, write to the Free Software + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + */ +#include <stdlib.h> +#include <stdio.h> +#include <string.h> +#include <stdint.h> + +#include <fdt.h> +#include <libfdt.h> + +#include "tests.h" +#include "testdata.h" + +int main(int argc, char *argv[]) +{ + void *fdt; + + test_init(argc, argv); + fdt = load_blob_arg(argc, argv); + + check_property_cell(fdt, 0, "var1", TEST_VALUE_1); + check_property_cell(fdt, 0, "var2", TEST_VALUE_1); + + PASS(); +} diff --git a/tests/identifiers.dts b/tests/identifiers.dts new file mode 100644 index 0000000..e8d8e23 --- /dev/null +++ b/tests/identifiers.dts @@ -0,0 +1,12 @@ +/dts-v1/; + +/define/ VAR1 0xdeadbeef; +/define/ VAR2 VAR1; + +/ { + var1 = <VAR1>; + var2 = <VAR2>; +}; + +/define/ OTHER 0xdeadbeef; + diff --git a/tests/run_tests.sh b/tests/run_tests.sh index 72dda32..e0da087 100755 --- a/tests/run_tests.sh +++ b/tests/run_tests.sh @@ -343,6 +343,10 @@ dtc_tests () { run_dtc_test -I dtb -O dts -o stdin_odts_test_tree1.dtb.test.dts - < test_tree1.dtb run_wrap_test cmp stdin_odts_test_tree1.dtb.test.dts odts_test_tree1.dtb.test.dts + # Test identifiers + run_dtc_test -I dts -O dtb -o identifiers.dtb identifiers.dts + run_test identifiers identifiers.dtb + # Check for graceful failure in some error conditions run_sh_test dtc-fatal.sh -I dts -O dtb nosuchfile.dts run_sh_test dtc-fatal.sh -I dtb -O dtb nosuchfile.dtb -- 1.7.0.4 ^ permalink raw reply related [flat|nested] 16+ messages in thread
[parent not found: <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> @ 2011-12-12 20:19 ` Simon Glass [not found] ` <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Simon Glass @ 2011-12-12 20:19 UTC (permalink / raw) To: Stephen Warren; +Cc: Devicetree Discuss Hi Stephen, On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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> > --- > I posted this back in early September. I'd like to ask again that this > feature be merged into dtc; there are many situations where it'd allow > .dts files to be simplified. Yes I agree, it is very useful. I get conflicts with this - does it need a rebase? Regards, Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2011-12-12 20:23 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Stephen Warren @ 2011-12-12 20:23 UTC (permalink / raw) To: Simon Glass; +Cc: Devicetree Discuss Simon Glass wrote at Monday, December 12, 2011 1:19 PM: > On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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> > > --- > > I posted this back in early September. I'd like to ask again that this > > feature be merged into dtc; there are many situations where it'd allow > > .dts files to be simplified. > > Yes I agree, it is very useful. > > I get conflicts with this - does it need a rebase? Yes, I should have mentioned this patch is still based on the same commit it was 3 months ago, and HEAD has moved forward since. If it's deemed conceptually acceptable, I'll rebase it to HEAD. (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".) -- nvpublic ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> @ 2012-01-04 0:46 ` Simon Glass [not found] ` <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Simon Glass @ 2012-01-04 0:46 UTC (permalink / raw) To: Stephen Warren; +Cc: Devicetree Discuss Hi Stephen, On Mon, Dec 12, 2011 at 12:23 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > Simon Glass wrote at Monday, December 12, 2011 1:19 PM: >> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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> >> > --- >> > I posted this back in early September. I'd like to ask again that this >> > feature be merged into dtc; there are many situations where it'd allow >> > .dts files to be simplified. >> >> Yes I agree, it is very useful. >> >> I get conflicts with this - does it need a rebase? > > Yes, I should have mentioned this patch is still based on the same commit > it was 3 months ago, and HEAD has moved forward since. If it's deemed > conceptually acceptable, I'll rebase it to HEAD. > > (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".) > > -- > nvpublic > I haven't seen any other comments. Is this going in? Constants would be useful. Regards, Simon ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2012-01-05 21:27 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Stephen Warren @ 2012-01-05 21:27 UTC (permalink / raw) To: Simon Glass, Jon Loeliger, David Gibson; +Cc: Devicetree Discuss Simon Glass wrote at Tuesday, January 03, 2012 5:46 PM: > On Mon, Dec 12, 2011 at 12:23 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > > Simon Glass wrote at Monday, December 12, 2011 1:19 PM: > >> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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> > >> > --- > >> > I posted this back in early September. I'd like to ask again that this > >> > feature be merged into dtc; there are many situations where it'd allow > >> > .dts files to be simplified. > >> > >> Yes I agree, it is very useful. > >> > >> I get conflicts with this - does it need a rebase? > > > > Yes, I should have mentioned this patch is still based on the same commit > > it was 3 months ago, and HEAD has moved forward since. If it's deemed > > conceptually acceptable, I'll rebase it to HEAD. > > > > (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".) > > I haven't seen any other comments. Is this going in? Constants would be useful. I took a quick look at rebasing this on HEAD today. There are some non- trivial conflicts with Anton's recent patch to support variable-sized elements in arrays. In particular, my patch relied on the cellval token, allowing it to reference a symbol or a literal, but Anton's patch has removed that token from the grammar. So, I'm still willing to rebase my patch, but given the non-trivial nature of doing so, I'd like prior confirmation from Jon and David that the syntax is acceptable, and so my work won't be in vain. For reference, here's the test .dts file from my patch: +/dts-v1/; + +/define/ VAR1 0xdeadbeef; +/define/ VAR2 VAR1; + +/ { + var1 = <VAR1>; + var2 = <VAR2>; +}; + +/define/ OTHER 0xdeadbeef; -- nvpublic ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>]
* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> @ 2012-01-10 21:54 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Stephen Warren @ 2012-01-10 21:54 UTC (permalink / raw) To: Simon Glass, Jon Loeliger, David Gibson; +Cc: Devicetree Discuss John, David, What can we do to reach consensus on expanding dtc to handle named constants, or in general any future direction to extend the syntax with expressions etc.? Will either of you be attending Linaro Connect or ELC 2012 in February by any chance? We could get together and talk this through in person if you are... Thanks for any kind of discussion! Stephen Warren wrote at Thursday, January 05, 2012 2:27 PM: > Simon Glass wrote at Tuesday, January 03, 2012 5:46 PM: > > On Mon, Dec 12, 2011 at 12:23 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote: > > > Simon Glass wrote at Monday, December 12, 2011 1:19 PM: > > >> On Mon, Dec 12, 2011 at 12:04 PM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 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> > > >> > --- > > >> > I posted this back in early September. I'd like to ask again that this > > >> > feature be merged into dtc; there are many situations where it'd allow > > >> > .dts files to be simplified. > > >> > > >> Yes I agree, it is very useful. > > >> > > >> I get conflicts with this - does it need a rebase? > > > > > > Yes, I should have mentioned this patch is still based on the same commit > > > it was 3 months ago, and HEAD has moved forward since. If it's deemed > > > conceptually acceptable, I'll rebase it to HEAD. > > > > > > (For reference, it's based on ed8fee1 "Add missing tests to .gitignore".) > > > > I haven't seen any other comments. Is this going in? Constants would be useful. > > I took a quick look at rebasing this on HEAD today. There are some non- > trivial conflicts with Anton's recent patch to support variable-sized > elements in arrays. In particular, my patch relied on the cellval token, > allowing it to reference a symbol or a literal, but Anton's patch has > removed that token from the grammar. > > So, I'm still willing to rebase my patch, but given the non-trivial nature > of doing so, I'd like prior confirmation from Jon and David that the syntax > is acceptable, and so my work won't be in vain. > > For reference, here's the test .dts file from my patch: > > +/dts-v1/; > + > +/define/ VAR1 0xdeadbeef; > +/define/ VAR2 VAR1; > + > +/ { > + var1 = <VAR1>; > + var2 = <VAR2>; > +}; > + > +/define/ OTHER 0xdeadbeef; -- nvpublic ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> @ 2012-01-11 13:00 ` David Gibson [not found] ` <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: David Gibson @ 2012-01-11 13:00 UTC (permalink / raw) To: Stephen Warren; +Cc: Devicetree Discuss On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: > John, David, > > What can we do to reach consensus on expanding dtc to handle named > constants, or in general any future direction to extend the syntax with > expressions etc.? Hrm, so, I'm not at all keen to add a named constant syntax without at least having an outline of what a future macro/function syntax would look like. The latter is almost certain to permit the former as a subcase, and I'd really rather not end up with two different syntaxes for constants. Unfortunately, much as I'd like to get all these extended features into dtc, it's not my main job, so I don't have a lot of time to ponder the possibilities. > Will either of you be attending Linaro Connect or ELC 2012 in February > by any chance? We could get together and talk this through in person if > you are... Not for me, I'm afraid. -- 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] 16+ messages in thread
[parent not found: <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org> @ 2012-01-11 14:38 ` Jon Loeliger [not found] ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Jon Loeliger @ 2012-01-11 14:38 UTC (permalink / raw) To: David Gibson; +Cc: Devicetree Discuss > On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: > > John, David, > > > > What can we do to reach consensus on expanding dtc to handle named > > constants, or in general any future direction to extend the syntax with > > expressions etc.? > > Hrm, so, I'm not at all keen to add a named constant syntax without at > least having an outline of what a future macro/function syntax would > look like. Which is where I thought it was left earlier...? :-) And it's not just what the macro/function syntax will look like, but also how these will play into a more generalized expression handling mechanism. Defining something one-off now that doesn't fit well into a long term plan is less than ideal. Yes, I know that is tantamount to requiring the whole, larger picture be solved first. But Dave is right -- at least an outline of the direction. Seriously, the lexical problems can form some of the nastiest gotchas if we're not careful from the onset. > The latter is almost certain to permit the former as a subcase, and > I'd really rather not end up with two different syntaxes for > constants. Exactly. > Unfortunately, much as I'd like to get all these extended features > into dtc, Agreed.... > > Will either of you be attending Linaro Connect or ELC 2012 in February > > by any chance? We could get together and talk this through in person if > > you are... > > Not for me, I'm afraid. Only if they are in Austin. :-) Which is to say "Sorry, no." jdl ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org>]
* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org> @ 2012-01-11 21:36 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2012-01-11 22:10 ` David VomLehn (dvomlehn) 1 sibling, 1 reply; 16+ messages in thread From: Stephen Warren @ 2012-01-11 21:36 UTC (permalink / raw) To: Jon Loeliger, David Gibson; +Cc: Devicetree Discuss Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM: > > On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: > > > John, David, > > > > > > What can we do to reach consensus on expanding dtc to handle named > > > constants, or in general any future direction to extend the syntax with > > > expressions etc.? > > > > Hrm, so, I'm not at all keen to add a named constant syntax without at > > least having an outline of what a future macro/function syntax would > > look like. > > Which is where I thought it was left earlier...? :-) > And it's not just what the macro/function syntax will look like, > but also how these will play into a more generalized expression > handling mechanism. Defining something one-off now that doesn't > fit well into a long term plan is less than ideal. > > Yes, I know that is tantamount to requiring the whole, larger > picture be solved first. But Dave is right -- at least an outline > of the direction. Seriously, the lexical problems can form some > of the nastiest gotchas if we're not careful from the onset. So that all makes sense. My question is: How can we get consensus on what we want that complete future syntax to be? IIRC, Jon has a branch that implements a proposal, and David at least posted a different proposal if not actual code that implemented it. We're not missing proposals, but rather a mechanism to decide between them? For what it's worth, I'd tend towards a simple expression-based syntax where property values can be calculated with C-style expressions. Basic math stuff like ( ) + - * / & | ~ << >> and some basic string handling operations (str(int) and concatenation). I think that'd cover the vast majority of use-cases wouldn't it? For more advanced stuff like loops to synthesize multiple nodes, it seems like writing a custom script to generate the .dts file and then passing the result to dtc would be more modular, and not require us to create a whole new Turing-complete language in dtc? -- nvpublic ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> @ 2012-01-12 0:05 ` Mitch Bradley [not found] ` <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2012-01-16 1:54 ` David Gibson 1 sibling, 1 reply; 16+ messages in thread From: Mitch Bradley @ 2012-01-12 0:05 UTC (permalink / raw) To: Stephen Warren; +Cc: Devicetree Discuss I find it ironic that the very first device tree implementation, dating back to 1989, was built around a Turing complete language. On 1/11/2012 11:36 AM, Stephen Warren wrote: > Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM: >>> On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: >>>> John, David, >>>> >>>> What can we do to reach consensus on expanding dtc to handle named >>>> constants, or in general any future direction to extend the syntax with >>>> expressions etc.? >>> >>> Hrm, so, I'm not at all keen to add a named constant syntax without at >>> least having an outline of what a future macro/function syntax would >>> look like. >> >> Which is where I thought it was left earlier...? :-) >> And it's not just what the macro/function syntax will look like, >> but also how these will play into a more generalized expression >> handling mechanism. Defining something one-off now that doesn't >> fit well into a long term plan is less than ideal. >> >> Yes, I know that is tantamount to requiring the whole, larger >> picture be solved first. But Dave is right -- at least an outline >> of the direction. Seriously, the lexical problems can form some >> of the nastiest gotchas if we're not careful from the onset. > > So that all makes sense. > > My question is: How can we get consensus on what we want that complete > future syntax to be? IIRC, Jon has a branch that implements a proposal, > and David at least posted a different proposal if not actual code that > implemented it. We're not missing proposals, but rather a mechanism to > decide between them? > > For what it's worth, I'd tend towards a simple expression-based syntax > where property values can be calculated with C-style expressions. Basic > math stuff like ( ) + - * /& | ~<< >> and some basic string handling > operations (str(int) and concatenation). I think that'd cover the vast > majority of use-cases wouldn't it? For more advanced stuff like loops > to synthesize multiple nodes, it seems like writing a custom script to > generate the .dts file and then passing the result to dtc would be more > modular, and not require us to create a whole new Turing-complete > language in dtc? > ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> @ 2012-01-12 14:11 ` Jon Loeliger 0 siblings, 0 replies; 16+ messages in thread From: Jon Loeliger @ 2012-01-12 14:11 UTC (permalink / raw) To: Mitch Bradley; +Cc: Devicetree Discuss > I find it ironic that the very first device tree implementation, dating > back to 1989, was built around a Turing complete language. ...and that my uncle wrote one of the very first books about that language. :-) jdl ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2012-01-12 0:05 ` Mitch Bradley @ 2012-01-16 1:54 ` David Gibson [not found] ` <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org> 1 sibling, 1 reply; 16+ messages in thread From: David Gibson @ 2012-01-16 1:54 UTC (permalink / raw) To: Stephen Warren; +Cc: Devicetree Discuss On Wed, Jan 11, 2012 at 01:36:46PM -0800, Stephen Warren wrote: > Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM: > > > On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: > > > > John, David, > > > > > > > > What can we do to reach consensus on expanding dtc to handle named > > > > constants, or in general any future direction to extend the syntax with > > > > expressions etc.? > > > > > > Hrm, so, I'm not at all keen to add a named constant syntax without at > > > least having an outline of what a future macro/function syntax would > > > look like. > > > > Which is where I thought it was left earlier...? :-) > > And it's not just what the macro/function syntax will look like, > > but also how these will play into a more generalized expression > > handling mechanism. Defining something one-off now that doesn't > > fit well into a long term plan is less than ideal. > > > > Yes, I know that is tantamount to requiring the whole, larger > > picture be solved first. But Dave is right -- at least an outline > > of the direction. Seriously, the lexical problems can form some > > of the nastiest gotchas if we're not careful from the onset. > > So that all makes sense. > > My question is: How can we get consensus on what we want that complete > future syntax to be? Um.. try to make a detailed proposal (synthesised from earlier ones) that enough people are happy with (Jon and myself for starters). > IIRC, Jon has a branch that implements a proposal, > and David at least posted a different proposal if not actual code that > implemented it. We're not missing proposals, but rather a mechanism to > decide between them? Well.. that's not entirely true. The proposed expression syntax was essentially identical between Jon's proposal and mine (though the implementation of it is quite different). Jon's proposal includes loops and "functions", mine started with just expressions. I had in mind some sort of macro language to allow making use of those expressions. I'm not sure quite what that would look like (or even if it would be implemented withing dtc, or use an external helper like cpp). So there's really only one proposal that covers the full space, it's just I don't like it that much. > For what it's worth, I'd tend towards a simple expression-based syntax > where property values can be calculated with C-style expressions. Basic > math stuff like ( ) + - * / & | ~ << >> and some basic string handling > operations (str(int) and concatenation). Ok. Well, I should de-bitrot and re-propose my integer expression patch, which covered most of that. I also intended basic string operations as you suggest, though I can't remember if I made a start on that. I think applying that would be reasonably safe as it is. If we go with Jon's proposal or something like it in the end, we'll need to reimplement most of the expression evaluation (to do delayed instead of parse-time evaluation). But I'm much less worried about having to rework code - even substantially - than I am about user-visible syntax regressions. > I think that'd cover the vast > majority of use-cases wouldn't it? Not quite. Expressions are interesting of themselves, but not all that useful. It's functions or macros plus expressions which gets us close to where we want to be. So expressions gives a little as it is, a lot more for people already running their dts through cpp. To really make progress, we still want a proposal for a standard function or macro syntax for dtc. And, obviously, a decision whether to go with functions or macros. I like macros, because I think they give a lot of flexibility with minimal conceptual complexity. Jon's proposal is based on functions. I didn't like his proposal very much as a whole, but I should take another look and see what I think of the function syntax in isolation. > For more advanced stuff like loops > to synthesize multiple nodes, it seems like writing a custom script to > generate the .dts file and then passing the result to dtc would be more > modular, and not require us to create a whole new Turing-complete > language in dtc? Perhaps. One of the reasons that I'm so doggedly conservative and picky about new dtc syntax is that small languages have a tendency to grow to Turing completeness, whether you intend it originally or not. I'm ok with that happening, but I'd really like to make sure that when and if it happens, we arrive at a decent Turing complete language, not a horrible one. -- 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] 16+ messages in thread
[parent not found: <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org> @ 2012-01-16 14:41 ` Jon Loeliger [not found] ` <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org> 0 siblings, 1 reply; 16+ messages in thread From: Jon Loeliger @ 2012-01-16 14:41 UTC (permalink / raw) To: David Gibson; +Cc: Devicetree Discuss > > > For what it's worth, I'd tend towards a simple expression-based syntax > > where property values can be calculated with C-style expressions. Basic > > math stuff like ( ) + - * / & | ~ << >> and some basic string handling > > operations (str(int) and concatenation). > > ... > > I think applying that would be reasonably safe as it is. If we go > with Jon's proposal or something like it in the end, we'll need to > reimplement most of the expression evaluation (to do delayed instead > of parse-time evaluation). But I'm much less worried about having to > rework code - even substantially - than I am about user-visible syntax > regressions. Even with that piece, there are substanial lexical and parsing issues that complicate things. Bare numbers, or expressions, next to each other without syntactic glue can cause parsing fits. :-) > > I think that'd cover the vast > > majority of use-cases wouldn't it? > > Not quite. Expressions are interesting of themselves, but not all > that useful. It's functions or macros plus expressions which gets us > close to where we want to be. So expressions gives a little as it is, That's the difficult and slippery slope here. Being able to write (FOO << (12 + 2)) is nice, but it would be nicer and more useful to represent (FOO << ((i) + 2)) where (i) was actually parameterized or iterated in some way. > a lot more for people already running their dts through cpp. To > really make progress, we still want a proposal for a standard function > or macro syntax for dtc. And, obviously, a decision whether to go > with functions or macros. I like macros, because I think they give a > lot of flexibility with minimal conceptual complexity. Jon's proposal > is based on functions. I didn't like his proposal very much as a > whole, but I should take another look and see what I think of the > function syntax in isolation. It might also be instructive to isolate my expression parsing for its lexical and syntactic changes and work towards introducing those, perhaps in isolation, as a first step. The key there WRT your interest, Stephen, is that it can capture the use of apparent variables or #define'd-equivalent symbols within the expression handling. (David's version did not.) > > For more advanced stuff like loops to synthesize multiple nodes, it > > seems like writing a custom script to generate the .dts file and > > then passing the result to dtc would be more modular, and not > > require us to create a whole new Turing-complete language in dtc? > > Perhaps. OK. Let's explore that approach. We'll write a, say, Python collection of code-objects for each, what?, device. Place them all in a large library. Your "device tree source" effectively now becomes a "main" that starts instantiating librarified devices, adding a litle glue to emit some one-off property or two. That could work. But is it now OK that the construction of the device tree source file is tied to Python? Do we make the kernel builds now reliant upon Python too? Or Perl? But wasn't that shot down *again*? Hans wants shell. Lotte likes Lua. Suki plays with Python. Willi is happy again. Adolf builds his DTS with Perl. No one uses Tcl. Everyone just checks-in their *generated* DTS results anyway. It'll be a war without tears. Or how do you see this working? > .. One of the reasons that I'm so doggedly conservative and > picky about new dtc syntax is that small languages have a tendency to > grow to Turing completeness, whether you intend it originally or not. Isn't that someone's observation...? Behind every flat-file there is a Turing-complete language trying to get out. > I'm ok with that happening, but I'd really like to make sure that when > and if it happens, we arrive at a decent Turing complete language, not > a horrible one. Name two decent ones. :-) C and ..., and .... See? There isn't another! Never mind. jdl ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org> @ 2012-01-21 21:56 ` David Gibson 0 siblings, 0 replies; 16+ messages in thread From: David Gibson @ 2012-01-21 21:56 UTC (permalink / raw) To: Jon Loeliger; +Cc: Devicetree Discuss On Mon, Jan 16, 2012 at 08:41:22AM -0600, Jon Loeliger wrote: > > > > > For what it's worth, I'd tend towards a simple expression-based syntax > > > where property values can be calculated with C-style expressions. Basic > > > math stuff like ( ) + - * / & | ~ << >> and some basic string handling > > > operations (str(int) and concatenation). > > > > ... > > > > I think applying that would be reasonably safe as it is. If we go > > with Jon's proposal or something like it in the end, we'll need to > > reimplement most of the expression evaluation (to do delayed instead > > of parse-time evaluation). But I'm much less worried about having to > > rework code - even substantially - than I am about user-visible syntax > > regressions. > > Even with that piece, there are substanial lexical and parsing > issues that complicate things. Bare numbers, or expressions, > next to each other without syntactic glue can cause parsing fits. :-) Well, my patch requires that expressions in cell lists have parens around them. I think that's the only sane choice, otherwise there's no reasonable way to distinguish between the 1 cell construct <(500-300)> and the 2 cell construct <500 (-300)>. > > > I think that'd cover the vast > > > majority of use-cases wouldn't it? > > > > Not quite. Expressions are interesting of themselves, but not all > > that useful. It's functions or macros plus expressions which gets us > > close to where we want to be. So expressions gives a little as it is, > > That's the difficult and slippery slope here. Being able to write > (FOO << (12 + 2)) > is nice, but it would be nicer and more useful to represent > (FOO << ((i) + 2)) > where (i) was actually parameterized or iterated in some way. Right, exactly my point. > > a lot more for people already running their dts through cpp. To > > really make progress, we still want a proposal for a standard function > > or macro syntax for dtc. And, obviously, a decision whether to go > > with functions or macros. I like macros, because I think they give a > > lot of flexibility with minimal conceptual complexity. Jon's proposal > > is based on functions. I didn't like his proposal very much as a > > whole, but I should take another look and see what I think of the > > function syntax in isolation. > > It might also be instructive to isolate my expression parsing > for its lexical and syntactic changes and work towards introducing > those, perhaps in isolation, as a first step. Right. I think my expression code and your expression code were essentially identical syntactically (possibly modulo a slightly different set of implemented operators). > The key there WRT your interest, Stephen, is that it can capture > the use of apparent variables or #define'd-equivalent symbols within > the expression handling. (David's version did not.) True, but constant definitions (as opposed to function definitions) would be trivial to add to my code. > > > For more advanced stuff like loops to synthesize multiple nodes, it > > > seems like writing a custom script to generate the .dts file and > > > then passing the result to dtc would be more modular, and not > > > require us to create a whole new Turing-complete language in dtc? > > > > Perhaps. > > OK. Let's explore that approach. We'll write a, say, Python collection > of code-objects for each, what?, device. Place them all in a large library. > Your "device tree source" effectively now becomes a "main" that starts > instantiating librarified devices, adding a litle glue to emit some > one-off property or two. > > That could work. But is it now OK that the construction of the device > tree source file is tied to Python? Do we make the kernel builds now > reliant upon Python too? Or Perl? But wasn't that shot down *again*? > Hans wants shell. Lotte likes Lua. Suki plays with Python. Willi > is happy again. Adolf builds his DTS with Perl. No one uses Tcl. > Everyone just checks-in their *generated* DTS results anyway. It'll > be a war without tears. > > Or how do you see this working? > > > .. One of the reasons that I'm so doggedly conservative and > > picky about new dtc syntax is that small languages have a tendency to > > grow to Turing completeness, whether you intend it originally or not. > > Isn't that someone's observation...? Behind every flat-file there is > a Turing-complete language trying to get out. > > > I'm ok with that happening, but I'd really like to make sure that when > > and if it happens, we arrive at a decent Turing complete language, not > > a horrible one. > > Name two decent ones. :-) C and ..., and .... See? There isn't another! > > Never mind. > > jdl > -- 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] 16+ messages in thread
* RE: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org> 2012-01-11 21:36 ` Stephen Warren @ 2012-01-11 22:10 ` David VomLehn (dvomlehn) [not found] ` <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org> 1 sibling, 1 reply; 16+ messages in thread From: David VomLehn (dvomlehn) @ 2012-01-11 22:10 UTC (permalink / raw) To: Jon Loeliger, David Gibson; +Cc: Devicetree Discuss Even if everyone can't make it, how about a BoF session at ELC 2012? I haven't had any time to contribute recently, but am tremendously interested in moving this forward. > -----Original Message----- > From: devicetree-discuss-bounces+dvomlehn=cisco.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org > [mailto:devicetree-discuss-bounces+dvomlehn=cisco.com-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org] > On Behalf Of Jon Loeliger > Sent: Wednesday, January 11, 2012 6:38 AM > To: David Gibson > Cc: Devicetree Discuss > Subject: Re: [PATCH v2 REPOST] dtc: Add support for named integer > constants > > > On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote: > > > John, David, > > > > > > What can we do to reach consensus on expanding dtc to handle named > > > constants, or in general any future direction to extend the syntax > with > > > expressions etc.? > > > > Hrm, so, I'm not at all keen to add a named constant syntax without > at > > least having an outline of what a future macro/function syntax would > > look like. > > Which is where I thought it was left earlier...? :-) > And it's not just what the macro/function syntax will look like, > but also how these will play into a more generalized expression > handling mechanism. Defining something one-off now that doesn't > fit well into a long term plan is less than ideal. > > Yes, I know that is tantamount to requiring the whole, larger > picture be solved first. But Dave is right -- at least an outline > of the direction. Seriously, the lexical problems can form some > of the nastiest gotchas if we're not careful from the onset. > > > The latter is almost certain to permit the former as a subcase, and > > I'd really rather not end up with two different syntaxes for > > constants. > > Exactly. > > > Unfortunately, much as I'd like to get all these extended features > > into dtc, > > Agreed.... > > > > Will either of you be attending Linaro Connect or ELC 2012 in > February > > > by any chance? We could get together and talk this through in > person if > > > you are... > > > > Not for me, I'm afraid. > > Only if they are in Austin. :-) Which is to say "Sorry, no." > > jdl > _______________________________________________ > devicetree-discuss mailing list > devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org > https://lists.ozlabs.org/listinfo/devicetree-discuss ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org>]
* Re: [PATCH v2 REPOST] dtc: Add support for named integer constants [not found] ` <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org> @ 2012-01-13 7:00 ` Shawn Guo 0 siblings, 0 replies; 16+ messages in thread From: Shawn Guo @ 2012-01-13 7:00 UTC (permalink / raw) To: David VomLehn (dvomlehn); +Cc: Devicetree Discuss On Wed, Jan 11, 2012 at 04:10:52PM -0600, David VomLehn (dvomlehn) wrote: > Even if everyone can't make it, how about a BoF session at ELC 2012? I > haven't had any time to contribute recently, but am tremendously > interested in moving this forward. > +1 We've been wanting this support for long time. -- Regards, Shawn ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2012-01-21 21:56 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-12 20:04 [PATCH v2 REPOST] dtc: Add support for named integer constants Stephen Warren [not found] ` <1323720257-23847-1-git-send-email-swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> 2011-12-12 20:19 ` Simon Glass [not found] ` <CAPnjgZ3Rnbu6qZponnbQ8bRgABb-58HG-yYSxRu2FZfvwPnMJw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2011-12-12 20:23 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF1751860874-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2012-01-04 0:46 ` Simon Glass [not found] ` <CAPnjgZ19s-O2m3CnrfSNLhg4hA61kKiwFym7pOTZ=C7kG+SVbA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-01-05 21:27 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF17761F17D5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2012-01-10 21:54 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A52D-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2012-01-11 13:00 ` David Gibson [not found] ` <20120111130056.GK4935-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org> 2012-01-11 14:38 ` Jon Loeliger [not found] ` <E1RkzJs-000590-4s-CYoMK+44s/E@public.gmane.org> 2012-01-11 21:36 ` Stephen Warren [not found] ` <74CDBE0F657A3D45AFBB94109FB122FF177EE3A7A5-C7FfzLzN0UxDw2glCA4ptUEOCMrvLtNR@public.gmane.org> 2012-01-12 0:05 ` Mitch Bradley [not found] ` <4F0E23C8.8030009-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> 2012-01-12 14:11 ` Jon Loeliger 2012-01-16 1:54 ` David Gibson [not found] ` <20120116015421.GC4512-MK4v0fQdeXQXU02nzanrWNbf9cGiqdzd@public.gmane.org> 2012-01-16 14:41 ` Jon Loeliger [not found] ` <E1RmnkQ-0006W9-OT-CYoMK+44s/E@public.gmane.org> 2012-01-21 21:56 ` David Gibson 2012-01-11 22:10 ` David VomLehn (dvomlehn) [not found] ` <7A9214B0DEB2074FBCA688B30B04400D03AD6CD4-2KNrN6/GZtCQwNoRDPPJJaBKnGwkPULj@public.gmane.org> 2012-01-13 7:00 ` Shawn Guo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).