From: Ulf Hansson <ulf.hansson@stericsson.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Mattias WALLIN <mattias.wallin@stericsson.com>,
Jonas ABERG <jonas.aberg@stericsson.com>,
Lee Jones <lee.jones@linaro.org>
Subject: Re: [PATCH] regulator: core: Keep boot_on regulators powered during init
Date: Wed, 25 Apr 2012 11:37:36 +0200 [thread overview]
Message-ID: <4F97C5E0.1050808@stericsson.com> (raw)
In-Reply-To: <20120425080226.GA3195@opensource.wolfsonmicro.com>
On 04/25/2012 10:02 AM, Mark Brown wrote:
> On Tue, Apr 24, 2012 at 02:43:20PM +0200, Ulf Hansson wrote:
>
>> So if grabbing a reference, there is no good point in the code were
>> I can drop it. Moreover _every_ host driver needs to handle this. It
>> will likely become a "hack" is my first impression.
>
> If it's something that every host driver needs to do then just factor it
> into the framework and we're done... The stuff you're trying to put in
> the regulator API feels equally like it's a bodge and it seems to me
> like we've just not thought of the best way for the MMC stack to figure
> out and keep track of if it needs a regulator or not.
>
>>> This just seems awfully fragile and very much dependant on things like
>>> having the driver actually enabled to clean up later.
>
>> Setting this constraint is not done be "default", it could be
>> clearly be stated that the consumer must handle the enable/disable,
>> otherwise the regulator will be left in the state it was when the
>> kernel booted.
>
> Right, but the whole point in having full constraints is to avoid that.
> Users are supposed to set constraints to grant permissions for things,
> not to work around internal problems in the rest of the stack. If I
> could see a general use case for the feature... but I'm having trouble
> doing that.
Maybe you have convinced me now :-) I will therefore start thinking of a
patch on the mmc framework instead. I will include you if/when I send
out the patch to the mmc-list, just for reference if that is ok with you?
Some final thoughts (please comment if you like):
We already have the boot_on constraint, which to me is similar to what a
new kind of "boot keep state" constraint would be. I think it would be
no more odd than what boot_on already is. Maybe not a good argument, but
still..
Kind regards
Ulf Hansson
next prev parent reply other threads:[~2012-04-25 9:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-23 9:37 [PATCH] regulator: core: Keep boot_on regulators powered during init Ulf Hansson
2012-04-23 10:18 ` Mark Brown
2012-04-23 10:52 ` Ulf Hansson
2012-04-23 11:05 ` Mark Brown
2012-04-23 12:21 ` Ulf Hansson
2012-04-23 12:25 ` Mark Brown
2012-04-23 12:45 ` Ulf Hansson
2012-04-23 18:01 ` Mark Brown
2012-04-24 8:09 ` Ulf Hansson
2012-04-24 10:56 ` Mark Brown
2012-04-24 12:43 ` Ulf Hansson
2012-04-25 8:02 ` Mark Brown
2012-04-25 9:37 ` Ulf Hansson [this message]
2012-04-25 9:58 ` Mark Brown
2012-04-25 16:45 ` Jassi Brar
2012-04-25 15:34 ` Jassi Brar
2012-04-25 15:44 ` Ulf Hansson
2012-04-25 16:31 ` Jassi Brar
2012-04-26 8:35 ` Mark Brown
2012-04-26 9:10 ` Jassi Brar
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=4F97C5E0.1050808@stericsson.com \
--to=ulf.hansson@stericsson.com \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=jonas.aberg@stericsson.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@slimlogic.co.uk \
--cc=mattias.wallin@stericsson.com \
/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).