GPIO Driver Design

[Robert Joslyn]

I'm working on writing a driver for custom hardware, but I'm not sure
the best way to expose the features of the hardware to userspace. The
hardware in question is basically a configurable industrial GPIO board,
but it has additional features that don't seem to map well to the
libgpio subsystem.

The board has a set of output pins that can be treated like normal GPIO
pins. The input pins, however, have additional configuration that can
be set by a user. For example, the inputs can be configured for
different input voltage levels, such as 24 Vdc, 110 Vac at 60 Hz, 220
Vac at 50 Hz, etc. Debounce times can also be configured. The hardware
also has a FIFO buffer that records the state of all input pins, as
well as a free running counter (FRC), when any input value changes.

What is a reasonable way to expose the voltage and debounce
configuration to userspace? Or the FIFO? 

Presently, I have an initial driver that creates a character device in
/dev and uses ioctls so a user can provide configuration, read
input/output state, and read the FIFO. There is also a custom sysfs
interface to access the same configuration values and data.The sysfs
interface is manily to provide something easier to use from shell, all
the functionality is also duplicated in the ioctl interface. I plan on
adding access to the input/output states through libgpio, but have not
finished this yet. I'd like to get this driver in a state where it
could be merged upstream, but I'm not sure that a custom sysfs class or
ioctls are the right way to go. Is there a better way for userspace to
provide this configuration, or access to the FIFO?

This is the first kernel driver I've worked on, so it's possible there
is an obvious way to implement this that I just haven't seen yet. Or
maybe this hardware is just too specific and doesn't make a good
candidate for pushing upstream. I'd appreciate any suggestions or
ideas!

Thanks,
Robert