Re: [PATCH v4 0/5] gpio: expose line bias flags to userspace

[Kent Gibson <warthog618@gmail.com>]

On Mon, Nov 04, 2019 at 11:14:56AM +0100, Bartosz Golaszewski wrote:
> pon., 4 lis 2019 o 02:07 Kent Gibson <warthog618@gmail.com> napisał(a):
> >
> > On Mon, Nov 04, 2019 at 01:26:54AM +0100, Linus Walleij wrote:
> > > On Thu, Oct 31, 2019 at 8:10 AM Bartosz Golaszewski
> > > <bgolaszewski@baylibre.com> wrote:
> > >
> > > > [Kent]
> > > > > This series adds gross control of pull-up/pull-down to the GPIO uAPI.
> > > > > Gross control means enabling and disabling of bias functionality,
> > > > > not finer grained control such as setting biasing impedances.
> > >
> > > Right, excellent and persistent work here, much appreciated!
> > >
> >
> > No problem - hopefully I haven't irritated too many people in the process.
> >
> > > As long as I get Bartosz's blanket ACK on v5 I think it is ready
> > > to merge. His consent is required for this.
> > >
> >
> > I'm still waiting on open questions from v4 before submitting v5:
> >
> > One, handling of errors when setting bias, Bart has referred to Thomas,
> > so waiting for feedback on that.
> >
> 
> If we can get it merged for v5.5, then I don't want to block it
> waiting for answers. Looking at the code I think we should only ignore
> the EOPNOTSUPP error and propagate all other codes. Can you add a
> patch changing that and then fix the other nits I pointed out? Also:
> please Cc Thomas Petazzoni so that he gets the chance to yell at us if
> it breaks something.
> 

Will do.

> > The other, where gpio_set_bias is hooked into gpiod_direction_output,
> > is fine as is for the UAPI - it can always be relocated subsequently if
> > other APIs need to set bias.  On the other hand, if decoupling setting
> > direction and bias is in order then that really should be done now.
> > Can I get an an ACK on that either way?
> >
> 
> This is in line with what you did for input. I don't think it should
> be decoupled (any particular reason for that? There is none mentioned
> in the cover letter), so I propose to leave it as it is in patch 5/5.
> 

Wrt decoupling, I was thinking of both input and output, not just output,
though it was the output that got me onto that line of thought as
gpiod_direction_output sets bias, but gpiod_direction_output_raw doesn't.
That seemed totally arbitrary.

That lead to thinking that the gpiod_direction_output (and _input) is now 
doing more than implied by the name, and by the documentation for that 
matter.  So perhaps it should be split out and promote gpio_set_bias to
gpiod_set_bias?  Anyway, that was the line of thought.
The problem there being some callers of gpiod_direction_input already
expect it to set bias, at least on a best effort basis, and they would 
have to be updated to call gpiod_set_bias.

Maybe just update the documentation for exported functions that do set 
bias?

> One more thing - since we all want this to make it for v5.5 - can you
> make the set config patches part of this series (simply bunch it all
> together)? This will make it easy to review and merge everything.
> 

May as well - I've got it all in the one branch anyway.

> Thanks in advance and great job!

I was about to start updating libgpiod to add set_config, after adding
the equivalent to my gpiod library (nearly finished writing the tests 
for that), but I'll put all that on the back burner and get v5,
including in the set_config patches, out as soon as I can.

Cheers,
Kent.

> Bartosz
> 
> > I've also made a couple of minor changes myself while reviewing v4 -
> > reordering the patches to group the gpiolib.c ones and leaving the
> > gpio-mockup til last, and removing the "bias requires input mode" check
> > from lineevent_create as the line is assumed to be input for events
> > regardless of the input flag - there is no such thing as as-is for
> > event requests.
> > Only mentioning here in case such changes are clearly wrong...
> >
> > Cheers,
> > Kent.
> >
> > > It looks pretty much as I imagined it when I discussed it with
> > > Drew some while back, with some gritty details fixed up.
> > >
> > > Yours,
> > > Linus Walleij