Re: gpiolib: why does gpio_set_bias() suppress ENOTSUPP?

[Kent Gibson <warthog618@gmail.com>]

On Fri, Apr 01, 2022 at 01:42:54PM +0300, Andy Shevchenko wrote:
> On Fri, Apr 01, 2022 at 08:08:37AM +0800, Kent Gibson wrote:
> > On Thu, Mar 31, 2022 at 08:19:39PM +0300, Andy Shevchenko wrote:
> > > On Thu, Mar 31, 2022 at 10:15:24PM +0800, Kent Gibson wrote:
> > > > On Thu, Mar 31, 2022 at 04:53:23PM +0300, Andy Shevchenko wrote:
> > > > > On Thu, Mar 31, 2022 at 10:52:03AM +0800, Kent Gibson wrote:
> > > > > > It has recently come to my attention that the setting of bias by the
> > > > > > cdev uAPI is a best effort operation that quietly succeeds if bias is
> > > > > > not supported by the hardware. That strikes me as being a bug.
> > > > > > It seems I was aware of this when adding bias to the uAPI and intended
> > > > > > to fix it, as shown in the comments of v4 of the corrsponding patch
> > > > > > series[1]:
> > > > > 
> > > > > > > > The setting of bias is performed by gpio_set_bias, which is hooked into
> > > > > > > > gpiod_direction_input and gpiod_direction_output.  It extends the setting
> > > > > > > > of bias that was already present in gpiod_direction_input.
> > > > > > > > In keeping with the existing behaviour, the bias is set on a best-effort
> > > > > > > > basis - no error is returned to the user if an error is returned by the
> > > > > > > > pinctrl driver.  Returning an error makes sense to me, particularly for
> > > > > > > > the uAPI, but that conflicts with the existing gpiod_direction_input
> > > > > > > > behaviour. So leave as best-effort, change gpiod_direction_input
> > > > > > > > behaviour, or restructure to support both behaviours?
> > > > > > 
> > > > > > > Thomas: is there any reason not to check the return value of these
> > > > > > > calls for errors other than -EOPNOTSUPP?
> > > > > > 
> > > > > > that being my comment, and Bart's followup question to Thomas.
> > > > > > 
> > > > > > That went unanswered AFAICT and the issue subsequently fell through the
> > > > > > cracks.
> > > > > 
> > > > > My understanding that all constraints we have in kernel is due to
> > > > > in-kernel use and possible (non-critical) issues.
> > > > > 
> > > > > For example, driver can set only selected values of bias. What to do when
> > > > > the given value is not supported by hardware?
> > > > > 
> > > > > Followup question: Why do you think your choice is any better than another
> > > > > one?
> > > > > 
> > > > 
> > > > I'm probably missing your point here.
> > > > 
> > > > What makes gpiolib best placed to decide that bias not being supported
> > > > by hardware is non-critical?  Why not just propagate the ENOTSUPP to the
> > > > caller and let them decide?
> > > 
> > > First of all, ENOTSUPP may not be sent to user, it's wrong error code.
> > > The returning any other error code make behaviour for the _very same_
> > > GPIO line _different_ when it being configured in kernel (via firmware)
> > > and user space. That's unacceptable. So, it means we have to have
> > > synchronized behaviour, means either error in both case or ignoring it.
> > > The latter one is current state of affairs, the former might break the
> > > cases where driver and firmware are not synchronized well.
> > > 
> > 
> > First of all, I was referring to in-kernel users of gpiolib, so gpiolib
> > would propagate ENOTSUPP.  You will note I said "caller", not "user"
> > to try to emphasise that point.
> > cdev, being the caller here, would translate the ENOTSUPP to EOPNOTSUPP
> > for user space consumption.
> 
> Ah, okay!
> 
> > But back to the point...
> > Are you saying that user space should not be given an error if bias is
> > not supported as it was already decided by gpiolib that the kernel
> > driver wouldn't be given one?
> > That makes no sense to me, so I'm probably missing something.
> > Can you clarify?
> 
> I think that deviating of the behaviour would confuse some.
> Why the configuration of the very same line described in DT
> and used in user space will behave differently?
> 

