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 22:53:40 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Charles Keepax <ckeepax@...nsource.cirrus.com>,
        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 2:25 PM Mark Brown <broonie@...nel.org> wrote:

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

I think we see some problems with devm_* managed resources here
and I see Charles' and your point.

The managed resources pretty much assume
that you tie resources to the device model and let kref inside the
kobject in struct device do all refcounting and that essentially
collides with the refcounting inside the regulator core, they both
want to control this now.

If we try to push the regulator requests into the regulator core
it becomes complex, because that requires at least two different
methods as we move away from the global GPIO numberspace,
and the drivers usually knows best how to request it.

Indeed I imagined it like so when adding descriptor support,
as we do this mostly like that for other resources.

I suspect maybe the lesser evil is to bite the bullet, invent
gpiod_get_from_of_node() which is the missing API (we currently
only have devm_gpiod_get_from_of_node()) and simply
fix up the converted regulator drivers to avoid devm_*
retrieveal in the same manner as wm8994 (the already
queued patch). This will make the regulator core own the
refcounting as it does today.

It's a bit unelegant but it's very straight forward and I know
I can fix it up qucikly.

Unless anyone thinks it's a bad idea I will try to make a
small fix series like that and a GPIO patch you can also
carry in the regulator tree with it.

Yours,
Linus Walleij