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;
MIME-Version: 1.0
References: <20181128104350.31902-1-linus.walleij@linaro.org> <20181128152238.GV16508@imbe.wolfsonmicro.main>
In-Reply-To: <20181128152238.GV16508@imbe.wolfsonmicro.main>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Thu, 29 Nov 2018 16:52:04 +0100
Message-ID: <CACRpkdbDWztKxjT4p8mfVSZRauPNOn4PBd9yjxHD1oYGecor1A@mail.gmail.com>
Subject: Re: [PATCH 00/10] Regulator ena_gpiod fixups
To:     Charles Keepax <ckeepax@opensource.cirrus.com>
Cc:     Liam Girdwood <lgirdwood@gmail.com>,
        Mark Brown <broonie@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Nov 28, 2018 at 4:22 PM Charles Keepax
<ckeepax@opensource.cirrus.com> wrote:

> It looks like the patches are assuming the regulator core,
> doesn't free the GPIO on an error, however that is not true in
> all cases. If only a single regulator has requested the GPIO then
> all the error paths after the call to regulator_ena_gpio_request
> in regulator_register will free the GPIO.

I guess part of it is that I should make sure not to gpiod_put()
if the [devm_]regulator_register() fails, I will go over the
series with that in mind!

Essentially the semantic is that the  [devm_]regulator_register()
call will immediately take ownership of the descriptor
and place it in the regulator core.

I'll check!

> Although this is not the
> case if more than one regulator has requested the GPIO.

This should be fine since the regulator core refcounts it,
when all the other regulators drops it, gpiod_put() will be
called as the refcount goes down to 0.

Yours,
Linus Walleij