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: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: NRob Herring <rob.herring@calxeda.com>
Showing
想要评论请 注册 或 登录