linux-kernel - Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 29 Jan 2018 14:43:48 +0100
From:   Ludovic Desroches <ludovic.desroches@...rochip.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
CC:     Linus Walleij <linus.walleij@...aro.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>
Subject: Re: [RFC PATCH 2/2] gpio: provide a consumer when requesting a gpio

On Fri, Jan 26, 2018 at 07:13:32PM +0200, Andy Shevchenko wrote:
> On Fri, Jan 26, 2018 at 9:32 AM, Ludovic Desroches
> <ludovic.desroches@...rochip.com> wrote:
> > On Wed, Jan 24, 2018 at 05:42:15PM +0200, Andy Shevchenko wrote:
> >> On Wed, Jan 24, 2018 at 3:07 PM, Ludovic Desroches
> >> <ludovic.desroches@...rochip.com> wrote:
> >> > On Thu, Jan 18, 2018 at 04:22:28PM +0100, Ludovic Desroches wrote:
> >> >> On Thu, Jan 18, 2018 at 11:30:00AM +0100, Linus Walleij wrote:
> 
> >> >> > Can't we just look up the associated gpio_chip from the GPIO range,
> >> >> > and in case the pin is connected between the pin controller and
> >> >> > the GPIO chip, then we allow the gpiochip to also take a
> >> >> > reference?
> >>
> >> How do you find my proposal about introducing ownership level (not
> >> requested yet; exclusive; shared)?
> 
> > Yes but I don't see how I can fix my issue with these levels. In my
> > case, I need an exclusive ownership at device level not at pin level. In
> > reality, it is at pin level but I am in this situation because my pin
> > controler was introduced as non strict and also because I need to set
> > the configuration of the pin which is going to be used as a GPIO.
> >
> > If the ownership is exclusive, pinmuxing coming from pinctrl-default
> > will be accepted but the GPIO request will fail even if it comes from the
> > same device.
> 
> The problem here is to declare a right consumer of the resource.
> 
> My understanding that consumer at the end is device or device(s):
> 
> none: resource is free to acquire
> exclusive: certain device has access to the resource (pin)
> shared: several devices may access to the resource
> 
> In both cases couple of caveats:
> - power management has a special access level to the resource on
> behalf of the owner(s)
> - it can have some flags, like 'locked', which means no more owners
> can be changed / added, but still possible to free resource by all
> owners to go to state 'none'
> 
> > If the ownership is shared then, pinmuxing coming from pinctrl-default
> > will be accepted but a GPIO request from another device will be accepted
> > too.
> >
> > Both situations are incorrect in my case.
> 
> Yes, since the ownership design is based on subsystem rather consumer device.
> 
> > Let me know if I have not well understood your proposal. My concern is
> > to get out of this situation without breaking current DTs.
> 
> See above, hope it clarifies a bit.

Yes I get it but I still don't see how I can use your approach to solve
my issue. We have a situation for several pin controllers. If I can't
know who is requesting the GPIO, I have no idea about how to solve this
issue. Bypassing the strict mode, as suggested, if the pin controller is also
a gpio controller may lead, IMO, to wrong behaviors. 

Do I have to try to find a way to fix this situation? Maybe, it will be
easier to progress on the muxing and configuration topic and to
introduce a DT property to enable the strict mode or wathever modes you
want once everything is ready and DTs fixed.

I'd prefer to fix the current situation then to improve muxing and
configuration stuff because it will take time.

Regards

Ludovic