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]
Message-ID: <20100524033859.GB24480@opensource.wolfsonmicro.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