linux-kernel - Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 26 Nov 2018 13:00:01 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Mark Brown <broonie@...nel.org>
CC:     Linus Walleij <linus.walleij@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>
Subject: Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs

On Fri, Nov 23, 2018 at 01:25:22PM +0000, Mark Brown wrote:
> On Fri, Nov 23, 2018 at 10:57:29AM +0000, Charles Keepax wrote:
> 
> > It's fixing something in the case of two regulators using the
> > same GPIO. The direction this patch chain takes is that the end
> > drivers own the GPIOs not the regulator core (except for the
> > legacy case). So both of the end drivers will devm_ request their
> 
> The situation with descriptor based GPIOs is a bug - the reason why the
> core does the request in the legacy case is precisely the problem Linus
> identified.  Once a GPIO is shared all the users of the GPIO need to
> coordinate with each other in order to set the value so the refcount by
> itself in the GPIO core isn't super useful unless it can also serve to
> help the multiple users find each other somehow.  I think what we want
> to do here is either push the gpiod requests into the regulator core or
> change things so that once the regulator is registered with the
> regulator core the regulator core owns and is responsible for freeing
> the regulator.

On the co-ordinating do we expect that the behaviour will
be that the GPIO should in the "enabled" state whenever any
regulator is requesting it? IE. the GPIO state is an OR of
the regulator states. Or are we expecting to handle more
complex interaction?

Thanks,
Charles