linux-toradex.git/drivers/cpufreq, branch v3.0.16

drivers/cpufreq/pcc-cpufreq.c: avoid NULL pointer dereference

2011-10-03T18:40:31+00:00

commit e71f5cc402ecb42b407ae52add7b173bf1c53daa upstream.

per_cpu(processors, n) can be NULL, resulting in:

  Loading CPUFreq modules[  437.661360] BUG: unable to handle kernel NULL pointer dereference at (null)
  IP: [] pcc_cpufreq_cpu_init+0x74/0x220 [pcc_cpufreq]

It's better to avoid the oops by failing the driver, and allowing the
system to boot.

Signed-off-by: Naga Chumbalkar 
Cc: Dave Jones 
Cc: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

[CPUFREQ] fix cpumask memory leak in acpi-cpufreq on cpu hotplug.

2011-07-10T21:03:04+00:00

I came across a memory leak during a cyclic cpu-online-offline test.

Signed-off-by: Yu Luming 
Cc: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Dave Jones

[CPUFREQ] powernow-k8: Don't try to transition if the pstate is incorrect

2011-06-16T20:31:13+00:00

This patch augments the pstate transition code to error out
(instead of returning 0) when an incorrect pstate is provided.

Suggested-by: Borislav Petkov 
CC: andre.przywara@amd.com
CC: Mark.Langsdorf@amd.com
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Dave Jones

[CPUFREQ] powernow-k8: Don't notify of successful transition if we failed (vid case).

2011-06-16T20:31:13+00:00

Before this patch if we failed the vid transition would still try to
submit the "new" frequencies to cpufreq.
That is incorrect - also we could submit a non-existing frequency value
which would cause cpufreq to crash. The ultimate fix is in cpufreq
to deal with incorrect values, but this patch improves the error
recovery in the AMD powernowk8 driver.

The failure that was reported was as follows:

powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [] cpufreq_stats_update+0x46/0x5b
...

And transition fails and data->currfid ends up with 0. Since
the machine does not support 800Mhz value when the calculation is
done ('find_khz_freq_from_fid(data->currfid);') it reports the
new frequency as 800000 which is bogus. This patch fixes
the issue during target setting.

