linux-kernel - Re: [PATCH 0/13] Updated V4

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: <20080509043708.GG4961@prithivi.gnumonks.org>
Date:	Fri, 9 May 2008 06:37:08 +0200
From:	Harald Welte <laforge@...monks.org>
To:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	arm kernel <linux-arm-kernel@...ts.arm.linux.org.uk>
Subject: Re: [PATCH 0/13] Updated V4  - Regulator Framework

On Thu, May 08, 2008 at 09:51:27PM +0100, Liam Girdwood wrote:
> > Do you think it would be worth to export something like this in the
> > generic API, too?  It's probably quite hard, since there are devices
> > that actually use the PCF506xx STANDBY state during suspend-to-ram, but
> > other devices leave the PCF506xx in the ON state and just disable the
> > individual regulators using I2C register writes.
> 
> Yes I think it would be worthwhile adding this sort of functionality. I
> had considered this earlier on in development but it was lower priority
> for me then.

ok. I also believe it is much lower priority. No disagreement here :)

> This would mean some additions to the regulator machine interface (to be
> used during machine regulator setup) and regulator driver interface (to
> set the values). I could add some 'standby_uV' and 'standby_mode' fields
> (one for each standby state) to struct regulation_constraints. This
> would define the desired voltage and regulator operating mode to be used
> during the regulators STANDBY/HIBERNATE states. Hence the correct
> regulator output state would be selected when the PMIC enters it's
> STANDBY/HIBERNATE state (via either a I2C write or hardware signal). 
> 
> Would this suffice for your PMIC (sorry I don't have the datasheet) ?

basically the pcf506xx cannot support a different voltage in standby
mode than in active mode.  They just simply have something like a
bitmaks where you define which regulator is still running in standby,
and which don't.

You can change the bits via I2C, and you can enter STANDBY via either
GPIO or I2C command.

As per the data sheet: If you really want to dig in to that, the
PCF50633 is publicly available at
http://people.openmoko.org/tony_tu/GTA02/datasheet/PMU/PCF50633UM_6.pdf
and the PCF50606 is available at
http://www.rockbox.org/twiki/pub/Main/DataSheets/pcf50606.pdf

> Entering the PMICs global STANDBY/HIBERNATE state usually either comes
> from the hardware (e.g. button press, low battery, over temp) or a
> software user request. The constraints would be set at machine init time
> (along with the runtime constraints). This would work well for WM8350,
> but I'm not sure for PCF506xx. 

it's pretty much the same.

> However, entering individual regulator STANDBY/HIBERNATE states can be
> more difficult and as it is quite tightly coupled to the machine (and
> it's current use case or use case transition). Do you need per regulator
> STANDBY/HIBERNATE control ? 

No!

Cheers,
-- 
- Harald Welte <laforge@...monks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

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