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-11-07 21:28:05
Also in: lkml

On Mon, Nov 5, 2012 at 6:35 PM, Stephen Warren [off-list ref] wrote:
[Me]
quoted
gpio_get() should get an abstract handle just like clk_get() or
regulator_get(), not a fixed numeral.
I don't really see why the return type of gpio_get() influences whether
it can be implemented or not.
It doesn't influence that, but I want to follow the opaqueness design
pattern from irq descriptors and struct clk.
With board files, some "gpio map" table would simply contain the same
int GPIO ID value the table as is used anywhere else already. With DT,
the same xlate function would translate from DT GPIO-chip-relative
IDs/specifiers into the global number space in the same way that we do
today via other APIs.
Yes, this part I buy into, just want to see how we can move forward
from there. The coplete nightmare is to introduce something into DT
that nails down a global GPIO numberspace... but I think that is not
the case atleast.
If the GPIO subsystem were reworked as you propose, this API could be
reworked in exactly the same way, or if implemented after the rework, it
would return whatever handle type was in use at the time.
Yes, I just think we should return an opaque struct from day 1, so
just a little, little bit more to shield us.

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