Re: [questions] : gpiolib and gpioset behaviour

[Gilles BULOZ <gilles.buloz@xxxxxxxxxxx>]

On Mon, Apr 22, 2024 at 3:55 PM Bartosz Golaszewski wrote :
> 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.
>

Which method should the driver implement to restore the state on GPIO when the
last process referencing the character device exits ?

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

OK

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

I was thinking about some specific "watcher" ioctl to do so, not a DBus
daemon because this is not welcome in the real-time and embedded world.
The only workaround I've found is to directly read the GPIO chip registers
but this is bad to do so.

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