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 09:44:10 +0000
From:	<kalle.jokiniemi@...ia.com>
To:	<Sakari.Ailus@...ia.com>
CC:	<broonie@...nsource.wolfsonmicro.com>, <lrg@...mlogic.co.uk>,
	<mchehab@...radead.org>, <svarbatov@...sol.com>,
	<saaguirre@...com>, <grosikopulos@...sol.com>,
	<vimarsh.zutshi@...ia.com>, <linux-kernel@...r.kernel.org>,
	<linux-media@...r.kernel.org>, <laurent.pinchart@...asonboard.com>
Subject: RE: [RFC] Regulator state after regulator_get

Hi,

 > -----Original Message-----
 > From: Sakari Ailus [mailto:sakari.ailus@...ia.com]
 > Sent: 28. huhtikuuta 2011 12:34
 > To: Jokiniemi Kalle (Nokia-SD/Tampere)
 > Cc: broonie@...nsource.wolfsonmicro.com; lrg@...mlogic.co.uk;
 > mchehab@...radead.org; svarbatov@...sol.com; saaguirre@...com;
 > grosikopulos@...sol.com; Zutshi Vimarsh (Nokia-SD/Helsinki); linux-
 > kernel@...r.kernel.org; linux-media@...r.kernel.org; Laurent Pinchart
 > Subject: Re: [RFC] Regulator state after regulator_get
 > 
 > Hello,
 > 
 > Jokiniemi Kalle (Nokia-SD/Tampere) wrote:
 > > Hello regulator FW and OMAP3 ISP fellows,
 > >
 > > I'm currently optimizing power management for Nokia N900 MeeGo DE
 > release,
 > > and found an issue with how regulators are handled at boot.
 > >
 > > The N900 uses VAUX2 regulator in OMAP3430 to power the CSIb IO complex
 > > that is used by the camera. While implementing regulator FW support to
 > > handle this regulator in the camera driver I noticed a problem with the
 > > regulator init sequence:
 > >
 > > 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.
 > >
 > > I found couple of solutions to this:
 > > 1. reset all regulators that have users (regulator_get is called on them) with
 > > a regulator_enable/disable cycle within the regulator FW.
 > > 2. enable/disable the specific vdds_csib regulator in the omap3isp driver
 > > to reset this one specific regulator to disabled state.
 > >
 > > So, please share comments on which approach is more appropriate to take?
 > > Or maybe there is option 3?
 > >
 > > Here are example code for the two options (based on .37 kernel, will update
 > > on top of appropriate tree once right solution is agreed):
 > >
 > > Option1:
 > >
 > > If a consumer device of a regulator gets a regulator, but
 > > does not enable/disable it during probe, the regulator may
 > > be left active from boot, even though it is not needed. If
 > > it were needed it would be enabled by the consumer device.
 > >
 > > So reset the regulator on first regulator_get call to make
 > > sure that any regulator that has users is not left active
 > > needlessly.
 > 
 > I'm not an expert in the regulator framework, but I'd think that one
 > should be able to assume a regulator is in a sane state after boot. The
 > fact that the regulator is enabled when it has no users should likely be
 > fixed in the boot loader. Is that an option?

Not an option, the device has shipped and there will be no updates to
the bootloader.

 > 
 > Does the problem exist in other boards beyond N900?

Don't know, I currently have only N900 to test with.

 > 
 > Another alternative to the first option you proposed could be to add a
 > flags field to regulator_consumer_supply, and use a flag to recognise
 > regulators which need to be disabled during initialisation. The flag
 > could be set by using a new macro e.g. REGULATOR_SUPPLY_NASTY() when
 > defining the regulator.

This sounds like a good option actually. Liam, Mark, any opinions?

- Kalle

 > 
 > Just my 0,05 euros. ;-)
 > 
 > Cc Laurent Pinchart.
 > 
 > Regards,
 > 
 > --
 > Sakari Ailus
 > sakari.ailus@...well.research.nokia.com
--
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/