Good! I suspect most folk who've had to work on a few different
embedded Linux boards have noticed lots of needlessly-different
GPIO code. Not many folk are actually seeing that as more than
The _interface_ allows those additional GPIO controllers though.
Specifically of the type you mentioned ... that's why this version
You used the key word: implementation. The interface allows it,
but such board-specific extensions haven't yet been needed; so
they've not yet been implemented.
See the appended for a patch roughly along the lines of what has
previously been discussed here. No interface change, just updated
implementation code. And the additional implementation logic won't
kick on boards that don't need it.
Note that the current implementations are a win even without yet
being able to handle the board-specific external GPIO controllers.
The API is clearer than chip-specific register access, and since
it's arch-neutral it already solves integration problems (like
One approach: updating implementations along the lines the patch below.
Other implementations could work too.
Note that I see that kind of update as happening after the first round
of patches go upstream: accept the interface first, then update boards
to support it ... including later the cansleep calls, on some boards.
I like the idea of first replacing the "old" GPIO accesses with ones
using the new APIs ... and only then starting to convert old I2C (etc)
An example showing one way to implement that interface ... appended.
The expanders would be board-specific, not arch/.../mach-* specific.
(I try to avoid using the word "machine" there; it's too ambiguous.)
The code below just show how boards could plug in; it doesn't actually
convert any boards to use that infrastructure. It should be obvious
how to do that, if you've got a board needing it which works with the
kernel.org GIT tree...
- Dave
================= CUT HERE
Preliminary version of support for board-specific declaring GPIO contro...
