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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130705165235.GC27646@sirena.org.uk>
Date:	Fri, 5 Jul 2013 17:52:35 +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 09:50:34AM -0500, Nishanth Menon wrote:
> On 07/05/2013 09:08 AM, Mark Brown wrote:

> >>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.

> :) it is similar, yes. by bypass get/set_voltage, I mean something like [1]

No, that's not a good idea.

> >What makes you think that the existing regulator drivers need to be
> >modified?

> data path difference - Almost all standard regulators use i2c
> (standard i2c APIs) for every other SMPS/LDO except for the ones
> controlled by OMAP custom i2c path(vc/vp), the
> set_voltage/get_voltage needs a different implementation when it
> comes to using the vc/vp path.

> > They already have all the data exported to the core (or
> > should do)...

> I see that twl-regulator does not indeed do it, but, assuming the
> regulators have all the data exported to the core, the data is
> hidden in struct regulator_desc which is private to the device and
> driver. lets go through these:

That's just a simple matter of programming to fix, and any regulator
which can work with this sort of table based stuff you're looking at
here must also be able to be converted to work with the equivalent code
in the regulator core so open coding is a deficiency in the driver.

> > +	.cmd_reg_addr = 0x00,

> command register is used for sending low power state commands -
> which is not the same as voltage register or vsel_reg as used in
> depicted in regulator_desc.	

There's no information about how to use this register in your
bindings...  but anyway, can't be too hard to add this if it's actually
used.

> > +	.i2c_timeout_us = 200,

> yep, does not match up.

Like I say I just don't see why this is even specified per device.

> > +	.max_uV = 1450000,

> can be used with constraints, but most regulator drivers seem to
> store this internally.

Or just trivially calculate it as we do currently.

> > +	.voltage_selector_offset = 0,
> > +	.voltage_selector_mask = 0x7F,
> > +	.voltage_selector_setbits = 0x0,
> > +	.voltage_selector_zero = false,

> to an extent we can map these to vsel_mask, linear_min_sel etc.
> (again assuming the regulator driver has populated it - most that
> implement custom set_voltage, get_voltage do not do that.

Anything that implements a custom set_voltage() won't work with your
data structure either...

> Other option is to make rdev available to omap_pmic regulator -
> which again implies change in existing regulator driver?

Why would any of the drivers need to change to do this?  They're already
exporting the information.

> >the only thing that's missing is the timeouts and it's
> >not at all obvious why those need to be tuned per device.

> OMAP VC hardware has no idea about how long to wait before giving up
> on an ongoing i2c transaction. This may depend on PMIC and what it
> does before acking on i2c.

So pick a high number (it's only for error cases...)?

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