linux-kernel - Re: Would devm_regulator

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52F0F7A6.4070700@roeck-us.net>
Date:	Tue, 04 Feb 2014 06:22:30 -0800
From:	Guenter Roeck <linux@...ck-us.net>
To:	Mark Brown <broonie@...nel.org>
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 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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/