Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 14 4月, 2015 2 次提交
    • L
      ACPICA: Events: Add support to return both enable/status register values for GPE and fixed event. · 09af8e82
      由 Lv Zheng 提交于 
      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/e25d791eSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      09af8e82
    • L
      ACPICA: Utilities: split IO address types from data type models. · 2b876010
      由 Lv Zheng 提交于 
      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=79501Reported-and-tested-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Reported-and-tested-by: NSial Nije <sialnije@gmail.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2b876010
  3. 05 2月, 2015 3 次提交
    • L
      ACPICA: Events: Introduce ACPI_GPE_DISPATCH_RAW_HANDLER to fix 2 issues for the current GPE APIs · 0d0988af
      由 Lv Zheng 提交于 
      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/199cad16Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0d0988af
    • D
      ACPICA: Update Copyright headers to 2015 · 82a80941
      由 David E. Box 提交于 
      ACPICA commit 8990e73ab2aa15d6a0068b860ab54feff25bee36

Link: https://github.com/acpica/acpica/commit/8990e73aSigned-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      82a80941
    • L
      ACPICA: Events: Cleanup GPE dispatcher type obtaining code · 7c43312a
      由 Lv Zheng 提交于 
      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/7926d5caSigned-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NDavid E. Box <david.e.box@linux.intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7c43312a
  5. 02 12月, 2014 1 次提交
    • R
      ACPICA: Save current masks of enabled GPEs after enable register writes · c50f13c6
      由 Rafael J. Wysocki 提交于 
      There is a race condition between acpi_hw_disable_all_gpes() or
acpi_enable_all_wakeup_gpes() and acpi_ev_asynch_enable_gpe() such
that if the latter wins the race, it may mistakenly enable a GPE
disabled by the former.  This may lead to premature system wakeups
during system suspend and potentially to more serious consequences.

The source of the problem is how acpi_hw_low_set_gpe() works when
passed ACPI_GPE_CONDITIONAL_ENABLE as the second argument.  In that
case, the GPE will be enabled if the corresponding bit is set in the
enable_for_run mask of the GPE enable register containing that bit.
However, acpi_hw_disable_all_gpes() and acpi_enable_all_wakeup_gpes()
don't modify the enable_for_run masks of GPE registers when writing
to them.  In consequence, if acpi_ev_asynch_enable_gpe(), which
eventually calls acpi_hw_low_set_gpe() with the second argument
equal to ACPI_GPE_CONDITIONAL_ENABLE, is executed in parallel with
one of these functions, it may reverse changes made by them.

To fix the problem, introduce a new enable_mask field in struct
acpi_gpe_register_info in which to store the current mask of
enabled GPEs and modify acpi_hw_low_set_gpe() to take this
mask into account instead of enable_for_run when its second
argument is equal to ACPI_GPE_CONDITIONAL_ENABLE.  Also modify
the low-level routines called by acpi_hw_disable_all_gpes(),
acpi_enable_all_wakeup_gpes() and acpi_enable_all_runtime_gpes()
to update the enable_mask masks of GPE registers after all
(successful) writes to those registers.
Acked-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      c50f13c6
  7. 21 10月, 2014 2 次提交
  9. 31 7月, 2014 2 次提交
  11. 08 7月, 2014 3 次提交
    • L
      ACPICA: Common: Enhance acpi_getopt() to improve portability · a92e9577
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a92e9577
    • L
      ACPICA: Utilities: Add formatted printing APIs · 80a648c1
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      80a648c1
    • L
      ACPICA: OSL: Add portable file IO to improve portability · 7824f44e
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7824f44e
  13. 07 5月, 2014 1 次提交
    • L
      ACPICA: OSL: Add configurability for memory allocation macros. · d5caf1cd
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d5caf1cd
  15. 18 3月, 2014 1 次提交
  17. 27 2月, 2014 1 次提交
  19. 13 2月, 2014 1 次提交
    • L
      ACPICA: acpidump: Remove integer types translation protection. · e252652f
      由 Lv Zheng 提交于 
      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: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e252652f
  21. 11 2月, 2014 1 次提交
  23. 08 1月, 2014 1 次提交
  25. 31 10月, 2013 4 次提交
  27. 30 10月, 2013 2 次提交
  29. 24 9月, 2013 3 次提交
  31. 13 8月, 2013 1 次提交
  33. 23 7月, 2013 2 次提交
  35. 18 7月, 2013 1 次提交
  37. 22 4月, 2013 1 次提交
  39. 12 3月, 2013 1 次提交
  41. 25 1月, 2013 1 次提交
  43. 11 1月, 2013 1 次提交
  45. 10 1月, 2013 4 次提交