Is there a standard on Red Hat for GPIO usage?

Latest response

My company has developed a new GPIO board and I need to write a driver for it. I want to be as compatible as possible. In the general linux community I don't find a solid GPIO foundation. Is there a standard on Red Hat for GPIO usage and drivers? Where should I start? Thanks.

HF
Log in to join the conversation

Responses

Jamie Bainbridge's picture Red Hat Guru 7257 points
7 May 2018 10:48 PM

I haven't seen anything specifically in RHEL. The upstream kernel had an older sysfs interface but that is deprecated. The current suggested method is the character device interface maintained by Linus Walleij:

HF Community Member 85 points
8 May 2018 6:55 PM

Thanks. I've encountered this work by Linus Walleij independently.

Do you or anyone else know if the latest version of RHEL has had any of this new GPIO stuff built into a kernel? That is, is there compatible code? (Now, this next sentence is going to sound stupid, so bear with me.) I'm used to free linux and building kernels to suit my hardware. I'm new to paid linux, which I understand RHEL to be. Are we still building our own kernels in RHEL? (LOL, I'm actually hoping to hear "no", and that the new GPIO stuff is either in one or not, from RH.)

Jamie Bainbridge's picture Red Hat Guru 7257 points
9 May 2018 2:21 AM

That's a good question, I didn't think to check.

This new GPIO interface isn't backported to RHEL7. It is still using the old deprecated sysfs interface documented at:

You'll also find the RHEL-current version of that file in the kernel-doc package:

# rpm -q kernel-doc
kernel-doc-3.10.0-862.el7.noarch
# rpm -ql kernel-doc | grep gpio
... many files ...

If you build your own kernels on a supported RHEL system that places the system in a difficult support position. Your kernel would be considered third-party software which is unsupported. We will have difficulty troubleshooting many kernel-related problems. We may ask you to reproduce any kernelspace issue (including storage, networking, filesystem, etc) on a supported kernel. We strongly recommend sticking to the supported package.

If you need something right now, then use the old sysfs interface. We will maintain that throughout the life of EL7.

If you have a paid support entitlement and business case for Red Hat to backport the new upstream GPIO interface to EL7, then you're welcome to open a support case to make a Request For Enhancement.

Future major releases will almost certainly include Linus W's new upstream character device interface.

HF Community Member 85 points
9 May 2018 6:45 PM

Jaime,

You didn't say it explicitly, but you implied: Generally speaking I should not be building my own kernel. Is that correct?

Note that I'm actually glad to hear the new GPIO is not in there, and that I shouldn't build my own kernel. This means that I do not have to write compatible driver (LKM) or support software. I didn't want to spend that labor. Also, since sysfs is deprecated, I can argue to the bosses that I shouldn't try to be compatible with that either. I didn't want to spend that labor. This means I can take a direct, easy, simple, quick, and effective path from nothing to finished with regard to my GPIO. Yeh!

BTW, while I have your attention, I'll throw in a related question. For my serial port compatibility, all I need to do is take an existing LKM and then upgrade the exported functions to be compatible with man pages IOCTL_TTY(2) and TERMIOS(3). That's pretty straight forward for this 40-year programming veteran, 35-year light linux user, but NEVER too deep in the kernel. On the other hand, nothing I find for GPIO seems this easy. The new stuff from Linus Walleij, and more specifically the new user space interface lib from Bartosz Golaszewski, seems to be like the kernel must already know about the GPIO stuff. I can't just load my LKM, create char devices, and export functions. I would have to have a deeper understanding of Linus Walleij's GPIO stuff inside the kernel, so I could connect myself under there. (In case you haven't figured it out, I have custom FPGA hardware that looks like a GPIO device, among other things.) Well, trying to get UNDERNEATH the existing kernel stuff in order to make Golszewski's library to work -- that's very, very scary to me. I don't have that much understanding. Meanwhile, I haven't really researched the old sysfs method, but I don't know if I am required to get under it, too. I like my serial solution -- just emulate the man page functions.

Thoughts?

HF Community Member 85 points
9 May 2018 6:47 PM

My boss suggested doing my GPIO stuff like I2C, presumably supported in the kernel. Does RHEL have I2C support in it? (I'm researching that business now...)

Jamie Bainbridge's picture Red Hat Guru 7257 points
9 May 2018 11:20 PM

Generally that's correct. I'll explain a little better.

You are most welcome to build and run your own kernel BUT if you wish your system to be fully supported by Red Hat, and for the rest of the OS components to be easily troubleshooted by us on a support case, then running your own kernel (or any other third-party kernel) makes our job of providing that support somewhere between very difficult and impossible.

We very strongly prefer all customers running our supported packages. This provides systems which are fully supported by us. In the event that you do open a support case, running our packages allows you to take advantage of the technical support you are getting with the paid RHEL entitlement.

It's not good for Red Hat to have customers unsupported. Then the support entitlement cannot be as effective, we may not be able to help solve problems you encounter. You ultimately might not see value in the entitlement, then stop paying for it and go to CentOS or Debian or some other zero-dollar distro. We want to have supported customers and we want to be able to help. Having customers supported is better for Red Hat and we sincerely hope that having our technical expertise and our issue ownership available on demand is better for customers too!

In the event that our kernel doesn't meet a customer's specific needs then we welcome a feature request with a business case. We can either extend the software or help find a way to use existing components to meet customer needs.

RHEL is built with I2C support as a loadable module. You can see the config options the kernel is built with like this for whatever kernel you have installed:

# egrep -RHn CONFIG_I2C /boot/config-3.10.0-862.el7.x86_64

As you probably know, m means "loadable module" and y means compiled into the kernel.

A rather helpful programming example for I2C is supplied at: https://www.kernel.org/doc/Documentation/i2c/dev-interface

If you have an existing proven driver where you can emulate serial reasonably accurately, that seems a viable option. The driver is already known to work with your hardware. Development time would probably be quicker as you just need to change a few things you're already confident with. However you would be supporting that kernel module which talks to your device, as that module is software not supplied by Red Hat.

Using a proper bus like I2C where you can address multiple specific devices and send messages between program and hardware seems a lot "cleaner" and more extensible to me. It would also let you keep your support only to your userspace application and the I2C hardware, the kernel parts would be fully supported by us. These advantages come with the cost of scrapping your existing driver and writing a new communication interface over I2C.

Both have their advantages. If you think you can do the serial emulation quickly then maybe try that and see if it's "good enough" for your needs. If that doesn't work as you desire, then invest the time and effort into an I2C solution.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.