linux-kernel - Re: [RFC PATCH 1/4] 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]

Date:	Thu, 13 Jun 2013 15:47:26 +0100
From:	Mark Brown <broonie@...nel.org>
To:	Nishanth Menon <nm@...com>
Cc:	Paul Walmsley <paul@...an.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Kevin Hilman <khilman@...prootsystems.com>,
	Tony Lindgren <tony@...mide.com>,
	devicetree-discuss@...ts.ozlabs.org,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, linux-doc@...r.kernel.org,
	lkml <linux-kernel@...r.kernel.org>,
	linux-omap <linux-omap@...r.kernel.org>,
	Grygorii Strashko <grygorii.strashko@...com>
Subject: Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control
 PMIC over VC/VP

On Thu, Jun 13, 2013 at 08:39:50AM -0500, Nishanth Menon wrote:

> I am having a bit of a difficulty trying to understand your concern
> here.

Your device tree for this stuff appears to mostly consist of repeating
the description of the PMIC that we already have - this really doesn't
seem like a great result.

> Problem statement:

> OMAP has this weird custom h/w where one programs the voltage and that
> voltage is send over i2c - this is not same as Tegra's lookup table
> array which automatically sends out entries, in OMAP, software has to trigger
> the voltage transition

The basic idea that's important here is that you need to figure out how
to tell the hardware what to write - how those writes get triggered is a
separate problem.

> If your concern was describing PMIC parameters in dts, I can easily move
> them inside the omap_pmic driver and provide required compatible flags.
> If, on the other hand, the entire approach followed is flawed, I'd like to
> understand the rationale for the same.

That's the biggest problem I saw so far but to be honest I've not
drilled down too much into the specifics.  From my point of view the
main thing is how this fits into the frameworks and so on, having the
register information in the DT was an alarm flag that suggested the
overall approach was a concern.

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