1. 28 5月, 2014 1 次提交
  2. 07 5月, 2014 1 次提交
  3. 21 4月, 2014 2 次提交
  4. 13 2月, 2014 2 次提交
    • 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
    • L
      ACPICA: acpidump: Add sparse declarators support. · 7e66b46b
      Lv Zheng 提交于
      Linux kernel resident ACPICA headers include some sparse declarators for
      kernel static checkers.  This patch adds code to disable them for non
      __KERNEL__ defined code so that it is possible for the ACPICA user space
      tool's source files to be built with Linux kernel ACPICA header files
      included.  Lv Zheng.
      
      Linux kernel build is not affected by this commit.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7e66b46b
  5. 11 2月, 2014 1 次提交
  6. 05 2月, 2014 1 次提交
    • A
      ACPI: introduce CONFIG_ACPI_REDUCED_HARDWARE_ONLY · af1ae78a
      Al Stone 提交于
      ACPI hardware reduced mode exists to allow newer platforms to use a
      simpler form of ACPI that does not require supporting legacy versions
      of the specification and their associated hardware.  This mode was
      introduced in the ACPI 5.0 specification.
      
      The ACPI hardware reduced mode is supposed to be used on systems
      having the HW_REDUCED_ACPI flag set in the FADT.  ACPICA checks
      that flag to determine whether or not it should work in the HW
      reduced mode and there are pieces of code in it that will never
      be used in that case.
      
      Since some architecutres will always use the ACPI HW reduced mode,
      it doesn't make sense for them to ever compile support for anything
      else.  Thus, they should set the flag ACPI_REDUCED_HARDWARE to TRUE
      in the ACPICA source.  To enable them to do that, introduce a new
      kernel configuration option, CONFIG_ACPI_REDUCED_HARDWARE_ONLY, that
      will cause the ACPICA's ACPI_REDUCED_HARDWARE flag to be TRUE when
      set.
      
      Introducing this configuration item is based on suggestions from Lv
      Zheng saying that this does not belong in ACPICA, but rather to the
      Linux kernel itself.
      
      References: http://www.spinics.net/lists/linux-acpi/msg46369.htmlSigned-off-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NAl Stone <al.stone@linaro.org>
      [rjw: Subject and changelog]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      af1ae78a
  7. 08 1月, 2014 1 次提交
  8. 31 10月, 2013 3 次提交
  9. 30 10月, 2013 1 次提交
  10. 24 9月, 2013 1 次提交
  11. 25 1月, 2013 1 次提交
  12. 10 1月, 2013 1 次提交
    • L
      ACPICA: Cleanup indentation to reduce differences between Linux and ACPICA. · 3e8214e5
      Lv Zheng 提交于
      This is a cosmetic patch only. Comparison of the resulting binary showed
      only line number differences.
      
      This patch does not affect the generation of the Linux binary.
      This patch decreases 210 lines of 20121018 divergence.diff.
      
      The ACPICA source codes uses a totally different indentation style from the
      Linux to be compatible with other users (operating systems or BIOS).
      
      Indentation differences are critical to the release automation. There are
      two causes related to the "indentation" that are affecting the release
      automation:
      1. The ACPICA -> Linux release process is:
           ACPICA source -- acpisrc - hierarchy - indent ->
           linuxized ACPICA source -- diff ->
           linuxized ACPICA patch (x) -- human intervention ->
           linuxized ACPICA patch (o)
           Where
             'x' means "cannot be directly applied to the Linux"
             'o' means "can be directly applied to the Linux"
         Different "indent" version or "indent" options used in the "indent"
         step will lead to different divergences.
         The version of "indent" used for the current release process is:
           GNU indent 2.2.11
         The options of "indent" used for the current release process is:
           -npro -kr -i8 -ts8 -sob -l80 -ss -ncs
      2. Manual indentation prettifying work in the Linux side will also harm the
         automatically generated linuxized ACPICA patches, making them impossible
         to apply directly.
      
      This patch fixes source code differences caused by the two causes so that
      the "human intervention" can be reduced in the future.
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3e8214e5
  13. 03 10月, 2012 1 次提交
  14. 17 7月, 2012 1 次提交
  15. 29 3月, 2012 1 次提交
  16. 01 11月, 2011 1 次提交
  17. 27 7月, 2011 1 次提交
  18. 14 7月, 2011 1 次提交
  19. 19 1月, 2011 1 次提交
  20. 01 10月, 2010 1 次提交
  21. 12 8月, 2010 1 次提交
    • T
      acpi: fix bogus preemption logic · 0a7992c9
      Thomas Gleixner 提交于
      The ACPI_PREEMPTION_POINT() logic was introduced in commit 8bd108d1
      (ACPICA: add preemption point after each opcode parse).  The follow up
      commits abe1dfab, 138d1569, c084ca70 tried to fix the preemption logic
      back and forth, but nobody noticed that the usage of
      in_atomic_preempt_off() in that context is wrong.
      
      The check which guards the call of cond_resched() is:
      
          if (!in_atomic_preempt_off() && !irqs_disabled())
      
      in_atomic_preempt_off() is not intended for general use as the comment
      above the macro definition clearly says:
      
       * Check whether we were atomic before we did preempt_disable():
       * (used by the scheduler, *after* releasing the kernel lock)
      
      On a CONFIG_PREEMPT=n kernel the usage of in_atomic_preempt_off() works by
      accident, but with CONFIG_PREEMPT=y it's just broken.
      
      The whole purpose of the ACPI_PREEMPTION_POINT() is to reduce the latency
      on a CONFIG_PREEMPT=n kernel, so make ACPI_PREEMPTION_POINT() depend on
      CONFIG_PREEMPT=n and remove the in_atomic_preempt_off() check.
      
      Addresses https://bugzilla.kernel.org/show_bug.cgi?id=16210
      
      [akpm@linux-foundation.org: fix build]
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Len Brown <lenb@kernel.org>
      Cc: Francois Valenduc <francois.valenduc@tvcablenet.be>
      Cc: Lin Ming <ming.m.lin@intel.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0a7992c9
  22. 23 1月, 2010 1 次提交
  23. 16 1月, 2010 1 次提交
  24. 30 8月, 2009 1 次提交
  25. 27 5月, 2009 1 次提交
  26. 31 12月, 2008 2 次提交
  27. 19 12月, 2008 1 次提交
  28. 23 10月, 2008 1 次提交
  29. 24 4月, 2008 1 次提交
  30. 03 7月, 2007 1 次提交
  31. 10 5月, 2007 1 次提交
  32. 03 2月, 2007 1 次提交
  33. 08 12月, 2006 1 次提交
  34. 10 7月, 2006 2 次提交