From: Mark Brown <broonie@kernel.org>
To: Pingbo Wen <pingbo.wen@linaro.org>
Cc: linux-kernel@vger.kernel.org, lgirdwood@gmail.com,
vincent.guittot@linaro.org, stephen.boyd@linaro.org
Subject: Re: [RFC PATCH] regulator: introduce boot protection flag
Date: Wed, 15 Jun 2016 14:32:55 +0100 [thread overview]
Message-ID: <20160615133255.GZ2282@sirena.org.uk> (raw)
In-Reply-To: <57614479.1060708@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 1788 bytes --]
On Wed, Jun 15, 2016 at 08:05:13PM +0800, Pingbo Wen wrote:
> On Thursday, June 09, 2016 01:16 AM, Mark Brown wrote:
> > It doesn't, it postpones them until late_initacall(). This is both
> > after the consumers have loaded if they are built in and before any
> > consumers built as modules come up.
> Yes, this patch only protects a regulator from regulator
> registration(built in) to late_initcall(). But, IMO, if a regulator is
> critical, it's weird to build as a module. Maybe I was thoughtless here.
Well, this comes back to the issue with it being very use case specific
and not generally clear what critical regualtors are supposed to be. It
really depends on what the system integrator wants, and there's things
like the distro use case where the normal thing to do is to build as
many drivers as possible as modules since you support such a huge range
of hardware.
> If we take modules under consideration, and to make this patch more
> universal, I think what we really need is adding a flag to protect a
> regulator from registration to a specific consumer(not the first
> consumer). The regulator driver gives the initial state, and the
> specific consumer need to clear this flag while finishing regulator
> setting(by calling a function like regulator_clear_protect()). And what
> the regulator core need to do is staging all operations during
> protection. And that will cover all consumers probing order, whenever
> the regulator is registered.
Having the consumer driver know that it's "critical" seems wrong since
different systems may have different ideas about that, it's probably
better to hook this in with the device model so that when the device
finishes probing that kicks things off.
> Any idea?
There were the other ideas I mentioned in my mail too.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2016-06-15 13:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 7:05 WEN Pingbo
2016-06-08 17:16 ` Mark Brown
2016-06-15 12:05 ` Pingbo Wen
2016-06-15 13:32 ` Mark Brown [this message]
2016-06-17 3:34 ` Pingbo Wen
2016-06-17 11:42 ` Mark Brown
2016-06-23 12:02 ` Pingbo Wen
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=20160615133255.GZ2282@sirena.org.uk \
--to=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pingbo.wen@linaro.org \
--cc=stephen.boyd@linaro.org \
--cc=vincent.guittot@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
all inboxes | Powered by JetHome®