linux.git/drivers/cpufreq, branch v3.12-rc3

cpufreq: exynos5440: Fix potential NULL pointer dereference

2013-09-25T01:25:58+00:00

If 'dvfs_info' is NULL (due to devm_kzalloc failure) the failure
error message would try to dereference it. Use 'pdev' instead.

Signed-off-by: Sachin Kamat 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: check cpufreq driver is valid and cpufreq isn't disabled in cpufreq_get()

2013-09-25T01:24:02+00:00

cpufreq_get() can be called from external drivers which might not be aware if
cpufreq driver is registered or not. And so we should actually check if cpufreq
driver is registered or not and also if cpufreq is active or disabled, at the
beginning of cpufreq_get().

Otherwise call to lock_policy_rwsem_read() might hit BUG_ON(!policy).

Reported-and-tested-by: Linus Walleij 
Signed-off-by: Viresh Kumar 
Reviewed-by: Srivatsa S. Bhat 
Signed-off-by: Rafael J. Wysocki

acpi-cpufreq: skip loading acpi_cpufreq after intel_pstate

2013-09-25T01:19:09+00:00

If the hw supports intel_pstate and acpi_cpufreq, intel_pstate will
get loaded first.

acpi_cpufreq_init() will call acpi_cpufreq_early_init()
and that will allocate perf data and init those perf data in ACPI core,
(that will cover all CPUs). But later it will free them as
cpufreq_register_driver(acpi_cpufreq) will fail as intel_pstate is
already registered

Use cpufreq_get_current_driver() to check if we can skip the
acpi_cpufreq loading.

Signed-off-by: Yinghai Lu 
Signed-off-by: Rafael J. Wysocki

cpufreq: return EEXIST instead of EBUSY for second registering

2013-09-19T22:37:10+00:00

On systems that support intel_pstate, acpi_cpufreq fails to load, and
udev keeps trying until trace gets filled up and kernel crashes.

The root cause is driver return ret from cpufreq_register_driver(),
because when some other driver takes over before, it will return
EBUSY and then udev will keep trying ...

cpufreq_register_driver() should return EEXIST instead so that the
system can boot without appending intel_pstate=disable and still use
intel_pstate.

Signed-off-by: Yinghai Lu 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: imx6q-cpufreq: assign cpu_dev correctly to cpu0 device

2013-09-19T01:53:43+00:00

Commit cdc58d602d2e657602a90c190cbf745886c95977 "cpufreq: imx6q-cpufreq:
remove device tree parsing for cpu nodes" assumed the pdev->dev is set to
cpu0 device in the platform code. But it actually points to the virtual
cpufreq-cpu0 platform device which is not present in the device tree.
Most of the information needed by cpufreq is stored in cpu0 DT node.
So cpu_dev must point to cpu0 device.

This patch fixes the wrong assignment to cpu_dev.

Reported-by: Guennadi Liakhovetski 
Tested-by: Shawn Guo 
Signed-off-by: Sudeep KarkadaNagesha 
Signed-off-by: Rafael J. Wysocki

cpufreq: cpufreq-cpu0: assign cpu_dev correctly to cpu0 device

2013-09-19T01:53:43+00:00

Commit f837a9b5ab05c52a07108c6f09ca66f2e0aee757 "cpufreq: cpufreq-cpu0:
remove device tree parsing for cpu nodes" assumed the pdev->dev is set to
cpu0 device in the platform code. But it actually points to the virtual
cpufreq-cpu0 platform device which is not present in the device tree.
Most of the information needed by cpufreq is stored in cpu0 DT node.
So cpu_dev must point to cpu0 device.

This patch fixes the wrong assignment to cpu_dev.

Reported-and-tested-by: Guennadi Liakhovetski 
Cc: Shawn Guo 
Signed-off-by: Sudeep KarkadaNagesha 
Signed-off-by: Rafael J. Wysocki

cpufreq: unlock correct rwsem while updating policy->cpu

2013-09-17T22:01:52+00:00

Current code looks like this:

        WARN_ON(lock_policy_rwsem_write(cpu));
        update_policy_cpu(policy, new_cpu);
        unlock_policy_rwsem_write(cpu);

{lock|unlock}_policy_rwsem_write(cpu) takes/releases policy->cpu's rwsem.
Because cpu is changing with the call to update_policy_cpu(), the
unlock_policy_rwsem_write() will release the incorrect lock.

The right solution would be to release the same lock as was taken earlier. Also
update_policy_cpu() was also called from cpufreq_add_dev() without any locks and
so its better if we move this locking to inside update_policy_cpu().

This patch fixes a regression introduced in 3.12 by commit f9ba680d23
(cpufreq: Extract the handover of policy cpu to a helper function).

Reported-and-tested-by: Jon Medhurst
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Clear policy->cpus bits in __cpufreq_remove_dev_finish()

2013-09-17T22:01:27+00:00

This broke after a recent change "cedb70a cpufreq: Split __cpufreq_remove_dev()
into two parts" from Srivatsa.

Consider a scenario where we have two CPUs in a policy (0 & 1) and we are
removing CPU 1. On the call to __cpufreq_remove_dev_prepare() we have cleared 1
from policy->cpus and now on a call to __cpufreq_remove_dev_finish() we read
cpumask_weight of policy->cpus, which will come as 1 and this code will behave
as if we are removing the last CPU from policy :)

Fix it by clearing the CPU mask in __cpufreq_remove_dev_finish() instead of
__cpufreq_remove_dev_prepare().

Tested-by: Stephen Warren 
Reviewed-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

Merge branch 'pm-cpufreq'

2013-09-12T11:04:11+00:00

* pm-cpufreq:
  cpufreq: Acquire the lock in cpufreq_policy_restore() for reading
  cpufreq: Prevent problems in update_policy_cpu() if last_cpu == new_cpu
  cpufreq: Restructure if/else block to avoid unintended behavior
  cpufreq: Fix crash in cpufreq-stats during suspend/resume

cpufreq: Acquire the lock in cpufreq_policy_restore() for reading

2013-09-11T21:30:03+00:00

In cpufreq_policy_restore() before system suspend policy is read from
percpu's cpufreq_cpu_data_fallback.  It's a read operation rather
than a write one, so take the lock for reading in there.

Signed-off-by: Lan Tianyu 
Reviewed-by: Srivatsa S. Bhat 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki