linux-sg2042/include/acpi/acpixf.h

961 lines
30 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 */
/******************************************************************************
*
* Name: acpixf.h - External interfaces to the ACPI subsystem
*
* Copyright (C) 2000 - 2018, Intel Corp.
*
*****************************************************************************/
#ifndef __ACXFACE_H__
#define __ACXFACE_H__
/* Current ACPICA subsystem version in YYYYMMDD format */
#define ACPI_CA_VERSION 0x20180313
#include <acpi/acconfig.h>
#include <acpi/actypes.h>
#include <acpi/actbl.h>
#include <acpi/acbuffer.h>
/*****************************************************************************
*
* Macros used for ACPICA globals and configuration
*
****************************************************************************/
/*
* Ensure that global variables are defined and initialized only once.
*
* The use of these macros allows for a single list of globals (here)
* in order to simplify maintenance of the code.
*/
#ifdef DEFINE_ACPI_GLOBALS
#define ACPI_GLOBAL(type,name) \
extern type name; \
type name
ACPICA: Cleanup indentation to reduce differences between Linux and ACPICA. This is a cosmetic patch only. Comparison of the resulting binary showed only line number differences. This patch does not affect the generation of the Linux binary. This patch decreases 210 lines of 20121018 divergence.diff. The ACPICA source codes uses a totally different indentation style from the Linux to be compatible with other users (operating systems or BIOS). Indentation differences are critical to the release automation. There are two causes related to the "indentation" that are affecting the release automation: 1. The ACPICA -> Linux release process is: ACPICA source -- acpisrc - hierarchy - indent -> linuxized ACPICA source -- diff -> linuxized ACPICA patch (x) -- human intervention -> linuxized ACPICA patch (o) Where 'x' means "cannot be directly applied to the Linux" 'o' means "can be directly applied to the Linux" Different "indent" version or "indent" options used in the "indent" step will lead to different divergences. The version of "indent" used for the current release process is: GNU indent 2.2.11 The options of "indent" used for the current release process is: -npro -kr -i8 -ts8 -sob -l80 -ss -ncs 2. Manual indentation prettifying work in the Linux side will also harm the automatically generated linuxized ACPICA patches, making them impossible to apply directly. This patch fixes source code differences caused by the two causes so that the "human intervention" can be reduced in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-12-19 13:37:15 +08:00
#define ACPI_INIT_GLOBAL(type,name,value) \
type name=value
ACPICA: Cleanup indentation to reduce differences between Linux and ACPICA. This is a cosmetic patch only. Comparison of the resulting binary showed only line number differences. This patch does not affect the generation of the Linux binary. This patch decreases 210 lines of 20121018 divergence.diff. The ACPICA source codes uses a totally different indentation style from the Linux to be compatible with other users (operating systems or BIOS). Indentation differences are critical to the release automation. There are two causes related to the "indentation" that are affecting the release automation: 1. The ACPICA -> Linux release process is: ACPICA source -- acpisrc - hierarchy - indent -> linuxized ACPICA source -- diff -> linuxized ACPICA patch (x) -- human intervention -> linuxized ACPICA patch (o) Where 'x' means "cannot be directly applied to the Linux" 'o' means "can be directly applied to the Linux" Different "indent" version or "indent" options used in the "indent" step will lead to different divergences. The version of "indent" used for the current release process is: GNU indent 2.2.11 The options of "indent" used for the current release process is: -npro -kr -i8 -ts8 -sob -l80 -ss -ncs 2. Manual indentation prettifying work in the Linux side will also harm the automatically generated linuxized ACPICA patches, making them impossible to apply directly. This patch fixes source code differences caused by the two causes so that the "human intervention" can be reduced in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-12-19 13:37:15 +08:00
#else
#ifndef ACPI_GLOBAL
#define ACPI_GLOBAL(type,name) \
extern type name
#endif
ACPICA: Cleanup indentation to reduce differences between Linux and ACPICA. This is a cosmetic patch only. Comparison of the resulting binary showed only line number differences. This patch does not affect the generation of the Linux binary. This patch decreases 210 lines of 20121018 divergence.diff. The ACPICA source codes uses a totally different indentation style from the Linux to be compatible with other users (operating systems or BIOS). Indentation differences are critical to the release automation. There are two causes related to the "indentation" that are affecting the release automation: 1. The ACPICA -> Linux release process is: ACPICA source -- acpisrc - hierarchy - indent -> linuxized ACPICA source -- diff -> linuxized ACPICA patch (x) -- human intervention -> linuxized ACPICA patch (o) Where 'x' means "cannot be directly applied to the Linux" 'o' means "can be directly applied to the Linux" Different "indent" version or "indent" options used in the "indent" step will lead to different divergences. The version of "indent" used for the current release process is: GNU indent 2.2.11 The options of "indent" used for the current release process is: -npro -kr -i8 -ts8 -sob -l80 -ss -ncs 2. Manual indentation prettifying work in the Linux side will also harm the automatically generated linuxized ACPICA patches, making them impossible to apply directly. This patch fixes source code differences caused by the two causes so that the "human intervention" can be reduced in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2012-12-19 13:37:15 +08:00
#ifndef ACPI_INIT_GLOBAL
#define ACPI_INIT_GLOBAL(type,name,value) \
extern type name
#endif
#endif
/*
* These macros configure the various ACPICA interfaces. They are
* useful for generating stub inline functions for features that are
* configured out of the current kernel or ACPICA application.
*/
#ifndef ACPI_EXTERNAL_RETURN_STATUS
#define ACPI_EXTERNAL_RETURN_STATUS(prototype) \
prototype;
#endif
#ifndef ACPI_EXTERNAL_RETURN_OK
#define ACPI_EXTERNAL_RETURN_OK(prototype) \
prototype;
#endif
#ifndef ACPI_EXTERNAL_RETURN_VOID
#define ACPI_EXTERNAL_RETURN_VOID(prototype) \
prototype;
#endif
#ifndef ACPI_EXTERNAL_RETURN_UINT32
#define ACPI_EXTERNAL_RETURN_UINT32(prototype) \
prototype;
#endif
#ifndef ACPI_EXTERNAL_RETURN_PTR
#define ACPI_EXTERNAL_RETURN_PTR(prototype) \
prototype;
#endif
/*****************************************************************************
*
* Public globals and runtime configuration options
*
****************************************************************************/
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 10:49:35 +08:00
/*
* Enable "slack mode" of the AML interpreter? Default is FALSE, and the
* interpreter strictly follows the ACPI specification. Setting to TRUE
* allows the interpreter to ignore certain errors and/or bad AML constructs.
*
* Currently, these features are enabled by this flag:
*
* 1) Allow "implicit return" of last value in a control method
* 2) Allow access beyond the end of an operation region
* 3) Allow access to uninitialized locals/args (auto-init to integer 0)
* 4) Allow ANY object type to be a source operand for the Store() operator
* 5) Allow unresolved references (invalid target name) in package objects
* 6) Enable warning messages for behavior that is not ACPI spec compliant
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_enable_interpreter_slack, FALSE);
/*
* Automatically serialize all methods that create named objects? Default
* is TRUE, meaning that all non_serialized methods are scanned once at
* table load time to determine those that create named objects. Methods
* that create named objects are marked Serialized in order to prevent
* possible run-time problems if they are entered by more than one thread.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_auto_serialize_methods, TRUE);
/*
* Create the predefined _OSI method in the namespace? Default is TRUE
* because ACPICA is fully compatible with other ACPI implementations.
* Changing this will revert ACPICA (and machine ASL) to pre-OSI behavior.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_create_osi_method, TRUE);
/*
* Optionally use default values for the ACPI register widths. Set this to
* TRUE to use the defaults, if an FADT contains incorrect widths/lengths.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_use_default_register_widths, TRUE);
ACPICA: Tables: Add mechanism to control early table checksum verification. It is reported that Linux x86 kernel cannot map large tables. The following large SSDT table on such platform fails to pass checksum verification and cannot be installed: ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331) It sounds strange that in the 64-bit virtual memory address space, we cannot map a single ACPI table to do checksum verification. The root cause is: 1. ACPICA doesn't split IO memory mapping and table mapping; 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map mechanism during early boot stage, which is more suitable for only IO mappings. ACPICA originally only mapped table header for signature validation, and this header mapping is required by OSL override mechanism. There was no checksum verification because we could not map the whole table using this OSL. While the following ACPICA commit enforces checksum verification by mapping the whole table during Linux boot stage and it finally triggers this issue on some platforms: Commit: 86dfc6f339886559d80ee0d4bd20fe5ee90450f0 Subject: ACPICA: Tables: Fix table checksums verification before installation. Before doing further cleanups for the OSL table mapping and override implementation, this patch introduces an option for such OSPMs to temporarily discard the checksum verification feature. It then can be re-enabled easily when the ACPICA and the underlying OSL is ready. This patch also deletes a comment around the limitation of mappings because it is not correct. The limitation is not how many times we can map in the early stage, but the OSL mapping facility may not be suitable for mapping the ACPI tables and thus may complain us the size limitation. The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the work around added, it now only applies to the table descriptor that hasn't been installed and cannot be used in other cases. Lv Zheng. Tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-31 08:14:44 +08:00
/*
* Whether or not to validate (map) an entire table to verify
* checksum/duplication in early stage before install. Set this to TRUE to
* allow early table validation before install it to the table manager.
* Note that enabling this option causes errors to happen in some OSPMs
* during early initialization stages. Default behavior is to allow such
* validation.
ACPICA: Tables: Add mechanism to control early table checksum verification. It is reported that Linux x86 kernel cannot map large tables. The following large SSDT table on such platform fails to pass checksum verification and cannot be installed: ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331) It sounds strange that in the 64-bit virtual memory address space, we cannot map a single ACPI table to do checksum verification. The root cause is: 1. ACPICA doesn't split IO memory mapping and table mapping; 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map mechanism during early boot stage, which is more suitable for only IO mappings. ACPICA originally only mapped table header for signature validation, and this header mapping is required by OSL override mechanism. There was no checksum verification because we could not map the whole table using this OSL. While the following ACPICA commit enforces checksum verification by mapping the whole table during Linux boot stage and it finally triggers this issue on some platforms: Commit: 86dfc6f339886559d80ee0d4bd20fe5ee90450f0 Subject: ACPICA: Tables: Fix table checksums verification before installation. Before doing further cleanups for the OSL table mapping and override implementation, this patch introduces an option for such OSPMs to temporarily discard the checksum verification feature. It then can be re-enabled easily when the ACPICA and the underlying OSL is ready. This patch also deletes a comment around the limitation of mappings because it is not correct. The limitation is not how many times we can map in the early stage, but the OSL mapping facility may not be suitable for mapping the ACPI tables and thus may complain us the size limitation. The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the work around added, it now only applies to the table descriptor that hasn't been installed and cannot be used in other cases. Lv Zheng. Tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-31 08:14:44 +08:00
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_enable_table_validation, TRUE);
ACPICA: Tables: Add mechanism to control early table checksum verification. It is reported that Linux x86 kernel cannot map large tables. The following large SSDT table on such platform fails to pass checksum verification and cannot be installed: ACPI: SSDT 0x00000000B9638018 07A0C4 (v02 INTEL S2600CP 00004000 INTL 20100331) It sounds strange that in the 64-bit virtual memory address space, we cannot map a single ACPI table to do checksum verification. The root cause is: 1. ACPICA doesn't split IO memory mapping and table mapping; 2. Linux x86 OSL implements acpi_os_map_memory() using a size limited fix-map mechanism during early boot stage, which is more suitable for only IO mappings. ACPICA originally only mapped table header for signature validation, and this header mapping is required by OSL override mechanism. There was no checksum verification because we could not map the whole table using this OSL. While the following ACPICA commit enforces checksum verification by mapping the whole table during Linux boot stage and it finally triggers this issue on some platforms: Commit: 86dfc6f339886559d80ee0d4bd20fe5ee90450f0 Subject: ACPICA: Tables: Fix table checksums verification before installation. Before doing further cleanups for the OSL table mapping and override implementation, this patch introduces an option for such OSPMs to temporarily discard the checksum verification feature. It then can be re-enabled easily when the ACPICA and the underlying OSL is ready. This patch also deletes a comment around the limitation of mappings because it is not correct. The limitation is not how many times we can map in the early stage, but the OSL mapping facility may not be suitable for mapping the ACPI tables and thus may complain us the size limitation. The acpi_tb_verify_table() is renamed to acpi_tb_verify_temp_table() due to the work around added, it now only applies to the table descriptor that hasn't been installed and cannot be used in other cases. Lv Zheng. Tested-by: Yuanhan Liu <yuanhan.liu@linux.intel.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-05-31 08:14:44 +08:00
/*
* Optionally enable output from the AML Debug Object.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_enable_aml_debug_object, FALSE);
/*
* Optionally copy the entire DSDT to local memory (instead of simply
* mapping it.) There are some BIOSs that corrupt or replace the original
* DSDT, creating the need for this option. Default is FALSE, do not copy
* the DSDT.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_copy_dsdt_locally, FALSE);
/*
* Optionally ignore an XSDT if present and use the RSDT instead.
* Although the ACPI specification requires that an XSDT be used instead
* of the RSDT, the XSDT has been found to be corrupt or ill-formed on
* some machines. Default behavior is to use the XSDT if present.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_do_not_use_xsdt, FALSE);
/*
* Optionally support group module level code.
ACPICA: Integrate package handling with module-level code ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7 This change completes the integration of the recent changes to package object handling with the module-level code support. For acpi_exec, the -ep flag is removed. This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope. DefinitionBlock (...) { Name(OBJ1, 0) if (1) { Device (DEV1) { Name (_HID,0x0) } } Scope (DEV1) { Name (OBJ2) } } The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace. This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1. Bug report links: Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 Link: https://bugzilla.kernel.org/show_bug.cgi?id=196165 Link: https://bugzilla.kernel.org/show_bug.cgi?id=192621 Link: https://bugzilla.kernel.org/show_bug.cgi?id=197207 Link: https://bugzilla.kernel.org/show_bug.cgi?id=198051 Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515 ACPICA repo: Link: https://github.com/acpica/acpica/commit/8faf6fca Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-16 05:09:30 +08:00
* NOTE, this is essentially obsolete and will be removed soon
* (01/2018).
*/
ACPICA: Integrate package handling with module-level code ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7 This change completes the integration of the recent changes to package object handling with the module-level code support. For acpi_exec, the -ep flag is removed. This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope. DefinitionBlock (...) { Name(OBJ1, 0) if (1) { Device (DEV1) { Name (_HID,0x0) } } Scope (DEV1) { Name (OBJ2) } } The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace. This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1. Bug report links: Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 Link: https://bugzilla.kernel.org/show_bug.cgi?id=196165 Link: https://bugzilla.kernel.org/show_bug.cgi?id=192621 Link: https://bugzilla.kernel.org/show_bug.cgi?id=197207 Link: https://bugzilla.kernel.org/show_bug.cgi?id=198051 Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515 ACPICA repo: Link: https://github.com/acpica/acpica/commit/8faf6fca Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-16 05:09:30 +08:00
ACPI_INIT_GLOBAL(u8, acpi_gbl_group_module_level_code, FALSE);
ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar for table loading ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e The MLC (Module Level Code) is an ACPICA terminology describing the AML code out of any control method, its support is an indication of the interpreter behavior during the table loading. The original implementation of MLC in ACPICA had several issues: 1. Out of any control method, besides of the object creating opcodes, only the code blocks wrapped by "If/Else/While" opcodes were supported. 2. The supported MLC code blocks were executed after loading the table rather than being executed right in place. ============================================================ The demo of this order issue is as follows: Name (OBJ1, 1) If (CND1 == 1) { Name (OBJ2, 2) } Name (OBJ3, 3) The original MLC support created OBJ2 after OBJ3's creation. ============================================================ Other than these limitations, MLC support in ACPICA looks correct. And supporting this should be easy/natural for ACPICA, but enabling of this was blocked by some ACPICA internal and OSPM specific initialization order issues we've fixed recently. The wrong support started from the following false bug fixing commit: Commit: 7f0c826a437157d2b19662977e9cf3b472cf24a6 Subject: ACPICA: Add support for module-level executable AML code Commit: 9a884ab64a4d092b4c3bf24fd9a30f7fbd4591e7 Subject: ACPICA: Add additional module-level code support ... We can confirm Windows interpreter behavior via reverse engineering means. It can be proven that not only If/Else/While wrapped code blocks, all opcodes can be executed at the module level, including operation region accesses. And it can be proven that the MLC should be executed right in place, not in such a deferred way executed after loading the table. And the above facts indeed reflect the spec words around ACPI definition block tables (DSDT/SSDT/...), the entire table and the Scope object is defined by the AML specification in BNF style as: AMLCode := def_block_header term_list def_scope := scope_op pkg_length name_string term_list The bodies of the scope opening terms (AMLCode/Scope) are all term_list, thus the table loading should be no difference than the control method evaluations as the body of the Method is also defined by the AML specification as term_list: def_method := method_op pkg_length name_string method_flags term_list The only difference is: after evaluating control method, created named objects may be freed due to no reference, while named objects created by the table loading should only be freed after unloading the table. So this patch follows the spec and the de-facto standard behavior, enables the new grammar (term_list) for the table loading. By doing so, beyond the fixes to the above issues, we can see additional differences comparing to the old grammar based table loading: 1. Originally, beyond the scope opening terms (AMLCode/Scope), If/Else/While wrapped code blocks under the scope creating terms (Device/power_resource/Processor/thermal_zone) are also supported as deferred MLC, which violates the spec defined grammar where object_list is enforced. With MLC support improved as non-deferred, the interpreter parses such scope creating terms as term_list rather object_list like the scope opening terms. After probing the Windows behavior and proving that it also parses these terms as term_list, we submitted an ECR (Engineering Change Request) to the ASWG (ACPI Specification Working Group) to clarify this. The ECR is titled as "ASL Grammar Clarification for Executable AML Opcodes" and has been accepted by the ASWG. The new grammar will appear in ACPI specification 6.2. 2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field arguments are evaluated in a deferred way after loading the table. With MLC support improved, they are also parsed right in place during the table loading. This is also Windows compliant and the only difference is the removal of the debugging messages implemented before acpi_ds_execute_arguments(), see Link # [1] for the details. A previous commit should have ensured that acpi_check_address_range() won't regress. Note that enabling this feature may cause regressions due to long term Linux ACPI support on top of the wrong grammar. So this patch also prepares a global option to be used to roll back to the old grammar during the period between a regression is reported and the regression is root-cause-fixed. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1] Link: https://github.com/acpica/acpica/issues/122 Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://github.com/acpica/acpica/commit/0e24fb67 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Reported-by: Ehsan <dashesy@gmail.com> Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> 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>
2016-09-07 14:06:54 +08:00
/*
* Optionally support module level code by parsing an entire table as
* a method as it is loaded. Default is TRUE.
ACPICA: Integrate package handling with module-level code ACPICA commit 8faf6fca445eb7219963d80543fb802302a7a8c7 This change completes the integration of the recent changes to package object handling with the module-level code support. For acpi_exec, the -ep flag is removed. This change allows table load to behave as if it were a method invocation. Before this, the definition block definition below would have loaded all named objects at the root scope. After loading, it would execute the if statements at the root scope. DefinitionBlock (...) { Name(OBJ1, 0) if (1) { Device (DEV1) { Name (_HID,0x0) } } Scope (DEV1) { Name (OBJ2) } } The above code would load OBJ1 to the namespace, defer the execution of the if statement and attempt to add OBJ2 within the scope of DEV1. Since DEV1 is not in scope, this would incur an AE_NOT_FOUND error. After this error is emitted, the if block is invoked and DEV1 and its _HID is added to the namespace. This commit changes the behavior to execute the if block in place rather than deferring it until all tables are loaded. The new behavior is as follows: insert OBJ1 in the namespace, invoke the if statement and add DEV1 and its _HID to the namespace, add OBJ2 to the scope of DEV1. Bug report links: Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 Link: https://bugzilla.kernel.org/show_bug.cgi?id=196165 Link: https://bugzilla.kernel.org/show_bug.cgi?id=192621 Link: https://bugzilla.kernel.org/show_bug.cgi?id=197207 Link: https://bugzilla.kernel.org/show_bug.cgi?id=198051 Link: https://bugzilla.kernel.org/show_bug.cgi?id=198515 ACPICA repo: Link: https://github.com/acpica/acpica/commit/8faf6fca Tested-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Erik Schmauss <erik.schmauss@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2018-02-16 05:09:30 +08:00
* NOTE, this is essentially obsolete and will be removed soon
* (01/2018).
ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar for table loading ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e The MLC (Module Level Code) is an ACPICA terminology describing the AML code out of any control method, its support is an indication of the interpreter behavior during the table loading. The original implementation of MLC in ACPICA had several issues: 1. Out of any control method, besides of the object creating opcodes, only the code blocks wrapped by "If/Else/While" opcodes were supported. 2. The supported MLC code blocks were executed after loading the table rather than being executed right in place. ============================================================ The demo of this order issue is as follows: Name (OBJ1, 1) If (CND1 == 1) { Name (OBJ2, 2) } Name (OBJ3, 3) The original MLC support created OBJ2 after OBJ3's creation. ============================================================ Other than these limitations, MLC support in ACPICA looks correct. And supporting this should be easy/natural for ACPICA, but enabling of this was blocked by some ACPICA internal and OSPM specific initialization order issues we've fixed recently. The wrong support started from the following false bug fixing commit: Commit: 7f0c826a437157d2b19662977e9cf3b472cf24a6 Subject: ACPICA: Add support for module-level executable AML code Commit: 9a884ab64a4d092b4c3bf24fd9a30f7fbd4591e7 Subject: ACPICA: Add additional module-level code support ... We can confirm Windows interpreter behavior via reverse engineering means. It can be proven that not only If/Else/While wrapped code blocks, all opcodes can be executed at the module level, including operation region accesses. And it can be proven that the MLC should be executed right in place, not in such a deferred way executed after loading the table. And the above facts indeed reflect the spec words around ACPI definition block tables (DSDT/SSDT/...), the entire table and the Scope object is defined by the AML specification in BNF style as: AMLCode := def_block_header term_list def_scope := scope_op pkg_length name_string term_list The bodies of the scope opening terms (AMLCode/Scope) are all term_list, thus the table loading should be no difference than the control method evaluations as the body of the Method is also defined by the AML specification as term_list: def_method := method_op pkg_length name_string method_flags term_list The only difference is: after evaluating control method, created named objects may be freed due to no reference, while named objects created by the table loading should only be freed after unloading the table. So this patch follows the spec and the de-facto standard behavior, enables the new grammar (term_list) for the table loading. By doing so, beyond the fixes to the above issues, we can see additional differences comparing to the old grammar based table loading: 1. Originally, beyond the scope opening terms (AMLCode/Scope), If/Else/While wrapped code blocks under the scope creating terms (Device/power_resource/Processor/thermal_zone) are also supported as deferred MLC, which violates the spec defined grammar where object_list is enforced. With MLC support improved as non-deferred, the interpreter parses such scope creating terms as term_list rather object_list like the scope opening terms. After probing the Windows behavior and proving that it also parses these terms as term_list, we submitted an ECR (Engineering Change Request) to the ASWG (ACPI Specification Working Group) to clarify this. The ECR is titled as "ASL Grammar Clarification for Executable AML Opcodes" and has been accepted by the ASWG. The new grammar will appear in ACPI specification 6.2. 2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field arguments are evaluated in a deferred way after loading the table. With MLC support improved, they are also parsed right in place during the table loading. This is also Windows compliant and the only difference is the removal of the debugging messages implemented before acpi_ds_execute_arguments(), see Link # [1] for the details. A previous commit should have ensured that acpi_check_address_range() won't regress. Note that enabling this feature may cause regressions due to long term Linux ACPI support on top of the wrong grammar. So this patch also prepares a global option to be used to roll back to the old grammar during the period between a regression is reported and the regression is root-cause-fixed. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1] Link: https://github.com/acpica/acpica/issues/122 Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://github.com/acpica/acpica/commit/0e24fb67 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Reported-by: Ehsan <dashesy@gmail.com> Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> 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>
2016-09-07 14:06:54 +08:00
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_execute_tables_as_methods, TRUE);
ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar for table loading ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e The MLC (Module Level Code) is an ACPICA terminology describing the AML code out of any control method, its support is an indication of the interpreter behavior during the table loading. The original implementation of MLC in ACPICA had several issues: 1. Out of any control method, besides of the object creating opcodes, only the code blocks wrapped by "If/Else/While" opcodes were supported. 2. The supported MLC code blocks were executed after loading the table rather than being executed right in place. ============================================================ The demo of this order issue is as follows: Name (OBJ1, 1) If (CND1 == 1) { Name (OBJ2, 2) } Name (OBJ3, 3) The original MLC support created OBJ2 after OBJ3's creation. ============================================================ Other than these limitations, MLC support in ACPICA looks correct. And supporting this should be easy/natural for ACPICA, but enabling of this was blocked by some ACPICA internal and OSPM specific initialization order issues we've fixed recently. The wrong support started from the following false bug fixing commit: Commit: 7f0c826a437157d2b19662977e9cf3b472cf24a6 Subject: ACPICA: Add support for module-level executable AML code Commit: 9a884ab64a4d092b4c3bf24fd9a30f7fbd4591e7 Subject: ACPICA: Add additional module-level code support ... We can confirm Windows interpreter behavior via reverse engineering means. It can be proven that not only If/Else/While wrapped code blocks, all opcodes can be executed at the module level, including operation region accesses. And it can be proven that the MLC should be executed right in place, not in such a deferred way executed after loading the table. And the above facts indeed reflect the spec words around ACPI definition block tables (DSDT/SSDT/...), the entire table and the Scope object is defined by the AML specification in BNF style as: AMLCode := def_block_header term_list def_scope := scope_op pkg_length name_string term_list The bodies of the scope opening terms (AMLCode/Scope) are all term_list, thus the table loading should be no difference than the control method evaluations as the body of the Method is also defined by the AML specification as term_list: def_method := method_op pkg_length name_string method_flags term_list The only difference is: after evaluating control method, created named objects may be freed due to no reference, while named objects created by the table loading should only be freed after unloading the table. So this patch follows the spec and the de-facto standard behavior, enables the new grammar (term_list) for the table loading. By doing so, beyond the fixes to the above issues, we can see additional differences comparing to the old grammar based table loading: 1. Originally, beyond the scope opening terms (AMLCode/Scope), If/Else/While wrapped code blocks under the scope creating terms (Device/power_resource/Processor/thermal_zone) are also supported as deferred MLC, which violates the spec defined grammar where object_list is enforced. With MLC support improved as non-deferred, the interpreter parses such scope creating terms as term_list rather object_list like the scope opening terms. After probing the Windows behavior and proving that it also parses these terms as term_list, we submitted an ECR (Engineering Change Request) to the ASWG (ACPI Specification Working Group) to clarify this. The ECR is titled as "ASL Grammar Clarification for Executable AML Opcodes" and has been accepted by the ASWG. The new grammar will appear in ACPI specification 6.2. 2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field arguments are evaluated in a deferred way after loading the table. With MLC support improved, they are also parsed right in place during the table loading. This is also Windows compliant and the only difference is the removal of the debugging messages implemented before acpi_ds_execute_arguments(), see Link # [1] for the details. A previous commit should have ensured that acpi_check_address_range() won't regress. Note that enabling this feature may cause regressions due to long term Linux ACPI support on top of the wrong grammar. So this patch also prepares a global option to be used to roll back to the old grammar during the period between a regression is reported and the regression is root-cause-fixed. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1] Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1] Link: https://github.com/acpica/acpica/issues/122 Link: https://bugs.acpica.org/show_bug.cgi?id=963 Link: https://github.com/acpica/acpica/commit/0e24fb67 Reported-and-tested-by: Chris Bainbridge <chris.bainbridge@gmail.com> Reported-by: Ehsan <dashesy@gmail.com> Reported-and-tested-by: Dutch Guy <lucht_piloot@gmx.net> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> 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>
2016-09-07 14:06:54 +08:00
/*
* Optionally use 32-bit FADT addresses if and when there is a conflict
* (address mismatch) between the 32-bit and 64-bit versions of the
* address. Although ACPICA adheres to the ACPI specification which
* requires the use of the corresponding 64-bit address if it is non-zero,
* some machines have been found to have a corrupted non-zero 64-bit
* address. Default is FALSE, do not favor the 32-bit addresses.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_use32_bit_fadt_addresses, FALSE);
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 14:43:11 +08:00
/*
* Optionally use 32-bit FACS table addresses.
* It is reported that some platforms fail to resume from system suspending
* if 64-bit FACS table address is selected:
* https://bugzilla.kernel.org/show_bug.cgi?id=74021
* Default is TRUE, favor the 32-bit addresses.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_use32_bit_facs_addresses, TRUE);
/*
* Optionally truncate I/O addresses to 16 bits. Provides compatibility
* with other ACPI implementations. NOTE: During ACPICA initialization,
* this value is set to TRUE if any Windows OSI strings have been
* requested by the BIOS.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_truncate_io_addresses, FALSE);
/*
* Disable runtime checking and repair of values returned by control methods.
* Use only if the repair is causing a problem on a particular machine.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_disable_auto_repair, FALSE);
/*
* Optionally do not install any SSDTs from the RSDT/XSDT during initialization.
* This can be useful for debugging ACPI problems on some machines.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_disable_ssdt_table_install, FALSE);
/*
* Optionally enable runtime namespace override.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_runtime_namespace_override, TRUE);
/*
* We keep track of the latest version of Windows that has been requested by
* the BIOS. ACPI 5.0.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_osi_data, 0);
/*
* ACPI 5.0 introduces the concept of a "reduced hardware platform", meaning
* that the ACPI hardware is no longer required. A flag in the FADT indicates
* a reduced HW machine, and that flag is duplicated here for convenience.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_reduced_hardware, FALSE);
/*
* Maximum timeout for While() loop iterations before forced method abort.
* This mechanism is intended to prevent infinite loops during interpreter
* execution within a host kernel.
*/
ACPI_INIT_GLOBAL(u32, acpi_gbl_max_loop_iterations, ACPI_MAX_LOOP_TIMEOUT);
/*
* Optionally ignore AE_NOT_FOUND errors from named reference package elements
* during DSDT/SSDT table loading. This reduces error "noise" in platforms
* whose firmware is carrying around a bunch of unused package objects that
* refer to non-existent named objects. However, If the AML actually tries to
* use such a package, the unresolved element(s) will be replaced with NULL
* elements.
*/
ACPI_INIT_GLOBAL(u8, acpi_gbl_ignore_package_resolution_errors, FALSE);
/*
* This mechanism is used to trace a specified AML method. The method is
* traced each time it is executed.
*/
ACPI_INIT_GLOBAL(u32, acpi_gbl_trace_flags, 0);
ACPI_INIT_GLOBAL(const char *, acpi_gbl_trace_method_name, NULL);
ACPI_INIT_GLOBAL(u32, acpi_gbl_trace_dbg_level, ACPI_TRACE_LEVEL_DEFAULT);
ACPI_INIT_GLOBAL(u32, acpi_gbl_trace_dbg_layer, ACPI_TRACE_LAYER_DEFAULT);
/*
* Runtime configuration of debug output control masks. We want the debug
* switches statically initialized so they are already set when the debugger
* is entered.
*/
ACPI_INIT_GLOBAL(u32, acpi_dbg_level, ACPI_DEBUG_DEFAULT);
ACPI_INIT_GLOBAL(u32, acpi_dbg_layer, 0);
/* Optionally enable timer output with Debug Object output */
ACPI_INIT_GLOBAL(u8, acpi_gbl_display_debug_timer, FALSE);
ACPICA: Debugger: Convert some mechanisms to OSPM specific The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 10:42:46 +08:00
/*
* Debugger command handshake globals. Host OSes need to access these
* variables to implement their own command handshake mechanism.
*/
#ifdef ACPI_DEBUGGER
ACPI_INIT_GLOBAL(u8, acpi_gbl_method_executing, FALSE);
ACPI_GLOBAL(char, acpi_gbl_db_line_buf[ACPI_DB_LINE_BUFFER_SIZE]);
#endif
/*
* Other miscellaneous globals
*/
ACPI_GLOBAL(struct acpi_table_fadt, acpi_gbl_FADT);
ACPI_GLOBAL(u32, acpi_current_gpe_count);
ACPI_GLOBAL(u8, acpi_gbl_system_awake_and_running);
/*****************************************************************************
*
* ACPICA public interface configuration.
*
* Interfaces that are configured out of the ACPICA build are replaced
* by inlined stubs by default.
*
****************************************************************************/
/*
* Hardware-reduced prototypes (default: Not hardware reduced).
*
* All ACPICA hardware-related interfaces that use these macros will be
* configured out of the ACPICA build if the ACPI_REDUCED_HARDWARE flag
* is set to TRUE.
*
* Note: This static build option for reduced hardware is intended to
* reduce ACPICA code size if desired or necessary. However, even if this
* option is not specified, the runtime behavior of ACPICA is dependent
* on the actual FADT reduced hardware flag (HW_REDUCED_ACPI). If set,
* the flag will enable similar behavior -- ACPICA will not attempt
* to access any ACPI-relate hardware (SCI, GPEs, Fixed Events, etc.)
*/
#if (!ACPI_REDUCED_HARDWARE)
#define ACPI_HW_DEPENDENT_RETURN_STATUS(prototype) \
ACPI_EXTERNAL_RETURN_STATUS(prototype)
#define ACPI_HW_DEPENDENT_RETURN_OK(prototype) \
ACPI_EXTERNAL_RETURN_OK(prototype)
#define ACPI_HW_DEPENDENT_RETURN_VOID(prototype) \
ACPI_EXTERNAL_RETURN_VOID(prototype)
ACPICA: Fix indentation issues for macro invocations. During the automatic translation of the upstream ACPICA source code into Linux kernel source code some extra white spaces are added by the "indent" program at the beginning of each line which is an invocation of a macro and there is no ";" at the end of the line. For this reason, a new mode has been added to the translation scripts to remove the extra spaces inserted before invoking such macros and add an empty line between the invocations of such macros (like the other function declarations). This new mode is executed after executing "indent" during the Linux release process. Consequently, some existing ACPICA source code in the Linux kernel tree needs to be adjusted to allow the new scripts to work correctly. The affected macros and files are: 1. ACPI_HW_DEPENDENT_RETURN (acpixf.h/acdebug.h/acevents.h): This macro is used as a wrapper for hardware dependent APIs to offer a stub when the reduced hardware is configured during compilation. 2. ACPI_EXPORT_SYMBOL (utglobal.c): This macro is used by Linux to export symbols to be found by Linux modules. All such invocations are well formatted except those exported as global variables. This can help to reduce the source code differences between Linux and upstream ACPICA, and also help to automate the release process. No functional or binary generation changes should result from it. Lv Zheng. [rjw: Changelog] 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>
2013-10-29 09:30:22 +08:00
#else
#define ACPI_HW_DEPENDENT_RETURN_STATUS(prototype) \
static ACPI_INLINE prototype {return(AE_NOT_CONFIGURED);}
#define ACPI_HW_DEPENDENT_RETURN_OK(prototype) \
static ACPI_INLINE prototype {return(AE_OK);}
#define ACPI_HW_DEPENDENT_RETURN_VOID(prototype) \
static ACPI_INLINE prototype {return;}
#endif /* !ACPI_REDUCED_HARDWARE */
/*
* Error message prototypes (default: error messages enabled).
*
* All interfaces related to error and warning messages
* will be configured out of the ACPICA build if the
* ACPI_NO_ERROR_MESSAGE flag is defined.
*/
#ifndef ACPI_NO_ERROR_MESSAGES
#define ACPI_MSG_DEPENDENT_RETURN_VOID(prototype) \
prototype;
#else
#define ACPI_MSG_DEPENDENT_RETURN_VOID(prototype) \
static ACPI_INLINE prototype {return;}
#endif /* ACPI_NO_ERROR_MESSAGES */
/*
* Debugging output prototypes (default: no debug output).
*
* All interfaces related to debug output messages
* will be configured out of the ACPICA build unless the
* ACPI_DEBUG_OUTPUT flag is defined.
*/
#ifdef ACPI_DEBUG_OUTPUT
#define ACPI_DBG_DEPENDENT_RETURN_VOID(prototype) \
prototype;
#else
#define ACPI_DBG_DEPENDENT_RETURN_VOID(prototype) \
static ACPI_INLINE prototype {return;}
#endif /* ACPI_DEBUG_OUTPUT */
/*
* Application prototypes
*
* All interfaces used by application will be configured
* out of the ACPICA build unless the ACPI_APPLICATION
* flag is defined.
*/
#ifdef ACPI_APPLICATION
#define ACPI_APP_DEPENDENT_RETURN_VOID(prototype) \
prototype;
#else
#define ACPI_APP_DEPENDENT_RETURN_VOID(prototype) \
static ACPI_INLINE prototype {return;}
#endif /* ACPI_APPLICATION */
/*
* Debugger prototypes
*
* All interfaces used by debugger will be configured
* out of the ACPICA build unless the ACPI_DEBUGGER
* flag is defined.
*/
#ifdef ACPI_DEBUGGER
#define ACPI_DBR_DEPENDENT_RETURN_OK(prototype) \
ACPI_EXTERNAL_RETURN_OK(prototype)
#define ACPI_DBR_DEPENDENT_RETURN_VOID(prototype) \
ACPI_EXTERNAL_RETURN_VOID(prototype)
#else
#define ACPI_DBR_DEPENDENT_RETURN_OK(prototype) \
static ACPI_INLINE prototype {return(AE_OK);}
#define ACPI_DBR_DEPENDENT_RETURN_VOID(prototype) \
static ACPI_INLINE prototype {return;}
#endif /* ACPI_DEBUGGER */
/*****************************************************************************
*
* ACPICA public interface prototypes
*
****************************************************************************/
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 10:49:35 +08:00
/*
* Initialization
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_initialize_tables(struct acpi_table_desc
*initial_storage,
u32 initial_table_count,
u8 allow_resize))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_initialize_subsystem(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_enable_subsystem(u32 flags))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_initialize_objects(u32 flags))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_terminate(void))
[ACPI] ACPICA 20050930 Completed a major overhaul of the Resource Manager code - specifically, optimizations in the area of the AML/internal resource conversion code. The code has been optimized to simplify and eliminate duplicated code, CPU stack use has been decreased by optimizing function parameters and local variables, and naming conventions across the manager have been standardized for clarity and ease of maintenance (this includes function, parameter, variable, and struct/typedef names.) All Resource Manager dispatch and information tables have been moved to a single location for clarity and ease of maintenance. One new file was created, named "rsinfo.c". The ACPI return macros (return_ACPI_STATUS, etc.) have been modified to guarantee that the argument is not evaluated twice, making them less prone to macro side-effects. However, since there exists the possibility of additional stack use if a particular compiler cannot optimize them (such as in the debug generation case), the original macros are optionally available. Note that some invocations of the return_VALUE macro may now cause size mismatch warnings; the return_UINT8 and return_UINT32 macros are provided to eliminate these. (From Randy Dunlap) Implemented a new mechanism to enable debug tracing for individual control methods. A new external interface, acpi_debug_trace(), is provided to enable this mechanism. The intent is to allow the host OS to easily enable and disable tracing for problematic control methods. This interface can be easily exposed to a user or debugger interface if desired. See the file psxface.c for details. acpi_ut_callocate() will now return a valid pointer if a length of zero is specified - a length of one is used and a warning is issued. This matches the behavior of acpi_ut_allocate(). Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2005-10-01 07:03:00 +08:00
/*
* Miscellaneous global interfaces
*/
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_enable(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_disable(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_subsystem_status(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_system_info(struct acpi_buffer
*ret_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_statistics(struct acpi_statistics *stats))
ACPI_EXTERNAL_RETURN_PTR(const char
*acpi_format_exception(acpi_status exception))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_purge_cached_objects(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_interface(acpi_string interface_name))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_remove_interface(acpi_string interface_name))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_update_interfaces(u8 action))
ACPI_EXTERNAL_RETURN_UINT32(u32
acpi_check_address_range(acpi_adr_space_type
space_id,
acpi_physical_address
address, acpi_size length,
u8 warn))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_decode_pld_buffer(u8 *in_buffer,
acpi_size length,
struct acpi_pld_info
**return_buffer))
/*
* ACPI table load/unload interfaces
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_install_table(acpi_physical_address address,
u8 physical))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_load_table(struct acpi_table_header *table))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_unload_parent_table(acpi_handle object))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_load_tables(void))
/*
* ACPI table manipulation interfaces
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_reallocate_root_table(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status ACPI_INIT_FUNCTION
acpi_find_root_pointer(acpi_physical_address
*rsdp_address))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_table_header(acpi_string signature,
u32 instance,
struct acpi_table_header
*out_table_header))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_table(acpi_string signature, u32 instance,
struct acpi_table_header
**out_table))
ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07 This patch back ports Linux acpi_get_table_with_size() and early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences. The 2 APIs are used by Linux as table management APIs for long time, it contains a hidden logic that during the early stage, the mapped tables should be unmapped before the early stage ends. During the early stage, tables are handled by the following sequence: acpi_get_table_with_size(); parse the table early_acpi_os_unmap_memory(); During the late stage, tables are handled by the following sequence: acpi_get_table(); parse the table Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the late stage. The reasoning of introducing acpi_get_table_with_size() is: ACPICA will remember the early mapped pointer in acpi_get_table() and Linux isn't able to prevent ACPICA from using the wrong early mapped pointer during the late stage as there is no API provided from ACPICA to be an inverse of acpi_get_table() to forget the early mapped pointer. But how ACPICA can work with the early/late stage requirement? Inside of ACPICA, tables are ensured to be remained in "INSTALLED" state during the early stage, and they are carefully not transitioned to "VALIDATED" state until the late stage. So the same logic is in fact implemented inside of ACPICA in a different way. The gap is only that the feature is not provided to the OSPMs in an accessible external API style. It then is possible to fix the gap by providing an inverse of acpi_get_table() from ACPICA, so that the two Linux sequences can be combined: acpi_get_table(); parse the table acpi_put_table(); In order to work easier with the current Linux code, acpi_get_table() and acpi_put_table() is implemented in a usage counting based style: 1. When the usage count of the table is increased from 0 to 1, table is mapped and .Pointer is set with the mapping address (VALIDATED); 2. When the usage count of the table is decreased from 1 to 0, .Pointer is unset and the mapping address is unmapped (INVALIDATED). So that we can deploy the new APIs to Linux with minimal effort by just invoking acpi_get_table() in acpi_get_table_with_size() and invoking acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng. Link: https://github.com/acpica/acpica/commit/cac67909 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>
2016-12-14 15:04:25 +08:00
ACPI_EXTERNAL_RETURN_VOID(void acpi_put_table(struct acpi_table_header *table))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07 This patch back ports Linux acpi_get_table_with_size() and early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences. The 2 APIs are used by Linux as table management APIs for long time, it contains a hidden logic that during the early stage, the mapped tables should be unmapped before the early stage ends. During the early stage, tables are handled by the following sequence: acpi_get_table_with_size(); parse the table early_acpi_os_unmap_memory(); During the late stage, tables are handled by the following sequence: acpi_get_table(); parse the table Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the late stage. The reasoning of introducing acpi_get_table_with_size() is: ACPICA will remember the early mapped pointer in acpi_get_table() and Linux isn't able to prevent ACPICA from using the wrong early mapped pointer during the late stage as there is no API provided from ACPICA to be an inverse of acpi_get_table() to forget the early mapped pointer. But how ACPICA can work with the early/late stage requirement? Inside of ACPICA, tables are ensured to be remained in "INSTALLED" state during the early stage, and they are carefully not transitioned to "VALIDATED" state until the late stage. So the same logic is in fact implemented inside of ACPICA in a different way. The gap is only that the feature is not provided to the OSPMs in an accessible external API style. It then is possible to fix the gap by providing an inverse of acpi_get_table() from ACPICA, so that the two Linux sequences can be combined: acpi_get_table(); parse the table acpi_put_table(); In order to work easier with the current Linux code, acpi_get_table() and acpi_put_table() is implemented in a usage counting based style: 1. When the usage count of the table is increased from 0 to 1, table is mapped and .Pointer is set with the mapping address (VALIDATED); 2. When the usage count of the table is decreased from 1 to 0, .Pointer is unset and the mapping address is unmapped (INVALIDATED). So that we can deploy the new APIs to Linux with minimal effort by just invoking acpi_get_table() in acpi_get_table_with_size() and invoking acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng. Link: https://github.com/acpica/acpica/commit/cac67909 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>
2016-12-14 15:04:25 +08:00
acpi_get_table_by_index(u32 table_index,
struct acpi_table_header
**out_table))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_table_handler(acpi_table_handler
handler, void *context))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_remove_table_handler(acpi_table_handler
handler))
/*
* Namespace and name interfaces
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_walk_namespace(acpi_object_type type,
acpi_handle start_object,
u32 max_depth,
acpi_walk_callback
descending_callback,
acpi_walk_callback
ascending_callback,
void *context,
void **return_value))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_devices(const char *HID,
acpi_walk_callback user_function,
void *context,
void **return_value))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_name(acpi_handle object, u32 name_type,
struct acpi_buffer *ret_path_ptr))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_handle(acpi_handle parent,
acpi_string pathname,
acpi_handle *ret_handle))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_attach_data(acpi_handle object,
acpi_object_handler handler,
void *data))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_detach_data(acpi_handle object,
acpi_object_handler handler))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_data(acpi_handle object,
acpi_object_handler handler,
void **data))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_debug_trace(const char *name, u32 debug_level,
u32 debug_layer, u32 flags))
/*
* Object manipulation and enumeration
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_evaluate_object(acpi_handle object,
acpi_string pathname,
struct acpi_object_list
*parameter_objects,
struct acpi_buffer
*return_object_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_evaluate_object_typed(acpi_handle object,
acpi_string pathname,
struct acpi_object_list
*external_params,
struct acpi_buffer
*return_buffer,
acpi_object_type
return_type))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_object_info(acpi_handle object,
struct acpi_device_info
**return_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_install_method(u8 *buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_next_object(acpi_object_type type,
acpi_handle parent,
acpi_handle child,
acpi_handle *out_handle))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_type(acpi_handle object,
acpi_object_type *out_type))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_parent(acpi_handle object,
acpi_handle *out_handle))
/*
* Handler interfaces
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_initialization_handler
(acpi_init_handler handler, u32 function))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_install_sci_handler(acpi_sci_handler
address,
void *context))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_remove_sci_handler(acpi_sci_handler
address))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_install_global_event_handler
(acpi_gbl_event_handler handler,
void *context))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_install_fixed_event_handler(u32
acpi_event,
acpi_event_handler
handler,
void
*context))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_remove_fixed_event_handler(u32 acpi_event,
acpi_event_handler
handler))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_install_gpe_handler(acpi_handle
gpe_device,
u32 gpe_number,
u32 type,
acpi_gpe_handler
address,
void *context))
ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs ACPICA commit 199cad16530a45aea2bec98e528866e20c5927e1 Since whether the GPE should be disabled/enabled/cleared should only be determined by the GPE driver's state machine: 1. GPE should be disabled if the driver wants to switch to the GPE polling mode when a GPE storm condition is indicated and should be enabled if the driver wants to switch back to the GPE interrupt mode when all of the storm conditions are cleared. The conditions should be protected by the driver's specific lock. 2. GPE should be enabled if the driver has accepted more than one request and should be disabled if the driver has completed all of the requests. The request count should be protected by the driver's specific lock. 3. GPE should be cleared either when the driver is about to handle an edge triggered GPE or when the driver has completed to handle a level triggered GPE. The handling code should be protected by the driver's specific lock. Thus the GPE enabling/disabling/clearing operations are likely to be performed with the driver's specific lock held while we currently cannot do this. This is because: 1. We have the acpi_gbl_gpe_lock held before invoking the GPE driver's handler. Driver's specific lock is likely to be held inside of the handler, thus we can see some dead lock issues due to the reversed locking order or recursive locking. In order to solve such dead lock issues, we need to unlock the acpi_gbl_gpe_lock before invoking the handler. BZ 1100. 2. Since GPE disabling/enabling/clearing should be determined by the GPE driver's state machine, we shouldn't perform such operations inside of ACPICA for a GPE handler to mess up the driver's state machine. BZ 1101. Originally this patch includes a logic to flush GPE handlers, it is dropped due to the following reasons: 1. This is a different issue; 2. Linux OSL has fixed this by flushing SCI in acpi_os_wait_events_complete(). We will pick up this topic when the Linux OSL fix turns out to be not sufficient. Note that currently the internal operations and the acpi_gbl_gpe_lock are also used by ACPI_GPE_DISPATCH_METHOD and ACPI_GPE_DISPATCH_NOTIFY. In order not to introduce regressions, we add one ACPI_GPE_DISPATCH_RAW_HANDLER type to be distiguished from ACPI_GPE_DISPATCH_HANDLER. For which the acpi_gbl_gpe_lock is unlocked before invoking the GPE handler and the internal enabling/disabling operations are bypassed to allow drivers to perform them at a proper position using the GPE APIs and ACPI_GPE_DISPATCH_RAW_HANDLER users should invoke acpi_set_gpe() instead of acpi_enable_gpe()/acpi_disable_gpe() to bypass the internal GPE clearing code in acpi_enable_gpe(). Lv Zheng. Known issues: 1. Edge-triggered GPE lost for frequent enablings On some buggy silicon platforms, GPE enable line may not be directly wired to the GPE trigger line. In that case, when GPE enabling is frequently performed for edge-triggered GPEs, GPE status may stay set without being triggered. This patch may maginify this problem as it allows GPE enabling to be parallel performed during the process the GPEs are handled. This is an existing issue, because: 1. For task context: Current ACPI_GPE_DISPATCH_METHOD practices have proven that this isn't a real issue - we can re-enable edge-triggered GPE in a work queue where the GPE status bit might already be set. 2. For IRQ context: This can even happen when the GPE enabling occurs before returning from the GPE handler and after unlocking the GPE lock. Thus currently no code is included to protect this. Link: https://github.com/acpica/acpica/commit/199cad16 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-02-05 16:27:03 +08:00
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_install_gpe_raw_handler(acpi_handle
gpe_device,
u32 gpe_number,
u32 type,
acpi_gpe_handler
address,
void *context))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_remove_gpe_handler(acpi_handle gpe_device,
u32 gpe_number,
acpi_gpe_handler
address))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_notify_handler(acpi_handle device,
u32 handler_type,
acpi_notify_handler
handler,
void *context))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_remove_notify_handler(acpi_handle device,
u32 handler_type,
acpi_notify_handler
handler))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_address_space_handler(acpi_handle
device,
acpi_adr_space_type
space_id,
acpi_adr_space_handler
handler,
acpi_adr_space_setup
setup,
void *context))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_remove_address_space_handler(acpi_handle
device,
acpi_adr_space_type
space_id,
acpi_adr_space_handler
handler))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_exception_handler
(acpi_exception_handler handler))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_install_interface_handler
(acpi_interface_handler handler))
/*
* Global Lock interfaces
*/
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_acquire_global_lock(u16 timeout,
u32 *handle))
ACPICA: Fix indentation issues for macro invocations. During the automatic translation of the upstream ACPICA source code into Linux kernel source code some extra white spaces are added by the "indent" program at the beginning of each line which is an invocation of a macro and there is no ";" at the end of the line. For this reason, a new mode has been added to the translation scripts to remove the extra spaces inserted before invoking such macros and add an empty line between the invocations of such macros (like the other function declarations). This new mode is executed after executing "indent" during the Linux release process. Consequently, some existing ACPICA source code in the Linux kernel tree needs to be adjusted to allow the new scripts to work correctly. The affected macros and files are: 1. ACPI_HW_DEPENDENT_RETURN (acpixf.h/acdebug.h/acevents.h): This macro is used as a wrapper for hardware dependent APIs to offer a stub when the reduced hardware is configured during compilation. 2. ACPI_EXPORT_SYMBOL (utglobal.c): This macro is used by Linux to export symbols to be found by Linux modules. All such invocations are well formatted except those exported as global variables. This can help to reduce the source code differences between Linux and upstream ACPICA, and also help to automate the release process. No functional or binary generation changes should result from it. Lv Zheng. [rjw: Changelog] 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>
2013-10-29 09:30:22 +08:00
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_release_global_lock(u32 handle))
/*
* Interfaces to AML mutex objects
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_acquire_mutex(acpi_handle handle,
acpi_string pathname,
u16 timeout))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_release_mutex(acpi_handle handle,
acpi_string pathname))
/*
* Fixed Event interfaces
*/
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_enable_event(u32 event, u32 flags))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_disable_event(u32 event, u32 flags))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_clear_event(u32 event))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_get_event_status(u32 event,
acpi_event_status
*event_status))
ACPICA: Fix indentation issues for macro invocations. During the automatic translation of the upstream ACPICA source code into Linux kernel source code some extra white spaces are added by the "indent" program at the beginning of each line which is an invocation of a macro and there is no ";" at the end of the line. For this reason, a new mode has been added to the translation scripts to remove the extra spaces inserted before invoking such macros and add an empty line between the invocations of such macros (like the other function declarations). This new mode is executed after executing "indent" during the Linux release process. Consequently, some existing ACPICA source code in the Linux kernel tree needs to be adjusted to allow the new scripts to work correctly. The affected macros and files are: 1. ACPI_HW_DEPENDENT_RETURN (acpixf.h/acdebug.h/acevents.h): This macro is used as a wrapper for hardware dependent APIs to offer a stub when the reduced hardware is configured during compilation. 2. ACPI_EXPORT_SYMBOL (utglobal.c): This macro is used by Linux to export symbols to be found by Linux modules. All such invocations are well formatted except those exported as global variables. This can help to reduce the source code differences between Linux and upstream ACPICA, and also help to automate the release process. No functional or binary generation changes should result from it. Lv Zheng. [rjw: Changelog] 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>
2013-10-29 09:30:22 +08:00
/*
* General Purpose Event (GPE) Interfaces
*/
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_update_all_gpes(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_enable_gpe(acpi_handle gpe_device,
u32 gpe_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_disable_gpe(acpi_handle gpe_device,
u32 gpe_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_clear_gpe(acpi_handle gpe_device,
u32 gpe_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_set_gpe(acpi_handle gpe_device,
u32 gpe_number, u8 action))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_finish_gpe(acpi_handle gpe_device,
u32 gpe_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_mask_gpe(acpi_handle gpe_device,
u32 gpe_number, u8 is_masked))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_mark_gpe_for_wake(acpi_handle gpe_device,
u32 gpe_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_setup_gpe_for_wake(acpi_handle
parent_device,
acpi_handle gpe_device,
u32 gpe_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_set_gpe_wake_mask(acpi_handle gpe_device,
u32 gpe_number,
u8 action))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_get_gpe_status(acpi_handle gpe_device,
u32 gpe_number,
acpi_event_status
*event_status))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_disable_all_gpes(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_enable_all_runtime_gpes(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_enable_all_wakeup_gpes(void))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_get_gpe_device(u32 gpe_index,
acpi_handle *gpe_device))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_install_gpe_block(acpi_handle gpe_device,
struct
acpi_generic_address
*gpe_block_address,
u32 register_count,
u32 interrupt_number))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_remove_gpe_block(acpi_handle gpe_device))
/*
* Resource interfaces
*/
typedef
acpi_status (*acpi_walk_resource_callback) (struct acpi_resource * resource,
void *context);
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_vendor_resource(acpi_handle device,
char *name,
struct acpi_vendor_uuid
*uuid,
struct acpi_buffer
*ret_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_current_resources(acpi_handle device,
struct acpi_buffer
*ret_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_possible_resources(acpi_handle device,
struct acpi_buffer
*ret_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_event_resources(acpi_handle device_handle,
struct acpi_buffer
*ret_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_walk_resource_buffer(struct acpi_buffer
*buffer,
acpi_walk_resource_callback
user_function,
void *context))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_walk_resources(acpi_handle device, char *name,
acpi_walk_resource_callback
user_function, void *context))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_set_current_resources(acpi_handle device,
struct acpi_buffer
*in_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_irq_routing_table(acpi_handle device,
struct acpi_buffer
*ret_buffer))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_resource_to_address64(struct acpi_resource
*resource,
struct
acpi_resource_address64
*out))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_buffer_to_resource(u8 *aml_buffer,
u16 aml_buffer_length,
struct acpi_resource
**resource_ptr))
/*
* Hardware (ACPI device) interfaces
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_reset(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_read(u64 *value,
struct acpi_generic_address *reg))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_write(u64 value,
struct acpi_generic_address *reg))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_read_bit_register(u32 register_id,
u32 *return_value))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_write_bit_register(u32 register_id,
u32 value))
/*
* Sleep/Wake interfaces
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_sleep_type_data(u8 sleep_state,
u8 *slp_typ_a,
u8 *slp_typ_b))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_enter_sleep_state_prep(u8 sleep_state))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_enter_sleep_state(u8 sleep_state))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_enter_sleep_state_s4bios(void))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_leave_sleep_state_prep(u8 sleep_state))
ACPI_EXTERNAL_RETURN_STATUS(acpi_status acpi_leave_sleep_state(u8 sleep_state))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_set_firmware_waking_vector
ACPICA: Hardware: Enable 64-bit firmware waking vector for selected FACS ACPICA commit 7aa598d711644ab0de5f70ad88f1e2de253115e4 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 1. ACPI specification says: A. 32-bit FACS address (FIRMWARE_CTRL field in FADT): Physical memory address of the FACS, where OSPM and firmware exchange control information. If the X_FIRMWARE_CTRL field contains a non zero value then this field must be zero. A zero value indicates that no FACS is specified by this field. B. 64-bit FACS address (X_FIRMWARE_CTRL field in FADT): 64bit physical memory address of the FACS. This field is used when the physical address of the FACS is above 4GB. If the FIRMWARE_CTRL field contains a non zero value then this field must be zero. A zero value indicates that no FACS is specified by this field. Thus the 32bit and 64bit firmware waking vector should indicate completely different resuming environment - real mode (1MB addressable) and non real mode (4GB+ addressable) and currently Linux only supports resuming from real mode. This patch enables 64-bit firmware waking vector for selected FACS via new acpi_set_firmware_waking_vectors() API so that it's up to OSPMs to determine which resuming mode should be used by BIOS and ACPICA changes won't trigger the bugs caused by the root cause 1. Lv Zheng. Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021 Link: https://github.com/acpica/acpica/commit/7aa598d7 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 14:43:04 +08:00
(acpi_physical_address physical_address,
acpi_physical_address physical_address64))
/*
* ACPI Timer interfaces
*/
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_get_timer_resolution(u32 *resolution))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status acpi_get_timer(u32 *ticks))
ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
acpi_get_timer_duration(u32 start_ticks,
u32 end_ticks,
u32 *time_elapsed))
/*
* Error/Warning output
*/
ACPI_MSG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(3)
void ACPI_INTERNAL_VAR_XFACE
acpi_error(const char *module_name,
u32 line_number,
const char *format, ...))
ACPI_MSG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(4)
void ACPI_INTERNAL_VAR_XFACE
acpi_exception(const char *module_name,
u32 line_number,
acpi_status status,
const char *format, ...))
ACPI_MSG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(3)
void ACPI_INTERNAL_VAR_XFACE
acpi_warning(const char *module_name,
u32 line_number,
const char *format, ...))
ACPI_MSG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(1)
void ACPI_INTERNAL_VAR_XFACE
acpi_info(const char *format, ...))
ACPI_MSG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(3)
void ACPI_INTERNAL_VAR_XFACE
acpi_bios_error(const char *module_name,
u32 line_number,
const char *format, ...))
ACPI_MSG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(3)
void ACPI_INTERNAL_VAR_XFACE
acpi_bios_warning(const char *module_name,
u32 line_number,
const char *format, ...))
/*
* Debug output
*/
ACPI_DBG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(6)
void ACPI_INTERNAL_VAR_XFACE
acpi_debug_print(u32 requested_debug_level,
u32 line_number,
const char *function_name,
const char *module_name,
u32 component_id,
const char *format, ...))
ACPI_DBG_DEPENDENT_RETURN_VOID(ACPI_PRINTF_LIKE(6)
void ACPI_INTERNAL_VAR_XFACE
acpi_debug_print_raw(u32 requested_debug_level,
u32 line_number,
const char *function_name,
const char *module_name,
u32 component_id,
const char *format, ...))
ACPI_DBG_DEPENDENT_RETURN_VOID(void
acpi_trace_point(acpi_trace_event_type type,
u8 begin,
u8 *aml, char *pathname))
acpi_status acpi_initialize_debugger(void);
void acpi_terminate_debugger(void);
/*
* Divergences
*/
ACPI_EXTERNAL_RETURN_STATUS(acpi_status
acpi_get_data_full(acpi_handle object,
acpi_object_handler handler,
void **data,
void (*callback)(void *)))
ACPICA: Debugger: Convert some mechanisms to OSPM specific The following mechanisms are OSPM specific: 1. Redirect output destination to console: no file redirection will be needed by an in-kernel debugger, there is even no file can be accessed when the debugger is running in the kernel mode. 2. Output command prompts: programs other than acpiexec can have different prompt characters and the prompt characters may be implemented as a special character sequence to form a char device IO protocol. 3. Command ready/complete handshake: OSPM debugger may wait more conditions to implement OSPM specific semantics (for example, FIFO full/empty conditions for O_NONBLOCK or IO open/close conditions). Leaving such OSPM specific stuffs in the ACPICA debugger core blocks Linux debugger IO driver implementation. Several new OSL APIs are provided by this patch: 1. acpi_os_initialize_command_signals: initialize command handshake mechanism or any other OSPM specific stuffs. 2. acpi_os_terminate_command_signals: reversal of acpi_os_initialize_command_signals. 3. acpi_os_wait_command_ready: putting debugger task into wait state when a command is not ready. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wait_event() or wait_for_multiple_object() may be used to implement this API. 4. acpi_os_notify_command_complete: putting user task into running state when a command has been completed. OSPMs can terminate command loop by returning AE_CTRL_TERMINATE from this API. Normally, wake_up() or set_event() may be used to implement this API. This patch also converts current command signaling implementation into a generic debugger layer (osgendbg.c) to be used by the existing OSPMs or acpiexec, in return, Linux can have chance to implement its own command handshake mechanism. This patch also implements acpiexec batch mode in a multi-threading mode comaptible style as a demo (this can be confirmed by configuring acpiexec into DEBUGGER_MULTI_THREADED mode where the batch mode is still working). Lv Zheng. Note that the OSPM specific command handshake mechanism is required by Linux kernel because: 1. Linux kernel trends to use wait queue to synchronize two threads, using mutexes to achieve that will cause false "dead lock" warnings. 2. The command handshake mechanism implemented by ACPICA is implemented in this way because of a design issue in debugger IO streaming. Debugger IO outputs are simply cached using a giant buffer, this should be tuned by Linux in the future. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-12-03 10:42:46 +08:00
void acpi_run_debugger(char *batch_buffer);
ACPICA: Debugger: Add thread ID support so that single step mode can only apply to the debugger thread When the debugger is running in the kernel mode, acpi_db_single_step() may also be invoked by the kernel runtime code path but the single stepping command prompt may be erronously logged as the kernel logs and runtime code path cannot proceed. This patch fixes this issue by adding acpi_gbl_db_thread_id for the debugger thread and preventing acpi_db_single_step() to be invoked from other threads. It is not suitable to add acpi_thread_id parameter for acpi_os_execute() as the function may be implemented as work queue on some hosts. So it is better to let the hosts invoke acpi_set_debugger_thread_id(). Currently acpiexec is not configured as DEBUGGER_MULTI_THREADED, but we can do this. When we do this, it is better to invoke acpi_set_debugger_thread_id() in acpi_os_execute() when the execution type is OSL_DEBUGGER_MAIN_THREAD. The support should look like: create_thread(&tid); if (type == OSL_DEBUGGER_MAIN_THREAD) acpi_set_debugger_thread_id(tid); resume_thread(tid); Similarly, semop() may be used for pthread implementation. But this patch simply skips debugger thread ID check for application instead of introducing such complications as there is no need to skip acpi_db_single_step() for an application debugger - acpiexec. Note that the debugger thread ID can also be used by acpi_os_printf() to filter out debugger output. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-10-19 10:25:50 +08:00
void acpi_set_debugger_thread_id(acpi_thread_id thread_id);
#endif /* __ACXFACE_H__ */