1. 27 11月, 2017 1 次提交
  2. 09 2月, 2017 1 次提交
  3. 01 12月, 2016 1 次提交
  4. 10 9月, 2016 2 次提交
    • L
      ACPICA: Namespace: Add acpi_ns_get_node_unlocked() · c2d981aa
      Lv Zheng 提交于
      ACPICA commit 3ef1a1bf5612fe1a629424c09eaaeb6f299d313c
      
      Add acpi_ns_get_node_unlocked() to be used when ACPI_MTX_NAMESPACE is
      locked. Lv Zheng.
      
      Link: https://github.com/acpica/acpica/commit/3ef1a1bfTested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Tested-by: NGreg White <gwhite@kupulau.com>
      Tested-by: NDutch Guy <lucht_piloot@gmx.net>
      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>
      c2d981aa
    • L
      ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar for table loading · de56ba95
      Lv Zheng 提交于
      ACPICA commit 0e24fb67cde08d7df7671d7d7b183490dc79707e
      
      The MLC (Module Level Code) is an ACPICA terminology describing the AML
      code out of any control method, its support is an indication of the
      interpreter behavior during the table loading.
      
      The original implementation of MLC in ACPICA had several issues:
      1. Out of any control method, besides of the object creating opcodes, only
         the code blocks wrapped by "If/Else/While" opcodes were supported.
      2. The supported MLC code blocks were executed after loading the table
         rather than being executed right in place.
         ============================================================
         The demo of this order issue is as follows:
           Name (OBJ1, 1)
           If (CND1 == 1)
           {
             Name (OBJ2, 2)
           }
           Name (OBJ3, 3)
         The original MLC support created OBJ2 after OBJ3's creation.
         ============================================================
      Other than these limitations, MLC support in ACPICA looks correct. And
      supporting this should be easy/natural for ACPICA, but enabling of this was
      blocked by some ACPICA internal and OSPM specific initialization order
      issues we've fixed recently. The wrong support started from the following
      false bug fixing commit:
        Commit: 7f0c826a
        Subject: ACPICA: Add support for module-level executable AML code
        Commit: 9a884ab6
        Subject: ACPICA: Add additional module-level code support
        ...
      
      We can confirm Windows interpreter behavior via reverse engineering means.
      It can be proven that not only If/Else/While wrapped code blocks, all
      opcodes can be executed at the module level, including operation region
      accesses. And it can be proven that the MLC should be executed right in
      place, not in such a deferred way executed after loading the table.
      
      And the above facts indeed reflect the spec words around ACPI definition
      block tables (DSDT/SSDT/...), the entire table and the Scope object is
      defined by the AML specification in BNF style as:
        AMLCode := def_block_header term_list
        def_scope := scope_op pkg_length name_string term_list
      The bodies of the scope opening terms (AMLCode/Scope) are all term_list,
      thus the table loading should be no difference than the control method
      evaluations as the body of the Method is also defined by the AML
      specification as term_list:
        def_method := method_op pkg_length name_string method_flags term_list
      The only difference is: after evaluating control method, created named
      objects may be freed due to no reference, while named objects created by
      the table loading should only be freed after unloading the table.
      
      So this patch follows the spec and the de-facto standard behavior, enables
      the new grammar (term_list) for the table loading.
      
      By doing so, beyond the fixes to the above issues, we can see additional
      differences comparing to the old grammar based table loading:
      1. Originally, beyond the scope opening terms (AMLCode/Scope),
         If/Else/While wrapped code blocks under the scope creating terms
         (Device/power_resource/Processor/thermal_zone) are also supported as
         deferred MLC, which violates the spec defined grammar where object_list
         is enforced. With MLC support improved as non-deferred, the interpreter
         parses such scope creating terms as term_list rather object_list like the
         scope opening terms.
         After probing the Windows behavior and proving that it also parses these
         terms as term_list, we submitted an ECR (Engineering Change Request) to
         the ASWG (ACPI Specification Working Group) to clarify this. The ECR is
         titled as "ASL Grammar Clarification for Executable AML Opcodes" and has
         been accepted by the ASWG. The new grammar will appear in ACPI
         specification 6.2.
      2. Originally, Buffer/Package/operation_region/create_XXXField/bank_field
         arguments are evaluated in a deferred way after loading the table. With
         MLC support improved, they are also parsed right in place during the
         table loading.
         This is also Windows compliant and the only difference is the removal
         of the debugging messages implemented before acpi_ds_execute_arguments(),
         see Link # [1] for the details. A previous commit should have ensured
         that acpi_check_address_range() won't regress.
      
      Note that enabling this feature may cause regressions due to long term
      Linux ACPI support on top of the wrong grammar. So this patch also prepares
      a global option to be used to roll back to the old grammar during the
      period between a regression is reported and the regression is
      root-cause-fixed. Lv Zheng.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=112911 # [1]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=117671 # [1]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=153541 # [1]
      Link: https://github.com/acpica/acpica/issues/122
      Link: https://bugs.acpica.org/show_bug.cgi?id=963
      Link: https://github.com/acpica/acpica/commit/0e24fb67Reported-and-tested-by: NChris Bainbridge <chris.bainbridge@gmail.com>
      Reported-by: NEhsan <dashesy@gmail.com>
      Reported-and-tested-by: NDutch Guy <lucht_piloot@gmx.net>
      Tested-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      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>
      de56ba95
  5. 05 4月, 2016 1 次提交
  6. 24 2月, 2016 1 次提交
  7. 16 1月, 2016 1 次提交
  8. 01 1月, 2016 2 次提交
  9. 22 10月, 2015 1 次提交
    • L
      ACPI: Enable build of AML interpreter debugger · 4d946f79
      Lv Zheng 提交于
      This patch enables ACPICA debugger files using a configurable
      CONFIG_ACPI_DEBUGGER configuration item. Those debugger related code that
      was originally masked as ACPI_FUTURE_USAGE now gets unmasked.
      
      Necessary OSL stubs are also added in this patch:
      1. acpi_os_readable(): This should be arch specific in Linux, while this
          patch doesn't introduce real implementation and a complex mechanism to
          allow architecture specific acpi_os_readable() to be implemented to
          validate the address. It may be done by future commits.
      2. acpi_os_get_line(): This is used to obtain debugger command input. This
          patch only introduces a simple KDB concept example in it and the
          example should be co-working with the code implemented in
          acpi_os_printf(). Since this KDB example won't be compiled unless
          ENABLE_DEBUGGER is defined and it seems Linux has already stopped to
          use ENABLE_DEBUGGER, thus do not expect it can work properly.
      
      This patch also cleans up all other ACPI_FUTURE_USAGE surroundings
      accordingly.
      1. Since linkage error can be automatically detected, declaration in the
         headers needn't be surrounded by ACPI_FUTURE_USAGE.
         So only the following separate exported fuction bodies are masked by
         this macro (other exported fucntions may have already been masked at
         entire module level via drivers/acpi/acpica/Makefile):
           acpi_install_exception_handler()
           acpi_subsystem_status()
           acpi_get_system_info()
           acpi_get_statistics()
           acpi_install_initialization_handler()
      2. Since strip can automatically zap the no-user functions, functions that
         are not marked with ACPI_EXPORT_SYMBOL() needn't get surrounded by
         ACPI_FUTURE_USAGE.
         So the following function which is not used by Linux kernel now won't
         get surrounded by this macro:
           acpi_ps_get_name()
      Signed-off-by: NLv Zheng <lv.zheng@intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      4d946f79
  10. 24 7月, 2015 1 次提交
  11. 02 7月, 2015 1 次提交
  12. 05 2月, 2015 1 次提交
  13. 18 3月, 2014 1 次提交
  14. 27 2月, 2014 1 次提交
  15. 11 2月, 2014 1 次提交
  16. 24 9月, 2013 1 次提交
  17. 13 8月, 2013 1 次提交
  18. 02 6月, 2013 1 次提交
  19. 12 4月, 2013 1 次提交
  20. 12 3月, 2013 4 次提交
  21. 25 1月, 2013 1 次提交
  22. 11 1月, 2013 1 次提交
  23. 10 1月, 2013 1 次提交
  24. 30 3月, 2012 1 次提交
  25. 17 1月, 2012 1 次提交
  26. 19 1月, 2011 1 次提交
  27. 01 10月, 2010 1 次提交
  28. 07 7月, 2010 1 次提交
  29. 23 1月, 2010 2 次提交
  30. 16 12月, 2009 2 次提交
  31. 25 11月, 2009 2 次提交
  32. 29 8月, 2009 1 次提交