Re: [PATCH 2/3] dtc: import latest upstream dtc

[Kim Phillips]

On Tue, 26 Feb 2013 21:08:06 -0600
Rob Landley  wrote:

> On 02/26/2013 07:36:14 PM, Kim Phillips wrote:
> > This updates scripts/dtc to upstream dtc commit 27cdc1b
> 
> There's an upstream for dts?

dtc - the device tree compiler, yes.

> > "Added license header to dtc/libfdt/fdt.h and libfdt_env.h"
> > from git://git.jdl.com/software/dtc.git.
> 
> That git repository has a Documentation directory with for example  
> "dts-format.txt" in it. My current linux git repository does not  
> contain a file called dts-format.txt.

this patch isn't attempting to update dts-format.txt, or any other
file that exists in the upstream dtc project that isn't present -
and used - in the kernel.  The purpose of this patch is to update
libfdt, which has in-kernel users.

Kim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] dtc: import latest upstream dtc

[Kim Phillips]

On Tue, 26 Feb 2013 21:08:06 -0600
Rob Landley r...@landley.net wrote:

 On 02/26/2013 07:36:14 PM, Kim Phillips wrote:
  This updates scripts/dtc to upstream dtc commit 27cdc1b
 
 There's an upstream for dts?

dtc - the device tree compiler, yes.

  Added license header to dtc/libfdt/fdt.h and libfdt_env.h
  from git://git.jdl.com/software/dtc.git.
 
 That git repository has a Documentation directory with for example  
 dts-format.txt in it. My current linux git repository does not  
 contain a file called dts-format.txt.

this patch isn't attempting to update dts-format.txt, or any other
file that exists in the upstream dtc project that isn't present -
and used - in the kernel.  The purpose of this patch is to update
libfdt, which has in-kernel users.

Kim

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] dtc: import latest upstream dtc

[Rob Landley]

On 02/26/2013 07:36:14 PM, Kim Phillips wrote:

This updates scripts/dtc to upstream dtc commit 27cdc1b


There's an upstream for dts?


"Added license header to dtc/libfdt/fdt.h and libfdt_env.h"
from git://git.jdl.com/software/dtc.git.


That git repository has a Documentation directory with for example  
"dts-format.txt" in it. My current linux git repository does not  
contain a file called dts-format.txt.


Ummm... huh?

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] dtc: import latest upstream dtc

[Kim Phillips]

This updates scripts/dtc to upstream dtc commit 27cdc1b
"Added license header to dtc/libfdt/fdt.h and libfdt_env.h"
from git://git.jdl.com/software/dtc.git.

Signed-off-by: Kim Phillips 
---
 scripts/dtc/dtc.c   |   3 --
 scripts/dtc/fdtdump.c   |  29 +--
 scripts/dtc/libfdt/fdt.c|   2 +-
 scripts/dtc/libfdt/fdt.h|  93 +++
 scripts/dtc/libfdt/fdt_ro.c |   7 ++-
 scripts/dtc/libfdt/fdt_rw.c |   4 +-
 scripts/dtc/libfdt/fdt_sw.c |   4 +-
 scripts/dtc/libfdt/fdt_wip.c|   2 +-
 scripts/dtc/libfdt/libfdt.h |  48 ---
 scripts/dtc/libfdt/libfdt_env.h | 104 +++-
 scripts/dtc/srcpos.c|   6 +--
 scripts/dtc/util.c  |  57 +++---
 scripts/dtc/util.h  |  22 +++--
 13 files changed, 279 insertions(+), 102 deletions(-)

diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index a375683..d40e220 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -201,9 +201,6 @@ int main(int argc, char *argv[])
if (minsize && padsize)
die("Can't set both -p and -S\n");
 
-   if (minsize)
-   fprintf(stderr, "DTC: Use of \"-S\" is deprecated; it will be 
removed soon, use \"-p\" instead\n");
-
if (depname) {
depfile = fopen(depname, "w");
if (!depfile)
diff --git a/scripts/dtc/fdtdump.c b/scripts/dtc/fdtdump.c
index 207a46d..03ea429 100644
--- a/scripts/dtc/fdtdump.c
+++ b/scripts/dtc/fdtdump.c
@@ -8,8 +8,8 @@
 #include 
 #include 
 
-#include 
 #include 
+#include 
 
 #include "util.h"
 
@@ -17,31 +17,6 @@
 #define PALIGN(p, a)   ((void *)(ALIGN((unsigned long)(p), (a
 #define GET_CELL(p)(p += 4, *((const uint32_t *)(p-4)))
 
-static void print_data(const char *data, int len)
-{
-   int i;
-   const char *p = data;
-
-   /* no data, don't print */
-   if (len == 0)
-   return;
-
-   if (util_is_printable_string(data, len)) {
-   printf(" = \"%s\"", (const char *)data);
-   } else if ((len % 4) == 0) {
-   printf(" = <");
-   for (i = 0; i < len; i += 4)
-   printf("0x%08x%s", fdt32_to_cpu(GET_CELL(p)),
-  i < (len - 4) ? " " : "");
-   printf(">");
-   } else {
-   printf(" = [");
-   for (i = 0; i < len; i++)
-   printf("%02x%s", *p++, i < len - 1 ? " " : "");
-   printf("]");
-   }
-}
-
 static void dump_blob(void *blob)
 {
struct fdt_header *bph = blob;
@@ -137,7 +112,7 @@ static void dump_blob(void *blob)
p = PALIGN(p + sz, 4);
 
printf("%*s%s", depth * shift, "", s);
-   print_data(t, sz);
+   utilfdt_print_data(t, sz);
printf(";\n");
}
 }
