From: Guenter Roeck <linux@roeck-us.net>
To: Mark Brown <broonie@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>
Subject: Re: Would devm_regulator_enable be useful ?
Date: Tue, 04 Feb 2014 06:22:30 -0800 [thread overview]
Message-ID: <52F0F7A6.4070700@roeck-us.net> (raw)
In-Reply-To: <20140204111045.GS22609@sirena.org.uk>
On 02/04/2014 03:10 AM, Mark Brown wrote:
> On Mon, Feb 03, 2014 at 02:27:26PM -0800, Guenter Roeck wrote:
>> On Mon, Feb 03, 2014 at 06:21:52PM +0000, Mark Brown wrote:
>
>>> As previously mentioned please fix your mailer to word wrap at a
>>> sensible limit.
>
>> I thought I did ;-). I'll try to make sure I only send e-mail to you
>> using mutt in the future ... but I notice that your line length is
>> less than the one I configured, so maybe that is the problem here.
>
> You need to allow some room for quoting.
>
>>> In both cases enabling and then leaving the resource enabled throughout
>>> the runtime of the device isn't normally the best practice for using
>>> them. You usually want to enable and disable at runtime with mechanisms
>>> like runtime PM when the device is idle rather than burning power all
>>> the time and once you start doing that managed resources don't fit so
>>> well.
>
>> Ok, I accept that. I thought that was what devm_xxx_[disable,remove] etc
>> was for, though.
>
> Sort of. They're there but that doesn't mean that they should be used
> in normal operation - they should be special cases, not normal things.
> Managed resources are supposed to for things that are more fire and
> forget.
>
Isn't that a bit philosophical ? The drivers I had in mind commonly
call regulator_enable() in probe and regulator_disable() in remove.
Having device managed functions would simplify that code a lot.
If those same drivers implement pm functions, I don't see a problem
using devm_ functions in those. Sure, execution complexity is a bit
higher, but it is not as if pm functions are high volume calls.
And, after all, the existence of devm_ functions doesn't mean
that they _have_ to be used.
Guenter
next prev parent reply other threads:[~2014-02-04 14:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-02 0:23 Would devm_regulator_enable be useful ? Guenter Roeck
2014-02-03 18:21 ` Mark Brown
2014-02-03 22:27 ` Guenter Roeck
2014-02-04 11:10 ` Mark Brown
2014-02-04 14:22 ` Guenter Roeck [this message]
2014-02-04 20:09 ` 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=52F0F7A6.4070700@roeck-us.net \
--to=linux@roeck-us.net \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.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.