linux-kernel - Re: regulator voltage aggregation

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

Message-ID: <20100817210312.GD5755@opensource.wolfsonmicro.com>
Date:	Tue, 17 Aug 2010 22:03:12 +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 01:44:36PM -0700, Bobby Crabtree wrote:

> Only remaining question I have is if the aggregation of
> multiple consumer constraints should be the default (and only)
> behavior. Or should we introduce a new flag to the
> regulator_constraints structure that tells the core to aggregate
> consumer voltages constraints?

I'd say make it the only behaviour - if there is only one consumer it
decays into the same behaviour as we have currently, and since voltage
changes need to be explicitly enabled by the machine constraints it
should not affect any existing machines.

One thing to take account of is an attempt to set a constraint which
can't be accomodated by the other enabled devices, or enable a device
which has constraints outside the currently allowed range.
--
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/