The patch however does not fix the issue in 'powernowk8_cpu_init'
where the pol->cur can also be set with the 800000 value:

          pol->cur = find_khz_freq_from_fid(data->currfid);
  dprintk("policy current frequency %d kHz\n", pol->cur);

  /* min/max the cpu is capable of */
  if (cpufreq_frequency_table_cpuinfo(pol, data->powernow_table)) {

The fix for that looks to update cpufreq_frequency_table_cpuinfo to
check pol->cur.... but that would cause an regression in how the
acpi-cpufreq driver works (it sets cpu->cur after calling
cpufreq_frequency_table_cpuinfo). Instead the fix will be to let
cpufreq gracefully handle bogus data (another patch).

Acked-by: Borislav Petkov 
CC: andre.przywara@amd.com
CC: Mark.Langsdorf@amd.com
Reported-by: Tobias Diedrich 
Tested-by: Tobias Diedrich 
[v1: Rebased on v3.0-rc2, reduced patch to deal with vid case]
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Dave Jones

[CPUFREQ] Don't set stat->last_index to -1 if the pol->cur has incorrect value.

2011-06-16T20:31:12+00:00

If the driver submitted an non-existing pol>cur value (say it
used the default initialized value of zero), when the cpufreq
stats tries to setup its initial values it incorrectly sets
stat->last_index to -1 (or 0xfffff...). And cpufreq_stats_update
tries to update at that index location and fails.

This can be caused by:

stat->last_index = freq_table_get_index(stat, policy->cur);

not finding the appropiate frequency in the table (b/c the policy->cur
is wrong) and we end up crashing. The fix however is
concentrated in the 'cpufreq_stats_update' as the last_index
(and old_index) are updated there. Which means it can reset
the last_index to -1 again and on the next iteration cause a crash.

Without this patch, the following crash is observed:

powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
powernow-k8: fid 0x2 (1000 MHz), vid 0x12
powernow-k8: fid 0xa (1800 MHz), vid 0xa
powernow-k8: fid 0xc (2000 MHz), vid 0x8
powernow-k8: fid 0xe (2200 MHz), vid 0x8
Marking TSC unstable due to cpufreq changes
powernow-k8: fid trans failed, fid 0x2, curr 0x0
BUG: unable to handle kernel paging request at ffff880807e07b78
IP: [] cpufreq_stats_update+0x46/0x5b
.. snip..
Pid: 1, comm: swapper Not tainted 3.0.0-rc2 #45 MICRO-STAR INTERNATIONAL CO., LTD MS-7094/MS-7094
..snip..
Call Trace:
 [] cpufreq_stat_notifier_trans+0x48/0x7c
 [] notifier_call_chain+0x32/0x5e
 [] __srcu_notifier_call_chain+0x47/0x63
 [] srcu_notifier_call_chain+0xf/0x11
 [] cpufreq_notify_transition+0x111/0x134
 [] powernowk8_target+0x53b/0x617
 [] __cpufreq_driver_target+0x2e/0x30
 [] cpufreq_governor_dbs+0x339/0x356
 [] __cpufreq_governor+0xa8/0xe9
 [] __cpufreq_set_policy+0x132/0x13e
 [] cpufreq_add_dev_interface+0x272/0x28c

Reported-by: Tobias Diedrich 
Tested-by: Tobias Diedrich 
Signed-off-by: Konrad Rzeszutek Wilk 
Signed-off-by: Dave Jones

[CPUFREQ] Remove cpufreq_stats sysfs entries on module unload.

2011-06-12T20:36:52+00:00

cpufreq_stats leaves behind its sysfs entries, which causes a panic
when something stumbled across them.
(Discovered by unloading cpufreq_stats while powertop was loaded).

Signed-off-by: Dave Jones 
Cc: stable@kernel.org

cpufreq: make DB8500 cpufreq driver compile

2011-05-24T20:20:14+00:00

Concluding interface update and movement of the driver by making
the DB8500 cpufreq driver compile in the cpufreq subsystem.

Cc: Arnd Bergmann 
Acked-by: Dave Jones 
Signed-off-by: Linus Walleij

cpufreq: update DB8500 cpufreq driver

2011-05-24T20:20:05+00:00

This updates the ux500 cpufreq driver to the new interface from the
updated DB8500 PRCMU

Cc: Arnd Bergmann 
Acked-by: Dave Jones 
Signed-off-by: Linus Walleij

mach-ux500: move CPUfreq driver to cpufreq subsystem

2011-05-24T20:19:55+00:00

As part of the ARM arch subsystem migration, move the DB8500
cpufreq driver to drivers/cpufreq as discussed with Dave Jones. The
Makefile is not updated in order to avoid cross-subsystem conflicts
for this file in merges.

Cc: Arnd Bergmann 
Acked-by: Dave Jones 
Signed-off-by: Linus Walleij

Merge branch 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

2011-05-20T00:55:12+00:00

* 'x86-cpu-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  x86, cpu: Fix detection of Celeron Covington stepping A1 and B0
  Documentation, ABI: Update L3 cache index disable text
  x86, AMD, cacheinfo: Fix L3 cache index disable checks
  x86, AMD, cacheinfo: Fix fallout caused by max3 conversion
  x86, cpu: Change NOP selection for certain Intel CPUs
  x86, cpu: Clean up and unify the NOP selection infrastructure
  x86, percpu: Use ASM_NOP4 instead of hardcoding P6_NOP4
  x86, cpu: Move AMD Elan Kconfig under "Processor family"

Fix up trivial conflicts in alternative handling (commit dc326fca2b64
"x86, cpu: Clean up and unify the NOP selection infrastructure" removed
some hacky 5-byte instruction stuff, while commit d430d3d7e646 "jump
label: Introduce static_branch() interface" renamed HAVE_JUMP_LABEL to
CONFIG_JUMP_LABEL in the code that went away)