linux/include/acpi/actypes.h, branch v3.17

ACPICA: ACPI 5.1: New notify value for System Affinity Update.

2014-07-30T22:50:24Z

New value for the Notify() operator. Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPICA: Remove a redundant cast to acpi_size for ACPI_OFFSET() macro.

2014-07-30T22:50:22Z

It is already casted to acpi_size by ACPI_PTR_DIFF() macro. Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPICA: Common: Enhance acpi_getopt() to improve portability

2014-07-08T12:22:26Z

This patch enhances acpi_getopt() by converting the standard C library invocations into portable ACPI string APIs and acpi_log_error() to improve portability. Lv Zheng. Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: Utilities: Add formatted printing APIs

2014-07-08T12:22:25Z

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 Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: OSL: Add portable file IO to improve portability

2014-07-08T12:22:25Z

This patch adds portable file IO to generic OSL to improve the portability of the applications. A portable application may use different file IO interfaces than the standard C library ones. This patch thus introduces an abstract file IO layer into the generic OSL. Note that this patch does not introduce users of such interfaces, further patches should introduce users one by one carefully with build tests performed. Lv Zheng. Signed-off-by: Lv Zheng Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: OSL: Add configurability for memory allocation macros.

2014-05-06T22:55:00Z

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 Signed-off-by: Bob Moore Signed-off-by: Rafael J. Wysocki

ACPICA: Revert "Headers: Deploy #pragma pack (push) and (pop)."

2014-03-18T00:53:45Z

This reverts commit aae576e5faefa8ba70647efa320d4747b6375f1e. Push and Pop are not portable "enough", and caused problems for some ACPICA customers. Signed-off-by: Robert Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPICA: Headers: Deploy #pragma pack (push) and (pop).

2014-02-26T23:45:59Z

Use push and pop to both guarantee that the correct alignment is used, and to restore the alignment to whatever it was before the header was included. It is reported that the #pragma pack(push/pop) directives are not supported by the specific GCCs, but this patch still doesn't affect kernel build as there are already #pragma pack([1]) directives used in the old ACPICA headers, which means there shouldn't be GCCs that are currently used to compile the ACPI kernels do not support #pragma pack() directives. References: https://bugs.acpica.org/show_bug.cgi?id=1058 Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki

ACPICA: acpidump: Remove integer types translation protection.

2014-02-13T15:21:15Z

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 Signed-off-by: Rafael J. Wysocki

ACPICA: Update ACPICA copyrights to 2014.

2014-02-10T23:30:25Z

Update ACPICA copyrights to 2014. Includes all source headers and signons for the various tools. Signed-off-by: Bob Moore Signed-off-by: Lv Zheng Signed-off-by: Rafael J. Wysocki