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: <20181011143531.7195-1-linus.walleij@linaro.org>
 <20181011144330.GF25351@sirena.org.uk> <CACRpkdbTnBQhPQARX77KfjtfWXY+t0oH6-B=WUN4hid8eQT0DA@mail.gmail.com>
 <20181011175406.GH25351@sirena.org.uk>
In-Reply-To: <20181011175406.GH25351@sirena.org.uk>
From:   Linus Walleij <linus.walleij@linaro.org>
Date:   Thu, 11 Oct 2018 20:41:16 +0200
Message-ID: <CACRpkdY=ya9CJz0HbsdgzR+05SdoHQ+V17fY8sBtNtF482eXew@mail.gmail.com>
Subject: Re: [PATCH] gpio/regulator: Allow nonexclusive GPIO access
To:     Mark Brown <broonie@kernel.org>
Cc:     Liam Girdwood <lgirdwood@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Marek Szyprowski <m.szyprowski@samsung.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Oct 11, 2018 at 7:54 PM Mark Brown <broonie@kernel.org> wrote:
> On Thu, Oct 11, 2018 at 07:01:13PM +0200, Linus Walleij wrote:
> > On Thu, Oct 11, 2018 at 4:43 PM Mark Brown <broonie@kernel.org> wrote:
> > > On Thu, Oct 11, 2018 at 04:35:31PM +0200, Linus Walleij wrote:
>
> > > enable line so you don't need to use the bus to do the enables.  That
> > > should just be a case of adding this flag to all the drivers that have
> > > already been converted to gpiod (including the core code that's in
> > > regulator_ena_gpio_request() which I thought was coping with this
> > > already) unless I'm missing something?
>
> > Sorry if I don't get it... we already have code in the core to
> > check if the same gpiod is used by two regulators.
> > regulator_ena_gpio_request() does this:
>
> >         if (config->ena_gpiod)
> >                 gpiod = config->ena_gpiod;
> >         else
> >                 gpiod = gpio_to_desc(config->ena_gpio);
>
> > So after the change I made to fixed.c this comes in through
> > config->ena_gpiod.
>
> Other regulators that have GPIO control for their enables do their own
> requests (as does the core) so don't they all need to set the flag
> GPIOD_FLAGS_BIT_NONEXCLUSIVE when they request otherwise it'll only work
> in systems where the regulators after the first that request the GPIO
> are fixed regulators?

Yeah ... I guess I assumed that the same enable line is not used
for a fixed regulator and then some other regulator (which is not
fixed).

If this is common practice we need to account for it. Obviously
I have no idea what is common practice :/

gpio-regulator.c will work fine since it passes in a global
number (still) so it will just grab the desc out of the GPIO
with the legacy function and go on. (I need to keep it in mind
when refactoring that one later though!)

Do we know some way to identify the affected systems or
should we just tag on GPIOD_FLAGS_BIT_NONEXCLUSIVE
on all the stuff we converted to descs to play it safe?
(I can cook a patch.)

Yours,
Linus Walleij