linux-toradex.git/drivers/cpufreq, branch v4.2.8

cpufreq: intel_pstate: Fix divide by zero on Knights Landing (KNL)

2015-11-09T22:37:39+00:00

commit 8e601a9f97a00bab031980de34f9a81891c1f82f upstream.

This is a workaround for KNL platform, where in some cases MPERF counter
will not have updated value before next read of MSR_IA32_MPERF. In this
case divide by zero will occur. This change ignores current sample for
busy calculation in this case.

Fixes: b34ef932d79a (intel_pstate: Knights Landing support)
Signed-off-by: Srinivas Pandruvada 
Acked-by: Kristen Carlson Accardi 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: acpi_cpufreq: prevent crash on reading freqdomain_cpus

2015-10-22T21:49:33+00:00

commit e25303676e18a7947185a34e26dd08cf0c0ea573 upstream.

When freqdomain_cpus attribute is read from an offlined cpu, it will
cause crash. This change prevents calling cpufreq_show_cpus when
policy driver_data is NULL.

Crash info:

[  170.814949] BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
[  170.814990] IP: [] _find_next_bit.part.0+0x10/0x70
[  170.815021] PGD 227d30067 PUD 229e56067 PMD 0
[  170.815043] Oops: 0000 [#2] SMP
[  170.816022] CPU: 3 PID: 3121 Comm: cat Tainted: G      D    OE   4.3.0-rc3+ #33
...
...
[  170.816657] Call Trace:
[  170.816672]  [] ? find_next_bit+0x15/0x20
[  170.816696]  [] cpufreq_show_cpus+0x5c/0xd0
[  170.816722]  [] show_freqdomain_cpus+0x19/0x20 [acpi_cpufreq]
[  170.816749]  [] show+0x3b/0x60
[  170.816769]  [] sysfs_kf_seq_show+0xbc/0x130
[  170.816793]  [] kernfs_seq_show+0x23/0x30
[  170.816816]  [] seq_read+0xec/0x390
[  170.816837]  [] kernfs_fop_read+0x10a/0x160
[  170.816861]  [] __vfs_read+0x37/0x100
[  170.816883]  [] ? security_file_permission+0xa0/0xc0
[  170.816909]  [] vfs_read+0x83/0x130
[  170.816930]  [] SyS_read+0x55/0xc0
...
...
[  170.817185] ---[ end trace bc6eadf82b2b965a ]---

Signed-off-by: Srinivas Pandruvada 
Acked-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: dt: Tolerance applies on both sides of target voltage

2015-10-22T21:49:30+00:00

commit a2022001cebd0825b96aa0f3345ea3ad44ae79d4 upstream.

Tolerance applies on both sides of the target voltage, i.e. both min and
max sides. But while checking if a voltage is supported by the regulator
or not, we haven't taken care of tolerance on the lower side. Fix that.

Cc: Lucas Stach 
Fixes: 045ee45c4ff2 ("cpufreq: cpufreq-dt: disable unsupported OPPs")
Signed-off-by: Viresh Kumar 
Reviewed-by: Lucas Stach 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

cpufreq: exynos: Fix for memory leak in case SoC name does not match

2015-08-14T09:33:47+00:00

During probe free the memory allocated to "exynos_info" in case of
unknown SoC type.

Signed-off-by: Shailendra Verma 
Acked-by: Viresh Kumar 
Acked-by: Lukasz Majewski 
[k.kozlowski: Rebased the patch around if(of_machine_is_compatible)]
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Kukjin Kim 
Signed-off-by: Rafael J. Wysocki

CPUFREQ: Loongson2: Fix broken build due to incorrect include.

2015-08-03T07:24:59+00:00

71eeedcf51544831ae356a773814401143ed32d4 (MIPS: Lemote 2F: Fix build caused
by recent mass rename.) only fixed one instance of this issue in arch/mips
but missed a 2nd one in drivers/cpufreq/loongson2_cpufreq.c.

[ralf@linux-mips.org: dropped the one segment for the already fixed
instance and changed the other avoiding an include  without a /
because that's generally is a bad idea.]

Signed-off-by: Ralf Baechle 
Acked-by: Viresh Kumar 
Patchwork: https://patchwork.linux-mips.org/patch/10659/

cpufreq: Avoid attempts to create duplicate symbolic links

2015-07-28T15:19:26+00:00

After commit 87549141d516 (cpufreq: Stop migrating sysfs files on
hotplug) there is a problem with CPUs that share cpufreq policy
objects with other CPUs and are initially offline.

Say CPU1 shares a policy with CPU0 which is online and is registered
first.  As part of the registration process, cpufreq_add_dev() is
called for it.  It creates the policy object and a symbolic link
to it from the CPU1's sysfs directory.  If CPU1 is registered
subsequently and it is offline at that time, cpufreq_add_dev() will
attempt to create a symbolic link to the policy object for it, but
that link is present already, so a warning about that will be
triggered.

To avoid that warning, make cpufreq use an additional CPU mask
containing related CPUs that are actually present for each policy
object.  That mask is initialized when the policy object is populated
after its creation (for the first online CPU using it) and it includes
CPUs from the "policy CPUs" mask returned by the cpufreq driver's
->init() callback that are physically present at that time.  Symbolic
links to the policy are created only for the CPUs in that mask.

If cpufreq_add_dev() is invoked for an offline CPU, it checks the
new mask and only creates the symlink if the CPU was not in it (the
CPU is added to the mask at the same time).

In turn, cpufreq_remove_dev() drops the given CPU from the new mask,
removes its symlink to the policy object and returns, unless it is
the CPU owning the policy object.  In that case, the policy object
is moved to a new CPU's sysfs directory or deleted if the CPU being
removed was the last user of the policy.

While at it, notice that cpufreq_remove_dev() can't fail, because
its return value is ignored, so make it ignore return values from
__cpufreq_remove_dev_prepare() and __cpufreq_remove_dev_finish()
and prevent these functions from aborting on errors returned by
__cpufreq_governor().  Also drop the now unused sif argument from
them.

Fixes: 87549141d516 (cpufreq: Stop migrating sysfs files on hotplug)
Signed-off-by: Rafael J. Wysocki 
Reported-and-tested-by: Russell King 
Acked-by: Viresh Kumar

intel_pstate: Add get_scaling cpu_defaults param to Knights Landing

2015-07-26T23:59:43+00:00

Scaling for Knights Landing is same as the default scaling (100000).
When Knigts Landing support was added to the pstate driver, this
parameter was omitted resulting in a kernel panic during boot.

Fixes: b34ef932d79a (intel_pstate: Knights Landing support)
Reported-by: Yasuaki Ishimatsu 
Signed-off-by: Dasaratharaman Chandramouli 
Signed-off-by: Lukasz Anaczkowski 
Acked-by: Kristen Carlson Accardi 
Cc: 4.1+  # 4.1+
Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-cpuidle', 'pm-cpufreq' and 'acpi-resources'

2015-07-16T21:47:19+00:00

* pm-cpuidle:
  suspend-to-idle: Prevent RCU from complaining about tick_freeze()

* pm-cpufreq:
  cpufreq: Allow freq_table to be obtained for offline CPUs
  cpufreq: Initialize the governor again while restoring policy

* acpi-resources:
  ACPI / PCI: Fix regressions caused by resource_size_t overflow with 32-bit kernel

cpufreq: Allow freq_table to be obtained for offline CPUs

2015-07-09T23:43:27+00:00

Users of freq table may want to access it for any CPU from
policy->related_cpus mask. One such user is cpu-cooling layer. It gets a
list of 'clip_cpus' (equivalent to policy->related_cpus) during
registration and tries to get freq_table for the first CPU of this mask.

If the CPU, for which it tries to fetch freq_table, is offline,
cpufreq_frequency_get_table() fails. This happens because it relies on
cpufreq_cpu_get_raw() for its functioning which returns policy only for
online CPUs.

The fix is to access the policy data structure for the given CPU
directly (which also returns a valid policy for offline CPUs), but the
policy itself has to be active (meaning that at least one CPU using it
is online) for the frequency table to be returned.

Because we will be using 'cpufreq_cpu_data' now, which is internal to
the cpufreq core, move cpufreq_frequency_get_table() to cpufreq.c.

Reported-and-tested-by: Pi-Cheng Chen 
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki

cpufreq: Initialize the governor again while restoring policy

2015-07-09T23:36:27+00:00

When all CPUs of a policy are hot-unplugged, we EXIT the governor but
don't mark policy->governor as NULL. This was done in order to keep last
used governor's information intact in sysfs, while the CPUs are offline.

But we also need to clear policy->governor when restoring the policy.

Because policy->governor still points to the last governor while policy
is restored, following sequence of event happens:
 - cpufreq_init_policy() called while restoring policy
 - find_governor() matches last_governor string for present governors and
   returns last used governor's pointer, say ondemand. policy->governor
   already has the same address, unless the governor was removed in
   between.
 - cpufreq_set_policy() is called with both old/new policies governor set
   as ondemand.
 - Because governors matched, we skip governor initialization and return
   after calling __cpufreq_governor(CPUFREQ_GOV_LIMITS). Because the
   governor wasn't initialized for this policy, it returned -EBUSY.
 - cpufreq_init_policy() exits the policy on this error, but doesn't
   destroy it properly (should be fixed separately).
 - And so we enter a scenario where the policy isn't completely
   initialized but used.

Fix this by setting policy->governor to NULL while restoring the policy.

Reported-and-tested-by: Pi-Cheng Chen 
Reported-and-tested-by: "Jon Medhurst (Tixy)" 
Reported-and-tested-by: Steven Rostedt 
Fixes: 18bf3a124ef8 (cpufreq: Mark policy->governor = NULL for inactive policies)
Signed-off-by: Viresh Kumar 
Signed-off-by: Rafael J. Wysocki