• Arjan van de Ven's avatar
    [PATCH] Reorganize the cpufreq cpu hotplug locking to not be totally bizare · 153d7f3f
    Arjan van de Ven authored
    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: default avatarArjan van de Ven <arjan@linux.intel.com>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    153d7f3f
cpufreq.c 42.1 KB