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

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

2017-04-11T06:04:30+00:00

commit 92c14bd9477a20a83144f08c0ca25b0308bf0730 upstream.

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)
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
Signed-off-by: Jiri Slaby

Revert "cpufreq: fix garbage kobjects on errors during suspend/resume"

2017-04-10T13:09:49+00:00

commit d4faadd5d5b368a7051fef374ee933ec3606713b upstream.

Commit 2167e2399dc5 (cpufreq: fix garbage kobjects on errors during
suspend/resume) breaks suspend/resume on Martin Ziegler's system
(hard lockup during resume), so revert it.

Fixes: 2167e2399dc5 (cpufreq: fix garbage kobjects on errors during suspend/resume)
References: https://bugzilla.kernel.org/show_bug.cgi?id=66751
Reported-by: Martin Ziegler 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

cpufreq: Fix and clean up show_cpuinfo_cur_freq()

2017-04-07T07:17:50+00:00

commit 9b4f603e7a9f4282aec451063ffbbb8bb410dcd9 upstream.

There is a missing newline in show_cpuinfo_cur_freq(), so add it,
but while at it clean that function up somewhat too.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Signed-off-by: Jiri Slaby

cpufreq: preserve user_policy across suspend/resume

2017-03-03T10:31:17+00:00

commit 08fd8c1cf0a99abf34e09a8b99b74872e0d73a23 upstream.

Prevent __cpufreq_add_dev() from overwriting the existing values of
user_policy.{min|max|policy|governor} with defaults during resume
from system suspend.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-by: Bjørn Mork 
Signed-off-by: Viresh Kumar 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

cpufreq: Clean up after a failing light-weight initialization

2017-03-03T10:31:16+00:00

commit 72368d122c7479aa6e14fbbd334717b8a0c157a6 upstream.

If cpufreq_policy_restore() returns NULL during system resume,
__cpufreq_add_dev() should just fall back to the full initialization
instead of returning an error, because that may actually make things
work.  Moreover, it should not leave stale fallback data behind after
it has failed to restore a previously existing policy.

This change is based on Viresh Kumar's work.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-by: Bjørn Mork 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar 
Signed-off-by: Jiri Slaby

cpufreq: remove sysfs files for CPUs which failed to come back after resume

2017-03-03T10:31:16+00:00

commit 42f921a6f10c6c2079b093a115eb7e3c3508357f upstream.

There are cases where cpufreq_add_dev() may fail for some CPUs
during system resume. With the current code we will still have
sysfs cpufreq files for those CPUs and struct cpufreq_policy
would be already freed for them. Hence any operation on those
sysfs files would result in kernel warnings.

Example of problems resulting from resume errors (from Bjørn Mork):

WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
missing sysfs attribute operations for kobject: (null)
Modules linked in: [stripped as irrelevant]
CPU: 0 PID: 6055 Comm: grep Tainted: G      D      3.13.0-rc2 #153
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
 0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
 ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
 ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
Call Trace:
 [] dump_stack+0x55/0x76
 [] warn_slowpath_common+0x7c/0x96
 [] ? sysfs_open_file+0x77/0x212
 [] warn_slowpath_fmt+0x41/0x43
 [] ? sysfs_get_active+0x6b/0x82
 [] ? sysfs_open_file+0x32/0x212
 [] sysfs_open_file+0x77/0x212
 [] ? sysfs_schedule_callback+0x1ac/0x1ac
 [] do_dentry_open+0x17c/0x257
 [] finish_open+0x41/0x4f
 [] do_last+0x80c/0x9ba
 [] ? inode_permission+0x40/0x42
 [] path_openat+0x233/0x4a1
 [] do_filp_open+0x35/0x85
 [] ? __alloc_fd+0x172/0x184
 [] do_sys_open+0x6b/0xfa
 [] SyS_openat+0xf/0x11
 [] system_call_fastpath+0x16/0x1b

To fix this, remove those sysfs files or put the associated kobject
in case of such errors. Also, to make it simple, remove the cpufreq
sysfs links from all the CPUs (except for the policy->cpu) during
suspend, as that operation won't result in a loss of sysfs file
permissions and we can create those links during resume just fine.

[js] no rwsem in 3.12 yet

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Reported-and-tested-by: Bjørn Mork 
Signed-off-by: Viresh Kumar 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

cpufreq: fix garbage kobjects on errors during suspend/resume

2017-03-03T10:31:15+00:00

commit 2167e2399dc5e69c62db56d933e9c8cbe107620a upstream.

