New GPIO API from upstream

[Joel Stanley]

Hey Eddie,

On Tue, Feb 28, 2017 at 9:20 AM, Edward James <eajames at us.ibm.com> wrote:
> I think we have some people interested in using the new GPIO chardev API
> (Matt? Not sure who else).

Great!

I did some experimentation with the chardev API a few months ago -
attempting to replace the GPIO utilities in skeleton that use sysfs
with a the chardev API. As you know sysfs is great for bash scripts,
but is clunky to use from C or C++. However I didn't find it much of a
win.

That said, I am happy to support anyone who wants to give it a go.

> The new API provides some useful stuff like
> triggering events when a gpio line changes, etc.

Triggering from GPIO line changes is also possible with the sysfs API
- you can poll() on the sysfs file as described in the documentation:

 https://www.kernel.org/doc/Documentation/gpio/sysfs.txt

When we're dealing with inputs, another useful interface we can use
from the kernel is input events. We use the device tree to bind the
gpio-keys driver to the GPIO, and this gives us an input device to
read from:

 https://www.kernel.org/doc/Documentation/devicetree/bindings/input/gpio-keys.txt

> Problem is these changes are new since we branched off for dev-4.7. I have a
> list of commits I think we'd need, it's non-trivial, and I think there are
> some later commits that do some additional ioctl input checking.

> What do you think we should do? Hold off on any work using the new API until
> you rebase us to a later kernel release? Or do you want to patch dev-4.7?

I intended to move us to a 4.10 based tree last week. Due to our push
to get OpenFSI working, and other urgent tasks, that hasn't happened
yet. I hope to publish the tree this week.

I recommend that you start writing against the 4.10 APIs now. By the
time you have code ready to go we should be fine.

This will require solving a long-standing issue with userspace kernel
headers in our Yocto build. We build the userspace against the 4.4
kernel that Yocto ships, so you will lack the headers required to use
this API. I recommend we move openbmc to building against the compiler
and therefore the userspace headers against the same version of the
kernel as we use to boot the system.

Cheers,

Joel