GPIO Char device and tools/gpio/gpio-utils.c

GPIO Char device and tools/gpio/gpio-utils.c

[Jonathan Bennett]

[-- Attachment #1.1: Type: text/plain, Size: 1735 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GPIO Char device and tools/gpio/gpio-utils.c

[Linus Walleij]

On Fri, Jul 21, 2017 at 7:26 PM, Jonathan Bennett
<jbennett@cipherdyne.com> wrote:

> 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?

I do not remember putting any code in that would explicitly return the
GPIO line to
the inital state.

That said it makes some weird sense as people might be probing around with
the tools and then it would be good behaviour to leave things in the room like
they were arranged when you entered, don't you think?

I'd like to hear Bartosz take on this though, he is more versed with userspace
GPIO than me these days, and talk directly to users of this feature.

Yours,
Linus Walleij

Re: GPIO Char device and tools/gpio/gpio-utils.c

[Bartosz Golaszewski]

2017-07-31 14:22 GMT+02:00 Linus Walleij <linus.walleij@linaro.org>:
> On Fri, Jul 21, 2017 at 7:26 PM, Jonathan Bennett
> <jbennett@cipherdyne.com> wrote:
>
>> 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?
>
> I do not remember putting any code in that would explicitly return the
> GPIO line to
> the inital state.
>
> That said it makes some weird sense as people might be probing around with
> the tools and then it would be good behaviour to leave things in the room like
> they were arranged when you entered, don't you think?
>
> I'd like to hear Bartosz take on this though, he is more versed with userspace
> GPIO than me these days, and talk directly to users of this feature.
>
> Yours,
> Linus Walleij

Currently if a pin is driven low or high by HW design, it will return
to the default state after releasing the file descriptor. Floating
pins stay the way they were set even after closing the fd. While to me
this behavior looks correct, we could potentially add a new flag to
the request structure e.g. GPIO_REQUEST_RESTORE_STATE that would make
gpiolib explicitly restore the previous state even for floating pins
after close().

Best regards,
Bartosz Golaszewski