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