linux-kernel - Re: [linux-pm] Power Domain Framework

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-next>] [day] [month] [year] [list]

Date:	Sun, 23 May 2010 20:39:00 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Sundar <sunder.svit@...il.com>
Cc:	Viresh KUMAR <viresh.kumar@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...com>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	Armando VISCONTI <armando.visconti@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Vipin KUMAR <vipin.kumar@...com>,
	Shiraz HASHIM <shiraz.hashim@...com>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@...t.st.com>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] Power Domain Framework

On Sat, May 22, 2010 at 09:32:10AM +0530, Sundar wrote:

> > operating mode for the entire power domain. For example, I can see
> > hardware requiring that if more than a given number of blocks are
> > enabled at any level a higher operating point is selected.

> To me, since such a requirement is a constraint on the regulator,
> this can be added as a flag to the regulator details.
> This flag can then be used in the set_opp* functions to check the
> condition along with the client dependencies!

This is just one example of something that might come up and need
fitting in to the regulator API which is substantially different to the
needs of the core regulator applications.  As I keep saying I'm just not
seeing much more overlap here with the regulator API than I do with the
clock API: it feels like you've got another use case which needs an API
with a similar structure and the reference counted enable and disable
calls but otherwise very little overlap.

I don't think the enable and disable calls are enough of an overlap to
mean that the regulator use case and the operating point use case are
going to overlap well, it feels like it'd cause pain trying to match the
concepts between the two APIs.
--
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/