linux/include/acpi/actypes.h

1296 lines
41 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 */
/******************************************************************************
*
* Name: actypes.h - Common data types for the entire ACPI subsystem
*
* Copyright (C) 2000 - 2021, Intel Corp.
*
*****************************************************************************/
#ifndef __ACTYPES_H__
#define __ACTYPES_H__
/* acpisrc:struct_defs -- for acpisrc conversion */
/*
* ACPI_MACHINE_WIDTH must be specified in an OS- or compiler-dependent
* header and must be either 32 or 64. 16-bit ACPICA is no longer
* supported, as of 12/2006.
*/
#ifndef ACPI_MACHINE_WIDTH
#error ACPI_MACHINE_WIDTH not defined
#endif
/*
* Data type ranges
* Note: These macros are designed to be compiler independent as well as
* working around problems that some 32-bit compilers have with 64-bit
* constants.
*/
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#define ACPI_UINT8_MAX (u8) (~((u8) 0)) /* 0xFF */
#define ACPI_UINT16_MAX (u16)(~((u16) 0)) /* 0xFFFF */
#define ACPI_UINT32_MAX (u32)(~((u32) 0)) /* 0xFFFFFFFF */
#define ACPI_UINT64_MAX (u64)(~((u64) 0)) /* 0xFFFFFFFFFFFFFFFF */
#define ACPI_ASCII_MAX 0x7F
/*
* Architecture-specific ACPICA Subsystem Data Types
*
* The goal of these types is to provide source code portability across
* 16-bit, 32-bit, and 64-bit targets.
*
* 1) The following types are of fixed size for all targets (16/32/64):
*
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
* u8 Logical boolean
*
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
* u8 8-bit (1 byte) unsigned value
* u16 16-bit (2 byte) unsigned value
* u32 32-bit (4 byte) unsigned value
* u64 64-bit (8 byte) unsigned value
*
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
* s16 16-bit (2 byte) signed value
* s32 32-bit (4 byte) signed value
* s64 64-bit (8 byte) signed value
*
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
* COMPILER_DEPENDENT_UINT64/s64 - These types are defined in the
* compiler-dependent header(s) and were introduced because there is no
* common 64-bit integer type across the various compilation models, as
* shown in the table below.
*
* Datatype LP64 ILP64 LLP64 ILP32 LP32 16bit
* char 8 8 8 8 8 8
* short 16 16 16 16 16 16
* _int32 32
* int 32 64 32 32 16 16
* long 64 64 32 32 32 32
* long long 64 64
* pointer 64 64 64 32 32 32
*
* Note: ILP64 and LP32 are currently not supported.
*
*
* 2) These types represent the native word size of the target mode of the
* processor, and may be 16-bit, 32-bit, or 64-bit as required. They are
* usually used for memory allocation, efficient loop counters, and array
* indexes. The types are similar to the size_t type in the C library and
* are required because there is no C type that consistently represents the
* native data width. acpi_size is needed because there is no guarantee
* that a kernel-level C library is present.
*
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
* acpi_size 16/32/64-bit unsigned value
* acpi_native_int 16/32/64-bit signed value
*/
/*******************************************************************************
*
* Common types for all compilers, all targets
*
******************************************************************************/
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#ifndef ACPI_USE_SYSTEM_INTTYPES
typedef unsigned char u8;
typedef unsigned short u16;
ACPICA: Utilities: Add formatted printing APIs This patch introduces formatted printing APIs to handle ACPICA specific formatted print requirements. Currently only specific OSPMs will use this customized printing support, Linux kernel doesn't use these APIs at this time. It will be enabled for Linux kernel resident ACPICA after being well tested. So currently this patch is a no-op. The specific formatted printing APIs are useful to ACPICA as: 1. Some portable applications do not link standard C library, so they cannot use standard formatted print APIs directly. 2. Platform specific printing format may differ and thus not portable, for example, u64 is %ull for Linux kernel and is %uI64 for some MSVC versions. 3. Platform specific printing format may conflict with ACPICA's usages while it is not possible for ACPICA developers to test their code for all platforms. For example, developers may generate %pRxxx while Linux kernel treats %pR as structured resource printing and decodes variable argument as a "struct resource" pointer. This patch solves above issues by introducing the new APIs. Note that users of such APIs are not introduced in this patch. Users of acpi_os_file_vprintf()/acpi_ut_file_printf() need to invoke acpi_os_initialize(), this should be taken care by the further patches where such users are introduced. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-07-08 10:07:00 +08:00
typedef short s16;
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
typedef COMPILER_DEPENDENT_UINT64 u64;
typedef COMPILER_DEPENDENT_INT64 s64;
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#endif /* ACPI_USE_SYSTEM_INTTYPES */
/*
* Value returned by acpi_os_get_thread_id. There is no standard "thread_id"
* across operating systems or even the various UNIX systems. Since ACPICA
* only needs the thread ID as a unique thread identifier, we use a u64
* as the only common data type - it will accommodate any type of pointer or
* any type of integer. It is up to the host-dependent OSL to cast the
* native thread ID type to a u64 (in acpi_os_get_thread_id).
*/
#define acpi_thread_id u64
/*******************************************************************************
*
* Types specific to 64-bit targets
*
******************************************************************************/
#if ACPI_MACHINE_WIDTH == 64
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#ifndef ACPI_USE_SYSTEM_INTTYPES
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
typedef unsigned int u32;
typedef int s32;
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#endif /* ACPI_USE_SYSTEM_INTTYPES */
typedef s64 acpi_native_int;
typedef u64 acpi_size;
typedef u64 acpi_io_address;
typedef u64 acpi_physical_address;
#define ACPI_MAX_PTR ACPI_UINT64_MAX
#define ACPI_SIZE_MAX ACPI_UINT64_MAX
#define ACPI_USE_NATIVE_DIVIDE /* Has native 64-bit integer support */
#define ACPI_USE_NATIVE_MATH64 /* Has native 64-bit integer support */
/*
* In the case of the Itanium Processor Family (IPF), the hardware does not
* support misaligned memory transfers. Set the MISALIGNMENT_NOT_SUPPORTED
* flag to indicate that special precautions must be taken to avoid alignment
* faults. (IA64 or ia64 is currently used by existing compilers to indicate
* IPF.)
*
* Note: EM64T and other X86-64 processors support misaligned transfers,
* so there is no need to define this flag.
*/
#if defined (__IA64__) || defined (__ia64__)
#define ACPI_MISALIGNMENT_NOT_SUPPORTED
#endif
/*******************************************************************************
*
* Types specific to 32-bit targets
*
******************************************************************************/
#elif ACPI_MACHINE_WIDTH == 32
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#ifndef ACPI_USE_SYSTEM_INTTYPES
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
typedef unsigned int u32;
typedef int s32;
ACPICA: acpidump: Remove integer types translation protection. Remove translation protection for applications as Linux tools folder will start to use such types. In Linux kernel source tree, after removing this translation protection, the u8/u16/u32/u64/s32/s64 typedefs are exposed for both __KERNEL__ builds and !__KERNEL__ builds (tools/power/acpi) and the original definitions of ACPI_UINT8/16/32/64_MAX are changed. For !__KERNEL__ builds, this kind of defintions should already been tested by the distribution vendors that are distributing binary ACPICA package and we've achieved the successful built/run test result in the kernel source tree. For __KERNEL__ builds, there are 2 things affected: 1. u8/u16/u32/u64/s32/s64 type definitions: Since Linux has already type defined u8/u16/u32/u64/s32/s64 in include/uapi/asm-generic/int-ll64.h for __KERNEL__. In order not to introduce build regressions where the 2 typedefs are differed, ACPI_USE_SYSTEM_INTTYPES is introduced to mask out ACPICA's typedefs. It must be defined for Linux __KERNEL__ builds. 2. ACPI_UINT8/16/32/64_MAX definitions: Before applying this change: ACPI_UINT8_MAX: sizeof (UINT8) UINT8: unsigned char ACPI_UINT16_MAX: sizeof (UINT16) UINT16: unsigned short ACPI_UINT32_MAX: sizeof (UINT32) INT32: int UINT32: unsigned int ACPI_UINT64_MAX: sizeof (UINT64) INT64: COMPILER_DEPENDENT_INT64 COMPILER_DEPENDENT_INT64: signed long (IA64) or signed long long (IA32) UINT64: COMPILER_DEPENDENT_UINT64 COMPILER_DEPENDENT_UINT64: unsigned long (IA64) or unsigned long long (IA32) After applying this change: ACPI_UINT8_MAX: sizeof (u8) u8: unsigned char UINT8: (removed from actypes.h) ACPI_UINT16_MAX: sizeof (u16) u16: unsigned short UINT16: (removed from actypes.h) ACPI_UINT32_MAX: sizeof (u32) INT32/UINT32: (removed from actypes.h) s32: signed int u32: unsigned int ACPI_UINT64_MAX: sizeof (u64) INT64/UINT64: (removed from actypes.h) u64: unsigned long long s64: signed long long COMPILER_DEPENDENT_INT64: signed long (IA64) (not used any more) signed long long (IA32) (not used any more) COMPILER_DEPENDENT_UINT64: unsigned long (IA64) (not used any more) unsigned long long (IA32) (not used any more) All definitions are equal except ACPI_UINT64_MAX for CONFIG_IA64. It is changed from sizeof(unsigned long) to sizeof(unsigned long long). By investigation, 64bit Linux kernel build is LP64 compliant, i.e., sizeof(long) and (pointer) are 64. As sizeof(unsigned long) equals to sizeof(unsigned long long) on IA64 platform where CONFIG_64BIT cannot be disabled, this change actually will not affect the value of ACPI_UINT64_MAX on IA64 platforms. This patch is necessary for the ACPICA's acpidump tool to build correctly. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-02-11 10:51:43 +08:00
#endif /* ACPI_USE_SYSTEM_INTTYPES */
typedef s32 acpi_native_int;
typedef u32 acpi_size;
ACPICA: Utilities: split IO address types from data type models. ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 Reported-and-tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Reported-and-tested-by: Sial Nije <sialnije@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-13 11:48:58 +08:00
#ifdef ACPI_32BIT_PHYSICAL_ADDRESS
/*
* OSPMs can define this to shrink the size of the structures for 32-bit
* none PAE environment. ASL compiler may always define this to generate
* 32-bit OSPM compliant tables.
*/
typedef u32 acpi_io_address;
typedef u32 acpi_physical_address;
ACPICA: Utilities: split IO address types from data type models. ACPICA commit aacf863cfffd46338e268b7415f7435cae93b451 It is reported that on a physically 64-bit addressed machine, 32-bit kernel can trigger crashes in accessing the memory regions that are beyond the 32-bit boundary. The region field's start address should still be 32-bit compliant, but after a calculation (adding some offsets), it may exceed the 32-bit boundary. This case is rare and buggy, but there are real BIOSes leaked with such issues (see References below). This patch fixes this gap by always defining IO addresses as 64-bit, and allows OSPMs to optimize it for a real 32-bit machine to reduce the size of the internal objects. Internal acpi_physical_address usages in the structures that can be fixed by this change include: 1. struct acpi_object_region: acpi_physical_address address; 2. struct acpi_address_range: acpi_physical_address start_address; acpi_physical_address end_address; 3. struct acpi_mem_space_context; acpi_physical_address address; 4. struct acpi_table_desc acpi_physical_address address; See known issues 1 for other usages. Note that acpi_io_address which is used for ACPI_PROCESSOR may also suffer from same problem, so this patch changes it accordingly. For iasl, it will enforce acpi_physical_address as 32-bit to generate 32-bit OSPM compatible tables on 32-bit platforms, we need to define ACPI_32BIT_PHYSICAL_ADDRESS for it in acenv.h. Known issues: 1. Cleanup of mapped virtual address In struct acpi_mem_space_context, acpi_physical_address is used as a virtual address: acpi_physical_address mapped_physical_address; It is better to introduce acpi_virtual_address or use acpi_size instead. This patch doesn't make such a change. Because this should be done along with a change to acpi_os_map_memory()/acpi_os_unmap_memory(). There should be no functional problem to leave this unchanged except that only this structure is enlarged unexpectedly. Link: https://github.com/acpica/acpica/commit/aacf863c Reference: https://bugzilla.kernel.org/show_bug.cgi?id=87971 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=79501 Reported-and-tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Reported-and-tested-by: Sial Nije <sialnije@gmail.com> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-04-13 11:48:58 +08:00
#else /* ACPI_32BIT_PHYSICAL_ADDRESS */
/*
* It is reported that, after some calculations, the physical addresses can
* wrap over the 32-bit boundary on 32-bit PAE environment.
* https://bugzilla.kernel.org/show_bug.cgi?id=87971
*/
typedef u64 acpi_io_address;
typedef u64 acpi_physical_address;
#endif /* ACPI_32BIT_PHYSICAL_ADDRESS */
#define ACPI_MAX_PTR ACPI_UINT32_MAX
#define ACPI_SIZE_MAX ACPI_UINT32_MAX
#else
/* ACPI_MACHINE_WIDTH must be either 64 or 32 */
#error unknown ACPI_MACHINE_WIDTH
#endif
/*******************************************************************************
*
* OS-dependent types
*
[ACPI] ACPICA 20060127 Implemented support in the Resource Manager to allow unresolved namestring references within resource package objects for the _PRT method. This support is in addition to the previously implemented unresolved reference support within the AML parser. If the interpreter slack mode is enabled (true on Linux unless acpi=strict), these unresolved references will be passed through to the caller as a NULL package entry. http://bugzilla.kernel.org/show_bug.cgi?id=5741 Implemented and deployed new macros and functions for error and warning messages across the subsystem. These macros are simpler and generate less code than their predecessors. The new macros ACPI_ERROR, ACPI_EXCEPTION, ACPI_WARNING, and ACPI_INFO replace the ACPI_REPORT_* macros. Implemented the acpi_cpu_flags type to simplify host OS integration of the Acquire/Release Lock OSL interfaces. Suggested by Steven Rostedt and Andrew Morton. Fixed a problem where Alias ASL operators are sometimes not correctly resolved. causing AE_AML_INTERNAL http://bugzilla.kernel.org/show_bug.cgi?id=5189 http://bugzilla.kernel.org/show_bug.cgi?id=5674 Fixed several problems with the implementation of the ConcatenateResTemplate ASL operator. As per the ACPI specification, zero length buffers are now treated as a single EndTag. One-length buffers always cause a fatal exception. Non-zero length buffers that do not end with a full 2-byte EndTag cause a fatal exception. Fixed a possible structure overwrite in the AcpiGetObjectInfo external interface. (With assistance from Thomas Renninger) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-01-28 05:43:00 +08:00
* If the defaults below are not appropriate for the host system, they can
* be defined in the OS-specific header, and this will take precedence.
[ACPI] ACPICA 20060127 Implemented support in the Resource Manager to allow unresolved namestring references within resource package objects for the _PRT method. This support is in addition to the previously implemented unresolved reference support within the AML parser. If the interpreter slack mode is enabled (true on Linux unless acpi=strict), these unresolved references will be passed through to the caller as a NULL package entry. http://bugzilla.kernel.org/show_bug.cgi?id=5741 Implemented and deployed new macros and functions for error and warning messages across the subsystem. These macros are simpler and generate less code than their predecessors. The new macros ACPI_ERROR, ACPI_EXCEPTION, ACPI_WARNING, and ACPI_INFO replace the ACPI_REPORT_* macros. Implemented the acpi_cpu_flags type to simplify host OS integration of the Acquire/Release Lock OSL interfaces. Suggested by Steven Rostedt and Andrew Morton. Fixed a problem where Alias ASL operators are sometimes not correctly resolved. causing AE_AML_INTERNAL http://bugzilla.kernel.org/show_bug.cgi?id=5189 http://bugzilla.kernel.org/show_bug.cgi?id=5674 Fixed several problems with the implementation of the ConcatenateResTemplate ASL operator. As per the ACPI specification, zero length buffers are now treated as a single EndTag. One-length buffers always cause a fatal exception. Non-zero length buffers that do not end with a full 2-byte EndTag cause a fatal exception. Fixed a possible structure overwrite in the AcpiGetObjectInfo external interface. (With assistance from Thomas Renninger) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-01-28 05:43:00 +08:00
*
******************************************************************************/
ACPI: ACPICA 20060623 Implemented a new acpi_spinlock type for the OSL lock interfaces. This allows the type to be customized to the host OS for improved efficiency (since a spinlock is usually a very small object.) Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 Implemented the initial deployment of new OSL mutex interfaces. Since some host operating systems have separate mutex and semaphore objects, this feature was requested. The base code now uses mutexes (and the new mutex interfaces) wherever a binary semaphore was used previously. However, for the current release, the mutex interfaces are defined as macros to map them to the existing semaphore interfaces. Fixed several problems with the support for the control method SyncLevel parameter. The SyncLevel now works according to the ACPI specification and in concert with the Mutex SyncLevel parameter, since the current SyncLevel is a property of the executing thread. Mutual exclusion for control methods is now implemented with a mutex instead of a semaphore. Fixed three instances of the use of the C shift operator in the bitfield support code (exfldio.c) to avoid the use of a shift value larger than the target data width. The behavior of C compilers is undefined in this case and can cause unpredictable results, and therefore the case must be detected and avoided. (Fiodor Suietov) Added an info message whenever an SSDT or OEM table is loaded dynamically via the Load() or LoadTable() ASL operators. This should improve debugging capability since it will show exactly what tables have been loaded (beyond the tables present in the RSDT/XSDT.) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-24 05:04:00 +08:00
/* Flags for acpi_os_acquire_lock/acpi_os_release_lock */
[ACPI] ACPICA 20060127 Implemented support in the Resource Manager to allow unresolved namestring references within resource package objects for the _PRT method. This support is in addition to the previously implemented unresolved reference support within the AML parser. If the interpreter slack mode is enabled (true on Linux unless acpi=strict), these unresolved references will be passed through to the caller as a NULL package entry. http://bugzilla.kernel.org/show_bug.cgi?id=5741 Implemented and deployed new macros and functions for error and warning messages across the subsystem. These macros are simpler and generate less code than their predecessors. The new macros ACPI_ERROR, ACPI_EXCEPTION, ACPI_WARNING, and ACPI_INFO replace the ACPI_REPORT_* macros. Implemented the acpi_cpu_flags type to simplify host OS integration of the Acquire/Release Lock OSL interfaces. Suggested by Steven Rostedt and Andrew Morton. Fixed a problem where Alias ASL operators are sometimes not correctly resolved. causing AE_AML_INTERNAL http://bugzilla.kernel.org/show_bug.cgi?id=5189 http://bugzilla.kernel.org/show_bug.cgi?id=5674 Fixed several problems with the implementation of the ConcatenateResTemplate ASL operator. As per the ACPI specification, zero length buffers are now treated as a single EndTag. One-length buffers always cause a fatal exception. Non-zero length buffers that do not end with a full 2-byte EndTag cause a fatal exception. Fixed a possible structure overwrite in the AcpiGetObjectInfo external interface. (With assistance from Thomas Renninger) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-01-28 05:43:00 +08:00
#ifndef acpi_cpu_flags
#define acpi_cpu_flags acpi_size
[ACPI] ACPICA 20060127 Implemented support in the Resource Manager to allow unresolved namestring references within resource package objects for the _PRT method. This support is in addition to the previously implemented unresolved reference support within the AML parser. If the interpreter slack mode is enabled (true on Linux unless acpi=strict), these unresolved references will be passed through to the caller as a NULL package entry. http://bugzilla.kernel.org/show_bug.cgi?id=5741 Implemented and deployed new macros and functions for error and warning messages across the subsystem. These macros are simpler and generate less code than their predecessors. The new macros ACPI_ERROR, ACPI_EXCEPTION, ACPI_WARNING, and ACPI_INFO replace the ACPI_REPORT_* macros. Implemented the acpi_cpu_flags type to simplify host OS integration of the Acquire/Release Lock OSL interfaces. Suggested by Steven Rostedt and Andrew Morton. Fixed a problem where Alias ASL operators are sometimes not correctly resolved. causing AE_AML_INTERNAL http://bugzilla.kernel.org/show_bug.cgi?id=5189 http://bugzilla.kernel.org/show_bug.cgi?id=5674 Fixed several problems with the implementation of the ConcatenateResTemplate ASL operator. As per the ACPI specification, zero length buffers are now treated as a single EndTag. One-length buffers always cause a fatal exception. Non-zero length buffers that do not end with a full 2-byte EndTag cause a fatal exception. Fixed a possible structure overwrite in the AcpiGetObjectInfo external interface. (With assistance from Thomas Renninger) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-01-28 05:43:00 +08:00
#endif
ACPI: ACPICA 20060623 Implemented a new acpi_spinlock type for the OSL lock interfaces. This allows the type to be customized to the host OS for improved efficiency (since a spinlock is usually a very small object.) Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 Implemented the initial deployment of new OSL mutex interfaces. Since some host operating systems have separate mutex and semaphore objects, this feature was requested. The base code now uses mutexes (and the new mutex interfaces) wherever a binary semaphore was used previously. However, for the current release, the mutex interfaces are defined as macros to map them to the existing semaphore interfaces. Fixed several problems with the support for the control method SyncLevel parameter. The SyncLevel now works according to the ACPI specification and in concert with the Mutex SyncLevel parameter, since the current SyncLevel is a property of the executing thread. Mutual exclusion for control methods is now implemented with a mutex instead of a semaphore. Fixed three instances of the use of the C shift operator in the bitfield support code (exfldio.c) to avoid the use of a shift value larger than the target data width. The behavior of C compilers is undefined in this case and can cause unpredictable results, and therefore the case must be detected and avoided. (Fiodor Suietov) Added an info message whenever an SSDT or OEM table is loaded dynamically via the Load() or LoadTable() ASL operators. This should improve debugging capability since it will show exactly what tables have been loaded (beyond the tables present in the RSDT/XSDT.) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-24 05:04:00 +08:00
/* Object returned from acpi_os_create_cache */
#ifndef acpi_cache_t
#ifdef ACPI_USE_LOCAL_CACHE
ACPI: ACPICA 20060623 Implemented a new acpi_spinlock type for the OSL lock interfaces. This allows the type to be customized to the host OS for improved efficiency (since a spinlock is usually a very small object.) Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 Implemented the initial deployment of new OSL mutex interfaces. Since some host operating systems have separate mutex and semaphore objects, this feature was requested. The base code now uses mutexes (and the new mutex interfaces) wherever a binary semaphore was used previously. However, for the current release, the mutex interfaces are defined as macros to map them to the existing semaphore interfaces. Fixed several problems with the support for the control method SyncLevel parameter. The SyncLevel now works according to the ACPI specification and in concert with the Mutex SyncLevel parameter, since the current SyncLevel is a property of the executing thread. Mutual exclusion for control methods is now implemented with a mutex instead of a semaphore. Fixed three instances of the use of the C shift operator in the bitfield support code (exfldio.c) to avoid the use of a shift value larger than the target data width. The behavior of C compilers is undefined in this case and can cause unpredictable results, and therefore the case must be detected and avoided. (Fiodor Suietov) Added an info message whenever an SSDT or OEM table is loaded dynamically via the Load() or LoadTable() ASL operators. This should improve debugging capability since it will show exactly what tables have been loaded (beyond the tables present in the RSDT/XSDT.) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-24 05:04:00 +08:00
#define acpi_cache_t struct acpi_memory_list
#else
#define acpi_cache_t void *
#endif
ACPI: ACPICA 20060623 Implemented a new acpi_spinlock type for the OSL lock interfaces. This allows the type to be customized to the host OS for improved efficiency (since a spinlock is usually a very small object.) Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 Implemented the initial deployment of new OSL mutex interfaces. Since some host operating systems have separate mutex and semaphore objects, this feature was requested. The base code now uses mutexes (and the new mutex interfaces) wherever a binary semaphore was used previously. However, for the current release, the mutex interfaces are defined as macros to map them to the existing semaphore interfaces. Fixed several problems with the support for the control method SyncLevel parameter. The SyncLevel now works according to the ACPI specification and in concert with the Mutex SyncLevel parameter, since the current SyncLevel is a property of the executing thread. Mutual exclusion for control methods is now implemented with a mutex instead of a semaphore. Fixed three instances of the use of the C shift operator in the bitfield support code (exfldio.c) to avoid the use of a shift value larger than the target data width. The behavior of C compilers is undefined in this case and can cause unpredictable results, and therefore the case must be detected and avoided. (Fiodor Suietov) Added an info message whenever an SSDT or OEM table is loaded dynamically via the Load() or LoadTable() ASL operators. This should improve debugging capability since it will show exactly what tables have been loaded (beyond the tables present in the RSDT/XSDT.) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-24 05:04:00 +08:00
#endif
/*
* Synchronization objects - Mutexes, Semaphores, and spin_locks
*/
#if (ACPI_MUTEX_TYPE == ACPI_BINARY_SEMAPHORE)
/*
* These macros are used if the host OS does not support a mutex object.
* Map the OSL Mutex interfaces to binary semaphores.
*/
#define acpi_mutex acpi_semaphore
#define acpi_os_create_mutex(out_handle) acpi_os_create_semaphore (1, 1, out_handle)
#define acpi_os_delete_mutex(handle) (void) acpi_os_delete_semaphore (handle)
#define acpi_os_acquire_mutex(handle,time) acpi_os_wait_semaphore (handle, 1, time)
#define acpi_os_release_mutex(handle) (void) acpi_os_signal_semaphore (handle, 1)
#endif
/* Configurable types for synchronization objects */
#ifndef acpi_spinlock
#define acpi_spinlock void *
#endif
#ifndef acpi_raw_spinlock
#define acpi_raw_spinlock acpi_spinlock
#endif
#ifndef acpi_semaphore
#define acpi_semaphore void *
#endif
#ifndef acpi_mutex
#define acpi_mutex void *
#endif
/*******************************************************************************
*
* Compiler-dependent types
*
* If the defaults below are not appropriate for the host compiler, they can
* be defined in the compiler-specific header, and this will take precedence.
*
******************************************************************************/
ACPI: ACPICA 20060623 Implemented a new acpi_spinlock type for the OSL lock interfaces. This allows the type to be customized to the host OS for improved efficiency (since a spinlock is usually a very small object.) Implemented support for "ignored" bits in the ACPI registers. According to the ACPI specification, these bits should be preserved when writing the registers via a read/modify/write cycle. There are 3 bits preserved in this manner: PM1_CONTROL[0] (SCI_EN), PM1_CONTROL[9], and PM1_STATUS[11]. http://bugzilla.kernel.org/show_bug.cgi?id=3691 Implemented the initial deployment of new OSL mutex interfaces. Since some host operating systems have separate mutex and semaphore objects, this feature was requested. The base code now uses mutexes (and the new mutex interfaces) wherever a binary semaphore was used previously. However, for the current release, the mutex interfaces are defined as macros to map them to the existing semaphore interfaces. Fixed several problems with the support for the control method SyncLevel parameter. The SyncLevel now works according to the ACPI specification and in concert with the Mutex SyncLevel parameter, since the current SyncLevel is a property of the executing thread. Mutual exclusion for control methods is now implemented with a mutex instead of a semaphore. Fixed three instances of the use of the C shift operator in the bitfield support code (exfldio.c) to avoid the use of a shift value larger than the target data width. The behavior of C compilers is undefined in this case and can cause unpredictable results, and therefore the case must be detected and avoided. (Fiodor Suietov) Added an info message whenever an SSDT or OEM table is loaded dynamically via the Load() or LoadTable() ASL operators. This should improve debugging capability since it will show exactly what tables have been loaded (beyond the tables present in the RSDT/XSDT.) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-06-24 05:04:00 +08:00
/* Use C99 uintptr_t for pointer casting if available, "void *" otherwise */
#ifndef acpi_uintptr_t
#define acpi_uintptr_t void *
#endif
[ACPI] ACPICA 20060127 Implemented support in the Resource Manager to allow unresolved namestring references within resource package objects for the _PRT method. This support is in addition to the previously implemented unresolved reference support within the AML parser. If the interpreter slack mode is enabled (true on Linux unless acpi=strict), these unresolved references will be passed through to the caller as a NULL package entry. http://bugzilla.kernel.org/show_bug.cgi?id=5741 Implemented and deployed new macros and functions for error and warning messages across the subsystem. These macros are simpler and generate less code than their predecessors. The new macros ACPI_ERROR, ACPI_EXCEPTION, ACPI_WARNING, and ACPI_INFO replace the ACPI_REPORT_* macros. Implemented the acpi_cpu_flags type to simplify host OS integration of the Acquire/Release Lock OSL interfaces. Suggested by Steven Rostedt and Andrew Morton. Fixed a problem where Alias ASL operators are sometimes not correctly resolved. causing AE_AML_INTERNAL http://bugzilla.kernel.org/show_bug.cgi?id=5189 http://bugzilla.kernel.org/show_bug.cgi?id=5674 Fixed several problems with the implementation of the ConcatenateResTemplate ASL operator. As per the ACPI specification, zero length buffers are now treated as a single EndTag. One-length buffers always cause a fatal exception. Non-zero length buffers that do not end with a full 2-byte EndTag cause a fatal exception. Fixed a possible structure overwrite in the AcpiGetObjectInfo external interface. (With assistance from Thomas Renninger) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-01-28 05:43:00 +08:00
/*
* ACPI_PRINTF_LIKE is used to tag functions as "printf-like" because
* some compilers can catch printf format string problems
*/
#ifndef ACPI_PRINTF_LIKE
#define ACPI_PRINTF_LIKE(c)
#endif
/*
* Some compilers complain about unused variables. Sometimes we don't want
* to use all the variables (for example, _acpi_module_name). This allows us
* to tell the compiler in a per-variable manner that a variable
[ACPI] ACPICA 20060127 Implemented support in the Resource Manager to allow unresolved namestring references within resource package objects for the _PRT method. This support is in addition to the previously implemented unresolved reference support within the AML parser. If the interpreter slack mode is enabled (true on Linux unless acpi=strict), these unresolved references will be passed through to the caller as a NULL package entry. http://bugzilla.kernel.org/show_bug.cgi?id=5741 Implemented and deployed new macros and functions for error and warning messages across the subsystem. These macros are simpler and generate less code than their predecessors. The new macros ACPI_ERROR, ACPI_EXCEPTION, ACPI_WARNING, and ACPI_INFO replace the ACPI_REPORT_* macros. Implemented the acpi_cpu_flags type to simplify host OS integration of the Acquire/Release Lock OSL interfaces. Suggested by Steven Rostedt and Andrew Morton. Fixed a problem where Alias ASL operators are sometimes not correctly resolved. causing AE_AML_INTERNAL http://bugzilla.kernel.org/show_bug.cgi?id=5189 http://bugzilla.kernel.org/show_bug.cgi?id=5674 Fixed several problems with the implementation of the ConcatenateResTemplate ASL operator. As per the ACPI specification, zero length buffers are now treated as a single EndTag. One-length buffers always cause a fatal exception. Non-zero length buffers that do not end with a full 2-byte EndTag cause a fatal exception. Fixed a possible structure overwrite in the AcpiGetObjectInfo external interface. (With assistance from Thomas Renninger) Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-01-28 05:43:00 +08:00
* is unused
*/
#ifndef ACPI_UNUSED_VAR
#define ACPI_UNUSED_VAR
#endif
/*
* All ACPICA external functions that are available to the rest of the
* kernel are tagged with these macros which can be defined as appropriate
* for the host.
*
* Notes:
* ACPI_EXPORT_SYMBOL_INIT is used for initialization and termination
* interfaces that may need special processing.
* ACPI_EXPORT_SYMBOL is used for all other public external functions.
*/
#ifndef ACPI_EXPORT_SYMBOL_INIT
#define ACPI_EXPORT_SYMBOL_INIT(symbol)
#endif
#ifndef ACPI_EXPORT_SYMBOL
#define ACPI_EXPORT_SYMBOL(symbol)
#endif
/*
* Compiler/Clibrary-dependent debug initialization. Used for ACPICA
* utilities only.
*/
#ifndef ACPI_DEBUG_INITIALIZE
#define ACPI_DEBUG_INITIALIZE()
#endif
/*******************************************************************************
*
* Configuration
*
******************************************************************************/
ACPICA: OSL: Add configurability for memory allocation macros. OSPMs like Linux trend to include all header files but leave empty stub macros for a feature that is not configured during build. For macros defined without other symbols referencesd it is safe to leave them without protections. By investigation, there are only the following internal/external symbols referenced by the ACPICA macros: 1. C library symbols, including string, ctype, stdarg APIs. Since such symbols are always accessbile in the kernel source tree, it is safe to leave macros referencing them without protected for Linux. 2. ACPICA OSL symbols, such symbols are designed to be used only by ACPICA internal APIs. And there are macros directly referencing mutex and memory allocation OSL symbols. We need to examine the external usages of such macros. For macros referencing the mutex OSL symbols, fortunately, there is no external user directly invoking such macros. ======================================================================== !! IMPORTANT !! ======================================================================== For macros referencing memory allocation OSL symbols - 1. 'free' - ACPI_FREE 2. 'alloc' - ACPI_ALLOCATE, ACPI_ALLOCATE_ZEROED, ACPI_ALLOCATE_BUFFER, ACPI_ALLOCATE_LOCAL_BUFFER there are external users directly invoking 'alloc' macros. And the more complicated situation is the reversals of such macros are not ACPI_FREE but acpi_os_free (or kfree) in Linux. Though we can define such macros into no-op, we in fact cannot define their reversals into no-op. This patch adds mechanism to protect ACPICA memory allocation APIs for Linux so that acpi_os_free (or kfree) invoked in Linux can have a zero address returned by 'alloc' macros to free. In this way, acpi_os_free (or kfree) can be converted into no-op. ======================================================================== 3. ACPI_OFFSET and other macros that would access structure members, we need to check if such structure members are not accessible under a specific configuration. Fortunately, currently Linux doesn't use such structure members when CONFIG_ACPI is disabled. This patch thus only adds mechanism useful for implementing stubs for ACPICA provided macros - the configurability of memory allocation APIs. This patch doesn't include code for Linux to use this new mechanism, thus no functional changes. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 10:04:42 +08:00
#ifdef ACPI_NO_MEM_ALLOCATIONS
#define ACPI_ALLOCATE(a) NULL
#define ACPI_ALLOCATE_ZEROED(a) NULL
#define ACPI_FREE(a)
#define ACPI_MEM_TRACKING(a)
#else /* ACPI_NO_MEM_ALLOCATIONS */
#ifdef ACPI_DBG_TRACK_ALLOCATIONS
/*
* Memory allocation tracking (used by acpi_exec to detect memory leaks)
*/
#define ACPI_MEM_PARAMETERS _COMPONENT, _acpi_module_name, __LINE__
#define ACPI_ALLOCATE(a) acpi_ut_allocate_and_track ((acpi_size) (a), ACPI_MEM_PARAMETERS)
#define ACPI_ALLOCATE_ZEROED(a) acpi_ut_allocate_zeroed_and_track ((acpi_size) (a), ACPI_MEM_PARAMETERS)
#define ACPI_FREE(a) acpi_ut_free_and_track (a, ACPI_MEM_PARAMETERS)
#define ACPI_MEM_TRACKING(a) a
#else
/*
* Normal memory allocation directly via the OS services layer
*/
#define ACPI_ALLOCATE(a) acpi_os_allocate ((acpi_size) (a))
#define ACPI_ALLOCATE_ZEROED(a) acpi_os_allocate_zeroed ((acpi_size) (a))
#define ACPI_FREE(a) acpi_os_free (a)
#define ACPI_MEM_TRACKING(a)
#endif /* ACPI_DBG_TRACK_ALLOCATIONS */
ACPICA: OSL: Add configurability for memory allocation macros. OSPMs like Linux trend to include all header files but leave empty stub macros for a feature that is not configured during build. For macros defined without other symbols referencesd it is safe to leave them without protections. By investigation, there are only the following internal/external symbols referenced by the ACPICA macros: 1. C library symbols, including string, ctype, stdarg APIs. Since such symbols are always accessbile in the kernel source tree, it is safe to leave macros referencing them without protected for Linux. 2. ACPICA OSL symbols, such symbols are designed to be used only by ACPICA internal APIs. And there are macros directly referencing mutex and memory allocation OSL symbols. We need to examine the external usages of such macros. For macros referencing the mutex OSL symbols, fortunately, there is no external user directly invoking such macros. ======================================================================== !! IMPORTANT !! ======================================================================== For macros referencing memory allocation OSL symbols - 1. 'free' - ACPI_FREE 2. 'alloc' - ACPI_ALLOCATE, ACPI_ALLOCATE_ZEROED, ACPI_ALLOCATE_BUFFER, ACPI_ALLOCATE_LOCAL_BUFFER there are external users directly invoking 'alloc' macros. And the more complicated situation is the reversals of such macros are not ACPI_FREE but acpi_os_free (or kfree) in Linux. Though we can define such macros into no-op, we in fact cannot define their reversals into no-op. This patch adds mechanism to protect ACPICA memory allocation APIs for Linux so that acpi_os_free (or kfree) invoked in Linux can have a zero address returned by 'alloc' macros to free. In this way, acpi_os_free (or kfree) can be converted into no-op. ======================================================================== 3. ACPI_OFFSET and other macros that would access structure members, we need to check if such structure members are not accessible under a specific configuration. Fortunately, currently Linux doesn't use such structure members when CONFIG_ACPI is disabled. This patch thus only adds mechanism useful for implementing stubs for ACPICA provided macros - the configurability of memory allocation APIs. This patch doesn't include code for Linux to use this new mechanism, thus no functional changes. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 10:04:42 +08:00
#endif /* ACPI_NO_MEM_ALLOCATIONS */
/******************************************************************************
*
* ACPI Specification constants (Do not change unless the specification
* changes)
*
*****************************************************************************/
/* Number of distinct FADT-based GPE register blocks (GPE0 and GPE1) */
#define ACPI_MAX_GPE_BLOCKS 2
/* Default ACPI register widths */
#define ACPI_GPE_REGISTER_WIDTH 8
#define ACPI_PM1_REGISTER_WIDTH 16
#define ACPI_PM2_REGISTER_WIDTH 8
#define ACPI_PM_TIMER_WIDTH 32
#define ACPI_RESET_REGISTER_WIDTH 8
/* Names within the namespace are 4 bytes long */
#define ACPI_NAMESEG_SIZE 4 /* Fixed by ACPI spec */
#define ACPI_PATH_SEGMENT_LENGTH 5 /* 4 chars for name + 1 char for separator */
#define ACPI_PATH_SEPARATOR '.'
/* Sizes for ACPI table headers */
#define ACPI_OEM_ID_SIZE 6
#define ACPI_OEM_TABLE_ID_SIZE 8
/* ACPI/PNP hardware IDs */
#define PCI_ROOT_HID_STRING "PNP0A03"
#define PCI_EXPRESS_ROOT_HID_STRING "PNP0A08"
/* PM Timer ticks per second (HZ) */
#define ACPI_PM_TIMER_FREQUENCY 3579545
/*******************************************************************************
*
* Independent types
*
******************************************************************************/
/* Logical defines and NULL */
#ifdef FALSE
#undef FALSE
#endif
#define FALSE (1 == 0)
#ifdef TRUE
#undef TRUE
#endif
#define TRUE (1 == 1)
#ifndef NULL
#define NULL (void *) 0
#endif
/*
* Miscellaneous types
*/
typedef u32 acpi_status; /* All ACPI Exceptions */
typedef u32 acpi_name; /* 4-byte ACPI name */
typedef char *acpi_string; /* Null terminated ASCII string */
typedef void *acpi_handle; /* Actually a ptr to a NS Node */
/* Time constants for timer calculations */
#define ACPI_MSEC_PER_SEC 1000L
#define ACPI_USEC_PER_MSEC 1000L
#define ACPI_USEC_PER_SEC 1000000L
#define ACPI_100NSEC_PER_USEC 10L
#define ACPI_100NSEC_PER_MSEC 10000L
#define ACPI_100NSEC_PER_SEC 10000000L
#define ACPI_NSEC_PER_USEC 1000L
#define ACPI_NSEC_PER_MSEC 1000000L
#define ACPI_NSEC_PER_SEC 1000000000L
#define ACPI_TIME_AFTER(a, b) ((s64)((b) - (a)) < 0)
/* Owner IDs are used to track namespace nodes for selective deletion */
typedef u16 acpi_owner_id;
#define ACPI_OWNER_ID_MAX 0xFFF /* 4095 possible owner IDs */
#define ACPI_INTEGER_BIT_SIZE 64
#define ACPI_MAX_DECIMAL_DIGITS 20 /* 2^64 = 18,446,744,073,709,551,616 */
#define ACPI_MAX64_DECIMAL_DIGITS 20
#define ACPI_MAX32_DECIMAL_DIGITS 10
#define ACPI_MAX16_DECIMAL_DIGITS 5
#define ACPI_MAX8_DECIMAL_DIGITS 3
/*
* Constants with special meanings
*/
#define ACPI_ROOT_OBJECT ((acpi_handle) ACPI_TO_POINTER (ACPI_MAX_PTR))
#define ACPI_WAIT_FOREVER 0xFFFF /* u16, as per ACPI spec */
#define ACPI_DO_NOT_WAIT 0
/*
* Obsolete: Acpi integer width. In ACPI version 1 (1996), integers are
* 32 bits. In ACPI version 2 (2000) and later, integers are max 64 bits.
* Note that this pertains to the ACPI integer type only, not to other
* integers used in the implementation of the ACPICA subsystem.
*
* 01/2010: This type is obsolete and has been removed from the entire ACPICA
* code base. It remains here for compatibility with device drivers that use
* the type. However, it will be removed in the future.
*/
typedef u64 acpi_integer;
#define ACPI_INTEGER_MAX ACPI_UINT64_MAX
/*******************************************************************************
*
* Commonly used macros
*
******************************************************************************/
/* Data manipulation */
#define ACPI_LOBYTE(integer) ((u8) (u16)(integer))
#define ACPI_HIBYTE(integer) ((u8) (((u16)(integer)) >> 8))
#define ACPI_LOWORD(integer) ((u16) (u32)(integer))
#define ACPI_HIWORD(integer) ((u16)(((u32)(integer)) >> 16))
#define ACPI_LODWORD(integer64) ((u32) (u64)(integer64))
#define ACPI_HIDWORD(integer64) ((u32)(((u64)(integer64)) >> 32))
#define ACPI_SET_BIT(target,bit) ((target) |= (bit))
#define ACPI_CLEAR_BIT(target,bit) ((target) &= ~(bit))
#define ACPI_MIN(a,b) (((a)<(b))?(a):(b))
#define ACPI_MAX(a,b) (((a)>(b))?(a):(b))
/* Size calculation */
#define ACPI_ARRAY_LENGTH(x) (sizeof(x) / sizeof((x)[0]))
/* Pointer manipulation */
#define ACPI_CAST_PTR(t, p) ((t *) (acpi_uintptr_t) (p))
#define ACPI_CAST_INDIRECT_PTR(t, p) ((t **) (acpi_uintptr_t) (p))
#define ACPI_ADD_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) + (acpi_size)(b)))
#define ACPI_SUB_PTR(t, a, b) ACPI_CAST_PTR (t, (ACPI_CAST_PTR (u8, (a)) - (acpi_size)(b)))
#define ACPI_PTR_DIFF(a, b) ((acpi_size) (ACPI_CAST_PTR (u8, (a)) - ACPI_CAST_PTR (u8, (b))))
/* Pointer/Integer type conversions */
#define ACPI_TO_POINTER(i) ACPI_CAST_PTR (void, (acpi_size) (i))
#define ACPI_TO_INTEGER(p) ACPI_PTR_DIFF (p, (void *) 0)
#define ACPI_OFFSET(d, f) ACPI_PTR_DIFF (&(((d *) 0)->f), (void *) 0)
#define ACPI_PHYSADDR_TO_PTR(i) ACPI_TO_POINTER(i)
#define ACPI_PTR_TO_PHYSADDR(i) ACPI_TO_INTEGER(i)
/* Optimizations for 4-character (32-bit) acpi_name manipulation */
#ifndef ACPI_MISALIGNMENT_NOT_SUPPORTED
#define ACPI_COMPARE_NAMESEG(a,b) (*ACPI_CAST_PTR (u32, (a)) == *ACPI_CAST_PTR (u32, (b)))
#define ACPI_COPY_NAMESEG(dest,src) (*ACPI_CAST_PTR (u32, (dest)) = *ACPI_CAST_PTR (u32, (src)))
#else
#define ACPI_COMPARE_NAMESEG(a,b) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_CAST_PTR (char, (b)), ACPI_NAMESEG_SIZE))
#define ACPI_COPY_NAMESEG(dest,src) (strncpy (ACPI_CAST_PTR (char, (dest)), ACPI_CAST_PTR (char, (src)), ACPI_NAMESEG_SIZE))
#endif
/* Support for the special RSDP signature (8 characters) */
#define ACPI_VALIDATE_RSDP_SIG(a) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_SIG_RSDP, 8))
#define ACPI_MAKE_RSDP_SIG(dest) (memcpy (ACPI_CAST_PTR (char, (dest)), ACPI_SIG_RSDP, 8))
/* Support for OEMx signature (x can be any character) */
#define ACPI_IS_OEM_SIG(a) (!strncmp (ACPI_CAST_PTR (char, (a)), ACPI_OEM_NAME, 3) &&\
strnlen (a, ACPI_NAMESEG_SIZE) == ACPI_NAMESEG_SIZE)
/*
* Algorithm to obtain access bit or byte width.
* Can be used with access_width of struct acpi_generic_address and access_size of
* struct acpi_resource_generic_register.
*/
#define ACPI_ACCESS_BIT_WIDTH(size) (1 << ((size) + 2))
#define ACPI_ACCESS_BYTE_WIDTH(size) (1 << ((size) - 1))
/*******************************************************************************
*
* Miscellaneous constants
*
******************************************************************************/
/*
* Initialization sequence options
*/
#define ACPI_FULL_INITIALIZATION 0x0000
#define ACPI_NO_FACS_INIT 0x0001
#define ACPI_NO_ACPI_ENABLE 0x0002
#define ACPI_NO_HARDWARE_INIT 0x0004
#define ACPI_NO_EVENT_INIT 0x0008
#define ACPI_NO_HANDLER_INIT 0x0010
#define ACPI_NO_OBJECT_INIT 0x0020
#define ACPI_NO_DEVICE_INIT 0x0040
#define ACPI_NO_ADDRESS_SPACE_INIT 0x0080
/*
* Initialization state
*/
#define ACPI_SUBSYSTEM_INITIALIZE 0x01
#define ACPI_INITIALIZED_OK 0x02
/*
* Power state values
*/
#define ACPI_STATE_UNKNOWN (u8) 0xFF
#define ACPI_STATE_S0 (u8) 0
#define ACPI_STATE_S1 (u8) 1
#define ACPI_STATE_S2 (u8) 2
#define ACPI_STATE_S3 (u8) 3
#define ACPI_STATE_S4 (u8) 4
#define ACPI_STATE_S5 (u8) 5
#define ACPI_S_STATES_MAX ACPI_STATE_S5
#define ACPI_S_STATE_COUNT 6
#define ACPI_STATE_D0 (u8) 0
#define ACPI_STATE_D1 (u8) 1
#define ACPI_STATE_D2 (u8) 2
#define ACPI_STATE_D3_HOT (u8) 3
#define ACPI_STATE_D3 (u8) 4
#define ACPI_STATE_D3_COLD ACPI_STATE_D3
#define ACPI_D_STATES_MAX ACPI_STATE_D3
#define ACPI_D_STATE_COUNT 5
#define ACPI_STATE_C0 (u8) 0
#define ACPI_STATE_C1 (u8) 1
#define ACPI_STATE_C2 (u8) 2
#define ACPI_STATE_C3 (u8) 3
#define ACPI_C_STATES_MAX ACPI_STATE_C3
#define ACPI_C_STATE_COUNT 4
/*
* Sleep type invalid value
*/
#define ACPI_SLEEP_TYPE_MAX 0x7
#define ACPI_SLEEP_TYPE_INVALID 0xFF
/*
* Standard notify values
*/
#define ACPI_NOTIFY_BUS_CHECK (u8) 0x00
#define ACPI_NOTIFY_DEVICE_CHECK (u8) 0x01
#define ACPI_NOTIFY_DEVICE_WAKE (u8) 0x02
#define ACPI_NOTIFY_EJECT_REQUEST (u8) 0x03
#define ACPI_NOTIFY_DEVICE_CHECK_LIGHT (u8) 0x04
#define ACPI_NOTIFY_FREQUENCY_MISMATCH (u8) 0x05
#define ACPI_NOTIFY_BUS_MODE_MISMATCH (u8) 0x06
#define ACPI_NOTIFY_POWER_FAULT (u8) 0x07
#define ACPI_NOTIFY_CAPABILITIES_CHECK (u8) 0x08
#define ACPI_NOTIFY_DEVICE_PLD_CHECK (u8) 0x09
#define ACPI_NOTIFY_RESERVED (u8) 0x0A
#define ACPI_NOTIFY_LOCALITY_UPDATE (u8) 0x0B
#define ACPI_NOTIFY_SHUTDOWN_REQUEST (u8) 0x0C
#define ACPI_NOTIFY_AFFINITY_UPDATE (u8) 0x0D
#define ACPI_NOTIFY_MEMORY_UPDATE (u8) 0x0E
#define ACPI_NOTIFY_DISCONNECT_RECOVER (u8) 0x0F
#define ACPI_GENERIC_NOTIFY_MAX 0x0F
#define ACPI_SPECIFIC_NOTIFY_MAX 0x84
/*
* Types associated with ACPI names and objects. The first group of
* values (up to ACPI_TYPE_EXTERNAL_MAX) correspond to the definition
* of the ACPI object_type() operator (See the ACPI Spec). Therefore,
* only add to the first group if the spec changes.
*
* NOTE: Types must be kept in sync with the global acpi_ns_properties
* and acpi_ns_type_names arrays.
*/
typedef u32 acpi_object_type;
#define ACPI_TYPE_ANY 0x00
#define ACPI_TYPE_INTEGER 0x01 /* Byte/Word/Dword/Zero/One/Ones */
#define ACPI_TYPE_STRING 0x02
#define ACPI_TYPE_BUFFER 0x03
#define ACPI_TYPE_PACKAGE 0x04 /* byte_const, multiple data_term/Constant/super_name */
#define ACPI_TYPE_FIELD_UNIT 0x05
#define ACPI_TYPE_DEVICE 0x06 /* Name, multiple Node */
#define ACPI_TYPE_EVENT 0x07
#define ACPI_TYPE_METHOD 0x08 /* Name, byte_const, multiple Code */
#define ACPI_TYPE_MUTEX 0x09
#define ACPI_TYPE_REGION 0x0A
#define ACPI_TYPE_POWER 0x0B /* Name,byte_const,word_const,multi Node */
#define ACPI_TYPE_PROCESSOR 0x0C /* Name,byte_const,Dword_const,byte_const,multi nm_o */
#define ACPI_TYPE_THERMAL 0x0D /* Name, multiple Node */
#define ACPI_TYPE_BUFFER_FIELD 0x0E
#define ACPI_TYPE_DDB_HANDLE 0x0F
#define ACPI_TYPE_DEBUG_OBJECT 0x10
#define ACPI_TYPE_EXTERNAL_MAX 0x10
#define ACPI_NUM_TYPES (ACPI_TYPE_EXTERNAL_MAX + 1)
/*
* These are object types that do not map directly to the ACPI
* object_type() operator. They are used for various internal purposes
* only. If new predefined ACPI_TYPEs are added (via the ACPI
* specification), these internal types must move upwards. (There
* is code that depends on these values being contiguous with the
* external types above.)
*/
#define ACPI_TYPE_LOCAL_REGION_FIELD 0x11
#define ACPI_TYPE_LOCAL_BANK_FIELD 0x12
#define ACPI_TYPE_LOCAL_INDEX_FIELD 0x13
#define ACPI_TYPE_LOCAL_REFERENCE 0x14 /* Arg#, Local#, Name, Debug, ref_of, Index */
#define ACPI_TYPE_LOCAL_ALIAS 0x15
#define ACPI_TYPE_LOCAL_METHOD_ALIAS 0x16
#define ACPI_TYPE_LOCAL_NOTIFY 0x17
#define ACPI_TYPE_LOCAL_ADDRESS_HANDLER 0x18
#define ACPI_TYPE_LOCAL_RESOURCE 0x19
#define ACPI_TYPE_LOCAL_RESOURCE_FIELD 0x1A
#define ACPI_TYPE_LOCAL_SCOPE 0x1B /* 1 Name, multiple object_list Nodes */
#define ACPI_TYPE_NS_NODE_MAX 0x1B /* Last typecode used within a NS Node */
#define ACPI_TOTAL_TYPES (ACPI_TYPE_NS_NODE_MAX + 1)
/*
* These are special object types that never appear in
* a Namespace node, only in an object of union acpi_operand_object
*/
#define ACPI_TYPE_LOCAL_EXTRA 0x1C
#define ACPI_TYPE_LOCAL_DATA 0x1D
#define ACPI_TYPE_LOCAL_MAX 0x1D
/* All types above here are invalid */
#define ACPI_TYPE_INVALID 0x1E
#define ACPI_TYPE_NOT_FOUND 0xFF
#define ACPI_NUM_NS_TYPES (ACPI_TYPE_INVALID + 1)
/*
* All I/O
*/
#define ACPI_READ 0
#define ACPI_WRITE 1
#define ACPI_IO_MASK 1
/*
* Event Types: Fixed & General Purpose
*/
typedef u32 acpi_event_type;
/*
* Fixed events
*/
#define ACPI_EVENT_PMTIMER 0
#define ACPI_EVENT_GLOBAL 1
#define ACPI_EVENT_POWER_BUTTON 2
#define ACPI_EVENT_SLEEP_BUTTON 3
#define ACPI_EVENT_RTC 4
#define ACPI_EVENT_MAX 4
#define ACPI_NUM_FIXED_EVENTS ACPI_EVENT_MAX + 1
/*
* Event status - Per event
* -------------
* The encoding of acpi_event_status is illustrated below.
* Note that a set bit (1) indicates the property is TRUE
* (e.g. if bit 0 is set then the event is enabled).
* +-------------+-+-+-+-+-+-+
* | Bits 31:6 |5|4|3|2|1|0|
* +-------------+-+-+-+-+-+-+
* | | | | | | |
* | | | | | | +- Enabled?
* | | | | | +--- Enabled for wake?
* | | | | +----- Status bit set?
* | | | +------- Enable bit set?
* | | +--------- Has a handler?
* | +----------- Masked?
* +----------------- <Reserved>
*/
typedef u32 acpi_event_status;
#define ACPI_EVENT_FLAG_DISABLED (acpi_event_status) 0x00
#define ACPI_EVENT_FLAG_ENABLED (acpi_event_status) 0x01
#define ACPI_EVENT_FLAG_WAKE_ENABLED (acpi_event_status) 0x02
#define ACPI_EVENT_FLAG_STATUS_SET (acpi_event_status) 0x04
#define ACPI_EVENT_FLAG_ENABLE_SET (acpi_event_status) 0x08
#define ACPI_EVENT_FLAG_HAS_HANDLER (acpi_event_status) 0x10
#define ACPI_EVENT_FLAG_MASKED (acpi_event_status) 0x20
#define ACPI_EVENT_FLAG_SET ACPI_EVENT_FLAG_STATUS_SET
/* Actions for acpi_set_gpe, acpi_gpe_wakeup, acpi_hw_low_set_gpe */
#define ACPI_GPE_ENABLE 0
#define ACPI_GPE_DISABLE 1
#define ACPI_GPE_CONDITIONAL_ENABLE 2
/*
* GPE info flags - Per GPE
* +---+-+-+-+---+
* |7:6|5|4|3|2:0|
* +---+-+-+-+---+
* | | | | |
* | | | | +-- Type of dispatch:to method, handler, notify, or none
* | | | +----- Interrupt type: edge or level triggered
* | | +------- Is a Wake GPE
* | +--------- Has been enabled automatically at init time
* +------------ <Reserved>
*/
#define ACPI_GPE_DISPATCH_NONE (u8) 0x00
#define ACPI_GPE_DISPATCH_METHOD (u8) 0x01
#define ACPI_GPE_DISPATCH_HANDLER (u8) 0x02
#define ACPI_GPE_DISPATCH_NOTIFY (u8) 0x03
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
#define ACPI_GPE_DISPATCH_RAW_HANDLER (u8) 0x04
#define ACPI_GPE_DISPATCH_MASK (u8) 0x07
ACPICA: Events: Cleanup GPE dispatcher type obtaining code ACPICA commit 7926d5ca9452c87f866938dcea8f12e1efb58f89 There is an issue in acpi_install_gpe_handler() and acpi_remove_gpe_handler(). The code to obtain the GPE dispatcher type from the Handler->original_flags is wrong: if (((Handler->original_flags & ACPI_GPE_DISPATCH_METHOD) || (Handler->original_flags & ACPI_GPE_DISPATCH_NOTIFY)) && ACPI_GPE_DISPATCH_NOTIFY is 0x03 and ACPI_GPE_DISPATCH_METHOD is 0x02, thus this statement is TRUE for the following dispatcher types: 0x01 (ACPI_GPE_DISPATCH_HANDLER): not expected 0x02 (ACPI_GPE_DISPATCH_METHOD): expected 0x03 (ACPI_GPE_DISPATCH_NOTIFY): expected There is no functional issue due to this because Handler->original_flags is only set in acpi_install_gpe_handler(), and an earlier checker has excluded the ACPI_GPE_DISPATCH_HANDLER: if ((gpe_event_info->Flags & ACPI_GPE_DISPATCH_MASK) == ACPI_GPE_DISPATCH_HANDLER) { Status = AE_ALREADY_EXISTS; goto free_and_exit; } ... Handler->original_flags = (u8) (gpe_event_info->Flags & (ACPI_GPE_XRUPT_TYPE_MASK | ACPI_GPE_DISPATCH_MASK)); We need to clean this up before modifying the GPE dispatcher type values. In order to prevent such issue from happening in the future, this patch introduces ACPI_GPE_DISPATCH_TYPE() macro to be used to obtain the GPE dispatcher types. Lv Zheng. Link: https://github.com/acpica/acpica/commit/7926d5ca Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: David E. Box <david.e.box@linux.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 15:20:29 +08:00
#define ACPI_GPE_DISPATCH_TYPE(flags) ((u8) ((flags) & ACPI_GPE_DISPATCH_MASK))
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
#define ACPI_GPE_LEVEL_TRIGGERED (u8) 0x08
#define ACPI_GPE_EDGE_TRIGGERED (u8) 0x00
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
#define ACPI_GPE_XRUPT_TYPE_MASK (u8) 0x08
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
#define ACPI_GPE_CAN_WAKE (u8) 0x10
#define ACPI_GPE_AUTO_ENABLED (u8) 0x20
#define ACPI_GPE_INITIALIZED (u8) 0x40
/*
* Flags for GPE and Lock interfaces
*/
#define ACPI_NOT_ISR 0x1
#define ACPI_ISR 0x0
/* Notify types */
#define ACPI_SYSTEM_NOTIFY 0x1
#define ACPI_DEVICE_NOTIFY 0x2
#define ACPI_ALL_NOTIFY (ACPI_SYSTEM_NOTIFY | ACPI_DEVICE_NOTIFY)
#define ACPI_MAX_NOTIFY_HANDLER_TYPE 0x3
#define ACPI_NUM_NOTIFY_TYPES 2
#define ACPI_MAX_SYS_NOTIFY 0x7F
#define ACPI_MAX_DEVICE_SPECIFIC_NOTIFY 0xBF
#define ACPI_SYSTEM_HANDLER_LIST 0 /* Used as index, must be SYSTEM_NOTIFY -1 */
#define ACPI_DEVICE_HANDLER_LIST 1 /* Used as index, must be DEVICE_NOTIFY -1 */
/* Address Space (Operation Region) Types */
typedef u8 acpi_adr_space_type;
#define ACPI_ADR_SPACE_SYSTEM_MEMORY (acpi_adr_space_type) 0
#define ACPI_ADR_SPACE_SYSTEM_IO (acpi_adr_space_type) 1
#define ACPI_ADR_SPACE_PCI_CONFIG (acpi_adr_space_type) 2
#define ACPI_ADR_SPACE_EC (acpi_adr_space_type) 3
#define ACPI_ADR_SPACE_SMBUS (acpi_adr_space_type) 4
#define ACPI_ADR_SPACE_CMOS (acpi_adr_space_type) 5
#define ACPI_ADR_SPACE_PCI_BAR_TARGET (acpi_adr_space_type) 6
#define ACPI_ADR_SPACE_IPMI (acpi_adr_space_type) 7
#define ACPI_ADR_SPACE_GPIO (acpi_adr_space_type) 8
#define ACPI_ADR_SPACE_GSBUS (acpi_adr_space_type) 9
#define ACPI_ADR_SPACE_PLATFORM_COMM (acpi_adr_space_type) 10
#define ACPI_ADR_SPACE_PLATFORM_RT (acpi_adr_space_type) 11
#define ACPI_NUM_PREDEFINED_REGIONS 12
/*
* Special Address Spaces
*
* Note: A Data Table region is a special type of operation region
* that has its own AML opcode. However, internally, the AML
* interpreter simply creates an operation region with an address
* space type of ACPI_ADR_SPACE_DATA_TABLE.
*/
#define ACPI_ADR_SPACE_DATA_TABLE (acpi_adr_space_type) 0x7E /* Internal to ACPICA only */
#define ACPI_ADR_SPACE_FIXED_HARDWARE (acpi_adr_space_type) 0x7F
/* Values for _REG connection code */
#define ACPI_REG_DISCONNECT 0
#define ACPI_REG_CONNECT 1
/*
* bit_register IDs
*
* These values are intended to be used by the hardware interfaces
* and are mapped to individual bitfields defined within the ACPI
* registers. See the acpi_gbl_bit_register_info global table in utglobal.c
* for this mapping.
*/
/* PM1 Status register */
#define ACPI_BITREG_TIMER_STATUS 0x00
#define ACPI_BITREG_BUS_MASTER_STATUS 0x01
#define ACPI_BITREG_GLOBAL_LOCK_STATUS 0x02
#define ACPI_BITREG_POWER_BUTTON_STATUS 0x03
#define ACPI_BITREG_SLEEP_BUTTON_STATUS 0x04
#define ACPI_BITREG_RT_CLOCK_STATUS 0x05
#define ACPI_BITREG_WAKE_STATUS 0x06
#define ACPI_BITREG_PCIEXP_WAKE_STATUS 0x07
/* PM1 Enable register */
#define ACPI_BITREG_TIMER_ENABLE 0x08
#define ACPI_BITREG_GLOBAL_LOCK_ENABLE 0x09
#define ACPI_BITREG_POWER_BUTTON_ENABLE 0x0A
#define ACPI_BITREG_SLEEP_BUTTON_ENABLE 0x0B
#define ACPI_BITREG_RT_CLOCK_ENABLE 0x0C
#define ACPI_BITREG_PCIEXP_WAKE_DISABLE 0x0D
/* PM1 Control register */
#define ACPI_BITREG_SCI_ENABLE 0x0E
#define ACPI_BITREG_BUS_MASTER_RLD 0x0F
#define ACPI_BITREG_GLOBAL_LOCK_RELEASE 0x10
#define ACPI_BITREG_SLEEP_TYPE 0x11
#define ACPI_BITREG_SLEEP_ENABLE 0x12
/* PM2 Control register */
#define ACPI_BITREG_ARB_DISABLE 0x13
#define ACPI_BITREG_MAX 0x13
#define ACPI_NUM_BITREG ACPI_BITREG_MAX + 1
/* Status register values. A 1 clears a status bit. 0 = no effect */
#define ACPI_CLEAR_STATUS 1
/* Enable and Control register values */
#define ACPI_ENABLE_EVENT 1
#define ACPI_DISABLE_EVENT 0
/*
* External ACPI object definition
*/
/*
* Note: Type == ACPI_TYPE_ANY (0) is used to indicate a NULL package
* element or an unresolved named reference.
*/
union acpi_object {
acpi_object_type type; /* See definition of acpi_ns_type for values */
struct {
acpi_object_type type; /* ACPI_TYPE_INTEGER */
u64 value; /* The actual number */
} integer;
struct {
acpi_object_type type; /* ACPI_TYPE_STRING */
u32 length; /* # of bytes in string, excluding trailing null */
char *pointer; /* points to the string value */
} string;
struct {
acpi_object_type type; /* ACPI_TYPE_BUFFER */
u32 length; /* # of bytes in buffer */
u8 *pointer; /* points to the buffer */
} buffer;
struct {
acpi_object_type type; /* ACPI_TYPE_PACKAGE */
u32 count; /* # of elements in package */
union acpi_object *elements; /* Pointer to an array of ACPI_OBJECTs */
} package;
struct {
acpi_object_type type; /* ACPI_TYPE_LOCAL_REFERENCE */
acpi_object_type actual_type; /* Type associated with the Handle */
acpi_handle handle; /* object reference */
} reference;
struct {
acpi_object_type type; /* ACPI_TYPE_PROCESSOR */
u32 proc_id;
acpi_io_address pblk_address;
u32 pblk_length;
} processor;
struct {
acpi_object_type type; /* ACPI_TYPE_POWER */
u32 system_level;
u32 resource_order;
} power_resource;
};
/*
* List of objects, used as a parameter list for control method evaluation
*/
struct acpi_object_list {
u32 count;
union acpi_object *pointer;
};
/*
* Miscellaneous common Data Structures used by the interfaces
*/
#define ACPI_NO_BUFFER 0
ACPICA: OSL: Add configurability for memory allocation macros. OSPMs like Linux trend to include all header files but leave empty stub macros for a feature that is not configured during build. For macros defined without other symbols referencesd it is safe to leave them without protections. By investigation, there are only the following internal/external symbols referenced by the ACPICA macros: 1. C library symbols, including string, ctype, stdarg APIs. Since such symbols are always accessbile in the kernel source tree, it is safe to leave macros referencing them without protected for Linux. 2. ACPICA OSL symbols, such symbols are designed to be used only by ACPICA internal APIs. And there are macros directly referencing mutex and memory allocation OSL symbols. We need to examine the external usages of such macros. For macros referencing the mutex OSL symbols, fortunately, there is no external user directly invoking such macros. ======================================================================== !! IMPORTANT !! ======================================================================== For macros referencing memory allocation OSL symbols - 1. 'free' - ACPI_FREE 2. 'alloc' - ACPI_ALLOCATE, ACPI_ALLOCATE_ZEROED, ACPI_ALLOCATE_BUFFER, ACPI_ALLOCATE_LOCAL_BUFFER there are external users directly invoking 'alloc' macros. And the more complicated situation is the reversals of such macros are not ACPI_FREE but acpi_os_free (or kfree) in Linux. Though we can define such macros into no-op, we in fact cannot define their reversals into no-op. This patch adds mechanism to protect ACPICA memory allocation APIs for Linux so that acpi_os_free (or kfree) invoked in Linux can have a zero address returned by 'alloc' macros to free. In this way, acpi_os_free (or kfree) can be converted into no-op. ======================================================================== 3. ACPI_OFFSET and other macros that would access structure members, we need to check if such structure members are not accessible under a specific configuration. Fortunately, currently Linux doesn't use such structure members when CONFIG_ACPI is disabled. This patch thus only adds mechanism useful for implementing stubs for ACPICA provided macros - the configurability of memory allocation APIs. This patch doesn't include code for Linux to use this new mechanism, thus no functional changes. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 10:04:42 +08:00
#ifdef ACPI_NO_MEM_ALLOCATIONS
#define ACPI_ALLOCATE_BUFFER (acpi_size) (0)
#define ACPI_ALLOCATE_LOCAL_BUFFER (acpi_size) (0)
#else /* ACPI_NO_MEM_ALLOCATIONS */
#define ACPI_ALLOCATE_BUFFER (acpi_size) (-1) /* Let ACPICA allocate buffer */
#define ACPI_ALLOCATE_LOCAL_BUFFER (acpi_size) (-2) /* For internal use only (enables tracking) */
ACPICA: OSL: Add configurability for memory allocation macros. OSPMs like Linux trend to include all header files but leave empty stub macros for a feature that is not configured during build. For macros defined without other symbols referencesd it is safe to leave them without protections. By investigation, there are only the following internal/external symbols referenced by the ACPICA macros: 1. C library symbols, including string, ctype, stdarg APIs. Since such symbols are always accessbile in the kernel source tree, it is safe to leave macros referencing them without protected for Linux. 2. ACPICA OSL symbols, such symbols are designed to be used only by ACPICA internal APIs. And there are macros directly referencing mutex and memory allocation OSL symbols. We need to examine the external usages of such macros. For macros referencing the mutex OSL symbols, fortunately, there is no external user directly invoking such macros. ======================================================================== !! IMPORTANT !! ======================================================================== For macros referencing memory allocation OSL symbols - 1. 'free' - ACPI_FREE 2. 'alloc' - ACPI_ALLOCATE, ACPI_ALLOCATE_ZEROED, ACPI_ALLOCATE_BUFFER, ACPI_ALLOCATE_LOCAL_BUFFER there are external users directly invoking 'alloc' macros. And the more complicated situation is the reversals of such macros are not ACPI_FREE but acpi_os_free (or kfree) in Linux. Though we can define such macros into no-op, we in fact cannot define their reversals into no-op. This patch adds mechanism to protect ACPICA memory allocation APIs for Linux so that acpi_os_free (or kfree) invoked in Linux can have a zero address returned by 'alloc' macros to free. In this way, acpi_os_free (or kfree) can be converted into no-op. ======================================================================== 3. ACPI_OFFSET and other macros that would access structure members, we need to check if such structure members are not accessible under a specific configuration. Fortunately, currently Linux doesn't use such structure members when CONFIG_ACPI is disabled. This patch thus only adds mechanism useful for implementing stubs for ACPICA provided macros - the configurability of memory allocation APIs. This patch doesn't include code for Linux to use this new mechanism, thus no functional changes. Lv Zheng. Signed-off-by: Lv Zheng <lv.zheng@intel.com> Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2014-04-30 10:04:42 +08:00
#endif /* ACPI_NO_MEM_ALLOCATIONS */
struct acpi_buffer {
acpi_size length; /* Length in bytes of the buffer */
void *pointer; /* pointer to buffer */
};
/*
* name_type for acpi_get_name
*/
#define ACPI_FULL_PATHNAME 0
#define ACPI_SINGLE_NAME 1
#define ACPI_FULL_PATHNAME_NO_TRAILING 2
#define ACPI_NAME_TYPE_MAX 2
/*
* Predefined Namespace items
*/
struct acpi_predefined_names {
const char *name;
u8 type;
char *val;
};
/*
* Structure and flags for acpi_get_system_info
*/
#define ACPI_SYS_MODE_UNKNOWN 0x0000
#define ACPI_SYS_MODE_ACPI 0x0001
#define ACPI_SYS_MODE_LEGACY 0x0002
#define ACPI_SYS_MODES_MASK 0x0003
/*
* System info returned by acpi_get_system_info()
*/
struct acpi_system_info {
u32 acpi_ca_version;
u32 flags;
u32 timer_resolution;
u32 reserved1;
u32 reserved2;
u32 debug_level;
u32 debug_layer;
};
/*
* System statistics returned by acpi_get_statistics()
*/
struct acpi_statistics {
u32 sci_count;
u32 gpe_count;
u32 fixed_event_count[ACPI_NUM_FIXED_EVENTS];
u32 method_count;
};
/*
* Types specific to the OS service interfaces
*/
typedef u32
(ACPI_SYSTEM_XFACE * acpi_osd_handler) (void *context);
typedef void
(ACPI_SYSTEM_XFACE * acpi_osd_exec_callback) (void *context);
/*
* Various handlers and callback procedures
*/
typedef
u32 (*acpi_sci_handler) (void *context);
typedef
void (*acpi_gbl_event_handler) (u32 event_type,
acpi_handle device,
u32 event_number, void *context);
#define ACPI_EVENT_TYPE_GPE 0
#define ACPI_EVENT_TYPE_FIXED 1
typedef
u32(*acpi_event_handler) (void *context);
typedef
u32 (*acpi_gpe_handler) (acpi_handle gpe_device, u32 gpe_number, void *context);
typedef
void (*acpi_notify_handler) (acpi_handle device, u32 value, void *context);
typedef
void (*acpi_object_handler) (acpi_handle object, void *data);
typedef
acpi_status (*acpi_init_handler) (acpi_handle object, u32 function);
#define ACPI_INIT_DEVICE_INI 1
typedef
acpi_status (*acpi_exception_handler) (acpi_status aml_status,
acpi_name name,
u16 opcode,
u32 aml_offset, void *context);
/* Table Event handler (Load, load_table, etc.) and types */
typedef
acpi_status (*acpi_table_handler) (u32 event, void *table, void *context);
/* Table Event Types */
#define ACPI_TABLE_EVENT_LOAD 0x0
#define ACPI_TABLE_EVENT_UNLOAD 0x1
#define ACPI_TABLE_EVENT_INSTALL 0x2
#define ACPI_TABLE_EVENT_UNINSTALL 0x3
#define ACPI_NUM_TABLE_EVENTS 4
/* Address Spaces (For Operation Regions) */
typedef
acpi_status (*acpi_adr_space_handler) (u32 function,
acpi_physical_address address,
u32 bit_width,
u64 *value,
void *handler_context,
void *region_context);
#define ACPI_DEFAULT_HANDLER NULL
/* Special Context data for generic_serial_bus/general_purpose_io (ACPI 5.0) */
struct acpi_connection_info {
u8 *connection;
u16 length;
u8 access_length;
};
typedef
acpi_status (*acpi_adr_space_setup) (acpi_handle region_handle,
u32 function,
void *handler_context,
void **region_context);
#define ACPI_REGION_ACTIVATE 0
#define ACPI_REGION_DEACTIVATE 1
typedef
acpi_status (*acpi_walk_callback) (acpi_handle object,
u32 nesting_level,
void *context, void **return_value);
typedef
u32 (*acpi_interface_handler) (acpi_string interface_name, u32 supported);
/* Interrupt handler return values */
#define ACPI_INTERRUPT_NOT_HANDLED 0x00
#define ACPI_INTERRUPT_HANDLED 0x01
/* GPE handler return values */
#define ACPI_REENABLE_GPE 0x80
/* Length of 32-bit EISAID values when converted back to a string */
#define ACPI_EISAID_STRING_SIZE 8 /* Includes null terminator */
/* Length of UUID (string) values */
#define ACPI_UUID_LENGTH 16
/* Length of 3-byte PCI class code values when converted back to a string */
#define ACPI_PCICLS_STRING_SIZE 7 /* Includes null terminator */
/* Structures used for device/processor HID, UID, CID */
struct acpi_pnp_device_id {
u32 length; /* Length of string + null */
char *string;
};
struct acpi_pnp_device_id_list {
u32 count; /* Number of IDs in Ids array */
u32 list_size; /* Size of list, including ID strings */
struct acpi_pnp_device_id ids[]; /* ID array */
};
/*
* Structure returned from acpi_get_object_info.
* Optimized for both 32-bit and 64-bit builds.
*/
struct acpi_device_info {
u32 info_size; /* Size of info, including ID strings */
u32 name; /* ACPI object Name */
acpi_object_type type; /* ACPI object Type */
u8 param_count; /* If a method, required parameter count */
u16 valid; /* Indicates which optional fields are valid */
u8 flags; /* Miscellaneous info */
u8 highest_dstates[4]; /* _sx_d values: 0xFF indicates not valid */
u8 lowest_dstates[5]; /* _sx_w values: 0xFF indicates not valid */
u64 address; /* _ADR value */
struct acpi_pnp_device_id hardware_id; /* _HID value */
struct acpi_pnp_device_id unique_id; /* _UID value */
struct acpi_pnp_device_id class_code; /* _CLS value */
struct acpi_pnp_device_id_list compatible_id_list; /* _CID list <must be last> */
};
/* Values for Flags field above (acpi_get_object_info) */
#define ACPI_PCI_ROOT_BRIDGE 0x01
/* Flags for Valid field above (acpi_get_object_info) */
#define ACPI_VALID_ADR 0x0002
#define ACPI_VALID_HID 0x0004
#define ACPI_VALID_UID 0x0008
#define ACPI_VALID_CID 0x0020
#define ACPI_VALID_CLS 0x0040
#define ACPI_VALID_SXDS 0x0100
#define ACPI_VALID_SXWS 0x0200
/* Flags for _STA method */
#define ACPI_STA_DEVICE_PRESENT 0x01
#define ACPI_STA_DEVICE_ENABLED 0x02
#define ACPI_STA_DEVICE_UI 0x04
ACPI: ACPICA 20060421 Removed a device initialization optimization introduced in 20051216 where the _STA method was not run unless an _INI was also present for the same device. This optimization could cause problems because it could allow _INI methods to be run within a not-present device subtree (If a not-present device had no _INI, _STA would not be run, the not-present status would not be discovered, and the children of the device would be incorrectly traversed.) Implemented a new _STA optimization where namespace subtrees that do not contain _INI are identified and ignored during device initialization. Selectively running _STA can significantly improve boot time on large machines (with assistance from Len Brown.) Implemented support for the device initialization case where the returned _STA flags indicate a device not-present but functioning. In this case, _INI is not run, but the device children are examined for presence, as per the ACPI specification. Implemented an additional change to the IndexField support in order to conform to MS behavior. The value written to the Index Register is not simply a byte offset, it is a byte offset in units of the access width of the parent Index Field. (Fiodor Suietov) Defined and deployed a new OSL interface, acpi_os_validate_address(). This interface is called during the creation of all AML operation regions, and allows the host OS to exert control over what addresses it will allow the AML code to access. Operation Regions whose addresses are disallowed will cause a runtime exception when they are actually accessed (will not affect or abort table loading.) Defined and deployed a new OSL interface, acpi_os_validate_interface(). This interface allows the host OS to match the various "optional" interface/behavior strings for the _OSI predefined control method as appropriate (with assistance from Bjorn Helgaas.) Restructured and corrected various problems in the exception handling code paths within DsCallControlMethod and DsTerminateControlMethod in dsmethod (with assistance from Takayoshi Kochi.) Modified the Linux source converter to ignore quoted string literals while converting identifiers from mixed to lower case. This will correct problems with the disassembler and other areas where such strings must not be modified. The ACPI_FUNCTION_* macros no longer require quotes around the function name. This allows the Linux source converter to convert the names, now that the converter ignores quoted strings. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-22 05:15:00 +08:00
#define ACPI_STA_DEVICE_FUNCTIONING 0x08
#define ACPI_STA_DEVICE_OK 0x08 /* Synonym */
#define ACPI_STA_BATTERY_PRESENT 0x10
/* Context structs for address space handlers */
struct acpi_pci_id {
u16 segment;
u16 bus;
u16 device;
u16 function;
};
ACPICA: Preserve memory opregion mappings The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once which may be problematic at least in principle (for example, it may lead to conflicts with overlapping mappings having different attributes created by drivers). It may also be wasteful, because memory opregions on some systems take up vast chunks of address space while the fields in those regions actually accessed by AML are sparsely distributed. For this reason, a one-page "window" is mapped for a given opregion on the first memory access through it and if that "window" does not cover an address range accessed through that opregion subsequently, it is unmapped and a new "window" is mapped to replace it. Next, if the new "window" is not sufficient to acess memory through the opregion in question in the future, it will be replaced with yet another "window" and so on. That may lead to a suboptimal sequence of memory mapping and unmapping operations, for example if two fields in one opregion separated from each other by a sufficiently wide chunk of unused address space are accessed in an alternating pattern. The situation may still be suboptimal if the deferred unmapping introduced previously is supported by the OS layer. For instance, the alternating memory access pattern mentioned above may produce a relatively long list of mappings to release with substantial duplication among the entries in it, which could be avoided if acpi_ex_system_memory_space_handler() did not release the mapping used by it previously as soon as the current access was not covered by it. In order to improve that, modify acpi_ex_system_memory_space_handler() to preserve all of the memory mappings created by it until the memory regions associated with them go away. Accordingly, update acpi_ev_system_memory_region_setup() to unmap all memory associated with memory opregions that go away. Reported-by: Dan Williams <dan.j.williams@intel.com> Tested-by: Xiang Li <xiang.z.li@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-30 19:40:59 +08:00
struct acpi_mem_mapping {
acpi_physical_address physical_address;
u8 *logical_address;
acpi_size length;
struct acpi_mem_mapping *next_mm;
};
struct acpi_mem_space_context {
u32 length;
acpi_physical_address address;
ACPICA: Preserve memory opregion mappings The ACPICA's strategy with respect to the handling of memory mappings associated with memory operation regions is to avoid mapping the entire region at once which may be problematic at least in principle (for example, it may lead to conflicts with overlapping mappings having different attributes created by drivers). It may also be wasteful, because memory opregions on some systems take up vast chunks of address space while the fields in those regions actually accessed by AML are sparsely distributed. For this reason, a one-page "window" is mapped for a given opregion on the first memory access through it and if that "window" does not cover an address range accessed through that opregion subsequently, it is unmapped and a new "window" is mapped to replace it. Next, if the new "window" is not sufficient to acess memory through the opregion in question in the future, it will be replaced with yet another "window" and so on. That may lead to a suboptimal sequence of memory mapping and unmapping operations, for example if two fields in one opregion separated from each other by a sufficiently wide chunk of unused address space are accessed in an alternating pattern. The situation may still be suboptimal if the deferred unmapping introduced previously is supported by the OS layer. For instance, the alternating memory access pattern mentioned above may produce a relatively long list of mappings to release with substantial duplication among the entries in it, which could be avoided if acpi_ex_system_memory_space_handler() did not release the mapping used by it previously as soon as the current access was not covered by it. In order to improve that, modify acpi_ex_system_memory_space_handler() to preserve all of the memory mappings created by it until the memory regions associated with them go away. Accordingly, update acpi_ev_system_memory_region_setup() to unmap all memory associated with memory opregions that go away. Reported-by: Dan Williams <dan.j.williams@intel.com> Tested-by: Xiang Li <xiang.z.li@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2020-06-30 19:40:59 +08:00
struct acpi_mem_mapping *cur_mm;
struct acpi_mem_mapping *first_mm;
};
/*
* struct acpi_memory_list is used only if the ACPICA local cache is enabled
*/
struct acpi_memory_list {
const char *list_name;
void *list_head;
u16 object_size;
u16 max_depth;
u16 current_depth;
#ifdef ACPI_DBG_TRACK_ALLOCATIONS
/* Statistics for debug memory tracking only */
u32 total_allocated;
u32 total_freed;
u32 max_occupied;
u32 total_size;
u32 current_total_size;
u32 requests;
u32 hits;
#endif
};
/* Definitions of trace event types */
typedef enum {
ACPI_TRACE_AML_METHOD,
ACPI_TRACE_AML_OPCODE,
ACPI_TRACE_AML_REGION
} acpi_trace_event_type;
/* Definitions of _OSI support */
#define ACPI_VENDOR_STRINGS 0x01
#define ACPI_FEATURE_STRINGS 0x02
#define ACPI_ENABLE_INTERFACES 0x00
#define ACPI_DISABLE_INTERFACES 0x04
#define ACPI_DISABLE_ALL_VENDOR_STRINGS (ACPI_DISABLE_INTERFACES | ACPI_VENDOR_STRINGS)
#define ACPI_DISABLE_ALL_FEATURE_STRINGS (ACPI_DISABLE_INTERFACES | ACPI_FEATURE_STRINGS)
#define ACPI_DISABLE_ALL_STRINGS (ACPI_DISABLE_INTERFACES | ACPI_VENDOR_STRINGS | ACPI_FEATURE_STRINGS)
#define ACPI_ENABLE_ALL_VENDOR_STRINGS (ACPI_ENABLE_INTERFACES | ACPI_VENDOR_STRINGS)
#define ACPI_ENABLE_ALL_FEATURE_STRINGS (ACPI_ENABLE_INTERFACES | ACPI_FEATURE_STRINGS)
#define ACPI_ENABLE_ALL_STRINGS (ACPI_ENABLE_INTERFACES | ACPI_VENDOR_STRINGS | ACPI_FEATURE_STRINGS)
#define ACPI_OSI_WIN_2000 0x01
#define ACPI_OSI_WIN_XP 0x02
#define ACPI_OSI_WIN_XP_SP1 0x03
#define ACPI_OSI_WINSRV_2003 0x04
#define ACPI_OSI_WIN_XP_SP2 0x05
#define ACPI_OSI_WINSRV_2003_SP1 0x06
#define ACPI_OSI_WIN_VISTA 0x07
#define ACPI_OSI_WINSRV_2008 0x08
#define ACPI_OSI_WIN_VISTA_SP1 0x09
#define ACPI_OSI_WIN_VISTA_SP2 0x0A
#define ACPI_OSI_WIN_7 0x0B
#define ACPI_OSI_WIN_8 0x0C
#define ACPI_OSI_WIN_8_1 0x0D
#define ACPI_OSI_WIN_10 0x0E
#define ACPI_OSI_WIN_10_RS1 0x0F
#define ACPI_OSI_WIN_10_RS2 0x10
#define ACPI_OSI_WIN_10_RS3 0x11
#define ACPI_OSI_WIN_10_RS4 0x12
#define ACPI_OSI_WIN_10_RS5 0x13
#define ACPI_OSI_WIN_10_19H1 0x14
/* Definitions of getopt */
#define ACPI_OPT_END -1
/* Definitions for explicit fallthrough */
#ifndef ACPI_FALLTHROUGH
#define ACPI_FALLTHROUGH do {} while(0)
#endif
#endif /* __ACTYPES_H__ */