linux-kernel - Re: [PATCH V1] regulator: tps65910: Sleep control through external inputs

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: <20120124212144.GG1135@opensource.wolfsonmicro.com>
Date:	Tue, 24 Jan 2012 21:21:44 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Laxman Dewangan <ldewangan@...dia.com>
Cc:	"lrg@...com" <lrg@...com>,
	"jedu@...mlogic.co.uk" <jedu@...mlogic.co.uk>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH V1] regulator: tps65910: Sleep control through external
 inputs

On Tue, Jan 24, 2012 at 06:07:28PM +0530, Laxman Dewangan wrote:

> E.g. If cpu power is in VDDCTRL rail and if DVFS mechanism of SOC
> wants that cpu rails to be ON, it will make the control signal
> active and if it wants to disable the rail then it will deactivate
> it.

> The toggling of the control lines depends on how the power
> management controller is designed for a given SOC and how it
> manages.

Hrm, right.  This isn't something that the regulator API usually deals
with - normally we just deal with things that Linux owns and assume that
if the hardware is wired up for something else to own the regulator it
will deal with that completely including the configuration.  If we do
need to do something here we need to make sure that the normal regulator
code doesn't try to do anything clever with the regulator which messes
up the other device.  But I guess this doesn't really have a problem
with that, someone can always add a further patch optionally specifying
GPIOs which won't conflict with this approach.

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