Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 27 Nov 2018 09:18:56 +0000
From:   Charles Keepax <ckeepax@opensource.cirrus.com>
To:     Linus Walleij <linus.walleij@linaro.org>
CC:     Mark Brown <broonie@kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        Marek Szyprowski <m.szyprowski@samsung.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        <patches@opensource.cirrus.com>
Subject: Re: [PATCH 3/3] gpio: Add reference counting for non-exclusive GPIOs
Message-ID: <20181127091856.GQ16508@imbe.wolfsonmicro.main>
References: <20181122173015.23905-1-ckeepax@opensource.cirrus.com>
 <20181122173015.23905-3-ckeepax@opensource.cirrus.com>
 <CACRpkdZEu44WHScd5VibYT5C9RikqcvKsgpVOpkkdrYbLaV8Ng@mail.gmail.com>
 <20181123105729.GM16508@imbe.wolfsonmicro.main>
 <20181123132522.GE2089@sirena.org.uk>
 <CACRpkdZKJGFmYFKBHdiayRsA2ona2zWfJ+xckJxD1UBsj39=sA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CACRpkdZKJGFmYFKBHdiayRsA2ona2zWfJ+xckJxD1UBsj39=sA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-12-10)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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