linux-stable.git/include/acpi/actypes.h, branch v4.2.1

ACPICA: De-macroize calls to standard C library functions

2015-07-01T21:17:55+00:00

ACPICA commit 3b1026e0bdd3c32eb6d5d313f3ba0b1fee7597b4
ACPICA commit 00f0dc83f5cfca53b27a3213ae0d7719b88c2d6b
ACPICA commit 47d22a738d0e19fd241ffe4e3e9d4e198e4afc69

Across all of ACPICA. Replace C library macros such as ACPI_STRLEN with the
standard names such as strlen. The original purpose for these macros is
long since obsolete.
Also cast various invocations as necessary. Bob Moore, Jung-uk Kim, Lv Zheng.

Link: https://github.com/acpica/acpica/commit/3b1026e0
Link: https://github.com/acpica/acpica/commit/00f0dc83
Link: https://github.com/acpica/acpica/commit/47d22a73
Signed-off-by: Bob Moore 
Signed-off-by: Jung-uk Kim 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki

ACPICA: Utilities: Add _CLS processing

2015-07-01T21:17:53+00:00

ACPICA commit 9a2b638acb3a7215209432e070c6bd0312374229

ACPI Device object often contains a _CLS object to supply PCI-defined class
code for the device. This patch introduces logic to process the _CLS
object. Suravee Suthikulpanit, Lv Zheng.

Link: https://github.com/acpica/acpica/commit/9a2b638a
Acked-by: Mika Westerberg 
Reviewed-by: Hanjun Guo 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

ACPICA: Tables: Fix an issue that FACS initialization is performed twice

2015-07-01T21:17:52+00:00

ACPICA commit 90f5332a15e9d9ba83831ca700b2b9f708274658

This patch adds a new FACS initialization flag for acpi_tb_initialize().
acpi_enable_subsystem() might be invoked several times in OS bootup process,
and we don't want FACS initialization to be invoked twice. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/90f5332a
Cc: All applicable  # All applicable
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

ACPICA: ACPI 6.0: Add ACPI_SUB_PTR().

2015-05-22T01:22:20+00:00

ACPICA commit 5de82757aef5d6163e37064033aacbce193abbca

Using a minus number with ACPI_ADD_PTR() will cause compiler warnings, such
warnings cannot be eliminated by force casting an unsigned value to a
signed value. This patch thus introduces ACPI_SUB_PTR() to be used with
minus numbers. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/5de82757
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

ACPICA: Divergence: Remove redundant definitions.

2015-05-19T00:20:23+00:00

There are two same "define"s in the actypes.h for ACPI_USE_NATIVE_DIVIDE,
this patch removes one of them as it is useless and is not in the ACPICA
upstream. It is likely that the useless block is there because of the
issues in the old ACPICA release process.

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

ACPICA: remove duplicate u8 typedef

2015-04-28T21:58:54+00:00

During commit e252652fb266 ("ACPICA: acpidump: Remove integer types
translation protection.") two 'unsigned char' types got converted to 'u8'.

The result does not compile with gcc-4.5, it can not cope with duplicate
typedefs.

Signed-off-by: Olaf Hering 
Signed-off-by: Rafael J. Wysocki

ACPICA: Store GPE register enable masks upfront

2015-04-15T02:00:27+00:00

It is reported that ACPI interrupts do not work any more on
Dell Latitude D600 after commit c50f13c672df (ACPICA: Save
current masks of enabled GPEs after enable register writes).
The problem turns out to be related to the fact that the
enable_mask and enable_for_run GPE bit masks are not in
sync (in the absence of any system suspend/resume events)
for at least one GPE register on that machine.

Address this problem by writing the enable_for_run mask into
enable_mask as soon as enable_for_run is updated instead of
doing that only after the subsequent register write has
succeeded.  For consistency, update acpi_hw_gpe_enable_write()
to store the bit mask to be written into the GPE register
in enable_mask unconditionally before the write.

Since the ACPI_GPE_SAVE_MASK flag is not necessary any more after
that, drop it along with the symbols depending on it.

Reported-and-tested-by: Jim Bos 
Fixes: c50f13c672df (ACPICA: Save current masks of enabled GPEs after enable register writes)
Cc: 3.19+  # 3.19+
Signed-off-by: Rafael J. Wysocki

ACPICA: Add "Windows 2015" string to _OSI support.

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

ACPICA commit b293f602a67da478ae0bec129e68bd99787d9908

This change adds this string for Windows 10.

Link: https://github.com/acpica/acpica/commit/b293f602
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
Signed-off-by: Rafael J. Wysocki

ACPICA: Events: Add support to return both enable/status register values for GPE and fixed event.

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

ACPICA commit e25d791e4b3d5b9f4ead298269610cb05f89749a

There is a facility in Linux, developers can obtain GPE and fixed event
status via /sys/firmware/interrupts/. This is implemented using
acpi_get_event_status() and acpi_get_gpe_status(). Recently while debugging some
GPE race issues, it is found that the facility is lacking in the ability to
obtain real hardware register values, the confusing information makes
debugging difficult.

This patch modifies acpi_get_gpe_status() to return EN register values to fix
this gap. Then flags returned from acpi_get_event_status() and
acpi_get_gpe_status() are also cleaned up to reflect this change.

The old ACPI_EVENT_FLAG_SET is carefully kept to avoid regressions. It can
be deleted after we can make sure all its references are removed from OSPM
code. Lv Zheng.

Link: https://github.com/acpica/acpica/commit/e25d791e
Signed-off-by: Lv Zheng 
Signed-off-by: Bob Moore 
Signed-off-by: Rafael J. Wysocki

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