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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 4 Feb 2014 11:10:45 +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 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.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)