linux-kernel - Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP

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]

Date:	Fri, 5 Jul 2013 15:08:28 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Nishanth Menon <nm@...com>
Cc:	Benoît Cousson <b-cousson@...com>,
	Tony Lindgren <tony@...mide.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	Grygorii Strashko <grygorii.strashko@...com>,
	Taras Kondratiuk <taras@...com>
Subject: Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to
 control PMIC over VC/VP

On Fri, Jul 05, 2013 at 08:55:07AM -0500, Nishanth Menon wrote:

Please write in paragraphs, an enormous wall of unbroken text isn't
helpful for legibility.

> On 16:41-20130704, Mark Brown wrote:

> > So, this still has the thing where all the data about the PMIC is
> > replicated (but now in this driver).  It should be possible to pull all
> > the above information except possibly the I2C timeout and perhaps the
> > I2C address (if there's a separate control interface) from the standard
> > regulator core data structures for the PMIC.  This would allow the
> > driver to Just Work with any PMIC without needing to add it in two
> > places.

> option 1) we just bypass get_voltage/set_voltage to point through to
> this function. result will be something similar to what we got here[1]

I don't really know what you mean when you say "bypass get_voltage/set_voltage
so it's kind of hard to comment...  the link you posted appears to be a
link to the code I'm reviewing so it's not terribly enlightening.

> Again, based on this discussion, it is wrong - and we already did implement
> the *wrong* way in OMAP and the new code is supposed to throw away the
> old code once all relevant platforms are converted to DT.
> - now, we could improve this by passing rdev and slurp out required
>  data from regulator structures, but obviously, as you pointed out, it wont
>  be sufficient.
> - In this solution, we will have existing regulator drivers supporting
> additional data path. *but* that also means that existing regulator
> drivers will need to be modified to handle multiple data path and "Just
> Work" wont happen - so not really good other than screw up existing
> regulator drivers with handling OMAP specific APIs in them.

What makes you think that the existing regulator drivers need to be
modified?  They already have all the data exported to the core (or
should do)...  the only thing that's missing is the timeouts and it's
not at all obvious why those need to be tuned per device.

> option 2) make omap_pmic regulator use twl_regulator - regulator
> chaining.

Again I don't know what this is.

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