linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Mark Brown <broonie@kernel.org>
Cc: Marco Felsch <m.felsch@pengutronix.de>,
	zhang.chunyan@linaro.org, Liam Girdwood <lgirdwood@gmail.com>,
	ckeepax@opensource.cirrus.com,
	LKML <linux-kernel@vger.kernel.org>,
	Sascha Hauer <kernel@pengutronix.de>
Subject: Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage
Date: Mon, 23 Sep 2019 11:36:11 -0700	[thread overview]
Message-ID: <CAD=FV=WVGj8xzKFFxsjpeuqtVzSvv22cHmWBRJtTbH00eC=E9w@mail.gmail.com> (raw)
In-Reply-To: <20190923181431.GU2036@sirena.org.uk>

Hi,

On Mon, Sep 23, 2019 at 11:14 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Mon, Sep 23, 2019 at 11:02:26AM -0700, Doug Anderson wrote:
>
> > I will freely admit my ignorance here, but I've always been slightly
> > confused by the "always-on" vs. "boot-on" distinction...
>
> > The bindings say:
>
> >   regulator-always-on:
> >     description: boolean, regulator should never be disabled
>
> >   regulator-boot-on:
> >     description: bootloader/firmware enabled regulator
>
> > For 'boot-on' that's a bit ambiguous about what it means.  The
> > constraints have a bit more details:
>
> Boot on means that it's powered on when the kernel starts, it's
> for regulators that we can't read back the status of.

1. Would it be valid to say that it's always incorrect to set this
property if there is a way to read the status back from the regulator?

2. Would this be a valid description of how the property is expected to behave
a) At early boot this regulator will be turned on if it wasn't already on.
b) If no clients are found for this regulator after everything has
loaded, this regulator will be automatically disabled.

If so then I don't _think_ #2b is happening, but I haven't confirmed.


> > ...but then that begs the question of why we have two attributes?
> > Maybe this has already been discussed before and someone can point me
> > to a previous discussion?  We should probably make it more clear in
> > the bindings and/or the constraints.
>
> boot-on just refers to the status at boot, we can still turn
> those regulators off later on if we want to.

How, exactly?  As of my commit 5451781dadf8 ("regulator: core: Only
count load for enabled consumers") if you do:

  r = regulator_get(...)
  regulator_disable(r)

...then you'll get "Underflow of regulator enable count".  In other
words, if a given regulator client disables more times than it enables
then you will get an error.  Since there is no client that did the
initial "boot" enable then there's no way to do the disable unless it
happens automatically (as per 2b above).

...or do you mean that people could call regulator_force_disable()?
Couldn't they also do that with an always-on regulator?



-Doug

  reply	other threads:[~2019-09-23 18:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-17 15:40 [PATCH 0/3] Regulator core fixes Marco Felsch
2019-09-17 15:40 ` [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage Marco Felsch
2019-09-23 18:02   ` Doug Anderson
2019-09-23 18:14     ` Mark Brown
2019-09-23 18:36       ` Doug Anderson [this message]
2019-09-23 18:49         ` Mark Brown
2019-09-23 22:40           ` Doug Anderson
2019-09-24 18:27             ` Mark Brown
2019-09-26 19:44               ` Doug Anderson
2019-09-27  8:47                 ` Marco Felsch
2019-10-01 19:57                   ` Doug Anderson
2019-10-04  6:34                     ` Matti Vaittinen
2019-10-04 11:32                       ` Mark Brown
2019-10-04 12:03                         ` Vaittinen, Matti
2019-10-04 15:01                           ` Mark Brown
2019-10-07  9:34                     ` Marco Felsch
2019-10-07 18:29                       ` Mark Brown
2019-10-08  6:03                         ` Marco Felsch
2019-10-08 12:51                           ` Mark Brown
2019-10-08 14:56                             ` Marco Felsch
2019-10-08 15:42                               ` Mark Brown
2019-10-08 16:16                                 ` Marco Felsch
2019-10-08 16:23                                   ` Mark Brown
2019-10-08 20:16                                     ` Marco Felsch
2019-10-09  9:54                                       ` Mark Brown
2019-09-17 15:40 ` [PATCH 2/3] regulator: of: fix suspend-min/max-voltage parsing Marco Felsch
2019-09-17 16:02   ` Applied "regulator: of: fix suspend-min/max-voltage parsing" to the regulator tree Mark Brown
2019-09-17 15:40 ` [PATCH 3/3] regulator: core: make regulator_register() EPROBE_DEFER aware Marco Felsch
2019-09-17 16:02   ` Applied "regulator: core: make regulator_register() EPROBE_DEFER aware" to the regulator tree Mark Brown
2019-09-18  0:57   ` [PATCH 3/3] regulator: core: make regulator_register() EPROBE_DEFER aware Dmitry Torokhov
2019-09-18  8:18     ` Marco Felsch
2019-09-18 15:53       ` Dmitry Torokhov
2019-09-18 16:06         ` Marco Felsch
2019-09-18 16:08         ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD=FV=WVGj8xzKFFxsjpeuqtVzSvv22cHmWBRJtTbH00eC=E9w@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=broonie@kernel.org \
    --cc=ckeepax@opensource.cirrus.com \
    --cc=kernel@pengutronix.de \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=zhang.chunyan@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).