linux-stable.git/drivers/cpufreq, branch v3.16.4

cpufreq: update 'cpufreq_suspended' after stopping governors

2014-10-05T20:41:11+00:00

commit b1b12babe3b72cfb08b875245e5a5d7c2747c772 upstream.

Commit 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
introduced a bug where the governors wouldn't be stopped anymore for
->target{_index}() drivers during suspend. This happens because
'cpufreq_suspended' is updated before stopping the governors during suspend
and due to this __cpufreq_governor() would return early due to this check:

	/* Don't start any governor operations if we are entering suspend */
	if (cpufreq_suspended)
		return 0;

Fixes: 8e30444e1530 ("cpufreq: fix cpufreq suspend/resume for intel_pstate")
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: fix cpufreq suspend/resume for intel_pstate

2014-10-05T20:41:10+00:00

commit 8e30444e153008e8eb3e74cbcb7a865bfcfb04a0 upstream.

Cpufreq core introduces cpufreq_suspended flag to let cpufreq sysfs nodes
across S2RAM/S2DISK. But the flag is only set in the cpufreq_suspend()
for cpufreq drivers which have target or target_index callback. This
skips intel_pstate driver. This patch is to set the flag before checking
target or target_index callback.

Fixes: 2f0aea936360 (cpufreq: suspend governors on system suspend/hibernate)
Signed-off-by: Lan Tianyu 
[rjw: Subject]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: release policy->rwsem on error

2014-10-05T20:41:10+00:00

commit 7106e02baed4a72fb23de56b02ad4d31daa74d95 upstream.

