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

[Maxime Ripard <maxime.ripard@free-electrons.com>]

[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]

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@free-electrons.com> 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 :)

> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]