RE: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions

Simon Glass wrote at Tuesday, January 24, 2012 4:12 PM:

On Mon, Jan 23, 2012 at 10:18 AM, Stephen Warren [off-list ref] wrote:

quoted

On 01/21/2012 10:08 AM, Simon Glass wrote:

quoted

Hi Stephen,

On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren [off-list ref] wrote:

quoted

On 01/11/2012 09:32 PM, Simon Glass wrote:

quoted

This adds some support into fdtdec for reading GPIO definitions from
the fdt. ...

...

quoted

quoted

quoted

diff --git a/include/fdtdec.h b/include/fdtdec.h

...

quoted

+/* GPIOs are numbered from 0 */
+enum {
+     FDT_GPIO_NONE = -1U,    /* an invalid GPIO used to end our list */

Is this due to the way U-Boot works right now, or something defined by
this patch? It's been pointed out that the kernel's choice to use -1 as
"invalid GPIO" rather than 0 was a mistake, since that prevents GPIO
fields being easily added to platform data structures, since you then
have to go and initialize every new instance to -1, rather than relying
on BSS initializing it to 0. I assume this is just the way U-Boot works,
so solving this is outside the scope of this patch.

It is nothing to do with U-Boot itself - we can choose any number.

Surely the value you choose for DT parsing has to align with the value
that U-Boot's GPIO API chooses, so you can't just choose any number.

No, in the fdt we just leave out the gpio if it is not required. The
FDT_GPIO_NONE is purely internal to U-Boot.

That's consistent with what I said; I'm talking about the value that a
missing DT property translates into within U-Boot.

-- 
nvpublic