OF: Fixup resursive locking code paths
authorThomas Gleixner <tglx@linutronix.de>
Fri, 25 Jan 2013 18:21:47 +0000 (13:21 -0500)
committerRob Herring <rob.herring@calxeda.com>
Mon, 28 Jan 2013 02:20:23 +0000 (20:20 -0600)
commit28d0e36bf96863df1195f8f7b9fd559142873389
treec11d2627a91d81e69f20d9813f4d4224a0c7aeff
parent425140af9e7040adc84a1b3f2c198eaf6eebc5aa
OF: Fixup resursive locking code paths

There is no real reason to use a rwlock for devtree_lock. It even
could be a mutex, but unfortunately it's locked from cpu hotplug
paths which can't schedule :(

So it needs to become a raw lock on rt as well.  The devtree_lock would
be the only user of a raw_rw_lock, so we are better off cleaning up the
recursive locking paths which allows us to convert devtree_lock to a
read_lock.

Here we do the standard thing of introducing __foo() as the "raw"
version of foo(), so that we can take better control of the locking.
The "raw" versions are not exported and are for internal use within
the file itself.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
drivers/of/base.c