linux/drivers/acpi/acpica/tbutils.c

415 lines
13 KiB
C
Raw Normal View History

/******************************************************************************
*
* Module Name: tbutils - ACPI Table utilities
*
*****************************************************************************/
/*
* Copyright (C) 2000 - 2015, Intel Corp.
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions, and the following disclaimer,
* without modification.
* 2. Redistributions in binary form must reproduce at minimum a disclaimer
* substantially similar to the "NO WARRANTY" disclaimer below
* ("Disclaimer") and any redistribution must be conditioned upon
* including a substantially similar Disclaimer requirement for further
* binary redistribution.
* 3. Neither the names of the above-listed copyright holders nor the names
* of any contributors may be used to endorse or promote products derived
* from this software without specific prior written permission.
*
* Alternatively, this software may be distributed under the terms of the
* GNU General Public License ("GPL") version 2 as published by the Free
* Software Foundation.
*
* NO WARRANTY
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
* LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR
* A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
* HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
*/
#include <acpi/acpi.h>
#include "accommon.h"
#include "actables.h"
#define _COMPONENT ACPI_TABLES
ACPI_MODULE_NAME("tbutils")
ACPICA 20050408 from Bob Moore Fixed three cases in the interpreter where an "index" argument to an ASL function was still (internally) 32 bits instead of the required 64 bits. This was the Index argument to the Index, Mid, and Match operators. The "strupr" function is now permanently local (acpi_ut_strupr), since this is not a POSIX-defined function and not present in most kernel-level C libraries. References to the C library strupr function have been removed from the headers. Completed the deployment of static functions/prototypes. All prototypes with the static attribute have been moved from the headers to the owning C file. ACPICA 20050329 from Bob Moore An error is now generated if an attempt is made to create a Buffer Field of length zero (A CreateField with a length operand of zero.) The interpreter now issues a warning whenever executable code at the module level is detected during ACPI table load. This will give some idea of the prevalence of this type of code. Implemented support for references to named objects (other than control methods) within package objects. Enhanced package object output for the debug object. Package objects are now completely dumped, showing all elements. Enhanced miscellaneous object output for the debug object. Any object can now be written to the debug object (for example, a device object can be written, and the type of the object will be displayed.) The "static" qualifier has been added to all local functions across the core subsystem. The number of "long" lines (> 80 chars) within the source has been significantly reduced, by about 1/3. Cleaned up all header files to ensure that all CA/iASL functions are prototyped (even static functions) and the formatting is consistent. Two new header files have been added, acopcode.h and acnames.h. Removed several obsolete functions that were no longer used. Signed-off-by: Len Brown <len.brown@intel.com>
2005-04-19 02:49:35 +00:00
/* Local prototypes */
static acpi_physical_address
acpi_tb_get_root_table_entry(u8 *table_entry, u32 table_entry_size);
#if (!ACPI_REDUCED_HARDWARE)
/*******************************************************************************
*
* FUNCTION: acpi_tb_initialize_facs
*
* PARAMETERS: None
*
* RETURN: Status
*
* DESCRIPTION: Create a permanent mapping for the FADT and save it in a global
* for accessing the Global Lock and Firmware Waking Vector
*
******************************************************************************/
acpi_status acpi_tb_initialize_facs(void)
{
/* If Hardware Reduced flag is set, there is no FACS */
if (acpi_gbl_reduced_hardware) {
acpi_gbl_FACS = NULL;
return (AE_OK);
}
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
(void)acpi_get_table_by_index(ACPI_TABLE_INDEX_FACS,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963 ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949 ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch enables the firmware waking vectors for both 32bit/64bit FACS tables in order to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits so that if it turns out not to be necessary, this single commit can be reverted without affecting the useful one. Lv Zheng, Bob Moore. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/368eb607 Link: https://github.com/acpica/acpica/commit/70f62a80 Link: https://github.com/acpica/acpica/commit/a04dbfa3 Link: https://github.com/acpica/acpica/commit/ebd544ed Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:18 +00:00
&acpi_gbl_facs32));
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
(void)acpi_get_table_by_index(ACPI_TABLE_INDEX_X_FACS,
ACPI_CAST_INDIRECT_PTR(struct
acpi_table_header,
ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963 ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949 ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch enables the firmware waking vectors for both 32bit/64bit FACS tables in order to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits so that if it turns out not to be necessary, this single commit can be reverted without affecting the useful one. Lv Zheng, Bob Moore. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/368eb607 Link: https://github.com/acpica/acpica/commit/70f62a80 Link: https://github.com/acpica/acpica/commit/a04dbfa3 Link: https://github.com/acpica/acpica/commit/ebd544ed Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:18 +00:00
&acpi_gbl_facs64));
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963 ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949 ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch enables the firmware waking vectors for both 32bit/64bit FACS tables in order to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits so that if it turns out not to be necessary, this single commit can be reverted without affecting the useful one. Lv Zheng, Bob Moore. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/368eb607 Link: https://github.com/acpica/acpica/commit/70f62a80 Link: https://github.com/acpica/acpica/commit/a04dbfa3 Link: https://github.com/acpica/acpica/commit/ebd544ed Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:18 +00:00
if (acpi_gbl_facs64
&& (!acpi_gbl_facs32 || !acpi_gbl_use32_bit_facs_addresses)) {
acpi_gbl_FACS = acpi_gbl_facs64;
} else if (acpi_gbl_facs32) {
acpi_gbl_FACS = acpi_gbl_facs32;
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
}
ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963 ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949 ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch enables the firmware waking vectors for both 32bit/64bit FACS tables in order to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits so that if it turns out not to be necessary, this single commit can be reverted without affecting the useful one. Lv Zheng, Bob Moore. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/368eb607 Link: https://github.com/acpica/acpica/commit/70f62a80 Link: https://github.com/acpica/acpica/commit/a04dbfa3 Link: https://github.com/acpica/acpica/commit/ebd544ed Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:18 +00:00
/* If there is no FACS, just continue. There was already an error msg */
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
return (AE_OK);
}
#endif /* !ACPI_REDUCED_HARDWARE */
/*******************************************************************************
*
* FUNCTION: acpi_tb_tables_loaded
*
* PARAMETERS: None
*
* RETURN: TRUE if required ACPI tables are loaded
*
* DESCRIPTION: Determine if the minimum required ACPI tables are present
* (FADT, FACS, DSDT)
*
******************************************************************************/
u8 acpi_tb_tables_loaded(void)
{
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
if (acpi_gbl_root_table_list.current_table_count >= 4) {
return (TRUE);
}
return (FALSE);
}
/*******************************************************************************
*
* FUNCTION: acpi_tb_check_dsdt_header
*
* PARAMETERS: None
*
* RETURN: None
*
* DESCRIPTION: Quick compare to check validity of the DSDT. This will detect
* if the DSDT has been replaced from outside the OS and/or if
* the DSDT header has been corrupted.
*
******************************************************************************/
void acpi_tb_check_dsdt_header(void)
{
/* Compare original length and checksum to current values */
if (acpi_gbl_original_dsdt_header.length != acpi_gbl_DSDT->length ||
acpi_gbl_original_dsdt_header.checksum != acpi_gbl_DSDT->checksum) {
ACPI_BIOS_ERROR((AE_INFO,
"The DSDT has been corrupted or replaced - "
"old, new headers below"));
acpi_tb_print_table_header(0, &acpi_gbl_original_dsdt_header);
acpi_tb_print_table_header(0, acpi_gbl_DSDT);
ACPI_ERROR((AE_INFO,
"Please send DMI info to linux-acpi@vger.kernel.org\n"
"If system does not work as expected, please boot with acpi=copy_dsdt"));
/* Disable further error messages */
acpi_gbl_original_dsdt_header.length = acpi_gbl_DSDT->length;
acpi_gbl_original_dsdt_header.checksum =
acpi_gbl_DSDT->checksum;
}
}
/*******************************************************************************
*
* FUNCTION: acpi_tb_copy_dsdt
*
* PARAMETERS: table_desc - Installed table to copy
*
* RETURN: None
*
* DESCRIPTION: Implements a subsystem option to copy the DSDT to local memory.
* Some very bad BIOSs are known to either corrupt the DSDT or
* install a new, bad DSDT. This copy works around the problem.
*
******************************************************************************/
struct acpi_table_header *acpi_tb_copy_dsdt(u32 table_index)
{
struct acpi_table_header *new_table;
struct acpi_table_desc *table_desc;
table_desc = &acpi_gbl_root_table_list.tables[table_index];
new_table = ACPI_ALLOCATE(table_desc->length);
if (!new_table) {
ACPI_ERROR((AE_INFO, "Could not copy DSDT of length 0x%X",
table_desc->length));
return (NULL);
}
memcpy(new_table, table_desc->pointer, table_desc->length);
ACPICA: Tables: Clean up split INSTALLED/VALIDATED table state logics. This patch is mainly a naming cleanup to clarify hidden logics, no functional changes. acpi_initialize_tables() is used by Linux to install table addresses for early boot steps. During this stage, table addresses are mapped by early_ioremap() mechanism which is different from the runtime IO mappings. Thus it is not safe for ACPICA to keep mapped pointers in struct acpi_table_desc structure during this stage. In order to support this in ACPICA, table states are divided into 1. "INSTALLED" (where struct acpi_table_desc.Pointer is always NULL) and 2. "VALIDATED" (where struct acpi_table_desc.Pointer is always not NULL). During acpi_initialize_tables(), table state are ensured to be "INSTALLED" but not "VALIDATED". This logic is ensured by the original code in very ambigious way. For example, currently acpi_tb_delete_table() is invoked in some place to perform an uninstallation while it is invoked in other place to perform an invalidation. They happen to work just because no one enters the penalty where the 2 behaviours are not equivalent. The naming cleanups are made in this patch: A. For installation and validation: There is code setting struct acpi_table_desc.Pointer first and delete it immediately to keep the descriptor's state as "INSTALLED" during the installation. This patch implements this in more direct way. After applying it, struct acpi_table_desc.Pointer will never be set in acpi_tb_install_table() and acpi_tb_override_table() as they are the only functions invoked during acpi_initialize_tables(). This is achieved by: 1. Rename acpi_tb_verify_table() to acpi_tb_validate_table() to clarify this change. 2. Rename acpi_tb_table_override() to acpi_tb_override_table() to keep nameing consistencies as other APIs (verb. Table). 3. Stops setting struct acpi_table_desc.Pointer in acpi_tb_install_table() and acpi_tb_table_override(). 4. Introduce acpi_tb_acquire_table() to acquire the table pointer that is not maintained in the struct acpi_table_desc of the global root table list and rewrite acpi_tb_validate_table() using this new function to reduce redundancies. 5. Replace the table pointer using the overridden table pointer in acpi_tb_add_table(). As acpi_tb_add_table() is not invoked during early boot stage, tables returned from this functions should be "VALIDATED". As acpi_tb_override_table() is modified by this patch to return a "INSTALLED" but not "VALIDATED" descriptor, to keep acpi_tb_add_table() unchanged, struct acpi_table_desc.Pointer is filled in acpi_tb_add_table(). B. For invalidation and uninstallation: The original code invalidate table by invoking acpi_tb_delete_table() here and there, but actually this function should only be used to uninstall tables. This can work just because its invocations are equivalent to invalidation in some cases. This patch splits acpi_tb_delete_table() into acpi_tb_invalidate_table() and acpi_tb_uninstall_table() and cleans up the hidden logic using the new APIs. This is achieved by: 1. Rename acpi_tb_delete_table() to acpi_tb_uninstall_table() as it is mainly called before resetting struct acpi_table_desc.Address. Thus the table descriptor is in "not INSTALLED" state. This patch enforces this by setting struct acpi_table_desc.Address to NULL in this function. 2. Introduce acpi_tb_invalidate_table() to be the reversal of acpi_tb_validate_table() and invoke it in acpi_tb_uninstall_table(). 3. Introduce acpi_tb_release_table() to release the table pointer that is not maintained in acpi_gbl_root_table_list and rewrite acpi_tb_invalidate_table() using this new function to reduce redundancies. After cleaning up, the maintainability of the internal APIs are also improved: 1. acpi_tb_acquire_table: Acquire struct acpi_table_header according to ACPI_TABLE_ORIGIN_xxx flags. 2. acpi_tb_release_table: Release struct acpi_table_header according to ACPI_TABLE_ORIGIN_xxx flags. 3. acpi_tb_install_table: Make struct acpi_table_desc.Address not NULL according to ACPI_TABLE_ORIGIN_xxx flags. 4. acpi_tb_uninstall_table: Make struct acpi_table_desc.Address NULL according to ACPI_TABLE_ORIGIN_xxx flags. 5. acpi_tb_validate_table: Make struct acpi_table_desc.Pointer not NULL according to ACPI_TABLE_ORIGIN_xxx flags. 6. acpi_tb_invalidate_table: Make struct acpi_table_desc.Pointer NULL according to ACPI_TABLE_ORIGIN_xxx flags. 7. acpi_tb_override_table: Replace struct acpi_table_desc.Address and struct acpi_table_desc.Flags. It only happens in "INSTALLED" state. The patch has been unit tested in acpi_exec by: 1. Initializing; 2. Executing exc_tbl ASLTS tests; 3. Executing "Load" command. So that all original acpi_tb_install_table() and acpi_tb_override_table() invocations are covered. Known Issues: 1. Cleanup acpi_tb_add_table() to Kill Code Redundancies Current implementation in acpi_tb_add_table() is not very clean, further patch can rewrite acpi_tb_add_table() with ordered acpi_tb_install_table(), acpi_tb_override_table() and acpi_tb_validate_table(). It is not done in this patch so that it is easy for the reviewers to understand the changes in this patch. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-04 04:38:42 +00:00
acpi_tb_uninstall_table(table_desc);
acpi_tb_init_table_descriptor(&acpi_gbl_root_table_list.
tables[ACPI_TABLE_INDEX_DSDT],
ACPI_PTR_TO_PHYSADDR(new_table),
ACPI_TABLE_ORIGIN_INTERNAL_VIRTUAL,
new_table);
ACPI_INFO((AE_INFO,
"Forced DSDT copy: length 0x%05X copied locally, original unmapped",
new_table->length));
return (new_table);
}
/*******************************************************************************
*
* FUNCTION: acpi_tb_get_root_table_entry
*
* PARAMETERS: table_entry - Pointer to the RSDT/XSDT table entry
* table_entry_size - sizeof 32 or 64 (RSDT or XSDT)
*
* RETURN: Physical address extracted from the root table
*
* DESCRIPTION: Get one root table entry. Handles 32-bit and 64-bit cases on
* both 32-bit and 64-bit platforms
*
* NOTE: acpi_physical_address is 32-bit on 32-bit platforms, 64-bit on
* 64-bit platforms.
*
******************************************************************************/
static acpi_physical_address
acpi_tb_get_root_table_entry(u8 *table_entry, u32 table_entry_size)
{
u64 address64;
/*
* Get the table physical address (32-bit for RSDT, 64-bit for XSDT):
* Note: Addresses are 32-bit aligned (not 64) in both RSDT and XSDT
*/
if (table_entry_size == ACPI_RSDT_ENTRY_SIZE) {
/*
* 32-bit platform, RSDT: Return 32-bit table entry
* 64-bit platform, RSDT: Expand 32-bit to 64-bit and return
*/
return ((acpi_physical_address)
(*ACPI_CAST_PTR(u32, table_entry)));
} else {
/*
* 32-bit platform, XSDT: Truncate 64-bit to 32-bit and return
* 64-bit platform, XSDT: Move (unaligned) 64-bit to local,
* return 64-bit
*/
ACPI_MOVE_64_TO_64(&address64, table_entry);
#if ACPI_MACHINE_WIDTH == 32
if (address64 > ACPI_UINT32_MAX) {
/* Will truncate 64-bit address to 32 bits, issue warning */
ACPI_BIOS_WARNING((AE_INFO,
"64-bit Physical Address in XSDT is too large (0x%8.8X%8.8X),"
" truncating",
ACPI_FORMAT_UINT64(address64)));
}
#endif
return ((acpi_physical_address) (address64));
}
}
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
/*******************************************************************************
*
* FUNCTION: acpi_tb_parse_root_table
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
*
* PARAMETERS: rsdp - Pointer to the RSDP
*
* RETURN: Status
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
*
* DESCRIPTION: This function is called to parse the Root System Description
* Table (RSDT or XSDT)
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
*
* NOTE: Tables are mapped (not copied) for efficiency. The FACS must
* be mapped and cannot be copied because it contains the actual
* memory location of the ACPI Global Lock.
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
*
******************************************************************************/
acpi_status __init acpi_tb_parse_root_table(acpi_physical_address rsdp_address)
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
{
struct acpi_table_rsdp *rsdp;
u32 table_entry_size;
u32 i;
u32 table_count;
struct acpi_table_header *table;
acpi_physical_address address;
u32 length;
u8 *table_entry;
acpi_status status;
ACPICA: Tables: Fix table checksums verification before installation. The original table handling code does not always verify checksums before installing a table, this is because code to achieve this must be implemented here and there in the redundant code blocks. There are two stages during table initialization: 1. "INSTALLED" after acpi_tb_install_table() and acpi_tb_override_table(), struct acpi_table_desc.Pointer is ensured to be NULL. This can be safely used during OSPM's early boot stage. 2. "VALIDATED" after acpi_tb_validate_table(), struct acpi_table_desc.Pointer is ensured to be not NULL. This must not be used during OSPM's early boot stage. This patch changes acpi_tb_add_table() into an early boot safe API to reduce code redundancies by changing the table state that is returned by this function from "VALIDATED" to "INSTALLED". Then the table verification code can be done in a single place. Originally, the acpi_tb_add_table() can only be used by dynamic table loadings that are executed after early boot stage, it cannot be used by static table loadings that are executed in early boot stage as: 1. The address of the table is a virtual address either maintained by OSPMs who call acpi_load_table() or by ACPICA whenever "Load" or "LoadTable" opcodes are executed, while during early boot stage, physical address of the table should be used for table loading. 2. The API will ensure the state of the loaded table to be "VALIDATED" while during early boot stage, tables maintained by root table list should be kept as "INSTALLED". To achieve this: 1. Rename acpi_tb_install_table() to acpi_tb_install_fixed_table() as it only applies to DSDT/FACS installation. Rename acpi_tb_add_table() to acpi_tb_install_non_fixed_table() as it will be applied to the installation of the rest kinds of tables. 2. Introduce acpi_tb_install_table(), acpi_tb_install_and_override_table to collect redudant code where their invocations actually have slight differences. 1. acpi_tb_install_table() is used to fill an struct acpi_table_desc where the table length is known to the caller. 2. acpi_tb_install_and_override_table() is used to perform necessary overriding before installation. 3. Change a parameter of acpi_tb_install_non_fixed_table() from struct acpi_table_desc to acpi_physical_address to allow it to be invoked by static table loadings. Also cleanup acpi_ex_load_op() and acpi_load_table() to accomodate to the parameter change. 4. Invoke acpi_tb_install_non_fixed_table() for all table loadings other than DSDT/FACS in acpi_tb_parse_root_table() to improve code maintainability (logics are collected in the single function). Also delete useless code from acpi_tb_parse_root_table(). 5. Remove all acpi_tb_validate_table() from acpi_tb_install_non_fixed_table() and acpi_tb_install_fixed_table() so that the table descriptor is kept in the state of "INSTALLED" but not "VALIDATED" after returning from these functions. 6. Introduce temporary struct acpi_table_desc (new_table_desc/old_table_desc) into the functions to indicate a table descriptor that is not maintained by acpi_gbl_root_table_list. Introduce acpi_tb_acquire_temporal_table() and acpi_tb_release_temporal_table() to handle the use cases of such temporal tables. They are only used for verified installation. 7. Introduce acpi_tb_verify_table() to validate table and verify table checksum, also remove table checksum verification from acpi_tb_validate_table(). Invoke acpi_tb_validate_table() in the functions that will convert a table into "LOADED" state or invoke it from acpi_get_table_XXX() APIs. Invoke acpi_tb_verify_table() on temporary struct acpi_table_desc(s) that are going to be "INSTALLED". 8. Change acpi_tb_override_table() logic so that a temporary struct acpi_table_desc will be overridden before installtion, this makes code simpler. After applying the patch, tables are always installed after being overridden and the table checksums are always verified before installation. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> [rjw: Subject] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-04 04:38:57 +00:00
u32 table_index;
ACPI_FUNCTION_TRACE(tb_parse_root_table);
/* Map the entire RSDP and extract the address of the RSDT or XSDT */
rsdp = acpi_os_map_memory(rsdp_address, sizeof(struct acpi_table_rsdp));
if (!rsdp) {
return_ACPI_STATUS(AE_NO_MEMORY);
}
acpi_tb_print_table_header(rsdp_address,
ACPI_CAST_PTR(struct acpi_table_header,
rsdp));
/* Use XSDT if present and not overridden. Otherwise, use RSDT */
if ((rsdp->revision > 1) &&
rsdp->xsdt_physical_address && !acpi_gbl_do_not_use_xsdt) {
/*
* RSDP contains an XSDT (64-bit physical addresses). We must use
* the XSDT if the revision is > 1 and the XSDT pointer is present,
* as per the ACPI specification.
*/
address = (acpi_physical_address) rsdp->xsdt_physical_address;
table_entry_size = ACPI_XSDT_ENTRY_SIZE;
} else {
/* Root table is an RSDT (32-bit physical addresses) */
address = (acpi_physical_address) rsdp->rsdt_physical_address;
table_entry_size = ACPI_RSDT_ENTRY_SIZE;
}
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
/*
* It is not possible to map more than one entry in some environments,
* so unmap the RSDP here before mapping other tables
*/
acpi_os_unmap_memory(rsdp, sizeof(struct acpi_table_rsdp));
/* Map the RSDT/XSDT table header to get the full table length */
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
table = acpi_os_map_memory(address, sizeof(struct acpi_table_header));
if (!table) {
return_ACPI_STATUS(AE_NO_MEMORY);
}
acpi_tb_print_table_header(address, table);
/*
* Validate length of the table, and map entire table.
* Minimum length table must contain at least one entry.
*/
length = table->length;
acpi_os_unmap_memory(table, sizeof(struct acpi_table_header));
if (length < (sizeof(struct acpi_table_header) + table_entry_size)) {
ACPI_BIOS_ERROR((AE_INFO,
"Invalid table length 0x%X in RSDT/XSDT",
length));
return_ACPI_STATUS(AE_INVALID_TABLE_LENGTH);
}
table = acpi_os_map_memory(address, length);
if (!table) {
return_ACPI_STATUS(AE_NO_MEMORY);
}
/* Validate the root table checksum */
status = acpi_tb_verify_checksum(table, length);
if (ACPI_FAILURE(status)) {
acpi_os_unmap_memory(table, length);
return_ACPI_STATUS(status);
}
/* Get the number of entries and pointer to first entry */
table_count = (u32)((table->length - sizeof(struct acpi_table_header)) /
table_entry_size);
table_entry = ACPI_ADD_PTR(u8, table, sizeof(struct acpi_table_header));
/*
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
* First three entries in the table array are reserved for the DSDT
* and 32bit/64bit FACS, which are not actually present in the
* RSDT/XSDT - they come from the FADT
*/
ACPICA: Tables: Enable both 32-bit and 64-bit FACS ACPICA commit f7b86f35416e3d1f71c3d816ff5075ddd33ed486 The following commit is reported to have broken s2ram on some platforms: Commit: 0249ed2444d65d65fc3f3f64f398f1ad0b7e54cd ACPICA: Add option to favor 32-bit FADT addresses. The platform reports 2 FACS tables (which is not allowed by ACPI specification) and the new 32-bit address favor rule forces OSPMs to use the FACS table reported via FADT's X_FIRMWARE_CTRL field. The root cause of the reported bug might be one of the followings: 1. BIOS may favor the 64-bit firmware waking vector address when the version of the FACS is greater than 0 and Linux currently only supports resuming from the real mode, so the 64-bit firmware waking vector has never been set and might be invalid to BIOS while the commit enables higher version FACS. 2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the FADT while the commit doesn't set the firmware waking vector address of the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking vector address of the FACS reported by "X_FIRMWARE_CTRL". This patch excludes the cases that can trigger the bugs caused by the root cause 2. There is no handshaking mechanism can be used by OSPM to tell BIOS which FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still be used by BIOS and the 0 value of the 32-bit firmware waking vector might trigger such failure. This patch tries to favor 32bit FACS address in another way where both the FACS reported by "FIRMWARE_CTRL" and the FACS reported by "X_FIRMWARE_CTRL" are loaded so that further commit can set firmware waking vector in the both tables to ensure we can exclude the cases that trigger the bugs caused by the root cause 2. The exclusion is split into 2 commits as this commit is also useful for dumping more ACPI tables, it won't get reverted when such exclusion is no longer necessary. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/f7b86f35 Cc: 3.14.1+ <stable@vger.kernel.org> # 3.14.1+ Reported-and-tested-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-07-01 06:43:11 +00:00
acpi_gbl_root_table_list.current_table_count = 3;
/* Initialize the root table array from the RSDT/XSDT */
for (i = 0; i < table_count; i++) {
/* Get the table physical address (32-bit for RSDT, 64-bit for XSDT) */
ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT and XSDT. It is reported that there are buggy BIOSes in the world: AMI uses an XSDT compiler for early BIOSes, this compiler will generate XSDT with a NULL entry. The affected BIOS versions are "AMI BIOS F2-F4". Original solution on Linux is to use an alternative heathy root table instead of the ill one. This commit is: Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 Subject: ACPICA: Back port and refine validation of the XSDT root table. This is an example of such XSDT dumped from B85-HD3 (AMI F3 BIOS): [000h 0000 4] Signature : "XSDT" [Extended System Description Table] [004h 0004 4] Table Length : 00000074 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 18 [00Ah 0010 6] Oem ID : "ALASKA" [010h 0016 8] Oem Table ID : "A M I" [018h 0024 4] Oem Revision : 01072009 [01Ch 0028 4] Asl Compiler ID : "AMI " [020h 0032 4] Asl Compiler Revision : 00010013 [024h 0036 8] ACPI Table Address 0 : 00000000BA5F8180 [02Ch 0044 8] ACPI Table Address 1 : 00000000BA5F8290 [034h 0052 8] ACPI Table Address 2 : 00000000BA5F8308 [03Ch 0060 8] ACPI Table Address 3 : 00000000BA5F8848 [044h 0068 8] ACPI Table Address 4 : 00000000BA5F9320 [04Ch 0076 8] ACPI Table Address 5 : 00000000BA5F9360 [054h 0084 8] ACPI Table Address 6 : 00000000BA5F9398 [05Ch 0092 8] ACPI Table Address 7 : 00000000BA5F9708 [064h d100 8] ACPI Table Address 8 : 00000000BA5FC9A8 [06Ch 0108 8] ACPI Table Address 9 : 0000000000000000 But according to the bug report, the XSDT in fact is not broken. In the above XSDT, ACPI Table Address 1-8 contains the same value as RSDT. The differences can only be seen on the following 2 entries: 1. The first entry points to a FADT whose Revision is 5 while the first entry in RSDT points to a FADT whose Revision is 2. The FADT dumped from the address indicated by the first entry of XSDT: FACP @ 0x00000000BA5F8180 0000: 46 41 43 50 0C 01 00 00<05>4B 41 4C 41 53 4B 41 FACP.....KALASKA ... The FADT dumped from the address indicated by the first entry of RSDT: FACP @ 0x00000000BA5ED0F0 0000: 46 41 43 50 84 00 00 00<02>A7 41 4C 41 53 4B 41 FACP......ALASKA ... 2. The last entry is a NULL terminator. According to the test result, the Revision 5 FADT is accessible. Thus the original solution turns out to be a work around that is preventing the higher revision tables to be used for such platforms (they are all x86-64 platforms, and should use XSDT and higher revision FADT). This patch offers a new solution, where a sanity check is performed before installing a table address from XSDT. If the entry is NULL, it is simply discarded. Note that, this patch doesn't remove the original solution, so for Linux kernel, this commit is actually a no-op, but it allows acpidump to be working on such platforms. By doing so, we allow another easy revertable commit to enable this feature so that when that commit is reverted, the useful sanity check will not be affected. Lv Zheng. References: https://bugzilla.kernel.org/show_bug.cgi?id=73911 References: https://bugs.archlinux.org/task/39811 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 02:05:56 +00:00
address =
acpi_tb_get_root_table_entry(table_entry, table_entry_size);
/* Skip NULL entries in RSDT/XSDT */
if (!address) {
goto next_table;
}
status = acpi_tb_install_standard_table(address,
ACPI_TABLE_ORIGIN_INTERNAL_PHYSICAL,
FALSE, TRUE,
&table_index);
ACPICA: Tables: Fix table checksums verification before installation. The original table handling code does not always verify checksums before installing a table, this is because code to achieve this must be implemented here and there in the redundant code blocks. There are two stages during table initialization: 1. "INSTALLED" after acpi_tb_install_table() and acpi_tb_override_table(), struct acpi_table_desc.Pointer is ensured to be NULL. This can be safely used during OSPM's early boot stage. 2. "VALIDATED" after acpi_tb_validate_table(), struct acpi_table_desc.Pointer is ensured to be not NULL. This must not be used during OSPM's early boot stage. This patch changes acpi_tb_add_table() into an early boot safe API to reduce code redundancies by changing the table state that is returned by this function from "VALIDATED" to "INSTALLED". Then the table verification code can be done in a single place. Originally, the acpi_tb_add_table() can only be used by dynamic table loadings that are executed after early boot stage, it cannot be used by static table loadings that are executed in early boot stage as: 1. The address of the table is a virtual address either maintained by OSPMs who call acpi_load_table() or by ACPICA whenever "Load" or "LoadTable" opcodes are executed, while during early boot stage, physical address of the table should be used for table loading. 2. The API will ensure the state of the loaded table to be "VALIDATED" while during early boot stage, tables maintained by root table list should be kept as "INSTALLED". To achieve this: 1. Rename acpi_tb_install_table() to acpi_tb_install_fixed_table() as it only applies to DSDT/FACS installation. Rename acpi_tb_add_table() to acpi_tb_install_non_fixed_table() as it will be applied to the installation of the rest kinds of tables. 2. Introduce acpi_tb_install_table(), acpi_tb_install_and_override_table to collect redudant code where their invocations actually have slight differences. 1. acpi_tb_install_table() is used to fill an struct acpi_table_desc where the table length is known to the caller. 2. acpi_tb_install_and_override_table() is used to perform necessary overriding before installation. 3. Change a parameter of acpi_tb_install_non_fixed_table() from struct acpi_table_desc to acpi_physical_address to allow it to be invoked by static table loadings. Also cleanup acpi_ex_load_op() and acpi_load_table() to accomodate to the parameter change. 4. Invoke acpi_tb_install_non_fixed_table() for all table loadings other than DSDT/FACS in acpi_tb_parse_root_table() to improve code maintainability (logics are collected in the single function). Also delete useless code from acpi_tb_parse_root_table(). 5. Remove all acpi_tb_validate_table() from acpi_tb_install_non_fixed_table() and acpi_tb_install_fixed_table() so that the table descriptor is kept in the state of "INSTALLED" but not "VALIDATED" after returning from these functions. 6. Introduce temporary struct acpi_table_desc (new_table_desc/old_table_desc) into the functions to indicate a table descriptor that is not maintained by acpi_gbl_root_table_list. Introduce acpi_tb_acquire_temporal_table() and acpi_tb_release_temporal_table() to handle the use cases of such temporal tables. They are only used for verified installation. 7. Introduce acpi_tb_verify_table() to validate table and verify table checksum, also remove table checksum verification from acpi_tb_validate_table(). Invoke acpi_tb_validate_table() in the functions that will convert a table into "LOADED" state or invoke it from acpi_get_table_XXX() APIs. Invoke acpi_tb_verify_table() on temporary struct acpi_table_desc(s) that are going to be "INSTALLED". 8. Change acpi_tb_override_table() logic so that a temporary struct acpi_table_desc will be overridden before installtion, this makes code simpler. After applying the patch, tables are always installed after being overridden and the table checksums are always verified before installation. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> [rjw: Subject] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-04 04:38:57 +00:00
if (ACPI_SUCCESS(status) &&
ACPI_COMPARE_NAME(&acpi_gbl_root_table_list.
tables[table_index].signature,
ACPI_SIG_FADT)) {
acpi_tb_parse_fadt(table_index);
}
ACPICA: Tables: Add new mechanism to skip NULL entries in RSDT and XSDT. It is reported that there are buggy BIOSes in the world: AMI uses an XSDT compiler for early BIOSes, this compiler will generate XSDT with a NULL entry. The affected BIOS versions are "AMI BIOS F2-F4". Original solution on Linux is to use an alternative heathy root table instead of the ill one. This commit is: Commit: 671cc68dc61f029d44b43a681356078e02d8dab8 Subject: ACPICA: Back port and refine validation of the XSDT root table. This is an example of such XSDT dumped from B85-HD3 (AMI F3 BIOS): [000h 0000 4] Signature : "XSDT" [Extended System Description Table] [004h 0004 4] Table Length : 00000074 [008h 0008 1] Revision : 01 [009h 0009 1] Checksum : 18 [00Ah 0010 6] Oem ID : "ALASKA" [010h 0016 8] Oem Table ID : "A M I" [018h 0024 4] Oem Revision : 01072009 [01Ch 0028 4] Asl Compiler ID : "AMI " [020h 0032 4] Asl Compiler Revision : 00010013 [024h 0036 8] ACPI Table Address 0 : 00000000BA5F8180 [02Ch 0044 8] ACPI Table Address 1 : 00000000BA5F8290 [034h 0052 8] ACPI Table Address 2 : 00000000BA5F8308 [03Ch 0060 8] ACPI Table Address 3 : 00000000BA5F8848 [044h 0068 8] ACPI Table Address 4 : 00000000BA5F9320 [04Ch 0076 8] ACPI Table Address 5 : 00000000BA5F9360 [054h 0084 8] ACPI Table Address 6 : 00000000BA5F9398 [05Ch 0092 8] ACPI Table Address 7 : 00000000BA5F9708 [064h d100 8] ACPI Table Address 8 : 00000000BA5FC9A8 [06Ch 0108 8] ACPI Table Address 9 : 0000000000000000 But according to the bug report, the XSDT in fact is not broken. In the above XSDT, ACPI Table Address 1-8 contains the same value as RSDT. The differences can only be seen on the following 2 entries: 1. The first entry points to a FADT whose Revision is 5 while the first entry in RSDT points to a FADT whose Revision is 2. The FADT dumped from the address indicated by the first entry of XSDT: FACP @ 0x00000000BA5F8180 0000: 46 41 43 50 0C 01 00 00<05>4B 41 4C 41 53 4B 41 FACP.....KALASKA ... The FADT dumped from the address indicated by the first entry of RSDT: FACP @ 0x00000000BA5ED0F0 0000: 46 41 43 50 84 00 00 00<02>A7 41 4C 41 53 4B 41 FACP......ALASKA ... 2. The last entry is a NULL terminator. According to the test result, the Revision 5 FADT is accessible. Thus the original solution turns out to be a work around that is preventing the higher revision tables to be used for such platforms (they are all x86-64 platforms, and should use XSDT and higher revision FADT). This patch offers a new solution, where a sanity check is performed before installing a table address from XSDT. If the entry is NULL, it is simply discarded. Note that, this patch doesn't remove the original solution, so for Linux kernel, this commit is actually a no-op, but it allows acpidump to be working on such platforms. By doing so, we allow another easy revertable commit to enable this feature so that when that commit is reverted, the useful sanity check will not be affected. Lv Zheng. References: https://bugzilla.kernel.org/show_bug.cgi?id=73911 References: https://bugs.archlinux.org/task/39811 Signed-off-by: Lv Zheng <lv.zheng@intel.com> Reported-and-tested-by: Bruce Chiarelli <mano155@gmail.com> Reported-and-tested-by: Spyros Stathopoulos <spystath@gmail.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 02:05:56 +00:00
next_table:
table_entry += table_entry_size;
}
ACPI: ACPICA 20060331 Implemented header file support for the following additional ACPI tables: ASF!, BOOT, CPEP, DBGP, MCFG, SPCR, SPMI, TCPA, and WDRT. With this support, all current and known ACPI tables are now defined in the ACPICA headers and are available for use by device drivers and other software. Implemented support to allow tables that contain ACPI names with invalid characters to be loaded. Previously, this would cause the table load to fail, but since there are several known cases of such tables on existing machines, this change was made to enable ACPI support for them. Also, this matches the behavior of the Microsoft ACPI implementation. https://bugzilla.novell.com/show_bug.cgi?id=147621 Fixed a couple regressions introduced during the memory optimization in the 20060317 release. The namespace node definition required additional reorganization and an internal datatype that had been changed to 8-bit was restored to 32-bit. (Valery Podrezov) Fixed a problem where a null pointer passed to acpi_ut_delete_generic_state() could be passed through to acpi_os_release_object which is unexpected. Such null pointers are now trapped and ignored, matching the behavior of the previous implementation before the deployment of acpi_os_release_object(). (Valery Podrezov, Fiodor Suietov) Fixed a memory mapping leak during the deletion of a SystemMemory operation region where a cached memory mapping was not deleted. This became a noticeable problem for operation regions that are defined within frequently used control methods. (Dana Meyers) Reorganized the ACPI table header files into two main files: one for the ACPI tables consumed by the ACPICA core, and another for the miscellaneous ACPI tables that are consumed by the drivers and other software. The various FADT definitions were merged into one common section and three different tables (ACPI 1.0, 1.0+, and 2.0) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-03-31 05:00:00 +00:00
acpi_os_unmap_memory(table, length);
return_ACPI_STATUS(AE_OK);
}