linux/include/acpi, branch v3.0.87

ACPI: Store SRAT table revision

2012-01-26T01:24:57Z

commit 8df0eb7c9d96f9e82f233ee8b74e0f0c8471f868 upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. In order to know whether or not, we must know what version the SRAT table has. This patch stores the SRAT table revision for later consumption by arch specific __init functions. Signed-off-by: Kurt Garloff Signed-off-by: Len Brown Signed-off-by: Greg Kroah-Hartman

Merge branches 'd3cold', 'bugzilla-37412' and 'bugzilla-38152' into release

2011-07-14T04:16:38Z

ACPI: Fixes device power states array overflow

2011-07-14T03:53:22Z

Commit 28c2103 added new state ACPI_STATE_D3_COLD, so the device power states array must be expanded by one also. v2: Use ACPI_D_STATE_COUNT instead of number 5 for the array size. Reported-by: Dan Carpenter Suggested-by: Oldřich Jedlička Signed-off-by: Lin Ming Signed-off-by: Len Brown

ACPI: Fix lockdep false positives in acpi_power_off()

2011-07-13T18:49:09Z

All ACPICA locks are allocated by the same function, acpi_os_create_lock(), with the help of a local variable called "lock". Thus, when lockdep is enabled, it uses "lock" as the name of all those locks and regards them as instances of the same lock, which causes it to report possible locking problems with them when there aren't any. To work around this problem, define acpi_os_create_lock() as a macro and make it pass its argument to spin_lock_init(), so that lockdep uses it as the name of the new lock. Define this macron in a Linux-specific file, to minimize the resulting modifications of the OS-independent ACPICA parts. This change is based on an earlier patch from Andrea Righi and it addresses a regression from 2.6.39 tracked as https://bugzilla.kernel.org/show_bug.cgi?id=38152 Signed-off-by: Rafael J. Wysocki Reported-and-tested-by: Borislav Petkov Tested-by: Andrea Righi Reviewed-by: Florian Mickler Signed-off-by: Len Brown

Merge branches 'acpica', 'aml-custom', 'bugzilla-16548', 'bugzilla-20242', 'd3-cold', 'ec-asus' and 'thermal-fix' into release

2011-05-29T08:38:48Z

ACPI: Add D3 cold state

2011-05-29T06:21:08Z

_SxW returns an Integer containing the lowest D-state supported in state Sx. If OSPM has not indicated that it supports _PR3, then the value “3” corresponds to D3. If it has indicated _PR3 support, the value “3” represents D3hot and the value “4” represents D3cold. Linux does set _OSC._PR3, so we should fix it to expect that _SxW can return 4. Signed-off-by: Lin Ming Acked-by: Jesse Barnes Signed-off-by: Len Brown

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

ACPICA: Update to version 20110413

2011-05-10T02:16:12Z

Version 20110413 Signed-off-by: Bob Moore Signed-off-by: Lin Ming Signed-off-by: Len Brown

ACPICA: Execute an orphan _REG method under the EC device

2011-05-10T02:16:12Z

This change will force the execution of a _REG method underneath the EC device even if there is no corresponding operation region of type EmbeddedControl. Fixes a problem seen on some machines and apparently is compatible with Windows behavior. http://www.acpica.org/bugzilla/show_bug.cgi?id=875 Signed-off-by: Bob Moore Signed-off-by: Lin Ming Signed-off-by: Len Brown

ACPICA: Move ACPI_NUM_PREDEFINED_REGIONS to a more appropriate place

2011-05-10T02:16:12Z

Moved to where the predefined regions are actually defined. Signed-off-by: Bob Moore Signed-off-by: Lin Ming Signed-off-by: Len Brown