Re: [question] Does gpiod_set_value have a "guarantee"?

[Bartosz Golaszewski <brgl@xxxxxxxx>]

On Mon, Mar 18, 2024 at 6:13 PM Vincent Fazio <vfazio@xxxxxxxxx> wrote:
>
> Is there any implicit or expected guarantee that after having returned from
> gpiod_set_value that the GPIO will reflect the new value externally?
>

No, this is driver-specific behavior.

> Some drivers that leverage GPIO to emulate buses, like i2c-gpio, may be relying
> on this to be true in order to make a "stable" clock.
>

Well, they shouldn't rely on it because it's not enforced unless the
underlying driver enforces it.

> I was glancing at https://github.com/raspberrypi/linux/issues/5554 where
> someone ran into an issue and it looks like, at least on the RPi 4 platform,
> that there may need to be some "flush" mechanism to guarantee that a GPIO has
> been written out.
>
> If it's the responsibility of gpio_chip->set to do this, then I'm guessing the
> pinctrl driver may need to be updated, but that does incur a performance hit
> for every GPIO write.
>
> If it's up to the bus emulator to do this, short of sampling the pin, should
> there be some API or mechanism to assist with flushing writes out? Is there
> already a mechanism to do this?
>

That's an interesting use case. We could extend both the in-kernel and
user-space API for this quite easily. We could add a new flag to
gpiod_get() like GPIOD_SYNC or similar and maybe provide a callback
for GPIO drivers for flushing the state? Then do the same with
user-space request flags.

In any case, I don't think we can make it entirely generic.

Bart