Hey guys, I've hit an odd issue in the gpio-utils.c library, and possibly the new GPIO chardev interface. This might be a problem with the specific platform I'm using, or it's always possible I'm just misunderstanding how the chardev interface is intended to work. Sorry for the noise on this list, but I wasn't sure where else to ask. First off, I'm running Fedora 26 on a Raspberry Pi 2. Kernel version is 4.11.10-300.fc26.armv7hl. This is Fedora's nearly vanilla kernel, not the custom Pi kernel. This kernel is new enough to have the GPIO chardev interface. I've started by playing with the tools from the kernel tree, gpio-hammer and lsgpio. These seemed to work as expected, until I dug a bit further, and started to find the issue that prompted this email. The GPIO pin I'm testing default to high. When running gpio-hammer with a count of 1 (-c 1), the GPIO flips off, and then back on. Looking at the source of gpio-hammer, this seems odd. I would expect that the GPIO value should flip from on to off, and remain off, rather than reset back to default. Looking at the functions in the gpio-utils lib confirms that something is broken. The gpiotools_set function acts the same way, briefly flipping the GPIO pin to off, and then the pin falls back to its default. It seems that as soon as the /dev/gpiochip0 file descriptor is closed, all the GPIO lines are reverting to their defaults. The code in gpiotools_set seems to strongly indicate this is unintentional. So to use GPIO pins through the chardev interface, one has to hold on to the file descriptor to keep the pins from reverting to their initial state. Is this a bug, or intended behavior? Thanks! Jonathan Bennett
Attachment:
signature.asc
Description: OpenPGP digital signature