This is effectively a revert of commit 5302c3fb2e62 ("cpufreq: Perform
light-weight init/teardown during suspend/resume"), which enabled
suspend/resume optimizations leaving the sysfs files in place.

Errors during suspend/resume are not handled properly, leaving
dead sysfs attributes in case of failures.  There are are number of
functions with special code for the "frozen" case, and all these
need to also have special error handling.

The problem is easy to demonstrate by making cpufreq_driver->init()
or cpufreq_driver->get() fail during resume.

The code is too complex for a simple fix, with split code paths
in multiple blocks within a number of functions.  It is therefore
best to revert the patch enabling this code until the error handling
is in place.

Examples of problems resulting from resume errors:

WARNING: CPU: 0 PID: 6055 at fs/sysfs/file.c:343 sysfs_open_file+0x77/0x212()
missing sysfs attribute operations for kobject: (null)
Modules linked in: [stripped as irrelevant]
CPU: 0 PID: 6055 Comm: grep Tainted: G      D      3.13.0-rc2 #153
Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011
 0000000000000009 ffff8802327ebb78 ffffffff81380b0e 0000000000000006
 ffff8802327ebbc8 ffff8802327ebbb8 ffffffff81038635 0000000000000000
 ffffffff811823c7 ffff88021a19e688 ffff88021a19e688 ffff8802302f9310
Call Trace:
 [] dump_stack+0x55/0x76
 [] warn_slowpath_common+0x7c/0x96
 [] ? sysfs_open_file+0x77/0x212
 [] warn_slowpath_fmt+0x41/0x43
 [] ? sysfs_get_active+0x6b/0x82
 [] ? sysfs_open_file+0x32/0x212
 [] sysfs_open_file+0x77/0x212
 [] ? sysfs_schedule_callback+0x1ac/0x1ac
 [] do_dentry_open+0x17c/0x257
 [] finish_open+0x41/0x4f
 [] do_last+0x80c/0x9ba
 [] ? inode_permission+0x40/0x42
 [] path_openat+0x233/0x4a1
 [] do_filp_open+0x35/0x85
 [] ? __alloc_fd+0x172/0x184
 [] do_sys_open+0x6b/0xfa
 [] SyS_openat+0xf/0x11
 [] system_call_fastpath+0x16/0x1b

The failure to restore cpufreq devices on cancelled hibernation is
not a new bug. It is caused by the ACPI _PPC call failing unless the
hibernate is completed. This makes the acpi_cpufreq driver fail its
init.

Previously, the cpufreq device could be restored by offlining the
cpu temporarily.  And as a complete hibernation cycle would do this,
it would be automatically restored most of the time.  But after
commit 5302c3fb2e62 the leftover sysfs attributes will block any
device add action.  Therefore offlining and onlining CPU 1 will no
longer restore the cpufreq object, and a complete suspend/resume
cycle will replace it with garbage.

Fixes: 5302c3fb2e62 ("cpufreq: Perform light-weight init/teardown during suspend/resume")
Signed-off-by: Bjørn Mork 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

cpufreq: Fix GOV_LIMITS handling for the userspace governor

2016-09-29T09:14:17+00:00

commit e43e94c1eda76dabd686ddf6f7825f54d747b310 upstream.

Currently, the userspace governor only updates frequency on GOV_LIMITS
if policy->cur falls outside policy->{min/max}. However, it is also
necessary to update current frequency on GOV_LIMITS to match the user
requested value if it can be achieved within the new policy->{max/min}.

This was previously the behaviour in the governor until commit d1922f0
("cpufreq: Simplify userspace governor") which incorrectly assumed that
policy->cur == user requested frequency via scaling_setspeed. This won't
be true if the user requested frequency falls outside policy->{min/max}.
Ex: a temporary thermal cap throttled the user requested frequency.

Fix this by storing the user requested frequency in a seperate variable.
The governor will then try to achieve this request on every GOV_LIMITS
change.

Fixes: d1922f02562f (cpufreq: Simplify userspace governor)
Signed-off-by: Sai Gurrappadi 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

intel_pstate: Use del_timer_sync in intel_pstate_cpu_stop

2016-04-11T14:43:52+00:00

commit c2294a2f7853e6450361d078b65407bdaa6d1d11 upstream.

Ensure that no timer callback is running since we are about to free
the timer structure.  We cannot guarantee that the call back is called
on the CPU where the timer is running.

Reported-by: Thomas Gleixner 
Signed-off-by: Dirk Brandewie 
Reviewed-by: Srivatsa S. Bhat 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby

cpufreq: pcc: Enable autoload of pcc-cpufreq for ACPI processors

2015-06-23T13:56:21+00:00

commit 7e7e8fe69820c6fa31395dbbd8e348e3c69cd2a9 upstream.

The pcc-cpufreq driver is not automatically loaded on systems where
the platform's power management setting requires this driver.
Instead, on those systems no CPU frequency driver is registered and
active.

Make the autoloading matching criteria for loading the pcc-cpufreq
driver the same as done in acpi-cpufreq by commit c655affbd524d01
("ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq").

x86 CPU frequency drivers are now typically autoloaded by specifying
MODULE_DEVICE_TABLE entries and x86cpu model specific matching.
But pcc-cpufreq was omitted when acpi-cpufreq and other drivers were
changed to use this approach.

Both acpi-cpufreq and pcc-cpufreq depend on a distinct and mutually
exclusive set of ACPI methods which are not directly tied to specific
processor model numbers. Both of these drivers have init routines
which look for their required ACPI methods. As a result, only the
appropriate driver registers as the cpu frequency driver and the other
one ends up being unloaded.

Tested on various systems where acpi-cpufreq, intel_pstate, and
pcc-cpufreq are the expected cpu frequency drivers.

Signed-off-by: Lenny Szubowicz 
Signed-off-by: Joseph Szczypek 
Reported-by: Trinh Dao 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Jiri Slaby