From: Mark Brown <broonie@kernel.org>
To: "Vaittinen, Matti" <Matti.Vaittinen@fi.rohmeurope.com>
Cc: "lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"dianders@chromium.org" <dianders@chromium.org>,
"m.felsch@pengutronix.de" <m.felsch@pengutronix.de>,
"kernel@pengutronix.de" <kernel@pengutronix.de>,
"zhang.chunyan@linaro.org" <zhang.chunyan@linaro.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"ckeepax@opensource.cirrus.com" <ckeepax@opensource.cirrus.com>
Subject: Re: [PATCH 1/3] regulator: core: fix boot-on regulators use_count usage
Date: Fri, 4 Oct 2019 16:01:50 +0100 [thread overview]
Message-ID: <20191004150150.GD4866@sirena.co.uk> (raw)
In-Reply-To: <054bc4c050f1b16988de057f812232b0feb707cb.camel@fi.rohmeurope.com>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
On Fri, Oct 04, 2019 at 12:03:12PM +0000, Vaittinen, Matti wrote:
> On Fri, 2019-10-04 at 12:32 +0100, Mark Brown wrote:
> > 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.
> I thought the regulator-boot-on could have been used for that. But as I
> said - I don't really know all this so well =) And no, I am not opposed
> to offloading this from kernel to boot, I was just trying to learn what
> is the correct thing to do (tm). Thanks for educating me on this :) I
> will suggest adding the enabling to boot code if (when) I get questions
> concerning this. (always-on won't do for regulators which need to be
> controlled for power saving or heating issues).
If you want the kernel to do it early on without the bootloader then I
think we really need to understand the use case. My guess would be that
the underlying request would be to get the driver up earlier which is
something we should be better at but often easier said than done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
next prev parent reply other threads:[~2019-10-04 15:01 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
2019-10-04 12:03 ` Vaittinen, Matti
2019-10-04 15:01 ` Mark Brown [this message]
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=20191004150150.GD4866@sirena.co.uk \
--to=broonie@kernel.org \
--cc=Matti.Vaittinen@fi.rohmeurope.com \
--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=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