From: Pingbo Wen <pingbo.wen@linaro.org>
To: Mark Brown <broonie@kernel.org>
Cc: pingbo.wen@linaro.org, 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: Thu, 23 Jun 2016 20:02:01 +0800 [thread overview]
Message-ID: <576BCFB9.2040503@linaro.org> (raw)
In-Reply-To: <20160617114235.GK26099@sirena.org.uk>
Hi, Mark
On Friday, June 17, 2016 07:42 PM, Mark Brown wrote:
> On Fri, Jun 17, 2016 at 11:34:25AM +0800, Pingbo Wen wrote:
>> On Wednesday, June 15, 2016 09:32 PM, Mark Brown wrote:
>
>>> 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.
>
>> That will imply the protection would be end when the specific device has
>> probed, and consumers should take their place at the same time. But
>> there have some other devices, which will set the consumer in a IRQ
>> event, or after some other events, can't be covered.
>
> I don't understand what this means, sorry.
>
I mean maybe there's some consumer driver only do partial initialization
during probing.
>> We can set the protection flag easily, but it's hard to tell whether a
>> consumer is well initialized, the end of protection, since regulator
>> consumer is not initialized within one call.
>
> If the driver is not initializing itself during probe the driver is
> doing something wrong and needs to be fixed anyway.
>
OK, if all driver have full initialized during probing, and we need
insert a hook after driver probing. I think we can add a function in
driver/base/dd.c:driver_probe_device() as this:
ret = really_probe(dev, drv);
...
if (!ret)
regulator_clean_up(dev);
And in regulator_clean_up(), we can iterate all regulator deivce, and
call a regulator_clear_boot_protection function:
if (!rdev->constraints->boot_protection)
return 0;
if (strcmp(rdev->constraints->critical_consumer, dev_name(dev)))
return 0;
rdev->constraints->boot_protection = 0;
...
-real clean stuffs-
the critical_consumer can be specified in devicetree.
Add a callback in driver_probe_device() is not so good, but it's fine
for me.
Pingbo
prev parent reply other threads:[~2016-06-23 12:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-09 7:05 [RFC PATCH] regulator: introduce boot protection flag WEN Pingbo
2016-06-08 17:16 ` Mark Brown
2016-06-15 12:05 ` Pingbo Wen
2016-06-15 13:32 ` Mark Brown
2016-06-17 3:34 ` Pingbo Wen
2016-06-17 11:42 ` Mark Brown
2016-06-23 12:02 ` Pingbo Wen [this message]
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=576BCFB9.2040503@linaro.org \
--to=pingbo.wen@linaro.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.