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

Message-ID: <1274115886.2698.22.camel@finisterre.wolfsonmicro.main>
Date:	Mon, 17 May 2010 10:04:46 -0700
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	sundar.iyer@...ricsson.com
Cc:	Deepak Sikri <deepak.sikri79@...il.com>,
	Viresh KUMAR <viresh.kumar@...com>,
	Rajeev KUMAR <rajeev-dlh.kumar@...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>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>,
	Linus WALLEIJ <linus.walleij@...ricsson.com>,
	STEricsson_nomadik_linux <STEricsson_nomadik_linux@...t.st.com>
Subject: Re: [linux-pm] Power Domain Framework

On Mon, 2010-05-17 at 22:05 +0530, Sundar R Iyer wrote:

> +/* locks held by regulator_set_operating_point() */
> +static int _regulator_set_operating_point(struct regulator_dev *rdev,
> +		unsigned int opp)
> +{
> +	int ret, regulator_curr_opp = 0;
> +
> +	if (!(rdev->constraints->valid_ops_mask & REGULATOR_CHANGE_OPP)) {
> +		printk(KERN_ERR "%s: operation not allowed for %s\n",
> +				__func__, rdev->desc->name);
> +		return -EPERM;
> +	}
> +
> +	/* sanity checks */
> +	if (!rdev->desc->ops->set_operating_point) {
> +		return -EINVAL;
> +	}
> +
> +	if (rdev->desc->ops->get_operating_point)
> +		regulator_curr_opp = rdev->desc->ops->get_operating_point(rdev);
> +
> +	/* we have no issues with upgrading the opp */
> +	if (opp == REGULATOR_OPERATINGPOINT_FULL) {
> +		if (rdev->constraints->opp_constraint_count < 1) {
> +			if (rdev->supply)
> +				ret = _regulator_set_operating_point(rdev->supply, opp);
> +			ret = rdev->desc->ops->set_operating_point(rdev, opp);
> +		}
> +		rdev->constraints->opp_constraint_count++;
> +	}

This implementation is assuming that the implementation in hardware only
has two levels, and that the decision to go to the higher level is done
by a simple or of requests for the full level from the consumers. I'm
not convinced that this will be true in general, or that it's always
going to be true that the different power domains are all isolated from
each other. There doesn't seem to be any immediate reason why hardware
won't ever implement more than two modes, and I'm not convinced that the
straight or of requests will always be sufficient to determine the
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.

Are you sure that this interface is sufficiently general to work with
all hardware, not just your own? How does this map on to the OMAP or SH
hardware, for example?

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