Requesting as a GPIO a pin already used through pinctrl

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

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

Hi,

I just came across an interesting issue on our Allwinner SoCs.

We have, like most of the SoCs these days, a bunch of boards that go
through pinctrl to ensure their exclusive usage for a particular
device. If a second pinctrl user comes in and tries to request one of
those pins, it gets an error. Everything works fine.

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, but given the implementation, I think that
it would work alike by calling gpiod_request).

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.

It seems from a look at the code that the request and
gpio_request_enable callbacks in the pinmux_ops, called in
pin_request, were meant to prevent such a thing.

But looking at all the drivers around, no one seems to take that case
into consideration, and this has been confirmed on an AT91 (which uses
an entirely different driver).

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.

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