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

[Kent Gibson <warthog618@xxxxxxxxx>]

On Wed, Jun 29, 2022 at 01:48:17PM +0200, Jiří Prchal wrote:
> 
> 
> On 29. 06. 22 13:25, Kent Gibson wrote:
> > On Wed, Jun 29, 2022 at 01:17:54PM +0200, Jiří Prchal wrote:
> > > 
> > > 
> > > On 29. 06. 22 12:47, Kent Gibson wrote:
> > > > On Wed, Jun 29, 2022 at 12:27:13PM +0200, Andy Shevchenko wrote:
> > > > > 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).
> > > > > 
> > > > 
> > > > Agreed.  Userspace should know the value they set the output to, and so
> > > > have no need to read it back.  GPIO is not NVM.
> > > Not NVM, bat RAM and it keeps their data untill reset, after reset it has specific value (usually 0)
> > > I haven't seen HW without possibility of reading back output register, but I don't say there couldn't be such one.
> > > 
> > 
> > No, no it is not RAM.
> > 
> > And I have seen hardware where you can't read back the output.
> > And so has Andy apparently.
> > That is the problem - there is lots of hardware out there and we are
> > trying to provide a consistent interface to inconsistent hardware.
> OK, but if hw supports it why not provide it. And for hw without support keep it's value in memory? Or return to user space with errno indicating "no support"?

No idea - I'm new here (by your definition) ;-).

In general we do provide it where the hardware supports it, so for
example typically reading back outputs works.

I would guess the reason we don't provide a guarantee is that is that in
most cases it isn't necessary, and to do so adds cost.
Full on caching and error handling as you suggest would be overkill
for most situations.  Most writes to outputs don't get read back, so why
waste resources caching them? And if you want to do the error handling
you suggest you have to cache them - just in case, or you have to
pre-get them to find out which lines need to be cached, but you can't do
that without changing the line direction to output and you certainly
can't do that autonomously, so the driver interface needs to be far more
complex to probe the driver capabilities down to the line and in
different modes.  And you need to spend time doing that...
Basically a can of worms.

And the simple workaround is for the user to cache the value themselves
if they need it and find their hardware doesn't support read back.

So best effort is the most pragmatic and cost effective solution.
(Hopefully Andy will chip in with the actual reason, which is probably
something far more obvious ;-)

As always, if you see a better way, submit a patch!

Cheers,
Kent.