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:
signature.asc
Description: PGP signature
