summaryrefslogtreecommitdiffstats
path: root/drivers/cpufreq/pcc-cpufreq.c
AgeCommit message (Collapse)AuthorFilesLines
2020-07-15cpufreq: pcc-cpufreq: Mark sometimes used ID structs as __maybe_unusedLee Jones1-1/+1
Not used when MODULE is not defined. Fixes the following W=1 kernel build warning(s): drivers/cpufreq/pcc-cpufreq.c:619:36: warning: ‘processor_device_ids’ defined but not used [-Wunused-const-variable=] 619 | static const struct acpi_device_id processor_device_ids[] = { | ^~~~~~~~~~~~~~~~~~~~ Signed-off-by: Lee Jones <lee.jones@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-01-31Merge tag 'pm-5.6-rc1-2' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more power manadement updates from Rafael Wysocki: "Prevent cpufreq from creating excessively large stack frames and fix the handling of devices deleted during system-wide resume in the PM core (Rafael Wysocki), revert a problematic commit affecting the cpupower utility and correct its man page (Thomas Renninger, Brahadambal Srinivasan), and improve the intel_pstate_tracer utility (Doug Smythies)" * tag 'pm-5.6-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: tools/power/x86/intel_pstate_tracer: change several graphs to autoscale y-axis tools/power/x86/intel_pstate_tracer: changes for python 3 compatibility Correction to manpage of cpupower cpufreq: Avoid creating excessively large stack frames PM: core: Fix handling of devices deleted during system-wide resume cpupower: Revert library ABI changes from commit ae2917093fb60bdc1ed3e
2020-01-27cpufreq: Avoid creating excessively large stack framesRafael J. Wysocki1-1/+1
In the process of modifying a cpufreq policy, the cpufreq core makes a copy of it including all of the internals which is stored on the CPU stack. Because struct cpufreq_policy is relatively large, this may cause the size of the stack frame to exceed the 2 KB limit and so the GCC complains when -Wframe-larger-than= is used. In fact, it is not necessary to copy the entire policy structure in order to modify it, however. First, because cpufreq_set_policy() obtains the min and max policy limits from frequency QoS now, it is not necessary to pass the limits to it from the callers. The only things that need to be passed to it from there are the new governor pointer or (if there is a built-in governor in the driver) the "policy" value representing the governor choice. They both can be passed as individual arguments, though, so make cpufreq_set_policy() take them this way and rework its callers accordingly. This avoids making copies of cpufreq policies in the callers of cpufreq_set_policy(). Second, cpufreq_set_policy() still needs to pass the new policy data to the ->verify() callback of the cpufreq driver whose task is to sanitize the min and max policy limits. It still does not need to make a full copy of struct cpufreq_policy for this purpose, but it needs to pass a few items from it to the driver in case they are needed (different drivers have different needs in that respect and all of them have to be covered). For this reason, introduce struct cpufreq_policy_data to hold copies of the members of struct cpufreq_policy used by the existing ->verify() driver callbacks and pass a pointer to a temporary structure of that type to ->verify() (instead of passing a pointer to full struct cpufreq_policy to it). While at it, notice that intel_pstate and longrun don't really need to verify the "policy" value in struct cpufreq_policy, so drop those check from them to avoid copying "policy" into struct cpufreq_policy_data (which allows it to be slightly smaller). Also while at it fix up white space in a couple of places and make cpufreq_set_policy() static (as it can be so). Fixes: 3000ce3c52f8 ("cpufreq: Use per-policy frequency QoS") Link: https://lore.kernel.org/linux-pm/CAMuHMdX6-jb1W8uC2_237m8ctCpsnGp=JCxqt8pCWVqNXHmkVg@mail.gmail.com Reported-by: kbuild test robot <lkp@intel.com> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: 5.4+ <stable@vger.kernel.org> # 5.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
2020-01-06remove ioremap_nocache and devm_ioremap_nocacheChristoph Hellwig1-1/+1
ioremap has provided non-cached semantics by default since the Linux 2.6 days, so remove the additional ioremap_nocache interface. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Arnd Bergmann <arnd@arndb.de>
2019-06-17cpufreq: pcc-cpufreq: Fail initialization if driver cannot be registeredDavid Arcari1-2/+2
Make pcc_cpufreq_init() return error codes when the driver cannot be registered. Otherwise the driver can shows up loaded via lsmod even though it failed initialization. This is confusing to the user. Signed-off-by: David Arcari <darcari@redhat.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-02-18cpufreq: pcc-cpufreq: remove unneeded semicolonYangtao Li1-1/+1
The semicolon is unneeded, so remove it. Signed-off-by: Yangtao Li <tiny.windzz@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
2018-07-25Merge back cpufreq material for 4.19.Rafael J. Wysocki1-0/+9
2018-07-18cpufreq: intel_pstate: Register when ACPI PCCH is presentRafael J. Wysocki1-0/+4
Currently, intel_pstate doesn't register if _PSS is not present on HP Proliant systems, because it expects the firmware to take over CPU performance scaling in that case. However, if ACPI PCCH is present, the firmware expects the kernel to use it for CPU performance scaling and the pcc-cpufreq driver is loaded for that. Unfortunately, the firmware interface used by that driver is not scalable for fundamental reasons, so pcc-cpufreq is way suboptimal on systems with more than just a few CPUs. In fact, it is better to avoid using it at all. For this reason, modify intel_pstate to look for ACPI PCCH if _PSS is not present and register if it is there. Also prevent the pcc-cpufreq driver from trying to initialize itself if intel_pstate has been registered already. Fixes: fbbcdc0744da (intel_pstate: skip the driver if ACPI has power mgmt option) Reported-by: Andreas Herrmann <aherrmann@suse.com> Reviewed-by: Andreas Herrmann <aherrmann@suse.com> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Tested-by: Andreas Herrmann <aherrmann@suse.com> Cc: 4.16+ <stable@vger.kernel.org> # 4.16+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-07-18cpufreq: pcc-cpufreq: Disable dynamic scaling on many-CPU systemsRafael J. Wysocki1-0/+9
The firmware interface used by the pcc-cpufreq driver is fundamentally not scalable and using it for dynamic CPU performance scaling on systems with many CPUs leads to degraded performance. For this reason, disable dynamic CPU performance scaling on systems with pcc-cpufreq where the number of CPUs present at the driver init time is greater than 4. Also make the driver print corresponding complaints to the kernel log. Reported-by: Andreas Herrmann <aherrmann@suse.com> Tested-by: Andreas Herrmann <aherrmann@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-07-22Revert "cpufreq: pcc-cpufreq: update default value of ↵Andreas Herrmann1-2/+0
cpuinfo_transition_latency" This reverts commit 790d849bf811a8ab5d4cd2cce0f6fda92f6aebf2. Using a v4.7-rc7 kernel on a HP ProLiant triggered following messages pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor The last line was shown for each CPU in the system. Testing v4.5 (where commit 790d849b was integrated) triggered similar messages. Same behaviour on a 2nd HP Proliant system. So commit 790d849bf (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency) causes the system to use performance governor which, I guess, was not the intention of the patch. Enabling debug output in pcc-cpufreq provides following verbose output: pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz pcc_get_offset: for CPU 0: pcc_cpu_data input_offset: 0x44, pcc_cpu_data output_offset: 0x48 init: policy->max is 2800000, policy->min is 1200000 get: get_freq for CPU 0 get: SUCCESS: (virtual) output_offset for cpu 0 is 0xffffc9000d7c0048, contains a value of: 0xff06. Speed is: 168000 MHz cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor target: CPU 0 should go to target freq: 2800000 (virtual) input_offset is 0xffffc9000d7c0044 target: was SUCCESSFUL for cpu 0 I am asking to revert 790d849bf to re-enable usage of ondemand governor with pcc-cpufreq. Fixes: 790d849bf (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency) CC: <stable@vger.kernel.org> # 4.5+ Signed-off-by: Andreas Herrmann <aherrmann@suse.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-06-23cpufreq: pcc-cpufreq: Fix doorbell.access_widthMike Galbraith1-1/+1
Commit 920de6ebfab8 (ACPICA: Hardware: Enhance acpi_hw_validate_register() with access_width/bit_offset awareness) apparently exposed a latent bug, doorbell.access_width is initialized to 64, but per Lv Zheng, it should be 4, and indeed, making that change does bring pcc-cpufreq back to life. Fixes: 920de6ebfab8 (ACPICA: Hardware: Enhance acpi_hw_validate_register() with access_width/bit_offset awareness) Suggested-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Mike Galbraith <umgwanakikbuti@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-10cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latencyJacob Tanenbaum1-0/+2
The cpufreq documentation specifies policy->cpuinfo.transition_latency the time it takes on this CPU to switch between two frequencies in nanoseconds (if appropriate, else specify CPUFREQ_ETERNAL) currently pcc-cpufreq does not expose the value and sets it to zero. I changed the pcc-cpufreq driver and it's documentation to conform to the default value specified in Documentation/cpu-freq/cpu-drivers.txt Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-11-14cpufreq: pcc: Enable autoload of pcc-cpufreq for ACPI processorsLenny Szubowicz1-0/+7
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 <lszubowi@redhat.com> Signed-off-by: Joseph Szczypek <joseph.szczypek@hp.com> Reported-by: Trinh Dao <trinh.dao@hp.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-09-29cpufreq: pcc-cpufreq: Fix wait_event() under spinlockRafael J. Wysocki1-1/+1
Fix the following bug introduced by commit 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) that forgot to move the spin_lock() in pcc_cpufreq_target() past cpufreq_freq_transition_begin() which calls wait_event(): BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370 in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe Preemption disabled at:[<ffffffffa04d74d7>] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq] [ 51.025044] CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7 Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010 00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000 ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090 0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00 Call Trace: [<ffffffff81589dbd>] dump_stack+0x4d/0x90 [<ffffffff8108e1df>] ___might_sleep+0x10f/0x180 [<ffffffff8108e298>] __might_sleep+0x48/0xd0 [<ffffffff8145b905>] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing); [<ffffffff8108fc99>] ? preempt_count_add+0xb9/0xc0 [<ffffffffa04d7513>] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock); [<ffffffff810e0d0f>] ? update_ts_time_stats+0x7f/0xb0 [<ffffffff8145be55>] __cpufreq_driver_target+0x85/0x170 [<ffffffff8145e4c8>] od_check_cpu+0xa8/0xb0 [<ffffffff8145ef10>] dbs_check_cpu+0x180/0x1d0 [<ffffffff8145f310>] cpufreq_governor_dbs+0x3b0/0x720 [<ffffffff8145ebe3>] od_cpufreq_governor_dbs+0x33/0xe0 [<ffffffff814593d9>] __cpufreq_governor+0xa9/0x210 [<ffffffff81459fb2>] cpufreq_set_policy+0x1e2/0x2e0 [<ffffffff8145a6cc>] cpufreq_init_policy+0x8c/0x110 [<ffffffff8145c9a0>] ? cpufreq_update_policy+0x1b0/0x1b0 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100 [<ffffffff8145c6c6>] __cpufreq_add_dev+0x596/0x6b0 [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [<ffffffff8145c7ee>] cpufreq_add_dev+0xe/0x10 [<ffffffff81408e81>] subsys_interface_register+0xc1/0xf0 [<ffffffff8108fb99>] ? preempt_count_sub+0xb9/0x100 [<ffffffff8145b3d7>] cpufreq_register_driver+0x117/0x2a0 [<ffffffffa016c65d>] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq] [<ffffffffa016c608>] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq] [<ffffffff81000298>] do_one_initcall+0xc8/0x1f0 [<ffffffff811a731d>] ? __vunmap+0x9d/0x100 [<ffffffff810eb9a0>] do_init_module+0x30/0x1b0 [<ffffffff810edfa6>] load_module+0x686/0x710 [<ffffffff810ebb20>] ? do_init_module+0x1b0/0x1b0 [<ffffffff810ee1db>] SyS_init_module+0x9b/0xc0 [<ffffffff8158f7a9>] system_call_fastpath+0x16/0x1b Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}) Reported-and-tested-by: Mike Galbraith <umgwanakikbuti@gmail.com> Cc: 3.15+ <stable@vger.kernel.org> # 3.15+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-03-26cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end}Viresh Kumar1-2/+2
CPUFreq core has new infrastructure that would guarantee serialized calls to target() or target_index() callbacks. These are called cpufreq_freq_transition_begin() and cpufreq_freq_transition_end(). This patch converts existing drivers to use these new set of routines. Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-01-06cpufreq: send new set of notification for transition failuresViresh Kumar1-11/+7
In the current code, if we fail during a frequency transition, we simply send the POSTCHANGE notification with the old frequency. This isn't enough. One of the core users of these notifications is the code responsible for keeping loops_per_jiffy aligned with frequency changes. And mostly it is written as: if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) || (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) { update-loops-per-jiffy... } So, suppose we are changing to a higher frequency and failed during transition, then following will happen: - CPUFREQ_PRECHANGE notification with freq-new > freq-old - CPUFREQ_POSTCHANGE notification with freq-new == freq-old The first one will update loops_per_jiffy and second one will do nothing. Even if we send the 2nd notification by exchanging values of freq-new and old, some users of these notifications might get unstable. This can be fixed by simply calling cpufreq_notify_post_transition() with error code and this routine will take care of sending notifications in the correct order. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Folded 3 patches into one, rebased unicore2 changes] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-28Merge branch 'pm-cpufreq'Rafael J. Wysocki1-9/+1
* pm-cpufreq: (167 commits) cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsem intel_pstate: Add Baytrail support intel_pstate: Refactor driver to support CPUs with different MSR layouts cpufreq: Implement light weight ->target_index() routine PM / OPP: rename header to linux/pm_opp.h PM / OPP: rename data structures to dev_pm equivalents PM / OPP: rename functions to dev_pm_opp* cpufreq / governor: Remove fossil comment cpufreq: exynos4210: Use the common clock framework to set APLL clock rate cpufreq: exynos4x12: Use the common clock framework to set APLL clock rate cpufreq: Detect spurious invocations of update_policy_cpu() cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) model cpufreq: pmac64: provide cpufreq transition latency for older G5 models cpufreq: pmac64: speed up frequency switch cpufreq: highbank-cpufreq: Enable Midway/ECX-2000 exynos-cpufreq: fix false return check from "regulator_set_voltage" speedstep-centrino: Remove unnecessary braces acpi-cpufreq: Add comment under ACPI_ADR_SPACE_SYSTEM_IO case cpufreq: arm-big-little: use clk_get instead of clk_get_sys cpufreq: exynos: Show a list of available frequencies ... Conflicts: drivers/devfreq/exynos/exynos5_bus.c
2013-10-16cpufreq: pcc: don't initialize part of policy set by coreViresh Kumar1-7/+0
Many common initializations of struct policy are moved to core now and hence this driver doesn't need to do it. This patch removes such code. Most recent of those changes is to call ->get() in the core after calling ->init(). Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-10-16cpufreq: add new routine cpufreq_verify_within_cpu_limits()Viresh Kumar1-2/+1
Most of the users of cpufreq_verify_within_limits() calls it for limiting with min/max from policy->cpuinfo. We can make that code simple by introducing another routine which will do this for them automatically. This patch adds another routine cpufreq_verify_within_cpu_limits() and updates others to use it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-09-24pcc_freq: convert acpi_get_handle() to acpi_has_method()Zhang Rui1-3/+2
acpi_has_method() is a new ACPI API introduced to check the existence of an ACPI control method. It can be used to replace acpi_get_handle() in the case that 1. the calling function doesn't need the ACPI handle of the control method. and 2. the calling function doesn't care the reason why the method is unavailable. Convert acpi_get_handle() to acpi_has_method() in drivers/cpufreq/pcc_freq.c in this patch. Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-08-10cpufreq: Drop the owner field from struct cpufreq_driverViresh Kumar1-1/+0
We don't need to set .owner = THIS_MODULE any more in cpufreq drivers as this field isn't used any more by the cpufreq core. This patch removes it and updates all dependent drivers accordingly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-06-24cpufreq: pcc: call CPUFREQ_POSTCHANGE notfier in error casesViresh Kumar1-0/+2
PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e either both should be called or both shouldn't be. In case we have started PRECHANGE notifier and found an error, we must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee that the sequence of calling notifiers is complete. This patch fixes it. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2013-04-02cpufreq: Notify all policy->cpus in cpufreq_notify_transition()Viresh Kumar1-3/+2
policy->cpus contains all online cpus that have single shared clock line. And their frequencies are always updated together. Many SMP system's cpufreq drivers take care of this in individual drivers but the best place for this code is in cpufreq core. This patch modifies cpufreq_notify_transition() to notify frequency change for all cpus in policy->cpus and hence updates all users of this API. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-08-08drivers/cpufreq/pcc-cpufreq.c: fix error return codeJulia Lawall1-0/+1
Convert a 0 error return code to a negative one, as returned elsewhere in the function. A simplified version of the semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ identifier ret; expression e,e1,e2,e3,e4,x; @@ ( if (\(ret != 0\|ret < 0\) || ...) { ... return ...; } | ret = 0 ) ... when != ret = e1 *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...); ... when != x = e2 when != ret = e3 *if (x == NULL || ...) { ... when != ret = e4 * return ret; } // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-09-14drivers/cpufreq/pcc-cpufreq.c: avoid NULL pointer dereferenceNaga Chumbalkar1-0/+3
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: [<ffffffffa0434314>] 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 <nagananda.chumbalkar@hp.com> Cc: Dave Jones <davej@codemonkey.org.uk> Cc: Len Brown <lenb@kernel.org> Cc: <stable@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-05-19[CPUFREQ] Move x86 drivers to drivers/cpufreq/Dave Jones1-0/+621
Signed-off-by: Dave Jones <davej@redhat.com>