litmus-rt.git/include/acpi/platform, branch master

ACPICA: Utilities: split IO address types from data type models.

2015-04-14T12:51:52+00:00

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 
Reported-and-tested-by: Sial Nije 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Cc: All applicable 
Signed-off-by: Rafael J. Wysocki

ACPICA: Update Copyright headers to 2015

2015-02-05T14:31:43+00:00

ACPICA commit 8990e73ab2aa15d6a0068b860ab54feff25bee36

Link: https://github.com/acpica/acpica/commit/8990e73a
Signed-off-by: David E. Box 
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki

Merge branch 'acpi-headers'

2014-07-27T21:52:05+00:00

* acpi-headers:
  ACPI: Add support to force header inclusion rules for .
  ACPI / SFI: Fix wrong  inclusion in SFI/ACPI wrapper - table definitions.
  ACPICA: Linux: Allow ACPICA inclusion for CONFIG_ACPI=n builds.
  ACPICA: Linux: Add support to exclude  inclusion.
  ACPICA: Linux: Add stub implementation of ACPICA 64-bit mathematics.
  ACPICA: Linux: Add stub support for Linux specific variables and functions.

ACPI: Add support to force header inclusion rules for .

2014-07-22T23:10:45+00:00

As there is only CONFIG_ACPI=n processing in the , it is not
safe to include  directly for source out of Linux ACPI
subsystems.

This patch adds error messaging to warn developers of such wrong
inclusions.

In order not to be bisected and reverted as a wrong commit, warning
messages are carefully split into a seperate patch other than the wrong
inclusion cleanups.

Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki

ACPICA: Linux: Add support to exclude inclusion.

2014-07-22T23:10:44+00:00

The forthcoming patch will make  to be visible to all kernel
source code. Thus for the architectures that do not support ACPI and
haven't implemented , we need to make it excluded.

Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki

ACPICA: Linux: Add stub implementation of ACPICA 64-bit mathematics.

2014-07-22T23:07:31+00:00

This patch adds default 64-bit mathematics in aclinux.h using do_div(). As
do_div() can be used for all Linux architectures, this can also be used as
stub macros for ACPICA 64-bit mathematics.

These macros are required by drivers/acpi/utmath.c when ACPI_USE_NATIVE_DIVIDE
is not defined.  It is used by ACPICA, so currently this is only meaningful to
CONFIG_ACPI builds.  So the kernel will not use these macros unless CONFIG_ACPI
is defined and ACPI_USE_DIVIDE is not defined.

For 64-bit kernels:
In include/acpi/actypes.h, for ACPI_MACHINE_WIDTH=64,
ACPI_USE_NATIVE_DIVIDE will be defined, thus these macros are not used.
In include/acpi/platform/aclinux.h, for __KERNEL__ surrounded code,
ACPI_MACHINE_WIDTH is defined to be BITS_PER_LONG.
So all 64-bit kernels do not use these macros.

For 32-bit kernels:
As mentioned above, these macros will be used when BITS_PER_LONG is 32.
Thus currently the i328 kernels are the only users for these macros.
But they won't use this default implementation provided by this patch,
because in arch/x86/include/asm/acenv.h, there are already overrides
implemented.  So these default macros are not used by 32-bit x86 (i386)
kernels.

These macros will only be used by future non x86 32-bit architectures
that try to support ACPI in Linux kernel.

During the period they do not have arch specific implementations of such
macros, we can avoid build errors for them.

And since they can see ACPICA functioning without implementing any arch
specific environment tunings, we  can also avoid function errors for
them.

As this implementation is not performance friendly, those architectures
still need to implement real support in the end.

Signed-off-by: Lv Zheng 
[rjw: Changelog]
Signed-off-by: Rafael J. Wysocki

ACPICA: acpidump: Add memory/string OSL usage to improve portability

2014-07-08T12:22:27+00:00

This patch adds code to use generic OSL for acpidump to improve the
portability of this tool. Lv Zheng.

Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

ACPICA: Utilities: Introduce acpi_log_error() to improve portability

2014-07-08T12:22:26+00:00

Invocations like fprintf(stderr) and perror() are not portable, this patch
introduces acpi_log_error() as a replacement, it is implemented using new
portable API - acpi_ut_file_vprintf().

Note that though acpi_os_initialize() need to be invoked prior than using
this new API, since no users are introduced in this patch, such invocations
are not added for applications that link utprint.c in this patch. Futher
patches that introduce users of acpi_log_error() should take care of this.

This patch is only useful for ACPICA applications, most of which are not
shipped in the Linux kernel.

Note that follow-up commits will update acpidump to use this new API to
improve portability. Lv Zheng.

Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

ACPICA: OSL: Update environments to improve portability

2014-07-08T12:22:25+00:00

This patch contains some environment updates that will be used by acpidump
because:
 1. The follow-up commits will release osunixxf.c to the Linux kernel for
    acpidump to link, and
 2. Such environment settings will be used to avoid linkage issues.

Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

ACPI: Clean up acpi_os_map/unmap_memory() to eliminate __iomem.

2014-05-27T16:13:08+00:00

ACPICA doesn't include protections around address space checking, Linux
build tests always complain increased sparse warnings around ACPICA
internal acpi_os_map/unmap_memory() invocations.  This patch tries to fix
this issue permanently.

There are 2 choices left for us to solve this issue:
 1. Add __iomem address space awareness into ACPICA.
 2. Remove sparse checker of __iomem from ACPICA source code.

This patch chooses solution 2, because:
 1.  Most of the acpi_os_map/unmap_memory() invocations are used for ACPICA.
     table mappings, which in fact are not IO addresses.
 2.  The only IO addresses usage is for "system memory space" mapping code in:
      drivers/acpi/acpica/exregion.c
      drivers/acpi/acpica/evrgnini.c
      drivers/acpi/acpica/exregion.c
    The mapped address is accessed in the handler of "system memory space"
    - acpi_ex_system_memory_space_handler().  This function in fact can be
    changed to invoke acpi_os_read/write_memory() so that __iomem can
    always be type-casted in the OSL layer.

According to the above investigation, we drew the following conclusion:
It is not a good idea to introduce __iomem address space awareness into
ACPICA mostly in order to protect non-IO addresses.

We can simply remove __iomem for acpi_os_map/unmap_memory() to remove
__iomem checker for ACPICA code. Then we need to enforce external usages
to invoke other APIs that are aware of __iomem address space.
The external usages are:
 drivers/acpi/apei/einj.c
 drivers/acpi/acpi_extlog.c
 drivers/char/tpm/tpm_acpi.c
 drivers/acpi/nvs.c

This patch thus performs cleanups in this way:
 1. Add acpi_os_map/unmap_iomem() to be invoked by non-ACPICA code.
 2. Remove __iomem from acpi_os_map/unmap_memory().

Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki