An error occurred fetching the project authors.
  1. 01 Jul, 2015 1 commit
    • Lv Zheng's avatar
      ACPICA: Hardware: Enable firmware waking vector for both 32-bit and 64-bit FACS · f06147f9
      Lv Zheng authored
      ACPICA commit 368eb60778b27b6ae94d3658ddc902ca1342a963
      ACPICA commit 70f62a80d65515e1285fdeeb50d94ee6f07df4bd
      ACPICA commit a04dbfa308a48ab0b2d10519c54a6c533c5c8949
      ACPICA commit ebd544ed24c5a4faba11f265e228b7a821a729f5
      
      The following commit is reported to have broken s2ram on some platforms:
       Commit: 0249ed24
       ACPICA: Add option to favor 32-bit FADT addresses.
      The platform reports 2 FACS tables (which is not allowed by ACPI
      specification) and the new 32-bit address favor rule forces OSPMs to use
      the FACS table reported via FADT's X_FIRMWARE_CTRL field.
      
      The root cause of the reported bug might be one of the followings:
      1. BIOS may favor the 64-bit firmware waking vector address when the
         version of the FACS is greater than 0 and Linux currently only supports
         resuming from the real mode, so the 64-bit firmware waking vector has
         never been set and might be invalid to BIOS while the commit enables
         higher version FACS.
      2. BIOS may favor the FACS reported via the "FIRMWARE_CTRL" field in the
         FADT while the commit doesn't set the firmware waking vector address of
         the FACS reported by "FIRMWARE_CTRL", it only sets the firware waking
         vector address of the FACS reported by "X_FIRMWARE_CTRL".
      
      This patch excludes the cases that can trigger the bugs caused by the root
      cause 2.
      
      There is no handshaking mechanism can be used by OSPM to tell BIOS which
      FACS is currently used. Thus the FACS reported by "FIRMWARE_CTRL" may still
      be used by BIOS and the 0 value of the 32-bit firmware waking vector might
      trigger such failure.
      
      This patch enables the firmware waking vectors for both 32bit/64bit FACS
      tables in order to ensure we can exclude the cases that trigger the bugs
      caused by the root cause 2. The exclusion is split into 2 commits so that
      if it turns out not to be necessary, this single commit can be reverted
      without affecting the useful one. Lv Zheng, Bob Moore.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=74021
      Link: https://github.com/acpica/acpica/commit/368eb607
      Link: https://github.com/acpica/acpica/commit/70f62a80
      Link: https://github.com/acpica/acpica/commit/a04dbfa3
      Link: https://github.com/acpica/acpica/commit/ebd544edReported-and-tested-by: default avatarOswald Buddenhagen <ossi@kde.org>
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f06147f9
  2. 14 Apr, 2015 2 commits
  3. 05 Feb, 2015 1 commit
  4. 27 Nov, 2014 1 commit
  5. 08 Jul, 2014 2 commits
    • Lv Zheng's avatar
      ACPICA: Utilities: Add formatted printing APIs · 80a648c1
      Lv Zheng authored
      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: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      80a648c1
    • Lv Zheng's avatar
      ACPICA: OSL: Clean up acpi_os_printf()/acpi_os_vprintf() stubs · 83b80bac
      Lv Zheng authored
      This patch is mainly for acpidump where there are redundant
      acpi_os_printf()/acpi_os_vprintf() stubs implemented. This patch cleans up such
      specific implementation by linking acpidump to osunixxf.c/oswinxf.c.
      
      To make acpi_os_printf() exported by osunixxf.c/oswinxf.c to behave as the
      old acpidump specific ones, applications need to:
       1. Initialize acpi_gbl_db_output_flags to ACPI_DB_CONSOLE_OUTPUT.
          This is automatically done by ACPI_INIT_GLOBAL(), applications need to
          link utglobal.o to utilize this mechanism.
       2. Initialize acpi_gbl_output_file to stdout.
          For GCC, assigning stdout to acpi_gbl_output_file using ACPI_INIT_GLOBAL()
          is not possible as stdout is not a constant in GCC environment. As an
          alternative solution, stdout assignment is put into acpi_os_initialize().
          Thus acpi_os_initialize() need to be invoked very early by the
          applications to initialize the default output of acpi_os_printf().
      
      This patch also releases osunixxf.c to the Linux kernel. Lv Zheng.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarBob Moore <robert.moore@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      83b80bac
  6. 13 May, 2014 1 commit
  7. 06 May, 2014 2 commits
  8. 20 Apr, 2014 4 commits
  9. 26 Mar, 2014 3 commits
  10. 18 Mar, 2014 2 commits
  11. 26 Feb, 2014 1 commit
  12. 10 Feb, 2014 1 commit
  13. 27 Jan, 2014 1 commit
  14. 08 Jan, 2014 3 commits
  15. 31 Oct, 2013 1 commit
  16. 23 Sep, 2013 2 commits
  17. 13 Aug, 2013 1 commit
  18. 15 Jun, 2013 1 commit
  19. 12 Apr, 2013 1 commit
  20. 11 Mar, 2013 2 commits
  21. 25 Jan, 2013 2 commits
  22. 11 Jan, 2013 1 commit
  23. 10 Jan, 2013 2 commits
    • Lv Zheng's avatar
      ACPICA: Cleanup source to reduce differences between Linux and ACPICA. · 739dcbb9
      Lv Zheng authored
      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 389 lines of 20121018 divergence.diff.
      
      This patch reduces source code diff caused by the simple code maintenance
      work:
      1. Deletion of the unused include files.
      2. Deletion of the deprecated codes blocks.
      3. Repositioning of the code blocks.
      4. Replacing the values with the well defined macros.
      5. Replacing the types with the equivalent types.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      739dcbb9
    • Lv Zheng's avatar
      ACPICA: Update codes under disabled build options. · 56324c10
      Lv Zheng authored
      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 170 lines of 20121018 divergence.diff.
      
      This patch updates ACPICA codes surrounded by some disabled build options
      so that the source code diff between Linux and ACPICA can be reduced.
      
      Some of these build options may never be used in the kernel, so they may
      be deleted entirely in future patches.
      Signed-off-by: default avatarLv Zheng <lv.zheng@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      56324c10
  24. 14 Nov, 2012 2 commits