1. 03 8月, 2006 2 次提交
  2. 01 8月, 2006 9 次提交
  3. 30 7月, 2006 2 次提交
  4. 29 7月, 2006 1 次提交
  5. 28 7月, 2006 1 次提交
  6. 26 7月, 2006 1 次提交
    • A
      [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
      Arjan van de Ven 提交于
      The patch below moves the cpu hotplugging higher up in the cpufreq
      layering; this is needed to avoid recursive taking of the cpu hotplug
      lock and to otherwise detangle the mess.
      
      The new rules are:
      1. you must do lock_cpu_hotplug() around the following functions:
         __cpufreq_driver_target
         __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
         __cpufreq_set_policy
      2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
         lock in any way; they are called with the lock taken already
      3. if your governer spawns a thread that does things, like calling
         __cpufreq_driver_target, your thread must honor rule #1.
      4. the policy lock and other cpufreq internal locks nest within
         the lock_cpu_hotplug() lock.
      
      I'm not entirely happy about how the __cpufreq_governor rule ended up
      (conditional locking rule depending on the argument) but basically all
      callers pass this as a constant so it's not too horrible.
      
      The patch also removes the cpufreq_governor() function since during the
      locking audit it turned out to be entirely unused (so no need to fix it)
      
      The patch works on my testbox, but it could use more testing
      (otoh... it can't be much worse than the current code)
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      153d7f3f
  7. 25 7月, 2006 3 次提交
  8. 24 7月, 2006 1 次提交
    • L
      cpu hotplug: simplify and hopefully fix locking · aa953877
      Linus Torvalds 提交于
      The CPU hotplug locking was quite messy, with a recursive lock to
      handle the fact that both the actual up/down sequence wanted to
      protect itself from being re-entered, but the callbacks that it
      called also tended to want to protect themselves from CPU events.
      
      This splits the lock into two (one to serialize the whole hotplug
      sequence, the other to protect against the CPU present bitmaps
      changing). The latter still allows recursive usage because some
      subsystems (ondemand policy for cpufreq at least) had already gotten
      too used to the lax locking, but the locking mistakes are hopefully
      now less fundamental, and we now warn about recursive lock usage
      when we see it, in the hope that it can be fixed.
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      aa953877
  9. 22 7月, 2006 1 次提交
  10. 20 7月, 2006 1 次提交
    • T
      [PATCH] libata: improve EH action and EHI flag handling · 13abf50d
      Tejun Heo 提交于
      Update ata_eh_about_to_do() and ata_eh_done() to improve EH action and
      EHI flag handling.
      
      * There are two types of EHI flags - one which expires on successful
        EH and the other which expires on a successful reset.  Make this
        distinction clear.
      
      * Unlike other EH actions, reset actions are represented by two EH
        action masks and a EHI modifier.  Implement correct about_to_do/done
        semantics for resets.  That is, prior to reset, related EH info is
        sucked in from ehi and cleared, and after reset is complete, related
        EH info in ehc is cleared.
      
      These changes improve consistency and remove unnecessary EH actions
      caused by stale EH action masks and EHI flags.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      13abf50d
  11. 15 7月, 2006 17 次提交
  12. 14 7月, 2006 1 次提交
    • R
      [PATCH] Fix broken kernel headers preventing ARM build · 3e705f27
      Russell King 提交于
      As a result of 894673ee, the ARM
      architecture is more or less unbuildable - only one defconfig appears
      to build, with all others erroring out with:
      
      	  CC      arch/arm/kernel/setup.o
      	In file included from /home/rmk/git/linux-2.6-rmk/arch/arm/kernel/setup.c:22:
      	/home/rmk/git/linux-2.6-rmk/include/linux/root_dev.h:7: warning: implicit declaration of function `MKDEV'
      	...
      
      Essentially, root_dev.h uses MKDEV and dev_t, but does not include any
      headers which provide either of these definitions.  The reason it worked
      previously is that linux/tty.h just happened to include the required
      headers for linux/root_dev.h.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      3e705f27