1. 28 1月, 2013 1 次提交
    • T
      OF: Fixup resursive locking code paths · 28d0e36b
      Thomas Gleixner 提交于
      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>
      28d0e36b
  2. 25 1月, 2013 1 次提交
  3. 21 1月, 2013 1 次提交
  4. 18 1月, 2013 2 次提交
  5. 17 1月, 2013 22 次提交
  6. 16 1月, 2013 4 次提交
  7. 15 1月, 2013 9 次提交