[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140204200951.GA22609@sirena.org.uk>
Date: Tue, 4 Feb 2014 20:09:51 +0000
From: Mark Brown <broonie@...nel.org>
To: Guenter Roeck <linux@...ck-us.net>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Liam Girdwood <lgirdwood@...il.com>
Subject: Re: Would devm_regulator_enable be useful ?
On Tue, Feb 04, 2014 at 06:22:30AM -0800, Guenter Roeck wrote:
> On 02/04/2014 03:10 AM, Mark Brown wrote:
> >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.
It's partly about what we're encouraging people to do - if the
frameworks are encouraging people to do things we don't want them to do
that's not great, and if there are things that are normally warning
signs that are getting used normally that's a bit worrying.
For what you're talking about it'd seem better to have the core
automatically drop the reference counts on enabled regulators when the
consumer is destroyed all the time rather than having an explicit devm_
function for it.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists