1. 14 4月, 2015 1 次提交
  2. 05 2月, 2015 1 次提交
  3. 31 7月, 2014 1 次提交
  4. 08 7月, 2014 6 次提交
    • L
      ACPICA: acpidump: Reduce freopen() invocations to improve portability · 846d6ef4
      Lv Zheng 提交于
      This patch reduces the requirement of invoking freopen() in acpidump in order
      to reduce the porting effort of acpidump.
      
      This patch achieves this by turning all acpi_os_printf(stdout) into
      acpi_ut_file_printf(gbl_output_file). 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>
      846d6ef4
    • 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: Clean up acpi_os_printf()/acpi_os_vprintf() stubs · 83b80bac
      Lv Zheng 提交于
      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: 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>
      83b80bac
    • L
      ACPICA: Utilities: Add support to read table from files · e740304c
      Lv Zheng 提交于
      After the new table reading utility functions are well tested, acpidump can
      also switch to use the generic acpi_ut_read_table_xxx() APIs. Currently
      this patch is no-op as acpidump does not link to the new APIs.
      
      This patch is only useful for ACPICA applications, most of which are not
      shipped in the Linux kernel.
      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>
      e740304c
    • L
      ACPICA: Utilities: Fix an issue with non-native ACPI_IS_PRINT() · ae8ffc7d
      Lv Zheng 提交于
      An error was found in the ACPICA provided non-native ACPI_IS_PRINT() causing the
      following difference with the native isprint() implementation:
        The GNU libc isprint('\n') test result:
         isprint(0x20) is FALSE
        The Linux kernel isprint('\n') test result:
         ACPI: isprint(0x20) is FALSE
        The _acpi_ctype isprint('\n') test result:
         isprint(0x20) is TRUE
      
      The ACPI_IS_PRINT() macro generated for _acpi_ctype is wrong. It should use
      _ACPI_XS instead of _ACPI_SP.  _ACPI_XS is white space only. Other space
      characters should be non printable.
      
      This patch fixes this issue. For OSPMs that are using native standard
      isprint() implementations, this patch is a no-op. 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>
      ae8ffc7d
  5. 21 4月, 2014 3 次提交
  6. 18 3月, 2014 1 次提交
  7. 27 2月, 2014 1 次提交
  8. 11 2月, 2014 2 次提交
  9. 30 10月, 2013 2 次提交
  10. 23 7月, 2013 2 次提交
  11. 16 6月, 2013 2 次提交
  12. 02 6月, 2013 1 次提交
  13. 12 4月, 2013 3 次提交
  14. 12 3月, 2013 1 次提交
  15. 25 1月, 2013 1 次提交
  16. 11 1月, 2013 1 次提交
  17. 10 1月, 2013 1 次提交
  18. 15 11月, 2012 5 次提交
  19. 01 6月, 2012 1 次提交
  20. 17 1月, 2012 3 次提交
  21. 19 1月, 2011 1 次提交