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:   Tue, 27 Nov 2018 09:18:56 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Mark Brown <broonie@...nel.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 Mon, Nov 26, 2018 at 10:53:40PM +0100, Linus Walleij wrote:
> On Fri, Nov 23, 2018 at 2:25 PM Mark Brown <broonie@...nel.org> wrote:
> 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.

This issue I ran into following that path is it becomes rather
fiddly to have regulator_register behave sensibly with respect to
the GPIO. Obviously in the success case the core now owns the
GPIO and no issues. However, in the failure case it's not clear if
we want to core to release the GPIO or not, and consistently
doing either is fairly hard. But if your happy to have a go at it
I don't have any objections to it as a solution.

Thanks,
Charles