linux-kernel - Re: regulator: query on regulator re-entrance

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]

Date:	Fri, 5 Apr 2013 10:44:12 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Nishanth Menon <nm@...com>
Cc:	Liam Girdwood <lgirdwood@...il.com>,
	Greg Guyotte <gguyotte@...com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	linux-arm <linux-arm-kernel@...ts.infradead.org>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: regulator: query on regulator re-entrance

On Fri, Apr 05, 2013 at 12:09:42AM -0500, Nishanth Menon wrote:

> If we ignore the details of the class 1.5 implementation, we will notice
> a) regulator set_voltage equivalent set_voltage() is required.
> b) this set_voltage does some 'magic stuff' depending on the SoC and AVS class
> and calls the 'real regulator' which talks to the PMIC over i2c/spi etc..
> in short the call sequence is more or less:
> 
> driver (cpufreq) -> AVS -> PMIC regulator.
> 
> By modeling AVS class drivers as an regulator, we then do not need to introduce
> SoC specific hacks and APIs.

But you're shoehorning something into the regulator API which isn't
supposed to be there and causing yourself problems.  This just isn't a
good idea.  The regulator API already has a mechanism for supporting
regulators which are supplied by other regulators, if you can't model in
terms of that (adding something to support variability better) then
you're not using a regulator.

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)