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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100817181557.GA5755@opensource.wolfsonmicro.com>
Date:	Tue, 17 Aug 2010 19:15:57 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Bobby Crabtree <bobbyc@...eaurora.org>
Cc:	lrg@...mlogic.co.uk, linux-kernel@...r.kernel.org,
	linux-arm-msm@...r.kernel.org
Subject: Re: regulator voltage aggregation

On Tue, Aug 17, 2010 at 11:06:10AM -0700, Bobby Crabtree wrote:
> I'm looking to upstream a new feature in which the regulator core
> aggregates voltage requests from multiple consumers and applies the best
> fitting voltage (e.g. max voltage) to a shared supply. The core would

It's unlikely that the highest voltage would ever be the best choice...

> recompute the best fitting voltage when a consumer requests a voltage
> change or requests to enable/disable the regulator (similar logic to
> DRMS).

> The reason we need this feature is for power savings. It would allow two
> or more consumers to "vote" on a voltage that's lower than the normal
> operating voltage.

This was actually a feature of the regulator API when originally
proposed, it got dropped for ease of review but there's some remanants
of this in the code so it shouldn't be hard to resurrect.  Whenever a
voltage was set the code stored the range on the consumer then iterated
over all consumers applying their ranges plus the machine constraints
rather than just using the immediate value.

> 1. Introduce a new API:

> int regulator_set_optimum_voltage(struct regulator *regulator,
>                 int min_uV, int max_uV);

Why would you want to do this?  This is just the same arguments as the
standard regulator_set_voltage() call and if we're ever setting anything
other than the optimal voltage we probably ought to just stop doing
that.

> 2. Add a flag to the regulation_constraints structure and reuse the
> existing regulator_set_voltage API.

> struct regulation_constraints {
>         ...
>         unsigned aggregate_uV:1;
>         ...
> };

> Does this sound like a reasonable feature? And if so, are there any
> preferences as to how the feature is implemented and exposed?

If we were going to add something for this it should be a capability,
however I don't think there's any need to add anything to the API since
this is the only sane interpretation of allowing voltage changes on a
regulator with more than one consumer.
--
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