Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 05 2月, 2015 1 次提交
    • 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
  3. 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
  5. 21 10月, 2014 2 次提交
  7. 31 7月, 2014 2 次提交
  9. 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
  11. 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
  13. 18 3月, 2014 1 次提交
  15. 27 2月, 2014 1 次提交
  17. 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
  19. 11 2月, 2014 1 次提交
  21. 08 1月, 2014 1 次提交
  23. 31 10月, 2013 4 次提交
  25. 30 10月, 2013 2 次提交
  27. 24 9月, 2013 3 次提交
  29. 13 8月, 2013 1 次提交
  31. 23 7月, 2013 2 次提交
  33. 18 7月, 2013 1 次提交
  35. 22 4月, 2013 1 次提交
  37. 12 3月, 2013 1 次提交
  39. 25 1月, 2013 1 次提交
  41. 11 1月, 2013 1 次提交
  43. 10 1月, 2013 5 次提交
  45. 15 11月, 2012 3 次提交