From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: How about a gpio_get(device *, char *) function? Date: Thu, 29 Nov 2012 17:34:07 +0000 Message-ID: <20121129173407.11A543E0A04@localhost> References: <38620644.IyR5R8rjKP@percival> <20121126111431.AE4C23E09C2@localhost> <2022442.P80mCjSeu2@percival> Return-path: In-Reply-To: <2022442.P80mCjSeu2@percival> Sender: linux-kernel-owner@vger.kernel.org To: Alex Courbot Cc: Linus Walleij , Stephen Warren , "devicetree-discuss@lists.ozlabs.org" , "linux-kernel@vger.kernel.org" List-Id: devicetree@vger.kernel.org On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot wrote: > On Monday 26 November 2012 19:14:31 Grant Likely wrote: > > I don't have any problem with a gpio_get function, but I do agree that > > making it return an opaque handle is how it should be written with a new > > set of accessors. The handle should probably be simply the pointer to > > the &gpio_desc[number] which is a private table in gpiolib.c. The > > definition of it isn't available outside of gpiolib.c > > That looks like a reasonable approach, but this would make the new API > available only to systems that use GPIOlib. Shouldn't we be concerned about > making this available to all GPIO implementations? Or is GPIOlib so widely > used that we don't care? I'm tempted to say non-gpiolib is not supported. However, there isn't anything that would prevent non-gpiolib users from implementing the api themselves, but they'd need to provide their own handle.. g.