linux-kernel - Re: [PATCH 2/2] regulator: Optimise out noop voltage changes

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]

Date:	Fri, 17 Dec 2010 11:44:30 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Saravana Kannan <skannan@...eaurora.org>
Cc:	Liam Girdwood <lrg@...mlogic.co.uk>, linux-kernel@...r.kernel.org,
	patches@...nsource.wolfsonmicro.com
Subject: Re: [PATCH 2/2] regulator: Optimise out noop voltage changes

On Thu, Dec 16, 2010 at 05:46:07PM -0800, Saravana Kannan wrote:
> 
> 1. With support for multiple consumers, we can further optimize and call
> the producer's set voltage only if the final voltage range changes. So if
> consumer A asks for (2.0 - 5.0) and consumer B keeps changing between (1.0
> - 5.0) and (1.5 - 5.0), then we can completely no-op all of consumer B's
> calls.

Yes, that could be done as a further optimisation - we'd be able to bale
out after the 

> 2. When I was trying to do the above this Sunday, I also noticed what
> looks like a bug or at least an unpleasant behavior. A consumer's min_uV
> and max_uV were being updated (for-next around Dec 12th) before calling
> the producer's set voltage. So, in the above example, if consumer C comes
> in and asks for (10 - 15), it will prevent the producer voltage from ever
> changing again. All of consumer A and B's future requests will result in a
> failure since min_uV > max_uV when you do the consumer aggregation.

I'm sorry I can't parse this at all.  What is a producer?

If the consumers are all asking for incompatible things there's a system
integration issue and the consumers need to be sorted out; it's
difficult for the regulator API to do anything safely while everything
wants incompatible configurations.
--
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/