linux-next regression caused by "gpiolib: request the gpio before querying its direction"
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Thu Aug 31 00:18:12 PDT 2017
Hello,
On Thu, 31 Aug 2017 09:08:45 +0200, Linus Walleij wrote:
> > However, even the "reference" pinctrl-single.c implementation does it,
> > in pcs_request_gpio().
>
> Yeah so we have unclear semantics on this and that is just a fact of
> life. It's a bit of pain as maintainer because I sometimes don't know
> what to do when something makes superficial sense and the only thing
> I can do is to toss it into linux-next and see what happens.
>
> Look what happened :D
>
> If the semantics should be changed, all drivers must be changed consistently
> in a larger patch series, so until then, we revert this and leave it as it is.
>
> Now this is reverted anyways.
Thanks for taking action on this. Regarding the semantics, the
kerneldoc comment says:
* @gpio_request_enable: requests and enables GPIO on a certain pin.
* Implement this only if you can mux every pin individually as GPIO. The
* affected GPIO range is passed along with an offset(pin number) into that
* specific GPIO range - function selectors and pin groups are orthogonal
* to this, the core will however make sure the pins do not collide.
* @gpio_disable_free: free up GPIO muxing on a certain pin, the reverse of
* @gpio_request_enable
So the ->gpio_request_enable() comment is not super clear, but the
->gpio_disable_free() explicitly says "free up GPIO muxing", which
would mean the ->gpio_request_enable() hook has muxed the pin as GPIO.
Things could be clearer, but I believe it's quite clear the intent is
that the ->gpio_request_enable() should mux the pin as a GPIO at the HW
level.
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.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
More information about the linux-arm-kernel
mailing list