linux-kernel - Re: [RFC PATCH] regulator: virtual: Introduce a new virtual locker regulator type

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:	Wed, 30 Apr 2014 18:28:25 -0700
From:	Mark Brown <broonie@...nel.org>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Inderpal Singh <inderpal.s@...sung.com>,
	Rob Herring <robh+dt@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-pm@...r.kernel.org,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Pawel Moll <pawel.moll@....com>
Subject: Re: [RFC PATCH] regulator: virtual: Introduce a new virtual locker
 regulator type

On Wed, Apr 30, 2014 at 11:56:08AM -0700, Doug Anderson wrote:

> I cornered Rob and Mark Rutland a little bit about this at ELC today
> (sorry!).  Neither of them was a huge ran of adding a pseudo device.
> Rob suggested that Mark Brown might be the best person to give
> direction here.  Mark Brown: any thoughts?

I glanced at this briefly and couldn't really understand what it was
supposed to do from a quick glance but I do tend to agree that it's too
complex and confusing.  Quite what the virtual regulator is supposed to
represent or how it is used is distinctly non-obvious.

> Potentially we could also make this type of thing a core regulator property:

Yes, that seems like the obvious solution if it's in the core.  Someone
would need to write the code of course.

> Another option is to add no device tree code at all and add code to
> the devfreq / cpufreq drivers used on this device.  In order to do
> this cleanly I think we'd need to extend the regulator core's
> notification scheme to introduce a new event:
> REGULATOR_EVENT_VOLTAGE_CHANGING that's called _before_ a voltage
> change happened.

That only works if it's the same thing scaling both voltages.  That
might be true most of the time but is it true all of the time?  If it is
then that's great.

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