Re: Requesting as a GPIO a pin already used through pinctrl

[Michael Welling <mwelling@xxxxxxxx>]

On Wed, Sep 21, 2016 at 10:51:28PM +0300, Maxime Ripard wrote:
> Hi Linus,
> 
> Thanks for your reply.
> 
> On Sun, Sep 18, 2016 at 01:30:24PM +0200, Linus Walleij wrote:
> > On Fri, Sep 16, 2016 at 3:58 PM, Maxime Ripard
> > <maxime.ripard@xxxxxxxxxxxxxxxxxx> wrote:
> > 
> > > However, things are getting weird when you have that requested pin
> > > assigned to one device, and you try to export the GPIO on that pin
> > > (through sysfs for example,
> > 
> > DON'T use sysfs. Use the new chardev ABI which is by the way enabled
> > by default.
> > 
> > (But you will face the same issue there I guess.)
> 
> Yeah, well, we could re-do the discussion on ksummit-discuss :)

Are you guys trolling me?

> 
> > > but given the implementation, I think that
> > > it would work alike by calling gpiod_request).
> > 
> > Yes
> > 
> > > In this case, you get no error, and the GPIO is indeed exported,
> > > allowing the user to change the direction and / or value of the pin,
> > > taking away that pin from its device.
> > 
> > If and only if the pin controller does not specify .strict in
> > struct pinmux_ops.
> > 
> > > I have the feeling that the core should prevent that, making sure that
> > > the gpiod_request returns EBUSY in such a case, but I'm not really
> > > sure whether it's the case or not, and if it is, where that check is
> > > happening.
> > 
> > - Did you try specifying .strict for the pinmux?
> > 
> > - Did you read Documentation/pinctrl.txt, section titled
> >   "GPIO mode pitfalls"?
> 
> Sigh. Sorry for that, I should learn to read the documentation. This
> is obviously the right thing to do.
> 
> However, it does have an unexpected side-effect. On our DT, for the
> GPIOs, we also set up a pinctrl node (which seem to be along the lines
> of the doc recommandations, section "Drivers needing both pin control
> and GPIOs").
> 
> However, when pinctrl_select_default is called by the core, which in
> turns ends up calling pinmux_enable_setting, which builds the owner
> name using the dev_name. However, when we call gpiod_request, it ends
> up in pinmux_request_gpio, which build the owner string using the
> pinctrl device name and the pin number.
> 
> This results in a mismatch of owners, and the gpiod_request fails,
> while the device really is the same.
> 
> Thanks,
> Maxime
> 
> -- 
> Maxime Ripard, 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html