linux-kernel - Re: [PATCH] ARM: dt: tegra: harmony: add regulators

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]

Message-ID: <5037CD99.8050700@wwwdotorg.org>
Date:	Fri, 24 Aug 2012 12:53:13 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Laxman Dewangan <ldewangan@...dia.com>
CC:	"olof@...om.net" <olof@...om.net>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	Liam Girdwood <lrg@...com>
Subject: Re: [PATCH] ARM: dt: tegra: harmony: add regulators

On 08/22/2012 01:07 PM, Mark Brown wrote:
> On Mon, Aug 20, 2012 at 12:37:44PM -0600, Stephen Warren wrote:
>> On 08/20/2012 12:14 PM, Mark Brown wrote:
> 
>>> Why not just pull the patch in via the regulator tree?  The
>>> idea of merging the entire regulator drivers branch into the
>>> Tegra tree doesn't seem awesome...
> 
>> I think that'd end up causing some annoying conflicts with other 
>> changes that also touch arch/arm/match-tegra/board-dt-tegra20.c. 
>> Perhaps they're manageable; they probably aren't that bad, but
>> it seems better to avoid them.
> 
> Ugh, right.  I guess I'd best rebase the commits out of the
> drivers branch.  Can you let me know what you depend on and I'll
> build a mergable branch for you to pull in?

I believe the only commit the Tegra tree might need is:

b93fffb regulator: tps6586x: add support for SYS rail

There is one other commit that touches this driver queued up for 3.7,
but I've validated that the two commits can merge together without any
conflicts, so I don't think we actually need this in the Tegra tree:

4c79c8d regulator: tps6586x: Convert to
regulator_[enable|disable|is_enabled|get_voltage_sel]_regmap

A few more notes on the overall situation:

a) As background, regulators on the Harmony board are broken in
v3.6-rc2, but fixed in v3.6-rc3. Specifically, commit 798bd59 "ARM:
tegra: more regulator fixes for Harmony" is required.

b) Even on top of v3.6-rc3, commit b93fffb "regulator: tps6586x: add
support for SYS rail" introduces a regression on Harmony. I did give a
Tested-by tag for this commit, but had tested it on a different board.
To fix this, the commit needs to also edit
arch/arm/mach-tegra/board-harmony-power.c and s/vdd_sys/REG-SYS/.

c) I tested all of next-20120822, regulator's for-next, and Tegra's
for-next. In all cases, if I fix the issues above, then merge Laxman's
change to instantiate all Harmony's regulators from DT, without
removing use of board-harmony-power.c, then all the regulator stuff
does in fact work OK; I had previously thought it didn't, but I
believe that was because of (a) and (b) above, not the .dts regulator
patch.

However, because the regulators are now registered from DT first, and
the regulator names in the DT are different to the regulator names in
board-harmony-power.c, Laxman's .dts regulator patch does break PCIe
on Harmony, since it can't obtain the regulators it needs.

Overall, I think the solution is as follows:

1) Remove b93fffb "regulator: tps6586x: add support for SYS rail" from
the regulator tree entirely.

2) Fix that patch to s/vdd_sys/REG-SYS/ in board-harmony-power.c, and
apply it to the Tegra tree.

3) Fix Laxman's regulator .dts patch to solve the PCIe problem,
possibly also remove board-harmony-power.c while we're at it, and
apply it to the Tegra tree.

If it makes life easier, I'm quite happy to move 4c79c8d "regulator:
tps6586x: Convert to
regulator_[enable|disable|is_enabled|get_voltage_sel]_regmap" to the
Tegra tree too. This might be useful; I know that Laxman has another
patch for the TPS6586x driver queued up to move the regulator-specific
DT parsing from the MFD driver into the regulator driver. I have no
idea, but it seems quite likely that would conflict with this patch,
and perhaps make everything easier to go through one tree?

An alternative would be:

1) Remove b93fffb "regulator: tps6586x: add support for SYS rail" from
the regulator tree since it causes a regression.

2) Fix that patch to s/vdd_sys/REG-SYS/ in board-harmony-power.c, and
re-apply it to its own branch in the regulator tree. It would be nice
to base this branch on v3.6-rc3 so Harmony regulators work before the
patch, so the patch can be checked for regressions.

3) Merge that branch into both regulator and Tegra.

4) Apply all future TPS6586x patches to the regulator tree.

5) Apply Laxman's patch to add Harmony regulators to the device tree
to the Tegra tree, after fixing the PCIe interaction issue.

Let me know which way you want to go. Sorry this driver is causing pain.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/