1. 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
  2. 18 3月, 2014 1 次提交
  3. 27 2月, 2014 1 次提交
  4. 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
  5. 11 2月, 2014 1 次提交
  6. 08 1月, 2014 1 次提交
  7. 31 10月, 2013 4 次提交
  8. 30 10月, 2013 2 次提交
  9. 24 9月, 2013 3 次提交
  10. 13 8月, 2013 1 次提交
  11. 23 7月, 2013 2 次提交
  12. 18 7月, 2013 1 次提交
  13. 22 4月, 2013 1 次提交
  14. 12 3月, 2013 1 次提交
  15. 25 1月, 2013 1 次提交
  16. 11 1月, 2013 1 次提交
  17. 10 1月, 2013 5 次提交
  18. 15 11月, 2012 5 次提交
  19. 21 9月, 2012 1 次提交
  20. 31 7月, 2012 1 次提交
    • L
      ACPI: delete _GTS/_BFS support · 3f6f49c7
      Len Brown 提交于
      _GTS and _BFS were added to the suspend/resume flow
      in the ACPI 2.0 specification.
      
      Linux dutifully implemented _GTS and _BFS.
      We discovered that it was rarely seen in systems
      in the field.  Further, some of those systems had
      AML so bogus that it could never work -- proof that
      no other operating system supports _GTS and _BFS.
      So we made _GTS and _BFS optional via modparam,
      and disabled them by default.
      
      But we've had to complicate some code to keep
      this support in the kernel, as these methods are defined
      to be evaluated very close to sleep entry and exit.
      Indeed, no other AML is ever evaluated with interrupts off.
      
      We have submitted a proposal for _GTS and _BFS
      to be officially removed from the ACPI specification
      on the next revision.  Here we remove it from Linux.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Acked-by: NIngo Molnar <mingo@kernel.org>
      Acked-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      3f6f49c7
  21. 17 7月, 2012 2 次提交
  22. 01 6月, 2012 2 次提交
  23. 05 5月, 2012 1 次提交
    • L
      ACPI: Fix D3hot v D3cold confusion · 1cc0c998
      Lin Ming 提交于
      Before this patch, ACPI_STATE_D3 incorrectly referenced D3hot
      in some places, but D3cold in other places.
      
      After this patch, ACPI_STATE_D3 always means ACPI_STATE_D3_COLD;
      and all references to D3hot use ACPI_STATE_D3_HOT.
      
      ACPI's _PR3 method is used to enter both D3hot and D3cold states.
      What distinguishes D3hot from D3cold is the presence _PR3
      (Power Resources for D3hot)  If these resources are all ON,
      then the state is D3hot.  If _PR3 is not present,
      or all _PR0 resources for the devices are OFF,
      then the state is D3cold.
      
      This patch applies after Linux-3.4-rc1.
      A future syntax cleanup may remove ACPI_STATE_D3
      to emphasize that it always means ACPI_STATE_D3_COLD.
      Signed-off-by: NLin Ming <ming.m.lin@intel.com>
      Acked-by: NRafael J. Wysocki <rjw@sisk.pl>
      Reviewed-by: NAaron Lu <aaron.lu@amd.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      1cc0c998