From: Mark Brown <broonie@kernel.org>
To: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com>
Cc: Doug Anderson <dianders@chromium.org>,
Marco Felsch <m.felsch@pengutronix.de>,
Chunyan Zhang <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: Fri, 4 Oct 2019 12:32:34 +0100 [thread overview]
Message-ID: <20191004113234.GA4866@sirena.co.uk> (raw)
In-Reply-To: <20191004063443.GA26028@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]
On Fri, Oct 04, 2019 at 09:34:43AM +0300, Matti Vaittinen wrote:
> On Tue, Oct 01, 2019 at 12:57:31PM -0700, Doug Anderson wrote:
> > I don't think your fix is correct. It sounds as if the intention of
> > "regulator-boot-on" is to have the OS turn the regulator on at bootup
> > and it keep an implicit reference until someone explicitly tells the
> > OS to drop the reference.
> Hmm.. What is the intended way to explicitly tell the OS to drop the
> reference? I would assume we should still use same logic as with other
> regulators - if last user calls regulator_disable() we should disable
> the regulator? (I may not understand all this well enough though)
Yes.
> > It's a fixed regulator controlled by a GPIO? Presumably the GPIO can
> > be read. That would mean it ideally shouldn't be using
> > "regulator-boot-on" since this is _not_ a regulator whose software
> > state can't be read. Just remove the property.
> How should we handle cases where we want OS to enable regulator at
> boot-up - possibly before consumer drivers can be load?
If you want the regulator to be on without any driver present then mark
it always-on. If you want the regulator to be enabled prior to the
driver being loaded then the expectation is that the bootloader will do
that, it's difficult to see what the benefit there is from having the
kernel enable things when it starts prior to having a driver unless the
intent is to keep the regulator always on.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-10-04 11:32 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
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 [this message]
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=20191004113234.GA4866@sirena.co.uk \
--to=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=dianders@chromium.org \
--cc=kernel@pengutronix.de \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=m.felsch@pengutronix.de \
--cc=matti.vaittinen@fi.rohmeurope.com \
--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).