From: Kent Gibson <warthog618@gmail.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: linux-gpio@vger.kernel.org
Subject: Re: [libgpiod][RFC] helper functions for basic use cases
Date: Tue, 14 May 2024 21:38:04 +0800 [thread overview]
Message-ID: <20240514133804.GA107324@rigel> (raw)
In-Reply-To: <CAMRc=MftXh6SV_jNVDaUOwww21gH5gFeb8zGSVBLv=jMP_mFKQ@mail.gmail.com>
On Tue, May 14, 2024 at 06:31:39AM -0700, Bartosz Golaszewski wrote:
> On Mon, 13 May 2024 12:13:31 +0200, Kent Gibson <warthog618@gmail.com> said:
> >
> >> > /**
> >> > * @brief Set the bias of requested input line.
> >> > * @param olr The request to reconfigure.
> >> > * @param bias The new bias to apply to requested input line.
> >> > * @return 0 on success, -1 on failure.
> >> > */
> >> > int gpiod_olr_set_bias(struct gpiod_line_request * olr,
> >> > enum gpiod_line_bias bias);
> >>
> >> For this to work, you'd most likely need a new struct wrapping the request
> >> and also storing the line config. Otherwise - how'd you keep the state of all
> >> the other line settings?
> >>
> >
> > Yeah, I realised that when I went to implement it :(.
> >
> > What I implemented was to read the line info and build the config from that.
> > So no impact on core.
> > Not the most efficient, but for this use case I wan't fussed.
> >
>
> I think those simplified requests should wrap the config structures, otherwise
> we'd have to readback the config from the kernel which would become quite
> complex for anything including more than one line.
>
The whole point of the simplified requests is that they only deal with
a single line. And the config mutators only deal with a single input.
Wouldn't wrapping break the ability to use all the other
gpiod_line_request_XXX functions, and so require adding more functions
to make use of the simplified requests?
Maybe I'm missing something.
Cheers,
Kent.
next prev parent reply other threads:[~2024-05-14 13:38 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-07 2:21 [libgpiod][RFC] helper functions for basic use cases Kent Gibson
2024-05-10 18:37 ` Bartosz Golaszewski
2024-05-11 1:11 ` Kent Gibson
2024-05-13 8:28 ` Bartosz Golaszewski
2024-05-13 10:13 ` Kent Gibson
2024-05-14 13:31 ` Bartosz Golaszewski
2024-05-14 13:38 ` Kent Gibson [this message]
2024-05-15 8:26 ` Bartosz Golaszewski
2024-05-15 9:18 ` Kent Gibson
2024-05-15 13:37 ` Kent Gibson
2024-05-15 13:54 ` Bartosz Golaszewski
2024-05-15 14:14 ` Kent Gibson
2024-05-16 0:19 ` Kent Gibson
2024-05-16 13:55 ` Kent Gibson
2024-05-17 10:53 ` Bartosz Golaszewski
2024-05-17 12:37 ` Kent Gibson
2024-05-22 10:59 ` Bartosz Golaszewski
2024-05-22 12:41 ` Kent Gibson
2024-05-24 14:20 ` Bartosz Golaszewski
2024-05-15 7:06 ` Martin Hundebøll
2024-05-15 9:32 ` Kent Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240514133804.GA107324@rigel \
--to=warthog618@gmail.com \
--cc=brgl@bgdev.pl \
--cc=linux-gpio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.