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

[Linus Walleij <linus.walleij@xxxxxxxxxx>]

On Wed, Aug 30, 2017 at 4:17 PM, Thomas Petazzoni
<thomas.petazzoni@xxxxxxxxxxxxxxxxxx> wrote:

> The call chain leading to the problem is:
>
>  gpiochip_add_data()
>   chip->request() == gpiochip_generic_request()
>    pinctrl_request_gpio()
>     pinmux_request_gpio()
>      pin_request()
>       ops->gpio_request_enable() == mvebu_pinmux_gpio_request_enable()
>        mvebu_pinconf_group_set()
>         grp->ctrl->mpp_set() == mvebu_regmap_mpp_ctrl_set()
>
> So what Timur is saying perhaps is that
> mvebu_pinmux_gpio_request_enable() shouldn't be changing the type of
> muxing, and therefore shouldn't be calling mvebu_pinconf_group_set().
>
> 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.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html