Messages in this thread | | | Date | Tue, 04 Feb 2014 06:22:30 -0800 | From | Guenter Roeck <> | Subject | Re: 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
| |