linux-next regression caused by "gpiolib: request the gpio before querying its direction"

[linux@armlinux.org.uk (Russell King - ARM Linux)]

On Thu, Aug 31, 2017 at 09:30:54AM +0200, Geert Uytterhoeven wrote:
> > Note that on my side, I've however not been convinced by this semantic:
> > I find it weird that when you request a GPIO, it gets automatically
> > muxed as such, without an explicit pinctrl configuration in the DT.
> 
> On lots of hardware, you first have to select between GPIO and "other
> function".
> For "other function", you have to select the actual function later.
> In that case, switching to a GPIO can be done by flipping a single bit.

What about hardware which you can configure for some alternate function
but still monitor the pin via GPIO, even though it's not mux'd as GPIO.

For instance, you may have a timer block which can capture on both
edges of an external event signal, which needs the pin to be muxed for
that function.  However, you need to read the state of the pin, and
that is only available through GPIO.  Muxing the pin to be a GPIO just
because someone requests the GPIO is, imho, ill thought-out and breaks
some use cases.

IMHO, the pinmux settings should always be specified in DT, and that's
what we should be using everywhere, not doing broken backdoor games like
"the gpio is being requested, it's obvious that we want this pin to be
a gpio" - that really doesn't follow.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up