Thread (20 messages) 20 messages, 4 authors, 2012-12-03

Re: How about a gpio_get(device *, char *) function?

From: Linus Walleij <hidden>
Date: 2012-12-01 18:41:44
Also in: lkml

On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely [off-list ref] wrote:
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.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..
I get the creeps when you say that ...

Now I think I have to put on my TODO to remove a few custom GPIO
implementations so it feels better. ;-)

Yours,
Linus Walleij
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help