[ANNOUNCE] libgpiod v2.0-rc3 released

[ANNOUNCE] libgpiod v2.0-rc3 released

[Bartosz Golaszewski]

I decided to introduce a late change to the C++ bindings - mark all
public types as final since they already don't have virtual
destructors and inheriting from them makes little sense anyway. This
has little impact on the programming interface but I still think it's
worth another RC and I also have a gut feeling that makes me want to
sit down over the weekend and inspect the entire API once more before
carving it in stone for the foreseeable future.

The tarball and git tree are in their usual places[1][2].

Bart

[1] https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/
[2] git://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git

Re: [ANNOUNCE] libgpiod v2.0-rc3 released

[andy.shevchenko]

Thu, Feb 23, 2023 at 08:25:02PM +0100, Bartosz Golaszewski kirjoitti:
> I decided to introduce a late change to the C++ bindings - mark all
> public types as final since they already don't have virtual
> destructors and inheriting from them makes little sense anyway. This
> has little impact on the programming interface but I still think it's
> worth another RC and I also have a gut feeling that makes me want to
> sit down over the weekend and inspect the entire API once more before
> carving it in stone for the foreseeable future.
> 
> The tarball and git tree are in their usual places[1][2].

Thank you for the update!

A bit of an offtopic here (but related a bit as well), but since all parties
are in Cc list I dare to ask.

I have got one bug report internally and, while thinking over it (it has nothing
to do with the library, but with the flow on how we change line states during
requests and releases), realised that we probably have no knob to tell GPIO driver
to which state pin should be left after release.

This at least allows several things to achieve:
1) emulation of the sysfs behaviour (to some extent) without a necessity of
   the context (yes, I know that this is still error prone, but why not);
2) allow the possibility to grab a GPIO line and set it to the particular
   state and leave the process off (makes sense in some setups where it's
   guaranted that no other process will touch the line);
3) something else I forgot or not even thinking of.

That said, would be nice to have an additional flag (during request?)
to tell kernel what it should do with the line after releasing the
handle from user space.

Thoughts?

P.S. Sorry if I missed any discussion related to this in the past.
In such case, please share the links.

> [1] https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/
> [2] git://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git

-- 
With Best Regards,
Andy Shevchenko

Re: [ANNOUNCE] libgpiod v2.0-rc3 released

[Linus Walleij]

On Fri, Feb 24, 2023 at 1:28 PM <andy.shevchenko@gmail.com> wrote:

> That said, would be nice to have an additional flag (during request?)
> to tell kernel what it should do with the line after releasing the
> handle from user space.

I think that kind of lines up with the "default initial values" that have
been proposed again and again and eventually merged as part
of the PCF8575 bindings in
Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml

These states are supposed to be set when the driver is initialized.

It would make sense that if a GPIO handle in usespace is released
and the hardware has lines-initial-states set for its driver, then
the line should snap back to that state.

+/- however ACPI would define this.

Yours,
Linus Walleij

Re: [ANNOUNCE] libgpiod v2.0-rc3 released

[Andy Shevchenko]

On Mon, Feb 27, 2023 at 12:36 PM Linus Walleij <linus.walleij@linaro.org> wrote:
> On Fri, Feb 24, 2023 at 1:28 PM <andy.shevchenko@gmail.com> wrote:
>
> > That said, would be nice to have an additional flag (during request?)
> > to tell kernel what it should do with the line after releasing the
> > handle from user space.
>
> I think that kind of lines up with the "default initial values" that have
> been proposed again and again and eventually merged as part
> of the PCF8575 bindings in
> Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml
>
> These states are supposed to be set when the driver is initialized.
>
> It would make sense that if a GPIO handle in usespace is released
> and the hardware has lines-initial-states set for its driver, then
> the line should snap back to that state.
>
> +/- however ACPI would define this.

Yeah, but I'm more about lines that are free to use by anybody (read:
user space). When we request the line we can tell the kernel, ok, this
line needs to "keep the state after release", or this line needs to
"reset the state to the previous". The flag should be available only
for user space handles.


-- 
With Best Regards,
Andy Shevchenko

Re: [ANNOUNCE] libgpiod v2.0-rc3 released

[Bartosz Golaszewski]

On Fri, Feb 24, 2023 at 1:28 PM <andy.shevchenko@gmail.com> wrote:
>
> Thu, Feb 23, 2023 at 08:25:02PM +0100, Bartosz Golaszewski kirjoitti:
> > I decided to introduce a late change to the C++ bindings - mark all
> > public types as final since they already don't have virtual
> > destructors and inheriting from them makes little sense anyway. This
> > has little impact on the programming interface but I still think it's
> > worth another RC and I also have a gut feeling that makes me want to
> > sit down over the weekend and inspect the entire API once more before
> > carving it in stone for the foreseeable future.
> >
> > The tarball and git tree are in their usual places[1][2].
>
> Thank you for the update!
>
> A bit of an offtopic here (but related a bit as well), but since all parties
> are in Cc list I dare to ask.
>
> I have got one bug report internally and, while thinking over it (it has nothing
> to do with the library, but with the flow on how we change line states during
> requests and releases), realised that we probably have no knob to tell GPIO driver
> to which state pin should be left after release.
>

As Linus said - this does sound like the "safe-state" mechanism that
tends to be discussed on this list every three years or so. :)

> This at least allows several things to achieve:
> 1) emulation of the sysfs behaviour (to some extent) without a necessity of
>    the context (yes, I know that this is still error prone, but why not);

But this doesn't emulate anything. The released line is up for grabs
by either another user-space or a kernel user. It may have reverted to
the previous state on release but what happens next is anyone's guess.
IMO: It's simply wrong to rely on a state of non-requested line.

> 2) allow the possibility to grab a GPIO line and set it to the particular
>    state and leave the process off (makes sense in some setups where it's
>    guaranted that no other process will touch the line);

It may be right for some use-cases but it's ultimately *logically*
wrong. Even sysfs DOES actually request lines that are exported, ie
there IS a defined user who is driving the line. In this case there's
nobody responsible. And in order to read back the state you'd have to
request it anyway.

> 3) something else I forgot or not even thinking of.
>
> That said, would be nice to have an additional flag (during request?)
> to tell kernel what it should do with the line after releasing the
> handle from user space.
>

I agree on the in-kernel mechanism for defining some safe-state to
which a line would revert whenever unused but I would argue that
allowing user-space to specify such a state would be just inviting
people to doing even worse stuff than with sysfs.

Bart

> Thoughts?
>
> P.S. Sorry if I missed any discussion related to this in the past.
> In such case, please share the links.
>
> > [1] https://mirrors.edge.kernel.org/pub/software/libs/libgpiod/
> > [2] git://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git
>
> --
> With Best Regards,
> Andy Shevchenko
>
>