While debugging a cpufreq-related hardware failure on a system I saw the
following lockdep warning:

 =========================
 [ BUG: held lock freed! ] 3.17.0-rc4+ #1 Tainted: G            E
 -------------------------
 insmod/2247 is freeing memory ffff88006e1b1400-ffff88006e1b17ff, with a lock still held there!
  (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80
 3 locks held by insmod/2247:
  #0:  (subsys mutex#5){+.+.+.}, at: [] subsys_interface_register+0x69/0x120
  #1:  (cpufreq_rwsem){.+.+.+}, at: [] __cpufreq_add_dev.isra.21+0x73/0xb80
  #2:  (&policy->rwsem){+.+...}, at: [] __cpufreq_add_dev.isra.21+0x47d/0xb80

 stack backtrace:
 CPU: 0 PID: 2247 Comm: insmod Tainted: G            E  3.17.0-rc4+ #1
 Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 08/24/2013
  0000000000000000 000000008f3063c4 ffff88006f87bb30 ffffffff8171b358
  ffff88006bcf3750 ffff88006f87bb68 ffffffff810e09e1 ffff88006e1b1400
  ffffea0001b86c00 ffffffff8156d327 ffff880073003500 0000000000000246
 Call Trace:
  [] dump_stack+0x4d/0x66
  [] debug_check_no_locks_freed+0x171/0x180
  [] ? __cpufreq_add_dev.isra.21+0x427/0xb80
  [] kfree+0xab/0x2b0
  [] __cpufreq_add_dev.isra.21+0x427/0xb80
  [] ? _raw_spin_unlock+0x27/0x40
  [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
  [] cpufreq_add_dev+0xe/0x10
  [] subsys_interface_register+0xc1/0x120
  [] cpufreq_register_driver+0x112/0x340
  [] ? kfree+0xda/0x2b0
  [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
  [] pcc_cpufreq_init+0x4af/0xe81 [pcc_cpufreq]
  [] ? pcc_cpufreq_do_osc+0x17f/0x17f [pcc_cpufreq]
  [] do_one_initcall+0xd4/0x210
  [] ? __vunmap+0xd2/0x120
  [] load_module+0x1315/0x1b70
  [] ? store_uevent+0x70/0x70
  [] ? copy_module_from_fd.isra.44+0x129/0x180
  [] SyS_finit_module+0xa6/0xd0
  [] system_call_fastpath+0x16/0x1b
 cpufreq: __cpufreq_add_dev: ->get() failed
insmod: ERROR: could not insert module pcc-cpufreq.ko: No such device

The warning occurs in the __cpufreq_add_dev() code which does

        down_write(&policy->rwsem);
	...
        if (cpufreq_driver->get && !cpufreq_driver->setpolicy) {
                policy->cur = cpufreq_driver->get(policy->cpu);
                if (!policy->cur) {
                        pr_err("%s: ->get() failed\n", __func__);
                        goto err_get_freq;
                }

If cpufreq_driver->get(policy->cpu) returns an error we execute the
code at err_get_freq, which does not up the policy->rwsem.  This causes
the lockdep warning.

Trivial patch to up the policy->rwsem in the error path.

After the patch has been applied, and an error occurs in the
cpufreq_driver->get(policy->cpu) call we will now see

cpufreq: __cpufreq_add_dev: ->get() failed
cpufreq: __cpufreq_add_dev: ->get() failed
modprobe: ERROR: could not insert 'pcc_cpufreq': No such device

Fixes: 4e97b631f24c (cpufreq: Initialize governor for a new policy under policy->rwsem)
Signed-off-by: Prarit Bhargava 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: OPP: Avoid sleeping while atomic

2014-10-05T20:40:50+00:00

commit 3c5445ce3a0c6d6935911212b735772af5115517 upstream.

We allocate the cpufreq table after calling rcu_read_lock(),
which disables preemption. This causes scheduling while atomic
warnings. Use GFP_ATOMIC instead of GFP_KERNEL and update for
kcalloc while we're here.

BUG: sleeping function called from invalid context at mm/slub.c:1246
in_atomic(): 0, irqs_disabled(): 0, pid: 80, name: modprobe
5 locks held by modprobe/80:
 #0:  (&dev->mutex){......}, at: [] __driver_attach+0x48/0x98
 #1:  (&dev->mutex){......}, at: [] __driver_attach+0x58/0x98
 #2:  (subsys mutex#5){+.+.+.}, at: [] subsys_interface_register+0x38/0xc8
 #3:  (cpufreq_rwsem){.+.+.+}, at: [] __cpufreq_add_dev.isra.22+0x84/0x92c
 #4:  (rcu_read_lock){......}, at: [] dev_pm_opp_init_cpufreq_table+0x18/0x10c
Preemption disabled at:[<  (null)>]   (null)

CPU: 2 PID: 80 Comm: modprobe Not tainted 3.16.0-rc3-next-20140701-00035-g286857f216aa-dirty #217
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x70/0xbc)
[] (dump_stack) from [] (__kmalloc+0x124/0x250)
[] (__kmalloc) from [] (dev_pm_opp_init_cpufreq_table+0x3c/0x10c)
[] (dev_pm_opp_init_cpufreq_table) from [] (cpufreq_init+0x48/0x378 [cpufreq_generic])
[] (cpufreq_init [cpufreq_generic]) from [] (__cpufreq_add_dev.isra.22+0x200/0x92c)
[] (__cpufreq_add_dev.isra.22) from [] (subsys_interface_register+0x84/0xc8)
[] (subsys_interface_register) from [] (cpufreq_register_driver+0x108/0x2d8)
[] (cpufreq_register_driver) from [] (generic_cpufreq_probe+0x50/0x74 [cpufreq_generic])
[] (generic_cpufreq_probe [cpufreq_generic]) from [] (platform_drv_probe+0x18/0x48)
[] (platform_drv_probe) from [] (driver_probe_device+0x128/0x370)
[] (driver_probe_device) from [] (__driver_attach+0x94/0x98)
[] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88)
[] (bus_for_each_dev) from [] (bus_add_driver+0xe8/0x204)
[] (bus_add_driver) from [] (driver_register+0x78/0xf4)
[] (driver_register) from [] (do_one_initcall+0xac/0x1d8)
[] (do_one_initcall) from [] (load_module+0x190c/0x21e8)
[] (load_module) from [] (SyS_init_module+0xa4/0x110)
[] (SyS_init_module) from [] (ret_fast_syscall+0x0/0x48)

Fixes: a0dd7b79657b (PM / OPP: Move cpufreq specific OPP functions out of generic OPP library)
Signed-off-by: Stephen Boyd 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

powerpc/cpufreq: Add pr_warn() on OPAL firmware failures

2014-09-17T16:21:51+00:00

commit 6174bac8c7ff73a86ae9a967d1c9cadc478023ae upstream.

Cpufreq depends on platform firmware to implement PStates.  In case of
platform firmware failure, cpufreq should not panic host kernel with
BUG_ON().  Less severe pr_warn() will suffice.

Add firmware_has_feature(FW_FEATURE_OPALv3) check to
skip probing for device-tree on non-powernv platforms.

Signed-off-by: Vaidyanathan Srinivasan 
Acked-by: Gautham R. Shenoy 
Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Greg Kroah-Hartman

cpufreq: move policy kobj to policy->cpu at resume

2014-07-17T12:23:22+00:00

This is only relevant to implementations with multiple clusters, where clusters
have separate clock lines but all CPUs within a cluster share it.

Consider a dual cluster platform with 2 cores per cluster. During suspend we
start hot unplugging CPUs in order 1 to 3. When CPU2 is removed, policy->kobj
would be moved to CPU3 and when CPU3 goes down we wouldn't free policy or its
kobj as we want to retain permissions/values/etc.

Now on resume, we will get CPU2 before CPU3 and will call __cpufreq_add_dev().
We will recover the old policy and update policy->cpu from 3 to 2 from
update_policy_cpu().

But the kobj is still tied to CPU3 and isn't moved to CPU2. We wouldn't create a
link for CPU2, but would try that for CPU3 while bringing it online. Which will
report errors as CPU3 already has kobj assigned to it.

This bug got introduced with commit 42f921a, which overlooked this scenario.

To fix this, lets move kobj to the new policy->cpu while bringing first CPU of a
cluster back. Also do a WARN_ON() if kobject_move failed, as we would reach here
only for the first CPU of a non-boot cluster. And we can't recover from this
situation, if kobject_move() fails.

Fixes: 42f921a6f10c (cpufreq: remove sysfs files for CPUs which failed to come back after resume)
Cc:  3.13+  # 3.13+
Reported-and-tested-by: Bu Yitian 
Reported-by: Saravana Kannan 
Reviewed-by: Srivatsa S. Bhat 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: cpu0: OPPs can be populated at runtime

2014-07-16T13:12:52+00:00

OPPs can be populated statically, via DT, or added at run time with
dev_pm_opp_add().

While this driver handles the first case correctly, it would fail to populate
OPPs added at runtime. Because call to of_init_opp_table() would fail as there
are no OPPs in DT and probe will return early.

To fix this, remove error checking and call dev_pm_opp_init_cpufreq_table()
unconditionally.

Update bindings as well.

Suggested-by: Stephen Boyd 
Tested-by: Stephen Boyd 
Signed-off-by: Viresh Kumar 
Acked-by: Santosh Shilimkar 
Signed-off-by: Rafael J. Wysocki

cpufreq: kirkwood: Reinstate cpufreq driver for ARCH_KIRKWOOD

2014-07-16T13:12:03+00:00

Commit ff1f0018cf66080d8e6f59791e552615648a033a ("drivers: Enable
building of Kirkwood drivers for mach-mvebu") added Kirkwood into
mach-mvebu, adding MACH_KIRKWOOD to ARCH_KIRKWOOD in the KConfig files.

The change for ARM_KIRKWOOD_CPUFREQ replaced ARCH_KIRKWOOD with
MACH_KIRKWOOD, whereas all the other changes were ARCH_KIRKWOOD ||
MACH_KIRKWOOD.

As a consequence of this change, the cpufreq driver is no longer enabled
for ARCH_KIRKWOOD. This patch reinstates ARM_KIRKWOOD_CPUFREQ for
ARCH_KIRKWOOD.

Signed-off-by: Quentin Armitage 
Acked-by: Andrew Lunn 
Signed-off-by: Rafael J. Wysocki

cpufreq: imx6q: Select PM_OPP

2014-07-16T12:45:37+00:00

PM_OPP is a library used by several of the existing cpufreq drivers.
ARM IMX6Q cpufreq driver uses this library for its functionality.
Thus, it should be selected in Kconfig.

Reported-by: Ezequiel Garcia 
Signed-off-by: Nicolas Del Piano 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: sa1110: set memory type for h3600

2014-07-16T12:30:17+00:00

The Compaq iPAQ h3600 also has the K4S281632b-1H memory type.
Verified by prying apart a broken board.

Signed-off-by: Linus Walleij 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki