Re: [libgpiod] feature request: output state read and sustain

[Andy Shevchenko <andy.shevchenko@xxxxxxxxx>]

On Wed, Jun 29, 2022 at 11:27 AM Jiří Prchal <jiri.prchal@xxxxxxxxxxx> wrote:
> On 29. 06. 22 9:23, Kent Gibson wrote:
> > On Tue, Jun 28, 2022 at 03:08:20PM +0200, Jiří Prchal wrote:

> >> using new libgpiod / chardev driver, is there any way to get state of
> >> output? I mean one process sets it for example to 1 and another process
> >> reads this output state for example to show that on web page.

I'm not sure it's guaranteed to read output back. Some (b0rken?) GPIO
chips may not allow this on H/W level and when reading they always
will get the value of Input Buffer (now imagine if the line is
configured as Output with Input being disconnected from the physical
pin).

> >> I have to say that old sysfs interface was more user friendly...

And much more buggy and PITA.

> > "new" being anything since Linux 4.8 ;-)?
> > And strictly speaking it isn't a driver - libgpiod and the GPIO subsystem
> > provide an interface to the chip driver.  More on that later.
> >
> > Only the process holding the line has access to the current value.
> > If you need that value elsewhere then it has to be published by that
> > process - it is not available through the GPIO API itself.
> > There is nothing preventing that process publishing the value
> > in whatever way is appropriate to your application.
> > e.g. write it to a file that can be read by your webapp, just as it
> > would from sysfs.
> >
> > Less restrictive access models are frequently "more user friendly", but
> > have other issues. e.g. some misbehaving process just reset your
> > modem for you.
> >
> > And sysfs has other great features like being slow and being complete
> > rubbish for events on input lines.
> >
> >> And at second: it would be better to NOT "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."
> >> "Set and forget" behavior is more natural to what some gpios are used. For
> >> example resetting external modems, need set 1 for short time, then to 0 and
> >> leave it for long long time until next reset is needed. It's non sense to
> >> keep running some process only to keep output at 0.
> >
> > Agreed, that might be more natural, but that behaviour is not by choice,
> > it is a consequence of the kernel internals.  In short, if the GPIO
> > subsystem does not hold the chip then the driver is free to do what it
> > likes to it.
> > So when you release a line all bets are off.
> > It may stay where you left it, but it may not - it may even switch to an
> > input - it depends on the driver.
> Does it mean that without changing this particular line it could be changed? For example by setting another line in chip?

No, it's only about the line in question.

> > If it works for you that's great, but without major kernel changes
> > libgpiod has no better option than to provide the caveat as the "set and
> > forget" behaviour is something that it cannot guarantee.
> Than is only way to write my own user space driver simulating sysfs? Or what is the right way of this scenario:
> start proces -> gpioset =1 -> sleep -> gpioset =0 -> do other things
> when the proces dies systemd will start it again

Do not use shell. Use proper programming language that may give you an
easier way of handling this, i.e. _context_. Shell tools are
_context-less_ and here is the problem you are trying to solve, but
from the wrong end.

> and another scenario:
> proces checks time, if is the right time -> gpioset =1
> other proces reads output and print out on web


-- 
With Best Regards,
Andy Shevchenko