linux-kernel - RE: [RFC] Regulator state after 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]

Date:	Thu, 28 Apr 2011 11:08:08 +0000
From:	<kalle.jokiniemi@...ia.com>
To:	<broonie@...nsource.wolfsonmicro.com>
CC:	<lrg@...mlogic.co.uk>, <mchehab@...radead.org>,
	<svarbatov@...sol.com>, <saaguirre@...com>,
	<grosikopulos@...sol.com>, <vimarsh.zutshi@...ia.com>,
	<Sakari.Ailus@...ia.com>, <linux-kernel@...r.kernel.org>,
	<linux-media@...r.kernel.org>
Subject: RE: [RFC] Regulator state after regulator_get

Hi,

 > -----Original Message-----
 > From: ext Mark Brown [mailto:broonie@...nsource.wolfsonmicro.com]
 > Sent: 28. huhtikuuta 2011 13:06
 > To: Jokiniemi Kalle (Nokia-SD/Tampere)
 > Cc: lrg@...mlogic.co.uk; mchehab@...radead.org; svarbatov@...sol.com;
 > saaguirre@...com; grosikopulos@...sol.com; Zutshi Vimarsh (Nokia-
 > SD/Helsinki); Ailus Sakari (Nokia-SD/Helsinki); linux-kernel@...r.kernel.org;
 > linux-media@...r.kernel.org
 > Subject: Re: [RFC] Regulator state after regulator_get
 > 
 > On Thu, Apr 28, 2011 at 09:01:03AM +0000, kalle.jokiniemi@...ia.com wrote:
 > 
 > > If the device driver using the regulator does not enable and disable the
 > > regulator after regulator_get, the regulator is left in the state that it was
 > > after bootloader. In case of N900 this is a problem as the regulator is left
 > > on to leak current. Of course there is the option to let regulator FW disable
 > > all unused regulators, but this will break the N900 functionality, as the
 > > regulator handling is not in place for many drivers.
 > 
 > You should use regulator_full_constraints() if your board has a fully
 > described set of regulators.  This will cause the framework to power
 > down any regulators which aren't in use after init has completed.  If
 > you have some regulators with no consumers or missing consumers you need
 > to mark them as always_on in their constraints.

I don't have a full set of regulators described, that's why things broke when
I tried the regulator_full_constraints call earlier. But I don't think it would be too
big issue to check the current after boot configuration and define all the
regulators as you suggest. I will try this approach.

 > 
 > > So reset the regulator on first regulator_get call to make
 > > sure that any regulator that has users is not left active
 > > needlessly.
 > 
 > This would cause lots of breakage, it would mean that all regulators
 > that aren't always_on would get bounced off at least once during startup
 > - that's not going to be great for things like the backlight.

OK, this is not a viable solution.

Thanks for the comments,
Kalle

--
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/