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

[jmondi <jacopo@jmondi.org>]

Hello,

On Wed, Aug 30, 2017 at 04:32:55PM +0200, Thomas Petazzoni wrote:
> Hello,
>
> On Wed, 30 Aug 2017 09:22:55 -0500, Timur Tabi wrote:
>
> > No, that's it.  The question is, what exactly should the 'request'
> > function do?  Should it be modifying the hardware to satisfy the
> > request?  When I wrote my patch, I assumed that it wouldn't.  I thought
> > that request simply answered the question, "can I touch this GPIO"?
>
> No, it also muxes the pin in GPIO, and you can see the "reference"
> implementation pinctrl-single also does it.
>
> Let's see what Linus W. has to say about the semantic of the "request"
> operation.
>
> But if we change the semantic of "request" to no longer mux the hardware
> as GPIO, then you will also have regressions, because there are plenty
> of GPIOs that are requested, but not explicitly muxed as GPIOs in the
> DT, precisely because today requesting a GPIO is sufficient to have it
> re-muxed as GPIO at the pinctrl level.

Just to point out one of Renesas' pin controller devices seems to
suffer from the same problem, introduced by Timur's commit

https://www.spinics.net/lists/linux-renesas-soc/msg17647.html

This is indeed caused by the "request" introduced by the above said
commit, that in rza1 pincontroller, actually muxes the requested
pin as GPIO.

Reverting that commit solves all the issues in our case too.

Thanks
   j
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html