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: <4F200C93.30502@nvidia.com>
Date:	Wed, 25 Jan 2012 19:37:15 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.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 V2] regulator: tps65910: Sleep control through external
 inputs

On Wednesday 25 January 2012 06:20 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Jan 25, 2012 at 06:17:43PM +0530, Laxman Dewangan wrote:
>> On Wednesday 25 January 2012 06:12 PM, Mark Brown wrote:
>>> This really isn't what the set_mode() API is for - especially the fact
>>> that it supports turning the regulator off which really isn't what
>>> set_mode() is supposed to do.  A generic driver using this API isn't
>>> going to play too well.
>> Then what should be the method? Is it through the macro similar to
>> patch V1 where LOW_POWER mode option come from platform data? The
>> idea  is to set the regulator in OFF or low power mode based on
>> external control.
> Like I said we've got the various suspend callbacks for setting the
> behaviour in suspend mode.
Then in this case, I will implement the
set_suspend_enable() and put the device in low power mode.
set_suspend_disable() and put the device in full power, normal mode.
set_suspend_mode(): based on mode and external control, either it will 
call existing set_mode() if it is not externally controlled otherwise 
set the mode locally for the case of externally controlled.

The board file will set the regulator_state accordingly for a given 
requirements through the constraints.

Does it make sense?


> * Unknown Key
> * 0x6E30FDDD

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