Re: [libgpiod] Documentation question

[Kent Gibson <warthog618@xxxxxxxxx>]

On Sun, Dec 31, 2023 at 05:02:26PM +0800, Kent Gibson wrote:
> On Sun, Dec 31, 2023 at 02:17:56AM -0600, Seamus de Mora wrote:
> > > On Sat, Dec 30, 2023 at 9:51 PM Kent Gibson <warthog618@xxxxxxxxx> wrote:
> > > >
> > > > On Sat, Dec 30, 2023 at 08:04:40PM -0600, Seamus de Mora wrote:
> > > > > Hello,
> > > > >
> > > >
> > > > Cheers,
> > > > Kent.
> > > >
> > > > [1] https://docs.kernel.org/driver-api/pin-control.html
> > > > [2] https://docs.kernel.org/driver-api/pin-control.html#gpio-mode-pitfalls
> >
> > The pinctrl refs didn't have what I was looking for, but thanks & keep
> > your eyes peeled, please. I found something close (and a surprise) in
> > this item named 'Using GPIO Lines in Linux'[1]. The surprise was the
> > recommendation against using the ABI (libgpiod??) for "production
> > systems". Am I reading that correctly?
> >
>

Oh, and you are still wanting to clarify why the GPIO uAPI/libgpiod only
deals with the GPIO subsystem?
Not sure you will find anything that states that explicitly as it is
minimalist Unix philosophy - do one thing well.
So the GPIO uAPI only deals with the GPIO subsystem, and libgpiod only
deals with the GPIO uAPI.

If you want an over-arching library that deals with all the possible
functions of GPIO lines, like lgpio tries to, then you can always write
something that sits above libgpiod and the other subsystem interfaces,
though I'm not sure what advantage that would provide over treating with
each of them independently.

Cheers,
Kent.