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: <1210362244.20475.125.camel@odin>
Date:	Fri, 09 May 2008 20:44:04 +0100
From:	Liam Girdwood <lg@...nsource.wolfsonmicro.com>
To:	Harald Welte <laforge@...monks.org>
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 Fri, 2008-05-09 at 06:37 +0200, Harald Welte wrote:
> 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.
> 

Ok, I've created a new struct regulator_state in machine.h to describe
a regulators suspended state for a given system suspend state :-

struct regulator_state {
        int uV; /* suspend voltage */
        unsigned int mode; /* suspend regulator operating mode */
        int enabled; /* is regulator enabled in this suspend state */
};

'uV' and 'mode' are optional 'enabled' is mandatory. This should also
cover other PMICs where voltage and operating mode may be configurable.

I've also added the following fields to struct regulation_constraints in
machine.h :-

/* regulator suspend states for global PMIC STANDBY/HIBERNATE */
struct regulator_state state_disk;
struct regulator_state state_mem;
struct regulator_state state_standby;
suspend_state_t initial_state; /* suspend state to set at init */

This should define all the regulator's supported system suspend states
and be registered with the other constraints.

In order to switch PMIC suspend configurations, I've added :-

int regulator_suspend_prepare(suspend_state_t state);

This will configure each PMIC regulator (if required) with the correct
suspend setup prior to entering the new suspend state (and could be
called by machine suspend code to prepare the pc506xx).

Liam


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