kernel/linux.git/drivers/acpi/processor_core.c, branch linux-2.6.35.y

ACPI: delete ZEPTO idle=nomwait DMI quirk

2010-10-29T04:51:43+00:00

commit 64a32307b710c100beb101e9c78f8022f0e8ba61 upstream. per comments in the bug report, this entry seems to hurt at much as it helps. https://bugzilla.kernel.org/show_bug.cgi?id=10807 Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: Handle ACPI0007 Device in acpi_early_set_pdc

2010-10-29T04:51:39+00:00

commit c1e0ddbf0a97e1704d7f13b4934f9acca002402d upstream. After | commit d8191fa4a33fdc817277da4f2b7f771ff605a41c | Author: Alex Chiang | Date: Mon Feb 22 12:11:39 2010 -0700 | | ACPI: processor: driver doesn't need to evaluate _PDC | | Now that the early _PDC evaluation path knows how to correctly | evaluate _PDC on only physically present processors, there's no | need for the processor driver to evaluate it later when it loads. | | To cover the hotplug case, push _PDC evaluation down into the | hotplug paths. only cpu with Processor Statement get processed with _PDC If bios is using Device object instead of Processor statement. SSDTs for Pstate/Cstate/Tstate can not be loaded dynamically. Need to try to scan ACPI0007 in addition to Processor. That commit is between 2.6.34-rc1 and 2.6.34-rc2, so stable tree for 2.6.34+ need this patch. Signed-off-by: Yinghai Lu Reviewed-by: Bjorn Helgaas Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

ACPI: processor: fix processor_physically_present on UP

2010-07-12T17:28:34+00:00

The commit 5d554a7bb06 (ACPI: processor: add internal processor_physically_present()) is broken on uniprocessor (UP) configurations, as acpi_get_cpuid() will always return -1. We use the value of num_possible_cpus() to tell us whether we got an invalid cpuid from acpi_get_cpuid() in the SMP case, or if instead, we are UP, in which case num_possible_cpus() is #defined as 1. We use num_possible_cpus() instead of num_online_cpus() to protect ourselves against the scenario of CPU hotplug, and we've taken down all the CPUs except one. Thanks to Jan Pogadl for initial report and analysis and Chen Gong for review. https://bugzilla.kernel.org/show_bug.cgi?id=16357 Reported-by: Jan Pogadl : Reviewed-by: Chen Gong Signed-off-by: Alex Chiang Signed-off-by: Len Brown

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

2010-03-30T13:02:32+00:00

percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo Guess-its-ok-by: Christoph Lameter Cc: Ingo Molnar Cc: Lee Schermerhorn

ACPI: processor: push file static MADT pointer into internal map_madt_entry()

2010-03-15T01:17:26+00:00

There's no real need for a pointer to the MADT to be global. The only function who uses it is map_madt_entry. This allows us to remove some more ugly #ifdefs. Acked-by: Venkatesh Pallipadi Signed-off-by: Alex Chiang Signed-off-by: Len Brown

ACPI: processor: refactor internal map_lsapic_id()

2010-03-15T01:17:25+00:00

Un-nest the if statements for readability. Remove comments that re-state the obvious. Change the control flow so that we no longer need a temp variable. Acked-by: Venkatesh Pallipadi Signed-off-by: Alex Chiang Signed-off-by: Len Brown

ACPI: processor: refactor internal map_x2apic_id()

2010-03-15T01:17:24+00:00

Untangle the nested if conditions to make this function look more similar to the other map_*apic_id() functions. Acked-by: Venkatesh Pallipadi Signed-off-by: Alex Chiang Signed-off-by: Len Brown

ACPI: processor: refactor internal map_lapic_id()

2010-03-15T01:17:23+00:00

Untangle the if() statement a little for readability. Acked-by: Venkatesh Pallipadi Signed-off-by: Alex Chiang Signed-off-by: Len Brown

ACPI: processor: driver doesn't need to evaluate _PDC

2010-03-15T01:17:22+00:00

Now that the early _PDC evaluation path knows how to correctly evaluate _PDC on only physically present processors, there's no need for the processor driver to evaluate it later when it loads. To cover the hotplug case, push _PDC evaluation down into the hotplug paths. Cc: x86@kernel.org Cc: Tony Luck Acked-by: Venkatesh Pallipadi Signed-off-by: Alex Chiang Signed-off-by: Len Brown

ACPI: processor: remove early _PDC optin quirks

2010-03-15T01:17:21+00:00

Now that we check for physically present processors before blindly evaluating _PDC, we no longer need to maintain a DMI opt-in table nor a kernel param. Acked-by: Venkatesh Pallipadi Signed-off-by: Alex Chiang Signed-off-by: Len Brown