• Lv Zheng's avatar
    ACPICA: Interpreter: Fix MLC issues by switching to new term_list grammar for table loading · de56ba95
    Lv Zheng authored
    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: default avatarChris Bainbridge <chris.bainbridge@gmail.com>
    Reported-by: default avatarEhsan <dashesy@gmail.com>
    Reported-and-tested-by: default avatarDutch Guy <lucht_piloot@gmx.net>
    Tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
    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>
    de56ba95
evrgnini.c 17.9 KB