linux/drivers/acpi/processor_core.c, branch v3.12.14

Merge back earlier 'acpi-assorted' material

2013-08-14T21:22:45Z

ACPI / processor: Fix incorrect placement of __initdata

2013-08-07T21:49:28Z

__initdata should be placed between the variable name and equal sign for the variable to be placed in the intended section. Signed-off-by: Sachin Kamat Signed-off-by: Rafael J. Wysocki

acpi: delete __cpuinit usage from all acpi files

2013-07-14T23:36:58Z

The __cpuinit type of throwaway sections might have made sense some time ago when RAM was more constrained, but now the savings do not offset the cost and complications. For example, the fix in commit 5e427ec2d0 ("x86: Fix bit corruption at CPU resume time") is a good example of the nasty type of bugs that can be created with improper use of the various __init prefixes. After a discussion on LKML[1] it was decided that cpuinit should go the way of devinit and be phased out. Once all the users are gone, we can then finally remove the macros themselves from linux/init.h. This removes all the drivers/acpi uses of the __cpuinit macros from all C files. [1] https://lkml.org/lkml/2013/5/20/589 Cc: Len Brown Cc: "Rafael J. Wysocki" Cc: linux-acpi@vger.kernel.org Signed-off-by: Paul Gortmaker

ACPI / processor: Remove redundant NULL check before kfree

2013-03-04T13:23:39Z

kfree() on a NULL pointer is a no-op, so remove a redundant NULL pointer check in map_mat_entry(). [rjw: Changelog] Signed-off-by: Syam Sidhardhan Signed-off-by: Rafael J. Wysocki

cpufreq / ACPI: Fix not loading acpi-cpufreq driver regression

2012-07-12T20:39:32Z

Commit d640113fe80e45ebd4a5b420b introduced a regression on SMP systems where the processor core with ACPI id zero is disabled (typically should be the case because of hyperthreading). The regression got spread through stable kernels. On 3.0.X it got introduced via 3.0.18. Such platforms may be rare, but do exist. Look out for a disabled processor with acpi_id 0 in dmesg: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x10] disabled) This problem has been observed on a: HP Proliant BL280c G6 blade This patch restricts the introduced workaround to platforms with nr_cpu_ids <= 1. Signed-off-by: Thomas Renninger CC: stable@vger.kernel.org Signed-off-by: Rafael J. Wysocki

ACPI: processor: fix acpi_get_cpuid for UP processor

2012-01-17T10:25:08Z

For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Cc: stable@vger.kernel.org Reported-and-tested-by: wallak@free.fr Signed-off-by: Lin Ming Signed-off-by: Len Brown

acpi: add export.h to files using THIS_MODULE/EXPORT_SYMBOL

2011-10-31T23:30:34Z

These files were relying on module.h to come in via the path in an include/acpi header file, but we don't want to have instances of module.h being included from include/* files if it can be avoided. Have the files include export.h instead. Signed-off-by: Paul Gortmaker

ACPI: processor: fix processor_physically_present in UP kernel

2011-05-29T06:17:56Z

Usually, there are multiple processors defined in ACPI table, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } processor_physically_present(...) will be called to check whether those processors are physically present. Currently we have below codes in processor_physically_present, cpuid = acpi_get_cpuid(...); if ((cpuid == -1) && (num_possible_cpus() > 1)) return false; return true; In UP kernel, acpi_get_cpuid(...) always return -1 and num_possible_cpus() always return 1, so processor_physically_present(...) always returns true for all passed in processor handles. This is wrong for UP processor or SMP processor running UP kernel. This patch removes the !SMP version of acpi_get_cpuid(), so both UP and SMP kernel use the same acpi_get_cpuid function. And for UP kernel, only processor 0 is valid. https://bugzilla.kernel.org/show_bug.cgi?id=16548 https://bugzilla.kernel.org/show_bug.cgi?id=16357 Tested-by: Anton Kochkov Tested-by: Ambroz Bizjak Signed-off-by: Lin Ming Signed-off-by: Len Brown

ACPI: use __cpuinit for the acpi_processor_set_pdc() call tree

2011-03-03T01:58:20Z

Once acpi_map_lsapic() in ia64 follows how x86 treats it wrt section placement, the whole tree from acpi_processor_set_pdc() can become __cpuinit. Signed-off-by: Jan Beulich Acked-by: Tony Luck Signed-off-by: Len Brown

ACPI: use __init where possible in processor driver

2011-03-03T01:56:53Z

Use __init for several functions, remove an unnecessary export and a stray use of __ref. Signed-off-by: Jan Beulich Signed-off-by: Len Brown