From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Subject: Re: [PATCH v4 03/20] fdt: Add basic support for decoding GPIO definitions Date: Mon, 23 Jan 2012 11:18:56 -0700 Message-ID: <4F1DA490.6090903@nvidia.com> References: <1326342789-5781-1-git-send-email-sjg@chromium.org> <1326342789-5781-4-git-send-email-sjg@chromium.org> <4F1744FE.4090409@nvidia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: Simon Glass Cc: U-Boot Mailing List , Devicetree Discuss , Tom Warren , Jerry Van Baren List-Id: devicetree@vger.kernel.org On 01/21/2012 10:08 AM, Simon Glass wrote: > Hi Stephen, > > On Wed, Jan 18, 2012 at 2:17 PM, Stephen Warren wrote: >> On 01/11/2012 09:32 PM, Simon Glass wrote: >>> This adds some support into fdtdec for reading GPIO definitions from >>> the fdt. ... ... >>> diff --git a/include/fdtdec.h b/include/fdtdec.h >> ... >>> +/* 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. > What is Linux using now / planning to use? Linux uses -1 right now, but should really have used 0. I don't think there's an actual plan to change this now, since the numbering scheme is entrenched. What Linux does isn't relevant; the numbering scheme I'm talking about is the internal numbering scheme within U-Boot or Linux, which are independent from each-other and the values in the device tree. So that said, I was wondering if U-Boot's GPIO support (covering both non-DT and DT cases) was new enough that it could use 0 to represent "invalid GPIO" rather than -1, and hence FDT_GPIO_NONE be 0 not -1. It probably isn't though; I guess U-Boot's GPIO numbering scheme is also already entrenched? -- nvpublic