Re: [questions] : gpiolib and gpioset behaviour

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Apr 22, 2024 at 2:44 PM Gilles BULOZ <gilles.buloz@xxxxxxxxxxx> wrote:
>
> Hi Bartosz,
>
> Several years after our discussions about GPIOs, some things are still unclear
> to me.
>
> 1 - The gpioset command has this in its help : "Note: the state of a GPIO line
> controlled over the character device reverts to default when the last process
> referencing the file descriptor representing the device file exits. This means
> that it's wrong to run gpioset, have it exit and expect the line to continue
> being driven high or low. It may happen if given pin is floating but it must
> be interpreted as undefined behavior." But up to now I've never seen such
> behaviour and I'm glad to have the GPIO set by gpioset keep their state once
> the command exits. Is reverting to default an optional behaviour in the GPIO
> chip driver, or in the gpiolib stack ?
>

This behavior is driver-specific. Meaning: you're in-kernel GPIO
driver may actually retain the state.

> 2 - I've recently wrote a GPIO driver for an I2C FPGA design having ~112 GPIOs
> and wanted to use get_multiple() and set_multiple to have more efficent
> accesses, but realized that the line number was limited to 63 because of the
> unsigned long mask/bits. But I've noticed that working on a line number >= 64
> was unexpectedly calling these methods with a mask at 0 instead of calling
> get/set methods, and that the only way to have things working was to not
> define get_multiple/set_multiple but only get/set. Is it the expected
> behaviour ?
> At the end I've split the GPIOs into two banks (first with 64 and second with
> 48 GPIOs) to be able to use get_multiple/set_multiple.
>

Please use libgpiod v2. That won't help you with the max requested
line limit but at least it's more modern API and actively developed.

> 3 - Is there some way to request a GPIO already owned by another process as
> input or output, just to get the current level on the input or the level
> driven on output ? This would be much more efficient for real-time
> applications than asking the owner such information.
>

Ha! Please help me help you. Take a look at the DBus daemon I recently
posted[1]. With the daemon running, the behavior will be exactly what
you expect. You'll be able to get/set values and have the command-line
tool exit while the daemon retains the state.

Bart

[1] https://lore.kernel.org/linux-gpio/20240412122804.109323-1-brgl@xxxxxxxx/