I've got patches in my queue too, sigh ...
Thanks for the review. I'll snip out typos and similar trivial
comments (and fix them!), using responses here for more the
substantive feedback.
- Dave
I'll take that out, to avoid the question. The answer is still mostly
TBD, but the gpiolib infrastructure provides a number of the hooks
that such a userspace interface would need.
Updated description:
* @n_latch: optional bit-inverse of initial register value; if
* you leave this initialized to zero, the driver will treat
* all bits as inputs as if the chip was just reset
This chip is documented as being "pseudo-bidirectional", which is
a sign that there are some confusing mechanisms lurking...
Conventions for naming negative-true signals include a "#" suffix
(illegal for C), a overbar (not expressible in ASCII), and prefixes
including "/" (illegal for C) and "n" (aha!). I morphed the latter
into "n_" since it's often paired with all-caps signal names, as
in "nRESET", which are bad kernel coding style.
Latches hold values; http://en.wikipedia.org/wiki/Latch_%28electronics%29
talks about bit-level latching, but GPIO controllers use register-wide
latches to record the value that should be driven on output pins.
(As opposed to input pins, whose values are read without latching.)
It's a wierd little arrangement, maybe you have a better explanation.
I tried hitting the confusing points more directly:
* These GPIO chips are only "pseudo-bidirectional"; read the chip specs
* to understand the behavior. They don't have separate registers to
* record which pins are used for input or output, record which output
* values are driven, or provide access to input values. That must all
* be inferred by reading the chip's value and knowing the last value
* written to it. If you don't initialize n_latch, that last written
* value is presumed to be all ones (as if the chip were just reset).
For alphabetical order it would go much sooner.
GPIO precedes SENSOR. ;)
I'll do that -- but note that the names *are* spelled out later.
I was thinking more like <linux/i2c/...> myself. There are many more
I2C chips than GPIO expanders.
No can do; return types differ, which means that on some platforms
the calling conventions have significant differences.
To share (current code) three copies of the "<3>%s %s: %s --> %d\n"
string. Every little bit of kernel bloat prevention helps. ;)
-
