Re: How about a gpio_get(device *, char *) function?
From: Grant Likely <hidden>
Date: 2012-12-03 14:15:35
Also in:
lkml
On Sat, 1 Dec 2012 19:41:39 +0100, Linus Walleij [off-list ref] wrote:
On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely [off-list ref] wrote:quoted
On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot [off-list ref] wrote:quoted
On Monday 26 November 2012 19:14:31 Grant Likely wrote:quoted
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.cThat 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..I get the creeps when you say that ...
hahaha. Well, what else do we do? By definiton the custom implementations are custom. We've got no way to support them unless we cast the gpio number to the gpio handle in that case. That would work but it would be mighty ugly. g.