lkml.org 
[lkml]   [2014]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Would devm_regulator_enable be useful ?
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



\
 
 \ /
  Last update: 2014-02-04 16:41    [W:0.052 / U:0.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site