On 02/11/2013 04:18 PM, Grant Likely wrote:

On Mon, Feb 11, 2013 at 7:54 PM, Rob Herring [off-list ref] wrote:

quoted

On 02/11/2013 01:29 PM, Stephen Warren wrote:

quoted

On 02/08/2013 04:09 PM, Rob Herring wrote:

quoted

On 02/06/2013 02:30 PM, Paul Gortmaker wrote:

quoted

From: Thomas Gleixner <redacted>

With the locking cleanup in place (from "OF: Fixup resursive
locking code paths"), we can now do the conversion from the
rw_lock to a raw spinlock as required for preempt-rt.

The previous cleanup and this conversion were originally
separate since they predated when mainline got raw spinlock (in
commit c2f21ce2e31286a "locking: Implement new raw_spinlock").

So, at that point in time, the cleanup was considered plausible
for mainline, but not this conversion.  In any case, we've kept
them separate as it makes for easier review and better bisection.

Signed-off-by: Thomas Gleixner <redacted>
[PG: taken from preempt-rt, update subject & add a commit log]
Signed-off-by: Paul Gortmaker <redacted>
---

[v2: recent commit e81b329 ("powerpc+of: Add /proc device tree
 updating to of node add/remove") added two more instances of
 write_unlock that also needed converting to raw_spin_unlock.
 Retested (boot) on sbc8548, defconfig builds on arm/sparc; no
 new warnings observed.]

 arch/sparc/kernel/prom_common.c |   4 +-
 drivers/of/base.c               | 100 ++++++++++++++++++++++------------------
 include/linux/of.h              |   2 +-
 3 files changed, 59 insertions(+), 47 deletions(-)

Applied.

This commit is present in next-20130211, and causes a boot failure
(hang) early while booting on Tegra. Reverting just this one commit
solves the issue.

I'll see if I can track down where the issue is. Given the commit
description, I assume there's some new recursive lock issue that snuck
in between the previous fix for them and this commit? Any hints welcome.

One thing I wonder looking at the patch: Most paths use
raw_spin_lock_irqsave() but a few use just raw_spin_lock(). I wonder how
that decision was made?

I found the problem. of_get_next_available_child ->
of_device_is_available -> of_get_property -> of_get_property. An
unlocked version of of_device_is_available is needed here.

Oops, I had testbooted on a single core machine which would mask the
issue. I've crafted a fix and am posting it for review before I apply
it.

I'm in the process of applying Stephen's fix.

Rob