diff --git a/scripts/dtc/libfdt/fdt.c b/scripts/dtc/libfdt/fdt.c
index e56833a..57faba3 100644
--- a/scripts/dtc/libfdt/fdt.c
+++ b/scripts/dtc/libfdt/fdt.c
@@ -92,7 +92,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, 
unsigned int len)
 
 uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
 {
-   const uint32_t *tagp, *lenp;
+   const fdt32_t *tagp, *lenp;
uint32_t tag;
int offset = startoffset;
const char *p;
diff --git a/scripts/dtc/libfdt/fdt.h b/scripts/dtc/libfdt/fdt.h
index 48ccfd9..526aedb 100644
--- a/scripts/dtc/libfdt/fdt.h
+++ b/scripts/dtc/libfdt/fdt.h
@@ -1,48 +1,99 @@
 #ifndef _FDT_H
 #define _FDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ * Copyright 2012 Kim Phillips, Freescale Semiconductor.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above
+ *copyright notice, this list of 

[PATCH 2/3] dtc: import latest upstream dtc

[Kim Phillips]

This updates scripts/dtc to upstream dtc commit 27cdc1b
Added license header to dtc/libfdt/fdt.h and libfdt_env.h
from git://git.jdl.com/software/dtc.git.

Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
 scripts/dtc/dtc.c   |   3 --
 scripts/dtc/fdtdump.c   |  29 +--
 scripts/dtc/libfdt/fdt.c|   2 +-
 scripts/dtc/libfdt/fdt.h|  93 +++
 scripts/dtc/libfdt/fdt_ro.c |   7 ++-
 scripts/dtc/libfdt/fdt_rw.c |   4 +-
 scripts/dtc/libfdt/fdt_sw.c |   4 +-
 scripts/dtc/libfdt/fdt_wip.c|   2 +-
 scripts/dtc/libfdt/libfdt.h |  48 ---
 scripts/dtc/libfdt/libfdt_env.h | 104 +++-
 scripts/dtc/srcpos.c|   6 +--
 scripts/dtc/util.c  |  57 +++---
 scripts/dtc/util.h  |  22 +++--
 13 files changed, 279 insertions(+), 102 deletions(-)

diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index a375683..d40e220 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -201,9 +201,6 @@ int main(int argc, char *argv[])
if (minsize  padsize)
die(Can't set both -p and -S\n);
 
-   if (minsize)
-   fprintf(stderr, DTC: Use of \-S\ is deprecated; it will be 
removed soon, use \-p\ instead\n);
-
if (depname) {
depfile = fopen(depname, w);
if (!depfile)
diff --git a/scripts/dtc/fdtdump.c b/scripts/dtc/fdtdump.c
index 207a46d..03ea429 100644
--- a/scripts/dtc/fdtdump.c
+++ b/scripts/dtc/fdtdump.c
@@ -8,8 +8,8 @@
 #include string.h
 #include ctype.h
 
-#include fdt.h
 #include libfdt_env.h
+#include fdt.h
 
 #include util.h
 
@@ -17,31 +17,6 @@
 #define PALIGN(p, a)   ((void *)(ALIGN((unsigned long)(p), (a
 #define GET_CELL(p)(p += 4, *((const uint32_t *)(p-4)))
 
-static void print_data(const char *data, int len)
-{
-   int i;
-   const char *p = data;
-
-   /* no data, don't print */
-   if (len == 0)
-   return;
-
-   if (util_is_printable_string(data, len)) {
-   printf( = \%s\, (const char *)data);
-   } else if ((len % 4) == 0) {
-   printf( = );
-   for (i = 0; i  len; i += 4)
-   printf(0x%08x%s, fdt32_to_cpu(GET_CELL(p)),
-  i  (len - 4) ?   : );
-   printf();
-   } else {
-   printf( = [);
-   for (i = 0; i  len; i++)
-   printf(%02x%s, *p++, i  len - 1 ?   : );
-   printf(]);
-   }
-}
-
 static void dump_blob(void *blob)
 {
struct fdt_header *bph = blob;
@@ -137,7 +112,7 @@ static void dump_blob(void *blob)
p = PALIGN(p + sz, 4);
 
printf(%*s%s, depth * shift, , s);
-   print_data(t, sz);
+   utilfdt_print_data(t, sz);
printf(;\n);
}
 }
diff --git a/scripts/dtc/libfdt/fdt.c b/scripts/dtc/libfdt/fdt.c
index e56833a..57faba3 100644
--- a/scripts/dtc/libfdt/fdt.c
+++ b/scripts/dtc/libfdt/fdt.c
@@ -92,7 +92,7 @@ const void *fdt_offset_ptr(const void *fdt, int offset, 
unsigned int len)
 
 uint32_t fdt_next_tag(const void *fdt, int startoffset, int *nextoffset)
 {
-   const uint32_t *tagp, *lenp;
+   const fdt32_t *tagp, *lenp;
uint32_t tag;
int offset = startoffset;
const char *p;
diff --git a/scripts/dtc/libfdt/fdt.h b/scripts/dtc/libfdt/fdt.h
index 48ccfd9..526aedb 100644
--- a/scripts/dtc/libfdt/fdt.h
+++ b/scripts/dtc/libfdt/fdt.h
@@ -1,48 +1,99 @@
 #ifndef _FDT_H
 #define _FDT_H
+/*
+ * libfdt - Flat Device Tree manipulation
+ * Copyright (C) 2006 David Gibson, IBM Corporation.
+ * Copyright 2012 Kim Phillips, Freescale Semiconductor.
+ *
+ * libfdt is dual licensed: you can use it either under the terms of
+ * the GPL, or the BSD license, at your option.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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
+ *
+ * Alternatively,
+ *
+ *  b) Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above
+ *copyright notice, this list 

Re: [PATCH 2/3] dtc: import latest upstream dtc

[Rob Landley]

On 02/26/2013 07:36:14 PM, Kim Phillips wrote:

This updates scripts/dtc to upstream dtc commit 27cdc1b


There's an upstream for dts?


Added license header to dtc/libfdt/fdt.h and libfdt_env.h
from git://git.jdl.com/software/dtc.git.


That git repository has a Documentation directory with for example  
dts-format.txt in it. My current linux git repository does not  
contain a file called dts-format.txt.


Ummm... huh?

Rob--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Sat, Oct 13, 2012 at 03:42:35PM +0200, Segher Boessenkool wrote:
> >Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
> >experimented with using cpp on dts manually before, and it seems to
> >have worked.
> 
> Maybe you used "-x assembler-with-cpp"?  That should work better ;-)
> Or just use the "-traditional-cpp" option, i.e. "gcc -E
> -traditional-cpp".

Ah, yes, assembler-with-cpp, that's the one I used.

> >  Note that IIRC with gcc cpp, -x assembler also means
> >that # won't be handled as a cpp directive except in column 0 which is
> >also an advantage for us, although no longer essential with your
> >escaping support.  Not all cpps have an equivalent option, though.
> 
> This is how the traditional C pre-processor behaves.  I don't think
> this is exactly what matters for DTS, or does it ever happen that
> you have a # preceded only by whitespace?

Uh.. pretty much whenever you define a #address-cells or #size-cells
property.  At least until Stephen's patch to allow escaping that.

>  The # and ## stringification
> and token pasting ops will of course bite you with the ISO C pre-processor,
> indeed.
> 
> 
> Segher
> 

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Sat, Oct 13, 2012 at 03:42:35PM +0200, Segher Boessenkool wrote:
 Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
 experimented with using cpp on dts manually before, and it seems to
 have worked.
 
 Maybe you used -x assembler-with-cpp?  That should work better ;-)
 Or just use the -traditional-cpp option, i.e. gcc -E
 -traditional-cpp.

Ah, yes, assembler-with-cpp, that's the one I used.

   Note that IIRC with gcc cpp, -x assembler also means
 that # won't be handled as a cpp directive except in column 0 which is
 also an advantage for us, although no longer essential with your
 escaping support.  Not all cpps have an equivalent option, though.
 
 This is how the traditional C pre-processor behaves.  I don't think
 this is exactly what matters for DTS, or does it ever happen that
 you have a # preceded only by whitespace?

Uh.. pretty much whenever you define a #address-cells or #size-cells
property.  At least until Stephen's patch to allow escaping that.

  The # and ## stringification
 and token pasting ops will of course bite you with the ISO C pre-processor,
 indeed.
 
 
 Segher
 

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Segher Boessenkool]

Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
experimented with using cpp on dts manually before, and it seems to
have worked.


Maybe you used "-x assembler-with-cpp"?  That should work better ;-)
Or just use the "-traditional-cpp" option, i.e. "gcc -E -traditional- 
cpp".



  Note that IIRC with gcc cpp, -x assembler also means
that # won't be handled as a cpp directive except in column 0 which is
also an advantage for us, although no longer essential with your
escaping support.  Not all cpps have an equivalent option, though.


This is how the traditional C pre-processor behaves.  I don't think
this is exactly what matters for DTS, or does it ever happen that
you have a # preceded only by whitespace?  The # and ## stringification
and token pasting ops will of course bite you with the ISO C pre- 
processor,

indeed.


Segher

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Fri, Oct 12, 2012 at 11:24:43AM -0600, Stephen Warren wrote:
> On 10/10/2012 05:18 PM, David Gibson wrote:
> ...
> > And as stated elsewhere, cpp should be invoked with similar options to
> > the way it's done for asm files.  A -D__DTS__ or something like that
> > would probably be a good idea too, just in case some .h needs to be
> > conditional on that.
> 
> Hmm. There are some problems here.
> 
> Right now, the command I proposed is basically:
> 
> $(CPP) -x c $< | dtc ...
> 
> Without "-x c", $(CPP) doesn't recognise the file extension of the input
> file, and defaults to assuming it's a linker script rather than an input
> file, even in pre-processing mode (CPP == $(CC) -E), which obviously
> doesn't work too well.
> 
> I chose "-x c" because *.dts syntax is closest to C.
> 
> However, related to your request above, "-x assembler" might be more
> appropriate, since this would presumably define __ASSEMBLY__, which is
> what the kernel headers currently use to determine whether to compile
> out anything other than #defines. However, executing $(CPP) -x assembler
> foo.dts yields a completely empty output! I'm not sure why that is yet.

Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
experimented with using cpp on dts manually before, and it seems to
have worked.  Note that IIRC with gcc cpp, -x assembler also means
that # won't be handled as a cpp directive except in column 0 which is
also an advantage for us, although no longer essential with your
escaping support.  Not all cpps have an equivalent option, though.

> I also tried passing to $(CPP) the exact same options that the kernel
> uses for compiling true assembly files, namely $(a_flags). Doing so
> would presumably provide complete compatibility in the pre-defined
> #defines between compiling *.S and *.dtsp, which would reduce the
> likelihood of needing to do anything different in *.h to support usage
> by both *.S and *.dtsp. (Note that I still need to pass a -x option, and
> the issue I described above still applies here too). This doesn't work
> out, because on ARM you get arch/arm/include/asm/unified.h
> force-included, which emits true assembly macros into the output, which
> obviously dtc can't parse. This could be avoided by editing that file to
> add #ifndef __DTS__ around the offending parts (and passing -D__DTS__ to
> $(CPP)), and that does appear to currently be the only file requiring a
> change. I wonder if using $(a_flags) is inviting more issues like this
> in the future though?

Ah, ok.  No we probably don't want a_flags, although I think we do
want -x assembler (once we work out what's going wrong with that).
Actually, what we should look at is how cpp is invoked for the .lds.S
linker scripts.  Hrm.. possibly that's why .S was used for that,
despite the potential confusion with asm files - because it
automatically triggers the behaviour wanted from cpp.

> Given this, I'm not convinced we should try to make $(CPP) usage for
> *.dts too much like its usage for *.S. I agree it'd probably make sense
> to add -D__DTS__ to the command-line, but switching away from -x c or to
> using $(a_flags) seems like it'd increase the maintenance requirements
> rather than reduce them.

Hrm.  I don't think we want $(a_flags), but I'm not convinced either
way about the -x option.  I definitely think we do want -D__DTS__, and
I think we want -D__ASSEMBLY__ (either directly or indirectly) too.
It's not really accurate, but will at least do the right thing for
quite a lot of the .h files existing in the kernel already.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Fri, Oct 12, 2012 at 11:24:43AM -0600, Stephen Warren wrote:
 On 10/10/2012 05:18 PM, David Gibson wrote:
 ...
  And as stated elsewhere, cpp should be invoked with similar options to
  the way it's done for asm files.  A -D__DTS__ or something like that
  would probably be a good idea too, just in case some .h needs to be
  conditional on that.
 
 Hmm. There are some problems here.
 
 Right now, the command I proposed is basically:
 
 $(CPP) -x c $ | dtc ...
 
 Without -x c, $(CPP) doesn't recognise the file extension of the input
 file, and defaults to assuming it's a linker script rather than an input
 file, even in pre-processing mode (CPP == $(CC) -E), which obviously
 doesn't work too well.
 
 I chose -x c because *.dts syntax is closest to C.
 
 However, related to your request above, -x assembler might be more
 appropriate, since this would presumably define __ASSEMBLY__, which is
 what the kernel headers currently use to determine whether to compile
 out anything other than #defines. However, executing $(CPP) -x assembler
 foo.dts yields a completely empty output! I'm not sure why that is yet.

Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
experimented with using cpp on dts manually before, and it seems to
have worked.  Note that IIRC with gcc cpp, -x assembler also means
that # won't be handled as a cpp directive except in column 0 which is
also an advantage for us, although no longer essential with your
escaping support.  Not all cpps have an equivalent option, though.

 I also tried passing to $(CPP) the exact same options that the kernel
 uses for compiling true assembly files, namely $(a_flags). Doing so
 would presumably provide complete compatibility in the pre-defined
 #defines between compiling *.S and *.dtsp, which would reduce the
 likelihood of needing to do anything different in *.h to support usage
 by both *.S and *.dtsp. (Note that I still need to pass a -x option, and
 the issue I described above still applies here too). This doesn't work
 out, because on ARM you get arch/arm/include/asm/unified.h
 force-included, which emits true assembly macros into the output, which
 obviously dtc can't parse. This could be avoided by editing that file to
 add #ifndef __DTS__ around the offending parts (and passing -D__DTS__ to
 $(CPP)), and that does appear to currently be the only file requiring a
 change. I wonder if using $(a_flags) is inviting more issues like this
 in the future though?

Ah, ok.  No we probably don't want a_flags, although I think we do
want -x assembler (once we work out what's going wrong with that).
Actually, what we should look at is how cpp is invoked for the .lds.S
linker scripts.  Hrm.. possibly that's why .S was used for that,
despite the potential confusion with asm files - because it
automatically triggers the behaviour wanted from cpp.

 Given this, I'm not convinced we should try to make $(CPP) usage for
 *.dts too much like its usage for *.S. I agree it'd probably make sense
 to add -D__DTS__ to the command-line, but switching away from -x c or to
 using $(a_flags) seems like it'd increase the maintenance requirements
 rather than reduce them.

Hrm.  I don't think we want $(a_flags), but I'm not convinced either
way about the -x option.  I definitely think we do want -D__DTS__, and
I think we want -D__ASSEMBLY__ (either directly or indirectly) too.
It's not really accurate, but will at least do the right thing for
quite a lot of the .h files existing in the kernel already.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Segher Boessenkool]

Oh, that's strange.  I'm pretty sure I've used -x assembler when I've
experimented with using cpp on dts manually before, and it seems to
have worked.


Maybe you used -x assembler-with-cpp?  That should work better ;-)
Or just use the -traditional-cpp option, i.e. gcc -E -traditional- 
cpp.



  Note that IIRC with gcc cpp, -x assembler also means
that # won't be handled as a cpp directive except in column 0 which is
also an advantage for us, although no longer essential with your
escaping support.  Not all cpps have an equivalent option, though.


This is how the traditional C pre-processor behaves.  I don't think
this is exactly what matters for DTS, or does it ever happen that
you have a # preceded only by whitespace?  The # and ## stringification
and token pasting ops will of course bite you with the ISO C pre- 
processor,

indeed.


Segher

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 05:18 PM, David Gibson wrote:
...
> And as stated elsewhere, cpp should be invoked with similar options to
> the way it's done for asm files.  A -D__DTS__ or something like that
> would probably be a good idea too, just in case some .h needs to be
> conditional on that.

Hmm. There are some problems here.

Right now, the command I proposed is basically:

$(CPP) -x c $< | dtc ...

Without "-x c", $(CPP) doesn't recognise the file extension of the input
file, and defaults to assuming it's a linker script rather than an input
file, even in pre-processing mode (CPP == $(CC) -E), which obviously
doesn't work too well.

I chose "-x c" because *.dts syntax is closest to C.

However, related to your request above, "-x assembler" might be more
appropriate, since this would presumably define __ASSEMBLY__, which is
what the kernel headers currently use to determine whether to compile
out anything other than #defines. However, executing $(CPP) -x assembler
foo.dts yields a completely empty output! I'm not sure why that is yet.

I also tried passing to $(CPP) the exact same options that the kernel
uses for compiling true assembly files, namely $(a_flags). Doing so
would presumably provide complete compatibility in the pre-defined
#defines between compiling *.S and *.dtsp, which would reduce the
likelihood of needing to do anything different in *.h to support usage
by both *.S and *.dtsp. (Note that I still need to pass a -x option, and
the issue I described above still applies here too). This doesn't work
out, because on ARM you get arch/arm/include/asm/unified.h
force-included, which emits true assembly macros into the output, which
obviously dtc can't parse. This could be avoided by editing that file to
add #ifndef __DTS__ around the offending parts (and passing -D__DTS__ to
$(CPP)), and that does appear to currently be the only file requiring a
change. I wonder if using $(a_flags) is inviting more issues like this
in the future though?

Given this, I'm not convinced we should try to make $(CPP) usage for
*.dts too much like its usage for *.S. I agree it'd probably make sense
to add -D__DTS__ to the command-line, but switching away from -x c or to
using $(a_flags) seems like it'd increase the maintenance requirements
rather than reduce them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 05:18 PM, David Gibson wrote:
...
 And as stated elsewhere, cpp should be invoked with similar options to
 the way it's done for asm files.  A -D__DTS__ or something like that
 would probably be a good idea too, just in case some .h needs to be
 conditional on that.

Hmm. There are some problems here.

Right now, the command I proposed is basically:

$(CPP) -x c $ | dtc ...

Without -x c, $(CPP) doesn't recognise the file extension of the input
file, and defaults to assuming it's a linker script rather than an input
file, even in pre-processing mode (CPP == $(CC) -E), which obviously
doesn't work too well.

I chose -x c because *.dts syntax is closest to C.

However, related to your request above, -x assembler might be more
appropriate, since this would presumably define __ASSEMBLY__, which is
what the kernel headers currently use to determine whether to compile
out anything other than #defines. However, executing $(CPP) -x assembler
foo.dts yields a completely empty output! I'm not sure why that is yet.

I also tried passing to $(CPP) the exact same options that the kernel
uses for compiling true assembly files, namely $(a_flags). Doing so
would presumably provide complete compatibility in the pre-defined
#defines between compiling *.S and *.dtsp, which would reduce the
likelihood of needing to do anything different in *.h to support usage
by both *.S and *.dtsp. (Note that I still need to pass a -x option, and
the issue I described above still applies here too). This doesn't work
out, because on ARM you get arch/arm/include/asm/unified.h
force-included, which emits true assembly macros into the output, which
obviously dtc can't parse. This could be avoided by editing that file to
add #ifndef __DTS__ around the offending parts (and passing -D__DTS__ to
$(CPP)), and that does appear to currently be the only file requiring a
change. I wonder if using $(a_flags) is inviting more issues like this
in the future though?

Given this, I'm not convinced we should try to make $(CPP) usage for
*.dts too much like its usage for *.S. I agree it'd probably make sense
to add -D__DTS__ to the command-line, but switching away from -x c or to
using $(a_flags) seems like it'd increase the maintenance requirements
rather than reduce them.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 03:42:33PM -1000, Mitch Bradley wrote:
> On 10/10/2012 1:16 PM, David Gibson wrote:
> > On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
> >> On 10/10/2012 10:16 AM, Stephen Warren wrote:
> >>> On 10/10/2012 01:24 AM, David Gibson wrote:
>  On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> > On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
> > [snip]
> >>> That's probably a reasonable idea, although I imagined that people would
> >>> actually split out the portions of any header file they wanted to use
> >>> with dtc, so that any headers included by *.dts would only include
> >>> #defines. Those headers could be used by both dtc and other .h files (or
> >>> .c files).
> >>
> >> Used by what other files? kernel files? We ultimately want to split out
> >> dts files from the kernel, so whatever we add needs to be self
> >> contained. I don't see this as a huge issue though because the whole
> >> point of the DT data is to move that information out of the kernel. If
> >> it is needed in both places, then something is wrong.
> > 
> > People get very hung up on this idea of having the DT move device
> > information out of the kernel, but that was never really the
> > motivation behind it.  Or at least, not the only or foremost
> > motivation.
> > 
> > The DT provides a consistent, flexible way of describing device
> > information.  That allows the core runtime the kernel to operate the
> > same way, regardless of how the DT information was obtained.  The DT
> > could come from firmware, but it could also come from an intermediate
> > bootloader or from early kernel code.  All are perfectly acceptable
> > options depending on the constraints of the platform.
> > 
> > The idea of firmware supplying the DT is much touted, but while it's a
> > theoretically nice idea, I think it's frequently a bad idea for
> > practical reasons.  Those being, in essence that a) firmware usually
> > sucks, b) it's usually harder (or at least no easier) to replace
> > firmware with a fixed version than the kernel/bootwrapper and c)
> > firmware usually *really* sucks.
> 
> Gee, it sounds like you want firmware to suck.  Beating on the "firmware
> sucks" drum is sort of a self-fulfilling prophecy, discouraging talented
> programmers from doing firmware.  Who would want to work on something
> that "everyone knows sucks"?

At this point it's already fulfilled.  Unfortunately, it really
doesn't matter how many more nice firmwares appear, once you have to
support the shitty ones - which we already do - the damage is done.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 1:16 PM, David Gibson wrote:
> On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
>> On 10/10/2012 10:16 AM, Stephen Warren wrote:
>>> On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
> [snip]
>>> That's probably a reasonable idea, although I imagined that people would
>>> actually split out the portions of any header file they wanted to use
>>> with dtc, so that any headers included by *.dts would only include
>>> #defines. Those headers could be used by both dtc and other .h files (or
>>> .c files).
>>
>> Used by what other files? kernel files? We ultimately want to split out
>> dts files from the kernel, so whatever we add needs to be self
>> contained. I don't see this as a huge issue though because the whole
>> point of the DT data is to move that information out of the kernel. If
>> it is needed in both places, then something is wrong.
> 
> People get very hung up on this idea of having the DT move device
> information out of the kernel, but that was never really the
> motivation behind it.  Or at least, not the only or foremost
> motivation.
> 
> The DT provides a consistent, flexible way of describing device
> information.  That allows the core runtime the kernel to operate the
> same way, regardless of how the DT information was obtained.  The DT
> could come from firmware, but it could also come from an intermediate
> bootloader or from early kernel code.  All are perfectly acceptable
> options depending on the constraints of the platform.
> 
> The idea of firmware supplying the DT is much touted, but while it's a
> theoretically nice idea, I think it's frequently a bad idea for
> practical reasons.  Those being, in essence that a) firmware usually
> sucks, b) it's usually harder (or at least no easier) to replace
> firmware with a fixed version than the kernel/bootwrapper and c)
> firmware usually *really* sucks.
> 

Gee, it sounds like you want firmware to suck.  Beating on the "firmware
sucks" drum is sort of a self-fulfilling prophecy, discouraging talented
programmers from doing firmware.  Who would want to work on something
that "everyone knows sucks"?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 09:16:34AM -0600, Stephen Warren wrote:
> On 10/10/2012 01:24 AM, David Gibson wrote:
> > On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
[snip]
> >> .h files include both structs and defines, which are fine for
> >> ordinary C code, but problematic in this context.
> > 
> > Right, cpp should be invoked with similar options to the way it's done
> > for asm files which have the same problem.  I'm not sure if the
> > current patch does so.
> 
> That's probably a reasonable idea, although I imagined that people would
> actually split out the portions of any header file they wanted to use
> with dtc, so that any headers included by *.dts would only include
> #defines. Those headers could be used by both dtc and other .h files (or
> .c files).

Given that header files are right now frequently used in both .c and
.S for the #defines, I don't think we can reasonably expect
differently for dts files.  There certainly is the potential for
#include dependency mess, but we cope with it for .S so we can cope
with it for dts as well.

But cpp should definitely be invoked "asm style" for dts files.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 08:56:11AM -1000, Mitch Bradley wrote:
> On 10/10/2012 8:45 AM, Stephen Warren wrote:
> > On 10/10/2012 12:23 PM, Mitch Bradley wrote:
> >> On 10/10/2012 7:09 AM, Rob Herring wrote:
> >>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
[snip]
> >> Instead of making a bunch of rules about how you can only use a small
> >> subset of cpp, why not just add a "define name value" command to DTC?
> > 
> > I implemented a patch to do exactly that, and it was rejected because it
> > only solved part of the problem (named constants) and not the reset (a
> > completely generic macro language/... within dtc). The argument was that
> > defining just the named constant syntax on its own without knowing what
> > the unspecified future macro language will look like might result in the
> > named constant syntax not fitting into it.
> > 
> > That all said, I now think that using cpp is actually a much better
> > solution that adding yet more dtc-specific syntax. The *huge* benefit
> > here is that it allows you to share .h files between *.dts and C code,
> > so you don't have to write out the same set of #defines once in dtc
> > syntax and once in cpp syntax.
> 
> ... and it imposes an equally *huge* restriction that you have to
> restrict the .h file to avoid avoid C constructs.  That can be done, but
> I've personally experienced a lot of headaches when trying to share .h
> files between different languages.

Yes, but we already deal with that for asm files.  And the sorts of
defines we use in asm files are often the same ones we'd want in dts
files.


-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
> On 10/10/2012 10:16 AM, Stephen Warren wrote:
> > On 10/10/2012 01:24 AM, David Gibson wrote:
> >> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> >>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
[snip]
> > That's probably a reasonable idea, although I imagined that people would
> > actually split out the portions of any header file they wanted to use
> > with dtc, so that any headers included by *.dts would only include
> > #defines. Those headers could be used by both dtc and other .h files (or
> > .c files).
> 
> Used by what other files? kernel files? We ultimately want to split out
> dts files from the kernel, so whatever we add needs to be self
> contained. I don't see this as a huge issue though because the whole
> point of the DT data is to move that information out of the kernel. If
> it is needed in both places, then something is wrong.

People get very hung up on this idea of having the DT move device
information out of the kernel, but that was never really the
motivation behind it.  Or at least, not the only or foremost
motivation.

The DT provides a consistent, flexible way of describing device
information.  That allows the core runtime the kernel to operate the
same way, regardless of how the DT information was obtained.  The DT
could come from firmware, but it could also come from an intermediate
bootloader or from early kernel code.  All are perfectly acceptable
options depending on the constraints of the platform.

The idea of firmware supplying the DT is much touted, but while it's a
theoretically nice idea, I think it's frequently a bad idea for
practical reasons.  Those being, in essence that a) firmware usually
sucks, b) it's usually harder (or at least no easier) to replace
firmware with a fixed version than the kernel/bootwrapper and c)
firmware usually *really* sucks.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 12:45:40PM -0600, Stephen Warren wrote:
> On 10/10/2012 12:23 PM, Mitch Bradley wrote:
> > On 10/10/2012 7:09 AM, Rob Herring wrote:
> >> On 10/09/2012 04:16 PM, Stephen Warren wrote:
> >>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
> >
> > What more do you think needs discussion re: dtc+cpp?
> 
>  How not to abuse the ever-loving shit out of it? :-)
> >>>
> >>> Perhaps we can just handle this through the regular patch review
> >>> process; I think it may be difficult to define and agree upon exactly
> >>> what "abuse" means ahead of time, but it's probably going to be easy
> >>> enough to recognize it when one sees it?
> >>
> >> Rather than repeating things over and over in reviews, we should
> >> document at least rules we can easily agree on and then add to it when
> >> people get "creative." Also, I can't keep up with every single binding
> >> review as is, and this could just add another level of complexity to the
> >> review. A few off the top of my head and from the thread discussion:
> >>
> >> - Headers must be self contained with no outside (i.e. libc, kernel,
> >> etc.) header dependencies.
> >> - No kernel kconfig option usage
> >> - No gcc built-in define usage
> >> - No unused items (i.e. externs, structs, etc.)
> >> - No macro concatenation
> >> - No macros for strings or property names
> > 
> > Instead of making a bunch of rules about how you can only use a small
> > subset of cpp, why not just add a "define name value" command to DTC?
> 
> I implemented a patch to do exactly that, and it was rejected because it

Well... more indefinitely postponed, rather than rejected.  Which you
would be entirely justified in seeing as a meaningless semantic
difference at this point.

> only solved part of the problem (named constants) and not the reset (a
> completely generic macro language/... within dtc). The argument was that
> defining just the named constant syntax on its own without knowing what
> the unspecified future macro language will look like might result in the
> named constant syntax not fitting into it.
> 
> That all said, I now think that using cpp is actually a much better
> solution that adding yet more dtc-specific syntax. The *huge* benefit
> here is that it allows you to share .h files between *.dts and C code,
> so you don't have to write out the same set of #defines once in dtc
> syntax and once in cpp syntax.

Right, I tend to agree.  In addition to those reasons, it avoids
creating yet another micro-language, and it obeys the #1 guiding
principle for dts syntax which is "don't surprise C programmers".

That said, there are a number of number of dtc extensions that would
make cpp-ability more useful.  The integer expression support that has
already gone in was a start on that, but richer expressions
(particularly strings and bytestrings) would be useful too.  Support
for invoking cpp automatically from within dtc would make that support
easier to use too.

I really would like to be working more actively on those things, but
unfortunately I don't have that much time free for dtc work.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 08:41:45AM -0600, Warner Losh wrote:
> On Oct 10, 2012, at 1:24 AM, David Gibson wrote:
> > On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
[snip]
> >> .h files include both structs and defines, which are fine for
> >> ordinary C code, but problematic in this context.
> > 
> > Right, cpp should be invoked with similar options to the way it's done
> > for asm files which have the same problem.  I'm not sure if the
> > current patch does so.
> 
> I know the current dtc code is very careful to license itself in a
> very agnostic way.  Would including files, possibly from the Linux
> kernel, pose any kind of license issue?  Or does the fact that many
> (but not all) .dts files being apparently licensed GPL already make
> this a moot point?  Or does it not matter since this is an interface
> and declaration of information, which likely isn't creative enough
> to receive to copyright protection  Or is this a can of worms
> best avoided :)

Um... what?  The licensing of dtc itself has nothing to do with the
licensing of the dts files used as input to it.  Those, and their
includes, would be licensed GPLv2 just like the rest of the kernel,
I'd expect.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 10:22:02AM -0600, Stephen Warren wrote:
> On 10/10/2012 10:09 AM, Scott Wood wrote:
> > On 10/10/2012 10:15:17 AM, Stephen Warren wrote:
> >> On 10/09/2012 06:04 PM, Scott Wood wrote:
> >> > On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
> >> >> On 10/9/2012 11:16 AM, Stephen Warren wrote:
> >> >> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
> >> >> >>>
> >> >> >>> What more do you think needs discussion re: dtc+cpp?
> >> >> >>
> >> >> >> How not to abuse the ever-loving shit out of it? :-)
> >> >> >
> >> >> > Perhaps we can just handle this through the regular patch review
> >> >> > process; I think it may be difficult to define and agree upon
> >> exactly
> >> >> > what "abuse" means ahead of time, but it's probably going to be easy
> >> >> > enough to recognize it when one sees it?
> >> >>
> >> >>
> >> >> One of the ways it could get out of hand would be via "include
> >> >> dependency hell".  People will be tempted to reuse existing .h files
> >> >> containing pin definitions, which, if history is a guide, will end up
> >> >> depending on all sorts of other .h files.
> >> >>
> >> >> Another problem I often face with symbolic names is the difficulty of
> >> >> figuring out what the numerical values really are (for debugging),
> >> >> especially when .h files are in different subtrees from the files that
> >> >> use the definitions, and when they use multiple macro levels and fancy
> >> >> features like concatenation.  Sometimes I think it's clearer just to
> >> >> write the number and use a comment to say what it is.
> >> >
> >> > Both comments apply just as well to ordinary C code, and I don't think
> >> > anyone would seriously suggest just using comments instead for C code.
> >> >
> >> > Is there a way to ask CPP to evaluate a macro in the context of the
> >> > input file, rather than produce normal output?  If not, I guess you
> >> > could make a tool that creates a wrapper file that includes the main
> >> > file and then evaluates the symbol you want.
> >>
> >> I'm not sure what "evaluate a macro in the context of the input file"
> >> means. Macros are obviously already evaluated based on the current set
> >> of macros defined by the file that's been processed or those it
> >> included. Do you mean only allowing the use of macros in the current
> >> file and not included files? What exactly would the wrapper you
> >> mentioned do?
> > 
> > I just meant a way for a developer to quickly ask the preprocessor what
> > a particular macro expands to, rather than try to figure it out
> > manually.  I was not suggesting any change to normal operation.
> 
> Oh right. Well, the patch I proposed to the kernel was basically:
> 
> %.dtb: %.dtsp
> cpp -E $< | dtc -o $@ -
> 
> A developer could run the same cpp -E command to find that out, or that
> build rule could instead save the intermediate result rather than just
> piping it, so you could just go read the file.

It would be nice to have a make target to actually do just that step,
even though it would usually only be invoked manually for debugging,
just as we have a %.i make target which can be used to see what the
preprocessor did to .c files.

And as stated elsewhere, cpp should be invoked with similar options to
the way it's done for asm files.  A -D__DTS__ or something like that
would probably be a good idea too, just in case some .h needs to be
conditional on that.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 8:45 AM, Stephen Warren wrote:
> On 10/10/2012 12:23 PM, Mitch Bradley wrote:
>> On 10/10/2012 7:09 AM, Rob Herring wrote:
>>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>
>> What more do you think needs discussion re: dtc+cpp?
>
> How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what "abuse" means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
>>>
>>> Rather than repeating things over and over in reviews, we should
>>> document at least rules we can easily agree on and then add to it when
>>> people get "creative." Also, I can't keep up with every single binding
>>> review as is, and this could just add another level of complexity to the
>>> review. A few off the top of my head and from the thread discussion:
>>>
>>> - Headers must be self contained with no outside (i.e. libc, kernel,
>>> etc.) header dependencies.
>>> - No kernel kconfig option usage
>>> - No gcc built-in define usage
>>> - No unused items (i.e. externs, structs, etc.)
>>> - No macro concatenation
>>> - No macros for strings or property names
>>
>> Instead of making a bunch of rules about how you can only use a small
>> subset of cpp, why not just add a "define name value" command to DTC?
> 
> I implemented a patch to do exactly that, and it was rejected because it
> only solved part of the problem (named constants) and not the reset (a
> completely generic macro language/... within dtc). The argument was that
> defining just the named constant syntax on its own without knowing what
> the unspecified future macro language will look like might result in the
> named constant syntax not fitting into it.
> 
> That all said, I now think that using cpp is actually a much better
> solution that adding yet more dtc-specific syntax. The *huge* benefit
> here is that it allows you to share .h files between *.dts and C code,
> so you don't have to write out the same set of #defines once in dtc
> syntax and once in cpp syntax.

... and it imposes an equally *huge* restriction that you have to
restrict the .h file to avoid avoid C constructs.  That can be done, but
I've personally experienced a lot of headaches when trying to share .h
files between different languages.

> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 8:40 AM, Stephen Warren wrote:
> On 10/10/2012 11:09 AM, Rob Herring wrote:
>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>
> What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)
>>>
>>> Perhaps we can just handle this through the regular patch review
>>> process; I think it may be difficult to define and agree upon exactly
>>> what "abuse" means ahead of time, but it's probably going to be easy
>>> enough to recognize it when one sees it?
>>
>> Rather than repeating things over and over in reviews, we should
>> document at least rules we can easily agree on and then add to it when
>> people get "creative." Also, I can't keep up with every single binding
>> review as is, and this could just add another level of complexity to the
>> review. A few off the top of my head and from the thread discussion:
>>
>> - Headers must be self contained with no outside (i.e. libc, kernel,
>> etc.) header dependencies.
>> - No kernel kconfig option usage
>> - No gcc built-in define usage
>> - No unused items (i.e. externs, structs, etc.)
> 
>> - No macro concatenation
> 
> That seems to be potentially a very useful feature; I have no idea why
> we would ban that; it isn't banned in C code in the kernel is it?

It's used in the kernel.  It is useful, but it has an unexpected side
effect that can be extremely annoying - it can make it extremely
difficult to find a definition with grep.  All the grep hits will be for
the fully-expanded uses of a symbol, while the definition is "hidden" by
virtue of being synthesized by concatenation.

Maybe it's not a big deal in a small project, but in a code base the
size of the Linux kernel, where you don't know a priori where something
is defined, it can make you want to tear your hair out.

> 
>> - No macros for strings or property names
> 
> Property names I can understand. Property values - I can perhaps see a
> use-case for...
> 
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 12:23 PM, Mitch Bradley wrote:
> On 10/10/2012 7:09 AM, Rob Herring wrote:
>> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>
> What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)
>>>
>>> Perhaps we can just handle this through the regular patch review
>>> process; I think it may be difficult to define and agree upon exactly
>>> what "abuse" means ahead of time, but it's probably going to be easy
>>> enough to recognize it when one sees it?
>>
>> Rather than repeating things over and over in reviews, we should
>> document at least rules we can easily agree on and then add to it when
>> people get "creative." Also, I can't keep up with every single binding
>> review as is, and this could just add another level of complexity to the
>> review. A few off the top of my head and from the thread discussion:
>>
>> - Headers must be self contained with no outside (i.e. libc, kernel,
>> etc.) header dependencies.
>> - No kernel kconfig option usage
>> - No gcc built-in define usage
>> - No unused items (i.e. externs, structs, etc.)
>> - No macro concatenation
>> - No macros for strings or property names
> 
> Instead of making a bunch of rules about how you can only use a small
> subset of cpp, why not just add a "define name value" command to DTC?

I implemented a patch to do exactly that, and it was rejected because it
only solved part of the problem (named constants) and not the reset (a
completely generic macro language/... within dtc). The argument was that
defining just the named constant syntax on its own without knowing what
the unspecified future macro language will look like might result in the
named constant syntax not fitting into it.

That all said, I now think that using cpp is actually a much better
solution that adding yet more dtc-specific syntax. The *huge* benefit
here is that it allows you to share .h files between *.dts and C code,
so you don't have to write out the same set of #defines once in dtc
syntax and once in cpp syntax.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 11:18 AM, Rob Herring wrote:
> On 10/10/2012 11:19 AM, Stephen Warren wrote:
>> On 10/10/2012 09:33 AM, Rob Herring wrote:
>>> On 10/10/2012 10:16 AM, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
>>
>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
>>
>>> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via "include
 dependency hell".  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
>>>
>>> Both comments apply just as well to ordinary C code, and I don't think 
>>> anyone would seriously suggest just using comments instead for C code.
>>
>> .h files include both structs and defines, which are fine for
>> ordinary C code, but problematic in this context.
>
> Right, cpp should be invoked with similar options to the way it's done
> for asm files which have the same problem.  I'm not sure if the
> current patch does so.

 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).
>>>
>>> Used by what other files? kernel files? We ultimately want to split out
>>> dts files from the kernel, so whatever we add needs to be self
>>> contained. I don't see this as a huge issue though because the whole
>>> point of the DT data is to move that information out of the kernel. If
>>> it is needed in both places, then something is wrong.
>>
>> One example is the IDs of the GPIOs, e.g.:
>>
>> #define TEGRA_PIN_VI_GP6_PA0_GPIO(0)
>> #define TEGRA_PIN_UART3_CTS_N_PA1   _GPIO(1)
>> #define TEGRA_PIN_DAP2_FS_PA2   _GPIO(2)
>> #define TEGRA_PIN_DAP2_SCLK_PA3 _GPIO(3)
>>
>> Those defines are useful to both the .dts files (so named constants can
>> be used) and the pinctrl driver. By using the same header file, we
>> guarantee that the .dts files and pinctrl driver use the exact same
>> naming for the pins; the pin naming/numbering being defined by the DT
>> binding more than anything else.
> 
> If pinctrl needs to get a matching name, then it should get it from the
> dtb. We should not have 2 sources of data. That is just broken.

Why? The data is static and there's zero need for it to be in the DTB.
We've been over this already many times.

This is just like /any/ other header file usage. Something defines the
legal values. Various things need to use them. So, we define the values
in a header file, and both *.dts and *.c include them.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 11:09 AM, Rob Herring wrote:
> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?
>>>
>>> How not to abuse the ever-loving shit out of it? :-)
>>
>> Perhaps we can just handle this through the regular patch review
>> process; I think it may be difficult to define and agree upon exactly
>> what "abuse" means ahead of time, but it's probably going to be easy
>> enough to recognize it when one sees it?
> 
> Rather than repeating things over and over in reviews, we should
> document at least rules we can easily agree on and then add to it when
> people get "creative." Also, I can't keep up with every single binding
> review as is, and this could just add another level of complexity to the
> review. A few off the top of my head and from the thread discussion:
> 
> - Headers must be self contained with no outside (i.e. libc, kernel,
> etc.) header dependencies.
> - No kernel kconfig option usage
> - No gcc built-in define usage
> - No unused items (i.e. externs, structs, etc.)

> - No macro concatenation

That seems to be potentially a very useful feature; I have no idea why
we would ban that; it isn't banned in C code in the kernel is it?

> - No macros for strings or property names

Property names I can understand. Property values - I can perhaps see a
use-case for...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 7:09 AM, Rob Herring wrote:
> On 10/09/2012 04:16 PM, Stephen Warren wrote:
>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?
>>>
>>> How not to abuse the ever-loving shit out of it? :-)
>>
>> Perhaps we can just handle this through the regular patch review
>> process; I think it may be difficult to define and agree upon exactly
>> what "abuse" means ahead of time, but it's probably going to be easy
>> enough to recognize it when one sees it?
> 
> Rather than repeating things over and over in reviews, we should
> document at least rules we can easily agree on and then add to it when
> people get "creative." Also, I can't keep up with every single binding
> review as is, and this could just add another level of complexity to the
> review. A few off the top of my head and from the thread discussion:
> 
> - Headers must be self contained with no outside (i.e. libc, kernel,
> etc.) header dependencies.
> - No kernel kconfig option usage
> - No gcc built-in define usage
> - No unused items (i.e. externs, structs, etc.)
> - No macro concatenation
> - No macros for strings or property names

Instead of making a bunch of rules about how you can only use a small
subset of cpp, why not just add a "define name value" command to DTC?

One of the things I like least about C is that the language itself is
incomplete; in order to actually program in C, you have to deal with not
only with the C syntactic structure, but also cpp, with its different
rules, and also make, with fundamentally different linguistic structure,
and then you end up wrapping that in something like KConfig, with yet
another linguistic framework, and the makefile contains embedded shell
commands, which is yet another syntax.

Rather than open Pandora's box by grafting on cpp, why not solve the
actual problem?


> 
> Do we further restrict things to say defines are only numbers? One could
> start to define complex macros to build the nodes themselves. If each
> platform does this slightly differently, it will become difficult to
> review and maintain. Then we will be doing dts consolidation. The fact
> that we have some fixed structure and each SOC is not free to do things
> their own way makes things easier to maintain. You don't have that in
> the kernel across platforms. For example, look how register defines and
> static mappings or platform device creation are done. They are all
> similar, but yet slightly different. That makes doing changes across
> platforms more difficult.
> 
>> I imagine the most common usage will simply be a bunch of:
>>
>> #define TEGRA_GPIO_PB0 32
>> #define TEGRA_GPIO_INT_LEVEL_LOW 8
>>
>> / {
>> xxx {
>> interrupts = ;
>>
>> and similarly, simple math:
>>
>> something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;
>>
> 
> These are all perfectly fine and sane use, but if we don't restrict
> things then the next step is this:
> 
> #define PROP_SOMETHING(v) (something = <(v)>)
> 
> Rob
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/10/2012 11:19 AM, Stephen Warren wrote:
> On 10/10/2012 09:33 AM, Rob Herring wrote:
>> On 10/10/2012 10:16 AM, Stephen Warren wrote:
>>> On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
>
> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
>
>> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>
>> What more do you think needs discussion re: dtc+cpp?
>
> How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what "abuse" means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
>>> One of the ways it could get out of hand would be via "include
>>> dependency hell".  People will be tempted to reuse existing .h files
>>> containing pin definitions, which, if history is a guide, will end up
>>> depending on all sorts of other .h files.
>>> Another problem I often face with symbolic names is the difficulty of
>>> figuring out what the numerical values really are (for debugging),
>>> especially when .h files are in different subtrees from the files that
>>> use the definitions, and when they use multiple macro levels and fancy
>>> features like concatenation.  Sometimes I think it's clearer just to
>>> write the number and use a comment to say what it is.
>>
>> Both comments apply just as well to ordinary C code, and I don't think 
>> anyone would seriously suggest just using comments instead for C code.
>
> .h files include both structs and defines, which are fine for
> ordinary C code, but problematic in this context.

 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.
>>>
>>> That's probably a reasonable idea, although I imagined that people would
>>> actually split out the portions of any header file they wanted to use
>>> with dtc, so that any headers included by *.dts would only include
>>> #defines. Those headers could be used by both dtc and other .h files (or
>>> .c files).
>>
>> Used by what other files? kernel files? We ultimately want to split out
>> dts files from the kernel, so whatever we add needs to be self
>> contained. I don't see this as a huge issue though because the whole
>> point of the DT data is to move that information out of the kernel. If
>> it is needed in both places, then something is wrong.
> 
> One example is the IDs of the GPIOs, e.g.:
> 
> #define TEGRA_PIN_VI_GP6_PA0_GPIO(0)
> #define TEGRA_PIN_UART3_CTS_N_PA1   _GPIO(1)
> #define TEGRA_PIN_DAP2_FS_PA2   _GPIO(2)
> #define TEGRA_PIN_DAP2_SCLK_PA3 _GPIO(3)
> 
> Those defines are useful to both the .dts files (so named constants can
> be used) and the pinctrl driver. By using the same header file, we
> guarantee that the .dts files and pinctrl driver use the exact same
> naming for the pins; the pin naming/numbering being defined by the DT
> binding more than anything else.

If pinctrl needs to get a matching name, then it should get it from the
dtb. We should not have 2 sources of data. That is just broken.

> 
> It'd be similarly useful to share GPIO or interrupt flag definitions,
> etc. etc.
> 
> We could do something like we do for dtc today, where there's an
> external repository for *.dts (and required *.h), yet those *.h are
> duplicated into the kernel tree as needed by drivers.

So as long as we only need to sync up about once a year that's fine
because we have yet to prove that doing it frequently for dtc will be
easy and painless.

I'd like fewer things to copy around, not more. If you have some
self-contained platform defines to copy, then it is your problem.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/09/2012 04:16 PM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
> 
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?

Rather than repeating things over and over in reviews, we should
document at least rules we can easily agree on and then add to it when
people get "creative." Also, I can't keep up with every single binding
review as is, and this could just add another level of complexity to the
review. A few off the top of my head and from the thread discussion:

- Headers must be self contained with no outside (i.e. libc, kernel,
etc.) header dependencies.
- No kernel kconfig option usage
- No gcc built-in define usage
- No unused items (i.e. externs, structs, etc.)
- No macro concatenation
- No macros for strings or property names

Do we further restrict things to say defines are only numbers? One could
start to define complex macros to build the nodes themselves. If each
platform does this slightly differently, it will become difficult to
review and maintain. Then we will be doing dts consolidation. The fact
that we have some fixed structure and each SOC is not free to do things
their own way makes things easier to maintain. You don't have that in
the kernel across platforms. For example, look how register defines and
static mappings or platform device creation are done. They are all
similar, but yet slightly different. That makes doing changes across
platforms more difficult.

> I imagine the most common usage will simply be a bunch of:
> 
> #define TEGRA_GPIO_PB0 32
> #define TEGRA_GPIO_INT_LEVEL_LOW 8
> 
> / {
> xxx {
> interrupts = ;
> 
> and similarly, simple math:
> 
> something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;
> 

These are all perfectly fine and sane use, but if we don't restrict
things then the next step is this:

#define PROP_SOMETHING(v) (something = <(v)>)

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 10:09 AM, Scott Wood wrote:
> On 10/10/2012 10:15:17 AM, Stephen Warren wrote:
>> On 10/09/2012 06:04 PM, Scott Wood wrote:
>> > On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>> >> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>> >> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>> >> >>>
>> >> >>> What more do you think needs discussion re: dtc+cpp?
>> >> >>
>> >> >> How not to abuse the ever-loving shit out of it? :-)
>> >> >
>> >> > Perhaps we can just handle this through the regular patch review
>> >> > process; I think it may be difficult to define and agree upon
>> exactly
>> >> > what "abuse" means ahead of time, but it's probably going to be easy
>> >> > enough to recognize it when one sees it?
>> >>
>> >>
>> >> One of the ways it could get out of hand would be via "include
>> >> dependency hell".  People will be tempted to reuse existing .h files
>> >> containing pin definitions, which, if history is a guide, will end up
>> >> depending on all sorts of other .h files.
>> >>
>> >> Another problem I often face with symbolic names is the difficulty of
>> >> figuring out what the numerical values really are (for debugging),
>> >> especially when .h files are in different subtrees from the files that
>> >> use the definitions, and when they use multiple macro levels and fancy
>> >> features like concatenation.  Sometimes I think it's clearer just to
>> >> write the number and use a comment to say what it is.
>> >
>> > Both comments apply just as well to ordinary C code, and I don't think
>> > anyone would seriously suggest just using comments instead for C code.
>> >
>> > Is there a way to ask CPP to evaluate a macro in the context of the
>> > input file, rather than produce normal output?  If not, I guess you
>> > could make a tool that creates a wrapper file that includes the main
>> > file and then evaluates the symbol you want.
>>
>> I'm not sure what "evaluate a macro in the context of the input file"
>> means. Macros are obviously already evaluated based on the current set
>> of macros defined by the file that's been processed or those it
>> included. Do you mean only allowing the use of macros in the current
>> file and not included files? What exactly would the wrapper you
>> mentioned do?
> 
> I just meant a way for a developer to quickly ask the preprocessor what
> a particular macro expands to, rather than try to figure it out
> manually.  I was not suggesting any change to normal operation.

Oh right. Well, the patch I proposed to the kernel was basically:

%.dtb: %.dtsp
cpp -E $< | dtc -o $@ -

A developer could run the same cpp -E command to find that out, or that
build rule could instead save the intermediate result rather than just
piping it, so you could just go read the file.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 09:33 AM, Rob Herring wrote:
> On 10/10/2012 10:16 AM, Stephen Warren wrote:
>> On 10/10/2012 01:24 AM, David Gibson wrote:
>>> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:

 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>
> What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)
>>>
>>> Perhaps we can just handle this through the regular patch review
>>> process; I think it may be difficult to define and agree upon exactly
>>> what "abuse" means ahead of time, but it's probably going to be easy
>>> enough to recognize it when one sees it?
>> One of the ways it could get out of hand would be via "include
>> dependency hell".  People will be tempted to reuse existing .h files
>> containing pin definitions, which, if history is a guide, will end up
>> depending on all sorts of other .h files.
>> Another problem I often face with symbolic names is the difficulty of
>> figuring out what the numerical values really are (for debugging),
>> especially when .h files are in different subtrees from the files that
>> use the definitions, and when they use multiple macro levels and fancy
>> features like concatenation.  Sometimes I think it's clearer just to
>> write the number and use a comment to say what it is.
>
> Both comments apply just as well to ordinary C code, and I don't think 
> anyone would seriously suggest just using comments instead for C code.

 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.
>>>
>>> Right, cpp should be invoked with similar options to the way it's done
>>> for asm files which have the same problem.  I'm not sure if the
>>> current patch does so.
>>
>> That's probably a reasonable idea, although I imagined that people would
>> actually split out the portions of any header file they wanted to use
>> with dtc, so that any headers included by *.dts would only include
>> #defines. Those headers could be used by both dtc and other .h files (or
>> .c files).
> 
> Used by what other files? kernel files? We ultimately want to split out
> dts files from the kernel, so whatever we add needs to be self
> contained. I don't see this as a huge issue though because the whole
> point of the DT data is to move that information out of the kernel. If
> it is needed in both places, then something is wrong.

One example is the IDs of the GPIOs, e.g.:

#define TEGRA_PIN_VI_GP6_PA0_GPIO(0)
#define TEGRA_PIN_UART3_CTS_N_PA1   _GPIO(1)
#define TEGRA_PIN_DAP2_FS_PA2   _GPIO(2)
#define TEGRA_PIN_DAP2_SCLK_PA3 _GPIO(3)

Those defines are useful to both the .dts files (so named constants can
be used) and the pinctrl driver. By using the same header file, we
guarantee that the .dts files and pinctrl driver use the exact same
naming for the pins; the pin naming/numbering being defined by the DT
binding more than anything else.

It'd be similarly useful to share GPIO or interrupt flag definitions,
etc. etc.

We could do something like we do for dtc today, where there's an
external repository for *.dts (and required *.h), yet those *.h are
duplicated into the kernel tree as needed by drivers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Scott Wood]

On 10/10/2012 10:15:17 AM, Stephen Warren wrote:

On 10/09/2012 06:04 PM, Scott Wood wrote:
> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>> >>>
>> >>> What more do you think needs discussion re: dtc+cpp?
>> >>
>> >> How not to abuse the ever-loving shit out of it? :-)
>> >
>> > Perhaps we can just handle this through the regular patch review
>> > process; I think it may be difficult to define and agree upon  
exactly
>> > what "abuse" means ahead of time, but it's probably going to be  
easy

>> > enough to recognize it when one sees it?
>>
>>
>> One of the ways it could get out of hand would be via "include
>> dependency hell".  People will be tempted to reuse existing .h  
files
>> containing pin definitions, which, if history is a guide, will end  
up

>> depending on all sorts of other .h files.
>>
>> Another problem I often face with symbolic names is the difficulty  
of

>> figuring out what the numerical values really are (for debugging),
>> especially when .h files are in different subtrees from the files  
that
>> use the definitions, and when they use multiple macro levels and  
fancy
>> features like concatenation.  Sometimes I think it's clearer just  
to

>> write the number and use a comment to say what it is.
>
> Both comments apply just as well to ordinary C code, and I don't  
think
> anyone would seriously suggest just using comments instead for C  
code.

>
> Is there a way to ask CPP to evaluate a macro in the context of the
> input file, rather than produce normal output?  If not, I guess you
> could make a tool that creates a wrapper file that includes the main
> file and then evaluates the symbol you want.

I'm not sure what "evaluate a macro in the context of the input file"
means. Macros are obviously already evaluated based on the current set
of macros defined by the file that's been processed or those it
included. Do you mean only allowing the use of macros in the current
file and not included files? What exactly would the wrapper you
mentioned do?


I just meant a way for a developer to quickly ask the preprocessor what  
a particular macro expands to, rather than try to figure it out  
manually.  I was not suggesting any change to normal operation.


-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/10/2012 10:16 AM, Stephen Warren wrote:
> On 10/10/2012 01:24 AM, David Gibson wrote:
>> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
>>>
>>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
>>>
 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>> On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?
>>>
>>> How not to abuse the ever-loving shit out of it? :-)
>>
>> Perhaps we can just handle this through the regular patch review
>> process; I think it may be difficult to define and agree upon exactly
>> what "abuse" means ahead of time, but it's probably going to be easy
>> enough to recognize it when one sees it?
> One of the ways it could get out of hand would be via "include
> dependency hell".  People will be tempted to reuse existing .h files
> containing pin definitions, which, if history is a guide, will end up
> depending on all sorts of other .h files.
> Another problem I often face with symbolic names is the difficulty of
> figuring out what the numerical values really are (for debugging),
> especially when .h files are in different subtrees from the files that
> use the definitions, and when they use multiple macro levels and fancy
> features like concatenation.  Sometimes I think it's clearer just to
> write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.
>>>
>>> .h files include both structs and defines, which are fine for
>>> ordinary C code, but problematic in this context.
>>
>> Right, cpp should be invoked with similar options to the way it's done
>> for asm files which have the same problem.  I'm not sure if the
>> current patch does so.
> 
> That's probably a reasonable idea, although I imagined that people would
> actually split out the portions of any header file they wanted to use
> with dtc, so that any headers included by *.dts would only include
> #defines. Those headers could be used by both dtc and other .h files (or
> .c files).

Used by what other files? kernel files? We ultimately want to split out
dts files from the kernel, so whatever we add needs to be self
contained. I don't see this as a huge issue though because the whole
point of the DT data is to move that information out of the kernel. If
it is needed in both places, then something is wrong.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 01:24 AM, David Gibson wrote:
> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
>>
>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
>>
>>> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via "include
 dependency hell".  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
>>>
>>> Both comments apply just as well to ordinary C code, and I don't think 
>>> anyone would seriously suggest just using comments instead for C code.
>>
>> .h files include both structs and defines, which are fine for
>> ordinary C code, but problematic in this context.
> 
> Right, cpp should be invoked with similar options to the way it's done
> for asm files which have the same problem.  I'm not sure if the
> current patch does so.

That's probably a reasonable idea, although I imagined that people would
actually split out the portions of any header file they wanted to use
with dtc, so that any headers included by *.dts would only include
#defines. Those headers could be used by both dtc and other .h files (or
.c files).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/09/2012 06:04 PM, Scott Wood wrote:
> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>> >>>
>> >>> What more do you think needs discussion re: dtc+cpp?
>> >>
>> >> How not to abuse the ever-loving shit out of it? :-)
>> >
>> > Perhaps we can just handle this through the regular patch review
>> > process; I think it may be difficult to define and agree upon exactly
>> > what "abuse" means ahead of time, but it's probably going to be easy
>> > enough to recognize it when one sees it?
>>
>>
>> One of the ways it could get out of hand would be via "include
>> dependency hell".  People will be tempted to reuse existing .h files
>> containing pin definitions, which, if history is a guide, will end up
>> depending on all sorts of other .h files.
>>
>> Another problem I often face with symbolic names is the difficulty of
>> figuring out what the numerical values really are (for debugging),
>> especially when .h files are in different subtrees from the files that
>> use the definitions, and when they use multiple macro levels and fancy
>> features like concatenation.  Sometimes I think it's clearer just to
>> write the number and use a comment to say what it is.
> 
> Both comments apply just as well to ordinary C code, and I don't think
> anyone would seriously suggest just using comments instead for C code.
> 
> Is there a way to ask CPP to evaluate a macro in the context of the
> input file, rather than produce normal output?  If not, I guess you
> could make a tool that creates a wrapper file that includes the main
> file and then evaluates the symbol you want.

I'm not sure what "evaluate a macro in the context of the input file"
means. Macros are obviously already evaluated based on the current set
of macros defined by the file that's been processed or those it
included. Do you mean only allowing the use of macros in the current
file and not included files? What exactly would the wrapper you
mentioned do?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 10, 2012, at 1:24 AM, David Gibson wrote:

> On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
>> 
>> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
>> 
>>> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>> 
>>> What more do you think needs discussion re: dtc+cpp?
>> 
>> How not to abuse the ever-loving shit out of it? :-)
> 
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via "include
 dependency hell".  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
>>> 
>>> Both comments apply just as well to ordinary C code, and I don't think 
>>> anyone would seriously suggest just using comments instead for C code.
>> 
>> .h files include both structs and defines, which are fine for
>> ordinary C code, but problematic in this context.
> 
> Right, cpp should be invoked with similar options to the way it's done
> for asm files which have the same problem.  I'm not sure if the
> current patch does so.

I know the current dtc code is very careful to license itself in a very 
agnostic way.  Would including files, possibly from the Linux kernel, pose any 
kind of license issue?  Or does the fact that many (but not all) .dts files 
being apparently licensed GPL already make this a moot point?  Or does it not 
matter since this is an interface and declaration of information, which likely 
isn't creative enough to receive to copyright protection  Or is this a can 
of worms best avoided :)

Warner--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
> 
> On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
> 
> > On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
> >> On 10/9/2012 11:16 AM, Stephen Warren wrote:
> >> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
> >> >>>
> >> >>> What more do you think needs discussion re: dtc+cpp?
> >> >>
> >> >> How not to abuse the ever-loving shit out of it? :-)
> >> >
> >> > Perhaps we can just handle this through the regular patch review
> >> > process; I think it may be difficult to define and agree upon exactly
> >> > what "abuse" means ahead of time, but it's probably going to be easy
> >> > enough to recognize it when one sees it?
> >> One of the ways it could get out of hand would be via "include
> >> dependency hell".  People will be tempted to reuse existing .h files
> >> containing pin definitions, which, if history is a guide, will end up
> >> depending on all sorts of other .h files.
> >> Another problem I often face with symbolic names is the difficulty of
> >> figuring out what the numerical values really are (for debugging),
> >> especially when .h files are in different subtrees from the files that
> >> use the definitions, and when they use multiple macro levels and fancy
> >> features like concatenation.  Sometimes I think it's clearer just to
> >> write the number and use a comment to say what it is.
> > 
> > Both comments apply just as well to ordinary C code, and I don't think 
> > anyone would seriously suggest just using comments instead for C code.
> 
> .h files include both structs and defines, which are fine for
> ordinary C code, but problematic in this context.

Right, cpp should be invoked with similar options to the way it's done
for asm files which have the same problem.  I'm not sure if the
current patch does so.

-- 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
 
 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
 
  On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
  On 10/9/2012 11:16 AM, Stephen Warren wrote:
   On 10/01/2012 12:39 PM, Jon Loeliger wrote:
  
   What more do you think needs discussion re: dtc+cpp?
  
   How not to abuse the ever-loving shit out of it? :-)
  
   Perhaps we can just handle this through the regular patch review
   process; I think it may be difficult to define and agree upon exactly
   what abuse means ahead of time, but it's probably going to be easy
   enough to recognize it when one sees it?
  One of the ways it could get out of hand would be via include
  dependency hell.  People will be tempted to reuse existing .h files
  containing pin definitions, which, if history is a guide, will end up
  depending on all sorts of other .h files.
  Another problem I often face with symbolic names is the difficulty of
  figuring out what the numerical values really are (for debugging),
  especially when .h files are in different subtrees from the files that
  use the definitions, and when they use multiple macro levels and fancy
  features like concatenation.  Sometimes I think it's clearer just to
  write the number and use a comment to say what it is.
  
  Both comments apply just as well to ordinary C code, and I don't think 
  anyone would seriously suggest just using comments instead for C code.
 
 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.

Right, cpp should be invoked with similar options to the way it's done
for asm files which have the same problem.  I'm not sure if the
current patch does so.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 10, 2012, at 1:24 AM, David Gibson wrote:

 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
 
 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
 
 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
 What more do you think needs discussion re: dtc+cpp?
 
 How not to abuse the ever-loving shit out of it? :-)
 
 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
 
 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.
 
 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.
 
 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.

I know the current dtc code is very careful to license itself in a very 
agnostic way.  Would including files, possibly from the Linux kernel, pose any 
kind of license issue?  Or does the fact that many (but not all) .dts files 
being apparently licensed GPL already make this a moot point?  Or does it not 
matter since this is an interface and declaration of information, which likely 
isn't creative enough to receive to copyright protection  Or is this a can 
of worms best avoided :)

Warner--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/09/2012 06:04 PM, Scott Wood wrote:
 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
  What more do you think needs discussion re: dtc+cpp?
 
  How not to abuse the ever-loving shit out of it? :-)
 
  Perhaps we can just handle this through the regular patch review
  process; I think it may be difficult to define and agree upon exactly
  what abuse means ahead of time, but it's probably going to be easy
  enough to recognize it when one sees it?


 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.

 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
 
 Both comments apply just as well to ordinary C code, and I don't think
 anyone would seriously suggest just using comments instead for C code.
 
 Is there a way to ask CPP to evaluate a macro in the context of the
 input file, rather than produce normal output?  If not, I guess you
 could make a tool that creates a wrapper file that includes the main
 file and then evaluates the symbol you want.

I'm not sure what evaluate a macro in the context of the input file
means. Macros are obviously already evaluated based on the current set
of macros defined by the file that's been processed or those it
included. Do you mean only allowing the use of macros in the current
file and not included files? What exactly would the wrapper you
mentioned do?

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:

 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.

 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.
 
 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.

That's probably a reasonable idea, although I imagined that people would
actually split out the portions of any header file they wanted to use
with dtc, so that any headers included by *.dts would only include
#defines. Those headers could be used by both dtc and other .h files (or
.c files).
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/10/2012 10:16 AM, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:

 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.

 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.

 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.
 
 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).

Used by what other files? kernel files? We ultimately want to split out
dts files from the kernel, so whatever we add needs to be self
contained. I don't see this as a huge issue though because the whole
point of the DT data is to move that information out of the kernel. If
it is needed in both places, then something is wrong.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Scott Wood]

On 10/10/2012 10:15:17 AM, Stephen Warren wrote:

On 10/09/2012 06:04 PM, Scott Wood wrote:
 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
  What more do you think needs discussion re: dtc+cpp?
 
  How not to abuse the ever-loving shit out of it? :-)
 
  Perhaps we can just handle this through the regular patch review
  process; I think it may be difficult to define and agree upon  
exactly
  what abuse means ahead of time, but it's probably going to be  
easy

  enough to recognize it when one sees it?


 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h  
files
 containing pin definitions, which, if history is a guide, will end  
up

 depending on all sorts of other .h files.

 Another problem I often face with symbolic names is the difficulty  
of

 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files  
that
 use the definitions, and when they use multiple macro levels and  
fancy
 features like concatenation.  Sometimes I think it's clearer just  
to

 write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't  
think
 anyone would seriously suggest just using comments instead for C  
code.


 Is there a way to ask CPP to evaluate a macro in the context of the
 input file, rather than produce normal output?  If not, I guess you
 could make a tool that creates a wrapper file that includes the main
 file and then evaluates the symbol you want.

I'm not sure what evaluate a macro in the context of the input file
means. Macros are obviously already evaluated based on the current set
of macros defined by the file that's been processed or those it
included. Do you mean only allowing the use of macros in the current
file and not included files? What exactly would the wrapper you
mentioned do?


I just meant a way for a developer to quickly ask the preprocessor what  
a particular macro expands to, rather than try to figure it out  
manually.  I was not suggesting any change to normal operation.


-Scott
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 09:33 AM, Rob Herring wrote:
 On 10/10/2012 10:16 AM, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:

 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.

 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.

 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.

 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).
 
 Used by what other files? kernel files? We ultimately want to split out
 dts files from the kernel, so whatever we add needs to be self
 contained. I don't see this as a huge issue though because the whole
 point of the DT data is to move that information out of the kernel. If
 it is needed in both places, then something is wrong.

One example is the IDs of the GPIOs, e.g.:

#define TEGRA_PIN_VI_GP6_PA0_GPIO(0)
#define TEGRA_PIN_UART3_CTS_N_PA1   _GPIO(1)
#define TEGRA_PIN_DAP2_FS_PA2   _GPIO(2)
#define TEGRA_PIN_DAP2_SCLK_PA3 _GPIO(3)

Those defines are useful to both the .dts files (so named constants can
be used) and the pinctrl driver. By using the same header file, we
guarantee that the .dts files and pinctrl driver use the exact same
naming for the pins; the pin naming/numbering being defined by the DT
binding more than anything else.

It'd be similarly useful to share GPIO or interrupt flag definitions,
etc. etc.

We could do something like we do for dtc today, where there's an
external repository for *.dts (and required *.h), yet those *.h are
duplicated into the kernel tree as needed by drivers.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 10:09 AM, Scott Wood wrote:
 On 10/10/2012 10:15:17 AM, Stephen Warren wrote:
 On 10/09/2012 06:04 PM, Scott Wood wrote:
  On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
  On 10/9/2012 11:16 AM, Stephen Warren wrote:
   On 10/01/2012 12:39 PM, Jon Loeliger wrote:
  
   What more do you think needs discussion re: dtc+cpp?
  
   How not to abuse the ever-loving shit out of it? :-)
  
   Perhaps we can just handle this through the regular patch review
   process; I think it may be difficult to define and agree upon
 exactly
   what abuse means ahead of time, but it's probably going to be easy
   enough to recognize it when one sees it?
 
 
  One of the ways it could get out of hand would be via include
  dependency hell.  People will be tempted to reuse existing .h files
  containing pin definitions, which, if history is a guide, will end up
  depending on all sorts of other .h files.
 
  Another problem I often face with symbolic names is the difficulty of
  figuring out what the numerical values really are (for debugging),
  especially when .h files are in different subtrees from the files that
  use the definitions, and when they use multiple macro levels and fancy
  features like concatenation.  Sometimes I think it's clearer just to
  write the number and use a comment to say what it is.
 
  Both comments apply just as well to ordinary C code, and I don't think
  anyone would seriously suggest just using comments instead for C code.
 
  Is there a way to ask CPP to evaluate a macro in the context of the
  input file, rather than produce normal output?  If not, I guess you
  could make a tool that creates a wrapper file that includes the main
  file and then evaluates the symbol you want.

 I'm not sure what evaluate a macro in the context of the input file
 means. Macros are obviously already evaluated based on the current set
 of macros defined by the file that's been processed or those it
 included. Do you mean only allowing the use of macros in the current
 file and not included files? What exactly would the wrapper you
 mentioned do?
 
 I just meant a way for a developer to quickly ask the preprocessor what
 a particular macro expands to, rather than try to figure it out
 manually.  I was not suggesting any change to normal operation.

Oh right. Well, the patch I proposed to the kernel was basically:

%.dtb: %.dtsp
cpp -E $ | dtc -o $@ -

A developer could run the same cpp -E command to find that out, or that
build rule could instead save the intermediate result rather than just
piping it, so you could just go read the file.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)
 
 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?

Rather than repeating things over and over in reviews, we should
document at least rules we can easily agree on and then add to it when
people get creative. Also, I can't keep up with every single binding
review as is, and this could just add another level of complexity to the
review. A few off the top of my head and from the thread discussion:

- Headers must be self contained with no outside (i.e. libc, kernel,
etc.) header dependencies.
- No kernel kconfig option usage
- No gcc built-in define usage
- No unused items (i.e. externs, structs, etc.)
- No macro concatenation
- No macros for strings or property names

Do we further restrict things to say defines are only numbers? One could
start to define complex macros to build the nodes themselves. If each
platform does this slightly differently, it will become difficult to
review and maintain. Then we will be doing dts consolidation. The fact
that we have some fixed structure and each SOC is not free to do things
their own way makes things easier to maintain. You don't have that in
the kernel across platforms. For example, look how register defines and
static mappings or platform device creation are done. They are all
similar, but yet slightly different. That makes doing changes across
platforms more difficult.

 I imagine the most common usage will simply be a bunch of:
 
 #define TEGRA_GPIO_PB0 32
 #define TEGRA_GPIO_INT_LEVEL_LOW 8
 
 / {
 xxx {
 interrupts = TEGRA_GPIO_PB0 TEGRA_GPIO_INT_LEVEL_LOW;
 
 and similarly, simple math:
 
 something = ((FOO  XXX_SHIFT) | (BAR  YYY_SHIFT));
 

These are all perfectly fine and sane use, but if we don't restrict
things then the next step is this:

#define PROP_SOMETHING(v) (something = (v))

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/10/2012 11:19 AM, Stephen Warren wrote:
 On 10/10/2012 09:33 AM, Rob Herring wrote:
 On 10/10/2012 10:16 AM, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:

 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.

 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.

 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.

 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).

 Used by what other files? kernel files? We ultimately want to split out
 dts files from the kernel, so whatever we add needs to be self
 contained. I don't see this as a huge issue though because the whole
 point of the DT data is to move that information out of the kernel. If
 it is needed in both places, then something is wrong.
 
 One example is the IDs of the GPIOs, e.g.:
 
 #define TEGRA_PIN_VI_GP6_PA0_GPIO(0)
 #define TEGRA_PIN_UART3_CTS_N_PA1   _GPIO(1)
 #define TEGRA_PIN_DAP2_FS_PA2   _GPIO(2)
 #define TEGRA_PIN_DAP2_SCLK_PA3 _GPIO(3)
 
 Those defines are useful to both the .dts files (so named constants can
 be used) and the pinctrl driver. By using the same header file, we
 guarantee that the .dts files and pinctrl driver use the exact same
 naming for the pins; the pin naming/numbering being defined by the DT
 binding more than anything else.

If pinctrl needs to get a matching name, then it should get it from the
dtb. We should not have 2 sources of data. That is just broken.

 
 It'd be similarly useful to share GPIO or interrupt flag definitions,
 etc. etc.
 
 We could do something like we do for dtc today, where there's an
 external repository for *.dts (and required *.h), yet those *.h are
 duplicated into the kernel tree as needed by drivers.

So as long as we only need to sync up about once a year that's fine
because we have yet to prove that doing it frequently for dtc will be
easy and painless.

I'd like fewer things to copy around, not more. If you have some
self-contained platform defines to copy, then it is your problem.

Rob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 7:09 AM, Rob Herring wrote:
 On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 
 Rather than repeating things over and over in reviews, we should
 document at least rules we can easily agree on and then add to it when
 people get creative. Also, I can't keep up with every single binding
 review as is, and this could just add another level of complexity to the
 review. A few off the top of my head and from the thread discussion:
 
 - Headers must be self contained with no outside (i.e. libc, kernel,
 etc.) header dependencies.
 - No kernel kconfig option usage
 - No gcc built-in define usage
 - No unused items (i.e. externs, structs, etc.)
 - No macro concatenation
 - No macros for strings or property names

Instead of making a bunch of rules about how you can only use a small
subset of cpp, why not just add a define name value command to DTC?

One of the things I like least about C is that the language itself is
incomplete; in order to actually program in C, you have to deal with not
only with the C syntactic structure, but also cpp, with its different
rules, and also make, with fundamentally different linguistic structure,
and then you end up wrapping that in something like KConfig, with yet
another linguistic framework, and the makefile contains embedded shell
commands, which is yet another syntax.

Rather than open Pandora's box by grafting on cpp, why not solve the
actual problem?


 
 Do we further restrict things to say defines are only numbers? One could
 start to define complex macros to build the nodes themselves. If each
 platform does this slightly differently, it will become difficult to
 review and maintain. Then we will be doing dts consolidation. The fact
 that we have some fixed structure and each SOC is not free to do things
 their own way makes things easier to maintain. You don't have that in
 the kernel across platforms. For example, look how register defines and
 static mappings or platform device creation are done. They are all
 similar, but yet slightly different. That makes doing changes across
 platforms more difficult.
 
 I imagine the most common usage will simply be a bunch of:

 #define TEGRA_GPIO_PB0 32
 #define TEGRA_GPIO_INT_LEVEL_LOW 8

 / {
 xxx {
 interrupts = TEGRA_GPIO_PB0 TEGRA_GPIO_INT_LEVEL_LOW;

 and similarly, simple math:

 something = ((FOO  XXX_SHIFT) | (BAR  YYY_SHIFT));

 
 These are all perfectly fine and sane use, but if we don't restrict
 things then the next step is this:
 
 #define PROP_SOMETHING(v) (something = (v))
 
 Rob
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 11:09 AM, Rob Herring wrote:
 On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 
 Rather than repeating things over and over in reviews, we should
 document at least rules we can easily agree on and then add to it when
 people get creative. Also, I can't keep up with every single binding
 review as is, and this could just add another level of complexity to the
 review. A few off the top of my head and from the thread discussion:
 
 - Headers must be self contained with no outside (i.e. libc, kernel,
 etc.) header dependencies.
 - No kernel kconfig option usage
 - No gcc built-in define usage
 - No unused items (i.e. externs, structs, etc.)

 - No macro concatenation

That seems to be potentially a very useful feature; I have no idea why
we would ban that; it isn't banned in C code in the kernel is it?

 - No macros for strings or property names

Property names I can understand. Property values - I can perhaps see a
use-case for...

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 11:18 AM, Rob Herring wrote:
 On 10/10/2012 11:19 AM, Stephen Warren wrote:
 On 10/10/2012 09:33 AM, Rob Herring wrote:
 On 10/10/2012 10:16 AM, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:

 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.

 Both comments apply just as well to ordinary C code, and I don't think 
 anyone would seriously suggest just using comments instead for C code.

 .h files include both structs and defines, which are fine for
 ordinary C code, but problematic in this context.

 Right, cpp should be invoked with similar options to the way it's done
 for asm files which have the same problem.  I'm not sure if the
 current patch does so.

 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).

 Used by what other files? kernel files? We ultimately want to split out
 dts files from the kernel, so whatever we add needs to be self
 contained. I don't see this as a huge issue though because the whole
 point of the DT data is to move that information out of the kernel. If
 it is needed in both places, then something is wrong.

 One example is the IDs of the GPIOs, e.g.:

 #define TEGRA_PIN_VI_GP6_PA0_GPIO(0)
 #define TEGRA_PIN_UART3_CTS_N_PA1   _GPIO(1)
 #define TEGRA_PIN_DAP2_FS_PA2   _GPIO(2)
 #define TEGRA_PIN_DAP2_SCLK_PA3 _GPIO(3)

 Those defines are useful to both the .dts files (so named constants can
 be used) and the pinctrl driver. By using the same header file, we
 guarantee that the .dts files and pinctrl driver use the exact same
 naming for the pins; the pin naming/numbering being defined by the DT
 binding more than anything else.
 
 If pinctrl needs to get a matching name, then it should get it from the
 dtb. We should not have 2 sources of data. That is just broken.

Why? The data is static and there's zero need for it to be in the DTB.
We've been over this already many times.

This is just like /any/ other header file usage. Something defines the
legal values. Various things need to use them. So, we define the values
in a header file, and both *.dts and *.c include them.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/10/2012 12:23 PM, Mitch Bradley wrote:
 On 10/10/2012 7:09 AM, Rob Herring wrote:
 On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?

 Rather than repeating things over and over in reviews, we should
 document at least rules we can easily agree on and then add to it when
 people get creative. Also, I can't keep up with every single binding
 review as is, and this could just add another level of complexity to the
 review. A few off the top of my head and from the thread discussion:

 - Headers must be self contained with no outside (i.e. libc, kernel,
 etc.) header dependencies.
 - No kernel kconfig option usage
 - No gcc built-in define usage
 - No unused items (i.e. externs, structs, etc.)
 - No macro concatenation
 - No macros for strings or property names
 
 Instead of making a bunch of rules about how you can only use a small
 subset of cpp, why not just add a define name value command to DTC?

I implemented a patch to do exactly that, and it was rejected because it
only solved part of the problem (named constants) and not the reset (a
completely generic macro language/... within dtc). The argument was that
defining just the named constant syntax on its own without knowing what
the unspecified future macro language will look like might result in the
named constant syntax not fitting into it.

That all said, I now think that using cpp is actually a much better
solution that adding yet more dtc-specific syntax. The *huge* benefit
here is that it allows you to share .h files between *.dts and C code,
so you don't have to write out the same set of #defines once in dtc
syntax and once in cpp syntax.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 8:40 AM, Stephen Warren wrote:
 On 10/10/2012 11:09 AM, Rob Herring wrote:
 On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?

 Rather than repeating things over and over in reviews, we should
 document at least rules we can easily agree on and then add to it when
 people get creative. Also, I can't keep up with every single binding
 review as is, and this could just add another level of complexity to the
 review. A few off the top of my head and from the thread discussion:

 - Headers must be self contained with no outside (i.e. libc, kernel,
 etc.) header dependencies.
 - No kernel kconfig option usage
 - No gcc built-in define usage
 - No unused items (i.e. externs, structs, etc.)
 
 - No macro concatenation
 
 That seems to be potentially a very useful feature; I have no idea why
 we would ban that; it isn't banned in C code in the kernel is it?

It's used in the kernel.  It is useful, but it has an unexpected side
effect that can be extremely annoying - it can make it extremely
difficult to find a definition with grep.  All the grep hits will be for
the fully-expanded uses of a symbol, while the definition is hidden by
virtue of being synthesized by concatenation.

Maybe it's not a big deal in a small project, but in a code base the
size of the Linux kernel, where you don't know a priori where something
is defined, it can make you want to tear your hair out.

 
 - No macros for strings or property names
 
 Property names I can understand. Property values - I can perhaps see a
 use-case for...
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 8:45 AM, Stephen Warren wrote:
 On 10/10/2012 12:23 PM, Mitch Bradley wrote:
 On 10/10/2012 7:09 AM, Rob Herring wrote:
 On 10/09/2012 04:16 PM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?

 Rather than repeating things over and over in reviews, we should
 document at least rules we can easily agree on and then add to it when
 people get creative. Also, I can't keep up with every single binding
 review as is, and this could just add another level of complexity to the
 review. A few off the top of my head and from the thread discussion:

 - Headers must be self contained with no outside (i.e. libc, kernel,
 etc.) header dependencies.
 - No kernel kconfig option usage
 - No gcc built-in define usage
 - No unused items (i.e. externs, structs, etc.)
 - No macro concatenation
 - No macros for strings or property names

 Instead of making a bunch of rules about how you can only use a small
 subset of cpp, why not just add a define name value command to DTC?
 
 I implemented a patch to do exactly that, and it was rejected because it
 only solved part of the problem (named constants) and not the reset (a
 completely generic macro language/... within dtc). The argument was that
 defining just the named constant syntax on its own without knowing what
 the unspecified future macro language will look like might result in the
 named constant syntax not fitting into it.
 
 That all said, I now think that using cpp is actually a much better
 solution that adding yet more dtc-specific syntax. The *huge* benefit
 here is that it allows you to share .h files between *.dts and C code,
 so you don't have to write out the same set of #defines once in dtc
 syntax and once in cpp syntax.

... and it imposes an equally *huge* restriction that you have to
restrict the .h file to avoid avoid C constructs.  That can be done, but
I've personally experienced a lot of headaches when trying to share .h
files between different languages.

 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 10:22:02AM -0600, Stephen Warren wrote:
 On 10/10/2012 10:09 AM, Scott Wood wrote:
  On 10/10/2012 10:15:17 AM, Stephen Warren wrote:
  On 10/09/2012 06:04 PM, Scott Wood wrote:
   On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
   On 10/9/2012 11:16 AM, Stephen Warren wrote:
On 10/01/2012 12:39 PM, Jon Loeliger wrote:
   
What more do you think needs discussion re: dtc+cpp?
   
How not to abuse the ever-loving shit out of it? :-)
   
Perhaps we can just handle this through the regular patch review
process; I think it may be difficult to define and agree upon
  exactly
what abuse means ahead of time, but it's probably going to be easy
enough to recognize it when one sees it?
  
  
   One of the ways it could get out of hand would be via include
   dependency hell.  People will be tempted to reuse existing .h files
   containing pin definitions, which, if history is a guide, will end up
   depending on all sorts of other .h files.
  
   Another problem I often face with symbolic names is the difficulty of
   figuring out what the numerical values really are (for debugging),
   especially when .h files are in different subtrees from the files that
   use the definitions, and when they use multiple macro levels and fancy
   features like concatenation.  Sometimes I think it's clearer just to
   write the number and use a comment to say what it is.
  
   Both comments apply just as well to ordinary C code, and I don't think
   anyone would seriously suggest just using comments instead for C code.
  
   Is there a way to ask CPP to evaluate a macro in the context of the
   input file, rather than produce normal output?  If not, I guess you
   could make a tool that creates a wrapper file that includes the main
   file and then evaluates the symbol you want.
 
  I'm not sure what evaluate a macro in the context of the input file
  means. Macros are obviously already evaluated based on the current set
  of macros defined by the file that's been processed or those it
  included. Do you mean only allowing the use of macros in the current
  file and not included files? What exactly would the wrapper you
  mentioned do?
  
  I just meant a way for a developer to quickly ask the preprocessor what
  a particular macro expands to, rather than try to figure it out
  manually.  I was not suggesting any change to normal operation.
 
 Oh right. Well, the patch I proposed to the kernel was basically:
 
 %.dtb: %.dtsp
 cpp -E $ | dtc -o $@ -
 
 A developer could run the same cpp -E command to find that out, or that
 build rule could instead save the intermediate result rather than just
 piping it, so you could just go read the file.

It would be nice to have a make target to actually do just that step,
even though it would usually only be invoked manually for debugging,
just as we have a %.i make target which can be used to see what the
preprocessor did to .c files.

And as stated elsewhere, cpp should be invoked with similar options to
the way it's done for asm files.  A -D__DTS__ or something like that
would probably be a good idea too, just in case some .h needs to be
conditional on that.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 08:41:45AM -0600, Warner Losh wrote:
 On Oct 10, 2012, at 1:24 AM, David Gibson wrote:
  On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
[snip]
  .h files include both structs and defines, which are fine for
  ordinary C code, but problematic in this context.
  
  Right, cpp should be invoked with similar options to the way it's done
  for asm files which have the same problem.  I'm not sure if the
  current patch does so.
 
 I know the current dtc code is very careful to license itself in a
 very agnostic way.  Would including files, possibly from the Linux
 kernel, pose any kind of license issue?  Or does the fact that many
 (but not all) .dts files being apparently licensed GPL already make
 this a moot point?  Or does it not matter since this is an interface
 and declaration of information, which likely isn't creative enough
 to receive to copyright protection  Or is this a can of worms
 best avoided :)

Um... what?  The licensing of dtc itself has nothing to do with the
licensing of the dts files used as input to it.  Those, and their
includes, would be licensed GPLv2 just like the rest of the kernel,
I'd expect.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 12:45:40PM -0600, Stephen Warren wrote:
 On 10/10/2012 12:23 PM, Mitch Bradley wrote:
  On 10/10/2012 7:09 AM, Rob Herring wrote:
  On 10/09/2012 04:16 PM, Stephen Warren wrote:
  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
  What more do you think needs discussion re: dtc+cpp?
 
  How not to abuse the ever-loving shit out of it? :-)
 
  Perhaps we can just handle this through the regular patch review
  process; I think it may be difficult to define and agree upon exactly
  what abuse means ahead of time, but it's probably going to be easy
  enough to recognize it when one sees it?
 
  Rather than repeating things over and over in reviews, we should
  document at least rules we can easily agree on and then add to it when
  people get creative. Also, I can't keep up with every single binding
  review as is, and this could just add another level of complexity to the
  review. A few off the top of my head and from the thread discussion:
 
  - Headers must be self contained with no outside (i.e. libc, kernel,
  etc.) header dependencies.
  - No kernel kconfig option usage
  - No gcc built-in define usage
  - No unused items (i.e. externs, structs, etc.)
  - No macro concatenation
  - No macros for strings or property names
  
  Instead of making a bunch of rules about how you can only use a small
  subset of cpp, why not just add a define name value command to DTC?
 
 I implemented a patch to do exactly that, and it was rejected because it

Well... more indefinitely postponed, rather than rejected.  Which you
would be entirely justified in seeing as a meaningless semantic
difference at this point.

 only solved part of the problem (named constants) and not the reset (a
 completely generic macro language/... within dtc). The argument was that
 defining just the named constant syntax on its own without knowing what
 the unspecified future macro language will look like might result in the
 named constant syntax not fitting into it.
 
 That all said, I now think that using cpp is actually a much better
 solution that adding yet more dtc-specific syntax. The *huge* benefit
 here is that it allows you to share .h files between *.dts and C code,
 so you don't have to write out the same set of #defines once in dtc
 syntax and once in cpp syntax.

Right, I tend to agree.  In addition to those reasons, it avoids
creating yet another micro-language, and it obeys the #1 guiding
principle for dts syntax which is don't surprise C programmers.

That said, there are a number of number of dtc extensions that would
make cpp-ability more useful.  The integer expression support that has
already gone in was a start on that, but richer expressions
(particularly strings and bytestrings) would be useful too.  Support
for invoking cpp automatically from within dtc would make that support
easier to use too.

I really would like to be working more actively on those things, but
unfortunately I don't have that much time free for dtc work.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
 On 10/10/2012 10:16 AM, Stephen Warren wrote:
  On 10/10/2012 01:24 AM, David Gibson wrote:
  On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
  On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
[snip]
  That's probably a reasonable idea, although I imagined that people would
  actually split out the portions of any header file they wanted to use
  with dtc, so that any headers included by *.dts would only include
  #defines. Those headers could be used by both dtc and other .h files (or
  .c files).
 
 Used by what other files? kernel files? We ultimately want to split out
 dts files from the kernel, so whatever we add needs to be self
 contained. I don't see this as a huge issue though because the whole
 point of the DT data is to move that information out of the kernel. If
 it is needed in both places, then something is wrong.

People get very hung up on this idea of having the DT move device
information out of the kernel, but that was never really the
motivation behind it.  Or at least, not the only or foremost
motivation.

The DT provides a consistent, flexible way of describing device
information.  That allows the core runtime the kernel to operate the
same way, regardless of how the DT information was obtained.  The DT
could come from firmware, but it could also come from an intermediate
bootloader or from early kernel code.  All are perfectly acceptable
options depending on the constraints of the platform.

The idea of firmware supplying the DT is much touted, but while it's a
theoretically nice idea, I think it's frequently a bad idea for
practical reasons.  Those being, in essence that a) firmware usually
sucks, b) it's usually harder (or at least no easier) to replace
firmware with a fixed version than the kernel/bootwrapper and c)
firmware usually *really* sucks.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 08:56:11AM -1000, Mitch Bradley wrote:
 On 10/10/2012 8:45 AM, Stephen Warren wrote:
  On 10/10/2012 12:23 PM, Mitch Bradley wrote:
  On 10/10/2012 7:09 AM, Rob Herring wrote:
  On 10/09/2012 04:16 PM, Stephen Warren wrote:
  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
[snip]
  Instead of making a bunch of rules about how you can only use a small
  subset of cpp, why not just add a define name value command to DTC?
  
  I implemented a patch to do exactly that, and it was rejected because it
  only solved part of the problem (named constants) and not the reset (a
  completely generic macro language/... within dtc). The argument was that
  defining just the named constant syntax on its own without knowing what
  the unspecified future macro language will look like might result in the
  named constant syntax not fitting into it.
  
  That all said, I now think that using cpp is actually a much better
  solution that adding yet more dtc-specific syntax. The *huge* benefit
  here is that it allows you to share .h files between *.dts and C code,
  so you don't have to write out the same set of #defines once in dtc
  syntax and once in cpp syntax.
 
 ... and it imposes an equally *huge* restriction that you have to
 restrict the .h file to avoid avoid C constructs.  That can be done, but
 I've personally experienced a lot of headaches when trying to share .h
 files between different languages.

Yes, but we already deal with that for asm files.  And the sorts of
defines we use in asm files are often the same ones we'd want in dts
files.


-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 09:16:34AM -0600, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
  On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
[snip]
  .h files include both structs and defines, which are fine for
  ordinary C code, but problematic in this context.
  
  Right, cpp should be invoked with similar options to the way it's done
  for asm files which have the same problem.  I'm not sure if the
  current patch does so.
 
 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).

Given that header files are right now frequently used in both .c and
.S for the #defines, I don't think we can reasonably expect
differently for dts files.  There certainly is the potential for
#include dependency mess, but we cope with it for .S so we can cope
with it for dts as well.

But cpp should definitely be invoked asm style for dts files.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/10/2012 1:16 PM, David Gibson wrote:
 On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
 On 10/10/2012 10:16 AM, Stephen Warren wrote:
 On 10/10/2012 01:24 AM, David Gibson wrote:
 On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
 On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
 [snip]
 That's probably a reasonable idea, although I imagined that people would
 actually split out the portions of any header file they wanted to use
 with dtc, so that any headers included by *.dts would only include
 #defines. Those headers could be used by both dtc and other .h files (or
 .c files).

 Used by what other files? kernel files? We ultimately want to split out
 dts files from the kernel, so whatever we add needs to be self
 contained. I don't see this as a huge issue though because the whole
 point of the DT data is to move that information out of the kernel. If
 it is needed in both places, then something is wrong.
 
 People get very hung up on this idea of having the DT move device
 information out of the kernel, but that was never really the
 motivation behind it.  Or at least, not the only or foremost
 motivation.
 
 The DT provides a consistent, flexible way of describing device
 information.  That allows the core runtime the kernel to operate the
 same way, regardless of how the DT information was obtained.  The DT
 could come from firmware, but it could also come from an intermediate
 bootloader or from early kernel code.  All are perfectly acceptable
 options depending on the constraints of the platform.
 
 The idea of firmware supplying the DT is much touted, but while it's a
 theoretically nice idea, I think it's frequently a bad idea for
 practical reasons.  Those being, in essence that a) firmware usually
 sucks, b) it's usually harder (or at least no easier) to replace
 firmware with a fixed version than the kernel/bootwrapper and c)
 firmware usually *really* sucks.
 

Gee, it sounds like you want firmware to suck.  Beating on the firmware
sucks drum is sort of a self-fulfilling prophecy, discouraging talented
programmers from doing firmware.  Who would want to work on something
that everyone knows sucks?

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[David Gibson]

On Wed, Oct 10, 2012 at 03:42:33PM -1000, Mitch Bradley wrote:
 On 10/10/2012 1:16 PM, David Gibson wrote:
  On Wed, Oct 10, 2012 at 10:33:31AM -0500, Rob Herring wrote:
  On 10/10/2012 10:16 AM, Stephen Warren wrote:
  On 10/10/2012 01:24 AM, David Gibson wrote:
  On Tue, Oct 09, 2012 at 10:43:50PM -0600, Warner Losh wrote:
  On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:
  [snip]
  That's probably a reasonable idea, although I imagined that people would
  actually split out the portions of any header file they wanted to use
  with dtc, so that any headers included by *.dts would only include
  #defines. Those headers could be used by both dtc and other .h files (or
  .c files).
 
  Used by what other files? kernel files? We ultimately want to split out
  dts files from the kernel, so whatever we add needs to be self
  contained. I don't see this as a huge issue though because the whole
  point of the DT data is to move that information out of the kernel. If
  it is needed in both places, then something is wrong.
  
  People get very hung up on this idea of having the DT move device
  information out of the kernel, but that was never really the
  motivation behind it.  Or at least, not the only or foremost
  motivation.
  
  The DT provides a consistent, flexible way of describing device
  information.  That allows the core runtime the kernel to operate the
  same way, regardless of how the DT information was obtained.  The DT
  could come from firmware, but it could also come from an intermediate
  bootloader or from early kernel code.  All are perfectly acceptable
  options depending on the constraints of the platform.
  
  The idea of firmware supplying the DT is much touted, but while it's a
  theoretically nice idea, I think it's frequently a bad idea for
  practical reasons.  Those being, in essence that a) firmware usually
  sucks, b) it's usually harder (or at least no easier) to replace
  firmware with a fixed version than the kernel/bootwrapper and c)
  firmware usually *really* sucks.
 
 Gee, it sounds like you want firmware to suck.  Beating on the firmware
 sucks drum is sort of a self-fulfilling prophecy, discouraging talented
 programmers from doing firmware.  Who would want to work on something
 that everyone knows sucks?

At this point it's already fulfilled.  Unfortunately, it really
doesn't matter how many more nice firmwares appear, once you have to
support the shitty ones - which we already do - the damage is done.

-- 
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
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

> On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
>> On 10/9/2012 11:16 AM, Stephen Warren wrote:
>> > On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>> >>>
>> >>> What more do you think needs discussion re: dtc+cpp?
>> >>
>> >> How not to abuse the ever-loving shit out of it? :-)
>> >
>> > Perhaps we can just handle this through the regular patch review
>> > process; I think it may be difficult to define and agree upon exactly
>> > what "abuse" means ahead of time, but it's probably going to be easy
>> > enough to recognize it when one sees it?
>> One of the ways it could get out of hand would be via "include
>> dependency hell".  People will be tempted to reuse existing .h files
>> containing pin definitions, which, if history is a guide, will end up
>> depending on all sorts of other .h files.
>> Another problem I often face with symbolic names is the difficulty of
>> figuring out what the numerical values really are (for debugging),
>> especially when .h files are in different subtrees from the files that
>> use the definitions, and when they use multiple macro levels and fancy
>> features like concatenation.  Sometimes I think it's clearer just to
>> write the number and use a comment to say what it is.
> 
> Both comments apply just as well to ordinary C code, and I don't think anyone 
> would seriously suggest just using comments instead for C code.

.h files include both structs and defines, which are fine for ordinary C code, 
but problematic in this context.

> Is there a way to ask CPP to evaluate a macro in the context of the input 
> file, rather than produce normal output?  If not, I guess you could make a 
> tool that creates a wrapper file that includes the main file and then 
> evaluates the symbol you want.

Not in the standard CPP, but perhaps you could scan the .dts file for all the 
values you need, and have it output the right values to use.

Warner--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Scott Wood]

On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:

On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
>
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon  
exactly

> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?


One of the ways it could get out of hand would be via "include
dependency hell".  People will be tempted to reuse existing .h files
containing pin definitions, which, if history is a guide, will end up
depending on all sorts of other .h files.

Another problem I often face with symbolic names is the difficulty of
figuring out what the numerical values really are (for debugging),
especially when .h files are in different subtrees from the files that
use the definitions, and when they use multiple macro levels and fancy
features like concatenation.  Sometimes I think it's clearer just to
write the number and use a comment to say what it is.


Both comments apply just as well to ordinary C code, and I don't think  
anyone would seriously suggest just using comments instead for C code.


Is there a way to ask CPP to evaluate a macro in the context of the  
input file, rather than produce normal output?  If not, I guess you  
could make a tool that creates a wrapper file that includes the main  
file and then evaluates the symbol you want.


-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/9/2012 11:16 AM, Stephen Warren wrote:
> On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>>
>>> What more do you think needs discussion re: dtc+cpp?
>>
>> How not to abuse the ever-loving shit out of it? :-)
> 
> Perhaps we can just handle this through the regular patch review
> process; I think it may be difficult to define and agree upon exactly
> what "abuse" means ahead of time, but it's probably going to be easy
> enough to recognize it when one sees it?


One of the ways it could get out of hand would be via "include
dependency hell".  People will be tempted to reuse existing .h files
containing pin definitions, which, if history is a guide, will end up
depending on all sorts of other .h files.

Another problem I often face with symbolic names is the difficulty of
figuring out what the numerical values really are (for debugging),
especially when .h files are in different subtrees from the files that
use the definitions, and when they use multiple macro levels and fancy
features like concatenation.  Sometimes I think it's clearer just to
write the number and use a comment to say what it is.


> 
> I imagine the most common usage will simply be a bunch of:
> 
> #define TEGRA_GPIO_PB0 32
> #define TEGRA_GPIO_INT_LEVEL_LOW 8
> 
> / {
> xxx {
> interrupts = ;
> 
> and similarly, simple math:
> 
> something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;
> 
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/01/2012 12:39 PM, Jon Loeliger wrote:
>>
>> What more do you think needs discussion re: dtc+cpp?
> 
> How not to abuse the ever-loving shit out of it? :-)

Perhaps we can just handle this through the regular patch review
process; I think it may be difficult to define and agree upon exactly
what "abuse" means ahead of time, but it's probably going to be easy
enough to recognize it when one sees it?

I imagine the most common usage will simply be a bunch of:

#define TEGRA_GPIO_PB0 32
#define TEGRA_GPIO_INT_LEVEL_LOW 8

/ {
xxx {
interrupts = ;

and similarly, simple math:

something = <((FOO << XXX_SHIFT) | (BAR << YYY_SHIFT))>;

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?
 
 How not to abuse the ever-loving shit out of it? :-)

Perhaps we can just handle this through the regular patch review
process; I think it may be difficult to define and agree upon exactly
what abuse means ahead of time, but it's probably going to be easy
enough to recognize it when one sees it?

I imagine the most common usage will simply be a bunch of:

#define TEGRA_GPIO_PB0 32
#define TEGRA_GPIO_INT_LEVEL_LOW 8

/ {
xxx {
interrupts = TEGRA_GPIO_PB0 TEGRA_GPIO_INT_LEVEL_LOW;

and similarly, simple math:

something = ((FOO  XXX_SHIFT) | (BAR  YYY_SHIFT));

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Mitch Bradley]

On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)
 
 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon exactly
 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?


One of the ways it could get out of hand would be via include
dependency hell.  People will be tempted to reuse existing .h files
containing pin definitions, which, if history is a guide, will end up
depending on all sorts of other .h files.

Another problem I often face with symbolic names is the difficulty of
figuring out what the numerical values really are (for debugging),
especially when .h files are in different subtrees from the files that
use the definitions, and when they use multiple macro levels and fancy
features like concatenation.  Sometimes I think it's clearer just to
write the number and use a comment to say what it is.


 
 I imagine the most common usage will simply be a bunch of:
 
 #define TEGRA_GPIO_PB0 32
 #define TEGRA_GPIO_INT_LEVEL_LOW 8
 
 / {
 xxx {
 interrupts = TEGRA_GPIO_PB0 TEGRA_GPIO_INT_LEVEL_LOW;
 
 and similarly, simple math:
 
 something = ((FOO  XXX_SHIFT) | (BAR  YYY_SHIFT));
 
 ___
 devicetree-discuss mailing list
 devicetree-disc...@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/devicetree-discuss
 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Scott Wood]

On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:

On 10/9/2012 11:16 AM, Stephen Warren wrote:
 On 10/01/2012 12:39 PM, Jon Loeliger wrote:

 What more do you think needs discussion re: dtc+cpp?

 How not to abuse the ever-loving shit out of it? :-)

 Perhaps we can just handle this through the regular patch review
 process; I think it may be difficult to define and agree upon  
exactly

 what abuse means ahead of time, but it's probably going to be easy
 enough to recognize it when one sees it?


One of the ways it could get out of hand would be via include
dependency hell.  People will be tempted to reuse existing .h files
containing pin definitions, which, if history is a guide, will end up
depending on all sorts of other .h files.

Another problem I often face with symbolic names is the difficulty of
figuring out what the numerical values really are (for debugging),
especially when .h files are in different subtrees from the files that
use the definitions, and when they use multiple macro levels and fancy
features like concatenation.  Sometimes I think it's clearer just to
write the number and use a comment to say what it is.


Both comments apply just as well to ordinary C code, and I don't think  
anyone would seriously suggest just using comments instead for C code.


Is there a way to ask CPP to evaluate a macro in the context of the  
input file, rather than produce normal output?  If not, I guess you  
could make a tool that creates a wrapper file that includes the main  
file and then evaluates the symbol you want.


-Scott
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Warner Losh]

On Oct 9, 2012, at 6:04 PM, Scott Wood wrote:

 On 10/09/2012 06:20:53 PM, Mitch Bradley wrote:
 On 10/9/2012 11:16 AM, Stephen Warren wrote:
  On 10/01/2012 12:39 PM, Jon Loeliger wrote:
 
  What more do you think needs discussion re: dtc+cpp?
 
  How not to abuse the ever-loving shit out of it? :-)
 
  Perhaps we can just handle this through the regular patch review
  process; I think it may be difficult to define and agree upon exactly
  what abuse means ahead of time, but it's probably going to be easy
  enough to recognize it when one sees it?
 One of the ways it could get out of hand would be via include
 dependency hell.  People will be tempted to reuse existing .h files
 containing pin definitions, which, if history is a guide, will end up
 depending on all sorts of other .h files.
 Another problem I often face with symbolic names is the difficulty of
 figuring out what the numerical values really are (for debugging),
 especially when .h files are in different subtrees from the files that
 use the definitions, and when they use multiple macro levels and fancy
 features like concatenation.  Sometimes I think it's clearer just to
 write the number and use a comment to say what it is.
 
 Both comments apply just as well to ordinary C code, and I don't think anyone 
 would seriously suggest just using comments instead for C code.

.h files include both structs and defines, which are fine for ordinary C code, 
but problematic in this context.

 Is there a way to ask CPP to evaluate a macro in the context of the input 
 file, rather than produce normal output?  If not, I guess you could make a 
 tool that creates a wrapper file that includes the main file and then 
 evaluates the symbol you want.

Not in the standard CPP, but perhaps you could scan the .dts file for all the 
values you need, and have it output the right values to use.

Warner--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Jon Loeliger]

> 
> What more do you think needs discussion re: dtc+cpp?

How not to abuse the ever-loving shit out of it? :-)

jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/01/2012 11:56 AM, Rob Herring wrote:
> On 10/01/2012 11:13 AM, Stephen Warren wrote:
>> On 10/01/2012 10:09 AM, Rob Herring wrote:
>>> On 09/28/2012 04:25 PM, Stephen Warren wrote:
 From: Stephen Warren 

 This updates scripts/dtc to commit 317a5d9 "dtc: zero out new label
 objects" from git://git.jdl.com/software/dtc.git.

 This adds features such as:
 * /bits/ syntax for cell data.
 * Math expressions within cell data.
 * The ability to delete properties or nodes.
 * Support for #line directives in the input file, which allows the use of
   cpp on *.dts.
 * -i command-line option (/include/ path)
 * -W/-E command-line options for error/warning control.
 * Removal of spew to STDOUT containing the filename being compiled.
 * Many additions to the libfdt API.

 Signed-off-by: Stephen Warren 
>>>
>>> Seems dtc doesn't really have a maintainer. Probably makes more sense
>>> for me to take this unless there are objections.
>>
>> Will you also take the two kbuild patches I posted that depend on this
>> (e.g. "kbuild: introduce cmd_dtc_cpp")? I'd assumed that Michal Marek
>> would take this given the dependencies and that he's take a fair number
>> of dtc patches recently.
> 
> No. I think whether we use the cpp preprocessor or not needs more time
> to discuss and some level of agreement. So I don't think it is 3.7 material.

Oh, you were planning on taking the dtc update into 3.7? I had assumed
you meant for 3.8. There wouldn't be any dependencies if you take the
dtc update now, so it'd probably be fine.

What more do you think needs discussion re: dtc+cpp?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Jon Loeliger]

> 
> Seems dtc doesn't really have a maintainer. 

Picking nits, let's be clear on that phraseology:

Seems dtc doesn't really have a maintainer
within the kernel repository.

Over in git.jdl.com land, there is a well established
maintainer for the upstream DTC.

> Probably makes more sense
> for me to take this unless there are objections.

Please, and thank you.

jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/01/2012 11:13 AM, Stephen Warren wrote:
> On 10/01/2012 10:09 AM, Rob Herring wrote:
>> On 09/28/2012 04:25 PM, Stephen Warren wrote:
>>> From: Stephen Warren 
>>>
>>> This updates scripts/dtc to commit 317a5d9 "dtc: zero out new label
>>> objects" from git://git.jdl.com/software/dtc.git.
>>>
>>> This adds features such as:
>>> * /bits/ syntax for cell data.
>>> * Math expressions within cell data.
>>> * The ability to delete properties or nodes.
>>> * Support for #line directives in the input file, which allows the use of
>>>   cpp on *.dts.
>>> * -i command-line option (/include/ path)
>>> * -W/-E command-line options for error/warning control.
>>> * Removal of spew to STDOUT containing the filename being compiled.
>>> * Many additions to the libfdt API.
>>>
>>> Signed-off-by: Stephen Warren 
>>
>> Seems dtc doesn't really have a maintainer. Probably makes more sense
>> for me to take this unless there are objections.
> 
> Will you also take the two kbuild patches I posted that depend on this
> (e.g. "kbuild: introduce cmd_dtc_cpp")? I'd assumed that Michal Marek
> would take this given the dependencies and that he's take a fair number
> of dtc patches recently.

No. I think whether we use the cpp preprocessor or not needs more time
to discuss and some level of agreement. So I don't think it is 3.7 material.

Rob

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/01/2012 10:09 AM, Rob Herring wrote:
> On 09/28/2012 04:25 PM, Stephen Warren wrote:
>> From: Stephen Warren 
>>
>> This updates scripts/dtc to commit 317a5d9 "dtc: zero out new label
>> objects" from git://git.jdl.com/software/dtc.git.
>>
>> This adds features such as:
>> * /bits/ syntax for cell data.
>> * Math expressions within cell data.
>> * The ability to delete properties or nodes.
>> * Support for #line directives in the input file, which allows the use of
>>   cpp on *.dts.
>> * -i command-line option (/include/ path)
>> * -W/-E command-line options for error/warning control.
>> * Removal of spew to STDOUT containing the filename being compiled.
>> * Many additions to the libfdt API.
>>
>> Signed-off-by: Stephen Warren 
> 
> Seems dtc doesn't really have a maintainer. Probably makes more sense
> for me to take this unless there are objections.

Will you also take the two kbuild patches I posted that depend on this
(e.g. "kbuild: introduce cmd_dtc_cpp")? I'd assumed that Michal Marek
would take this given the dependencies and that he's take a fair number
of dtc patches recently.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/01/2012 10:09 AM, Rob Herring wrote:
 On 09/28/2012 04:25 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 This updates scripts/dtc to commit 317a5d9 dtc: zero out new label
 objects from git://git.jdl.com/software/dtc.git.

 This adds features such as:
 * /bits/ syntax for cell data.
 * Math expressions within cell data.
 * The ability to delete properties or nodes.
 * Support for #line directives in the input file, which allows the use of
   cpp on *.dts.
 * -i command-line option (/include/ path)
 * -W/-E command-line options for error/warning control.
 * Removal of spew to STDOUT containing the filename being compiled.
 * Many additions to the libfdt API.

 Signed-off-by: Stephen Warren swar...@nvidia.com
 
 Seems dtc doesn't really have a maintainer. Probably makes more sense
 for me to take this unless there are objections.

Will you also take the two kbuild patches I posted that depend on this
(e.g. kbuild: introduce cmd_dtc_cpp)? I'd assumed that Michal Marek
would take this given the dependencies and that he's take a fair number
of dtc patches recently.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Rob Herring]

On 10/01/2012 11:13 AM, Stephen Warren wrote:
 On 10/01/2012 10:09 AM, Rob Herring wrote:
 On 09/28/2012 04:25 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 This updates scripts/dtc to commit 317a5d9 dtc: zero out new label
 objects from git://git.jdl.com/software/dtc.git.

 This adds features such as:
 * /bits/ syntax for cell data.
 * Math expressions within cell data.
 * The ability to delete properties or nodes.
 * Support for #line directives in the input file, which allows the use of
   cpp on *.dts.
 * -i command-line option (/include/ path)
 * -W/-E command-line options for error/warning control.
 * Removal of spew to STDOUT containing the filename being compiled.
 * Many additions to the libfdt API.

 Signed-off-by: Stephen Warren swar...@nvidia.com

 Seems dtc doesn't really have a maintainer. Probably makes more sense
 for me to take this unless there are objections.
 
 Will you also take the two kbuild patches I posted that depend on this
 (e.g. kbuild: introduce cmd_dtc_cpp)? I'd assumed that Michal Marek
 would take this given the dependencies and that he's take a fair number
 of dtc patches recently.

No. I think whether we use the cpp preprocessor or not needs more time
to discuss and some level of agreement. So I don't think it is 3.7 material.

Rob

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Jon Loeliger]

 
 Seems dtc doesn't really have a maintainer. 

Picking nits, let's be clear on that phraseology:

Seems dtc doesn't really have a maintainer
within the kernel repository.

Over in git.jdl.com land, there is a well established
maintainer for the upstream DTC.

 Probably makes more sense
 for me to take this unless there are objections.

Please, and thank you.

jdl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Stephen Warren]

On 10/01/2012 11:56 AM, Rob Herring wrote:
 On 10/01/2012 11:13 AM, Stephen Warren wrote:
 On 10/01/2012 10:09 AM, Rob Herring wrote:
 On 09/28/2012 04:25 PM, Stephen Warren wrote:
 From: Stephen Warren swar...@nvidia.com

 This updates scripts/dtc to commit 317a5d9 dtc: zero out new label
 objects from git://git.jdl.com/software/dtc.git.

 This adds features such as:
 * /bits/ syntax for cell data.
 * Math expressions within cell data.
 * The ability to delete properties or nodes.
 * Support for #line directives in the input file, which allows the use of
   cpp on *.dts.
 * -i command-line option (/include/ path)
 * -W/-E command-line options for error/warning control.
 * Removal of spew to STDOUT containing the filename being compiled.
 * Many additions to the libfdt API.

 Signed-off-by: Stephen Warren swar...@nvidia.com

 Seems dtc doesn't really have a maintainer. Probably makes more sense
 for me to take this unless there are objections.

 Will you also take the two kbuild patches I posted that depend on this
 (e.g. kbuild: introduce cmd_dtc_cpp)? I'd assumed that Michal Marek
 would take this given the dependencies and that he's take a fair number
 of dtc patches recently.
 
 No. I think whether we use the cpp preprocessor or not needs more time
 to discuss and some level of agreement. So I don't think it is 3.7 material.

Oh, you were planning on taking the dtc update into 3.7? I had assumed
you meant for 3.8. There wouldn't be any dependencies if you take the
dtc update now, so it'd probably be fine.

What more do you think needs discussion re: dtc+cpp?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dtc: import latest upstream dtc

[Jon Loeliger]

 
 What more do you think needs discussion re: dtc+cpp?

How not to abuse the ever-loving shit out of it? :-)

jdl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dtc: import latest upstream dtc

[Jon Loeliger]

> From: Stephen Warren 
> 
> This updates scripts/dtc to commit 317a5d9 "dtc: zero out new label
> objects" from git://git.jdl.com/software/dtc.git.
> 
> This adds features such as:
> * /bits/ syntax for cell data.
> * Math expressions within cell data.
> * The ability to delete properties or nodes.
> * Support for #line directives in the input file, which allows the use of
>   cpp on *.dts.
> * -i command-line option (/include/ path)
> * -W/-E command-line options for error/warning control.
> * Removal of spew to STDOUT containing the filename being compiled.
> * Many additions to the libfdt API.
> 
> Signed-off-by: Stephen Warren 

For what it might be worth:

Acked-by: Jon Loeliger 

jdl
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] dtc: import latest upstream dtc

[Jon Loeliger]

 From: Stephen Warren swar...@nvidia.com
 
 This updates scripts/dtc to commit 317a5d9 dtc: zero out new label
 objects from git://git.jdl.com/software/dtc.git.
 
 This adds features such as:
 * /bits/ syntax for cell data.
 * Math expressions within cell data.
 * The ability to delete properties or nodes.
 * Support for #line directives in the input file, which allows the use of
   cpp on *.dts.
 * -i command-line option (/include/ path)
 * -W/-E command-line options for error/warning control.
 * Removal of spew to STDOUT containing the filename being compiled.
 * Many additions to the libfdt API.
 
 Signed-off-by: Stephen Warren swar...@nvidia.com

For what it might be worth:

Acked-by: Jon Loeliger j...@jdl.com

jdl
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/