Ok, you are looking at the uAPI using a DT lens.
How many users would be using both DT and uAPI?
If the bias is already set via DT why set it again via uAPI?

The more likely use case is that users don't know anything about
DT, and are surprised to find that bias doesn't work - despite 
the uAPI accepting bias settings without complaint.

> > What I read from your answer is "that's the way it is".
> > I get that, but was after why.
> > I don't see dropping errors as a way to get anything in sync.
> > Quite the opposite - it ensures we can never tell if they are.
> > 
> > If the original problem was that there are two possible causes for
> > ENOTSUPP, and one of them is critical and one is not, then the solution
> > should be to split the functionality into separate calls, not just drop
> > the error from the "non-critical" one.  Again, gpiolib has no business
> > in that criticality decision, IMHO. And again when I say gpiolib here
> > I mean the core - gpiolib.c.
> 
> I got your point. But to me it is a way of breaking the prototyping and
> actual product. If you strict at prototyping and reuse same DT(b) over
> several generations of the platform, some of them (due to subtle hardware
> differences) may ignore errors (due to in-kernel behaviour) while during
> prototyping that was strict.
> 

I understand why you want application of pin description from DT to be
best-effort - I was unsure why that was done in gpiod_direction_input().
But Hans got me over that hump.

> The best approach here is to add a new IOCTL "enable extended error reporting"
> or alike and expect all of GPIO ABI calls to fail. In such case it won't
> alter status quo, not break ABI.
> 

Agreed, although I'm thinking a flag in the gpio_v2_line_request rather
than a new ioctl.  Or maybe in gpio_v2_line_config.

Thanks for the assistance - much appreciated.

Cheers,
Kent.

> > > > Is it because setting bias is piggy-backed onto
> > > > gpiod_direction_input() rather than being separate, so then you can't
> > > > tell whether it is input or bias that is not supported?
> > > > 
> > > > Anyway, if that interface is required for internal use then there is no
> > > > option but to refactor gpiod_direction_input() and provide an alternate
> > > > interface so that cdev can determine if bias is supported or not.
> > > 
> > > > > > I would like to fix the uAPI such that if the hardware does not support
> > > > > > the requested configuration, or if it can't be emulated in the kernel,
> > > > > > that fact is returned to userspace - bias being the sole counter example
> > > > > > as far as I am aware.
> > > > > > 
> > > > > > The simplest fix involves changing gpio_set_bias() to call gpio_set_config()
> > > > > > rather than gpio_set_config_with_argument_optional(), but as mentioned in
> > > > > > my comment above, that would impact any existing users of
> > > > > > gpiod_direction_input() that assume the best-effort behaviour.
> > > > > 
> > > > > Exactly, best effort is to supply it to the driver and <s>pray</s> hope for
> > > > > the best form the hardware driver.
> > > > > 
> > > > > > I haven't been able to find any such usage, but that could just be proof
> > > > > > that I'm not looking in the right place.
> > > > > > Any input on that front would be greatly appreciated.
> > > > > > 
> > > > > > Also, fixing this as mentioned could be considered an uAPI ABI change.
> > > > > > Is this a bug, so that is ok, or do I need to consider adding a strict
> > > > > > mode flag or somesuch to the API?
> > > > > > 
> > > > > > Bart, I'm also hoping to extend the gpiosim to optionally not support
> > > > > > bias in gc->set_config() to test this case.
> > > > > > Any suggstions on a configfs interface extension to do that?
> > > > > > 
> > > > > > My apologies for the verbage rather than proffering a patch, but the
> > > > > > different paths have vastly different costs, and the simplest solution
> > > > > > has the potential to introduce breakage.
> > > > > 
> > > > > > [1] https://www.spinics.net/lists/linux-gpio/msg43579.html
> > > 
> > > -- 
> > > With Best Regards,
> > > Andy Shevchenko
> > > 
> > > 
> 
> -- 
> With Best Regards,
> Andy Shevchenko
> 
>