linux.git/drivers/acpi/processor_core.c, branch v2.6.31

acpi: don't call acpi_processor_init if acpi is disabled

2009-08-27T03:06:52+00:00

Jens reported early_ioremap messages with old ASUS board...

> [    1.507461] pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
> [    1.532778] early_ioremap(3fffd080, 0000005c) [0] => Pid: 1, comm: swapper Not tainted 2.6.31-rc4 #36
> [    1.561007] Call Trace:
> [    1.568638]  [] ? printk+0x18/0x1d
> [    1.581734]  [] __early_ioremap+0x74/0x1e9
> [    1.596898]  [] early_ioremap+0x1a/0x1c
> [    1.611270]  [] __acpi_map_table+0x18/0x1a
> [    1.626451]  [] acpi_os_map_memory+0x1d/0x25
> [    1.642129]  [] acpi_tb_verify_table+0x20/0x49
> [    1.658321]  [] acpi_get_table_with_size+0x53/0xa1
> [    1.675553]  [] acpi_get_table+0x10/0x15
> [    1.690192]  [] acpi_processor_init+0x23/0xab
> [    1.706126]  [] do_one_initcall+0x33/0x180
> [    1.721279]  [] ? acpi_processor_init+0x0/0xab
> [    1.737479]  [] ? register_irq_proc+0xaa/0xc0
> [    1.753411]  [] ? init_irq_proc+0x67/0x80
> [    1.768316]  [] kernel_init+0x120/0x176
> [    1.782678]  [] ? kernel_init+0x0/0x176
> [    1.797062]  [] kernel_thread_helper+0x7/0x10
> [    1.812984] 00000080 + ffe00000

that is rather later.
acpi_gbl_permanent_mmap should be set in acpi_early_init()
if acpi is not disabled

and we have
> [    0.000000] ASUS P2B-DS detected: force use of acpi=ht

just don't load acpi_processor_init...

Reported-and-tested-by: Jens Rosenboom 
Signed-off-by: Yinghai Lu 
Acked-by: Ingo Molnar 
Cc: Len Brown 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branches 'acerhdf', 'acpi-pci-bind', 'bjorn-pci-root', 'bugzilla-12904', 'bugzilla-13121', 'bugzilla-13396', 'bugzilla-13533', 'bugzilla-13612', 'c3_lock', 'hid-cleanups', 'misc-2.6.31', 'pdc-leak-fix', 'pnpacpi', 'power_nocheck', 'thinkpad_acpi', 'video' and 'wmi' into release

2009-06-24T05:19:50+00:00

ACPI: Rename ACPI processor device bus ID

2009-06-24T05:18:04+00:00

Some BIOS re-use the same processor bus id
in different scope:

	\_SB.SCK0.CPU0
	\_SB.SCK1.CPU0

But the (deprecated) /proc/acpi/ interface
assumes the bus-id's are unique, resulting in an OOPS
when the processor driver is loaded:

WARNING: at fs/proc/generic.c:590 proc_register+0x148/0x180()
Hardware name: Sunrise Ridge
proc_dir_entry 'processor/CPU0' already registered
Call Trace:
 [] warn_slowpath+0xb1/0xe5
 [] ? ida_get_new_above+0x190/0x1b1
 [] ? idr_pre_get+0x5f/0x75
 [] proc_register+0x148/0x180
 [] proc_mkdir_mode+0x3d/0x52
 [] proc_mkdir+0x11/0x13
 [] acpi_processor_start+0x755/0x9bc [processor]

Rename the processor device bus id. And the new bus id will be
generated as the following format:
	CPU+ CPU ID

For example: If the cpu ID is 5, then the bus ID will be "CPU5".
	If the CPU ID is 10, then the bus ID will be "CPUA".

Yes, this will change the directory names seen
in /proc/acpi/processor/* on some systems.
Before this patch, those directory names where
totally arbitrary strings based on the interal AML device strings.

http://bugzilla.kernel.org/show_bug.cgi?id=13612

Signed-off-by: Zhao Yakui 
Signed-off-by: Len Brown

ACPI: pdc init related memory leak with physical CPU hotplug

2009-06-20T04:50:52+00:00

arch_acpi_processor_cleanup_pdc() in x86 and ia64 results in memory allocated
for _PDC objects that is never freed and will cause memory leak in case of
physical CPU remove and add. Patch fixes the memory leak by freeing the
objects soon after _PDC is evaluated.

Reported-by: Bjorn Helgaas 
Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Len Brown

cpumask: alloc zeroed cpumask for static cpumask_var_ts

2009-06-09T13:00:27+00:00

These are defined as static cpumask_var_t so if MAXSMP is not used,
they are cleared already.  Avoid surprises when MAXSMP is enabled.

Signed-off-by: Yinghai Lu 
Signed-off-by: Rusty Russell

ACPI: processor: move device _HID into driver

2009-05-28T01:14:28+00:00

The ACPI0007 _HID used for processor "Device" objects in the namespace
is not needed outside the processor driver, so move it there.  Also, the
#define is only used once, so just remove it and hard-code "ACPI0007".

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Len Brown

ACPI: processor: check for synthetic _HID, default to "Device" declaration

2009-05-28T01:14:03+00:00

This patch inverts the logic that distinguishes "Processor" statements
from "Device" statements, so we now check explicitly for "Processor" and
default to "Device".  This removes the only real use of ACPI_PROCESSOR_HID,
so we can then remove the #define.  It also has the theoretical advantage
that if a new processor _HID were ever added, we wouldn't have to change
the code here.

Signed-off-by: Bjorn Helgaas 
Signed-off-by: Len Brown

ACPI: processor: use .notify method instead of installing handler directly

2009-04-05T06:25:07+00:00

This patch adds a .notify() method.  The presence of .notify() causes
Linux/ACPI to manage event handlers and notify handlers on our behalf,
so we don't have to install and remove them ourselves.

Signed-off-by: Bjorn Helgaas 
CC: Zhang Rui 
CC: Zhao Yakui 
CC: Venki Pallipadi 
CC: Anil S Keshavamurthy 
Signed-off-by: Len Brown

Merge branch 'linus' into release

2009-04-05T06:14:15+00:00

Conflicts:
	arch/x86/kernel/cpu/cpufreq/longhaul.c

Signed-off-by: Len Brown

x86, ACPI: add support for x2apic ACPI extensions

2009-04-04T00:08:12+00:00

All logical processors with APIC ID values of 255 and greater will have their
APIC reported through Processor X2APIC structure (type-9 entry type) and all
logical processors with APIC ID less than 255 will have their APIC reported
through legacy Processor Local APIC (type-0 entry type) only. This is the
same case even for NMI structure reporting.
    
The Processor X2APIC Affinity structure provides the association between the
X2APIC ID of a logical processor and the proximity domain to which the logical
processor belongs.
    
For OSPM, Procssor IDs outside the 0-254 range are to be declared as Device()
objects in the ACPI namespace.

Signed-off-by: Suresh Siddha 
Signed-off-by: Len Brown