Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 18 2月, 2019 1 次提交
    • E
      ACPICA: Remove legacy module-level code support · aa342261
      由 Erik Schmauss 提交于 
      ACPICA commit 47f5607c204719d9239a12b889df725225098c8f

Module-level code refers to executable ASL code that runs during
table load. This is typically used in ASL to declare named objects
based on a condition evaluated during table load like so:

definition_block(...)
{
  opreation_region (OPR1, system_memory, ...)
  Field (OPR1)
  {
    FLD1, 8 /* Assume that FLD1's value is 0x1 */
  }

  /* The if statement below is referred to as module-level code */

  If (FLD1)
  {
    /* Declare DEV1 conditionally */
    Device (DEV1) {...}
  }

  Device (DEV2)
  {
    ...
  }
}

In legacy module-level code, the execution of the If statement
was deferred after other modules were loaded. The order of
code execution for the table above is the following:

1.) Load OPR1 to the ACPI Namespace
2.) Load FLD1 to the ACPI Namespace (not intended for drivers)
3.) Load DEV2 to the ACPI Namespace
4.) Execute If (FLD1) and load DEV1 if the condition is true

This legacy approach can be problematic for tables that look like the
following:

definition_block(...)
{
  opreation_region (OPR1, system_memory, ...)
  Field (OPR1)
  {
    FLD1, 8 /* Assume that FLD1's value is 0x1 */
  }

  /* The if statement below is referred to as module-level code */

  If (FLD1)
  {
    /* Declare DEV1 conditionally */
    Device (DEV1) {...}
  }

  Scope (DEV1)
  {
    /* Add objects DEV1's scope */
    Name (OBJ1, 0x1234)
  }
}

When loading this in the legacy approach, Scope DEV1 gets evaluated
before the If statement. The following is the order of execution:

1.) Load OPR1 to the ACPI Namespace
2.) Load FLD1 to the ACPI Namespace (not intended for drivers)
3.) Add OBJ1 under DEV1's scope -- ERROR. DEV1 does not exist
4.) Execute If (FLD1) and load DEV1 if the condition is true

The legacy approach can never succeed for tables like this due to the
deferral of the module-level code. Due to this limitation, a new
module-level code was developed. This new approach exeutes if
statements in the order that they appear in the definition block.
With this approach, the order of execution for the above defintion
block is as follows:

1.) Load OPR1 to the ACPI Namespace
2.) Load FLD1 to the ACPI Namespace (not intended for drivers)
3.) Execute If (FLD1) and load DEV1 because the condition is true
4.) Add OBJ1 under DEV1's scope.

Since DEV1 is loaded in the namespace in step 3, step 4 executes
successfully.

This change removes support for the legacy module-level code
execution. From this point onward, the new module-level code
execution will be the official approach.

Link: https://github.com/acpica/acpica/commit/47f5607cSigned-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NBob Moore <robert.moore@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      aa342261
  3. 16 1月, 2019 3 次提交
  5. 14 12月, 2018 1 次提交
  7. 09 11月, 2018 1 次提交
  9. 18 10月, 2018 1 次提交
    • E
      ACPICA: Remove acpi_gbl_group_module_level_code and only use... · 08930d56
      由 Erik Schmauss 提交于 
      ACPICA: Remove acpi_gbl_group_module_level_code and only use acpi_gbl_execute_tables_as_methods instead

acpi_gbl_group_module_level_code and acpi_gbl_execute_tables_as_methods were
used to enable different table load behavior. The different table
load behaviors are as follows:

A.) acpi_gbl_group_module_level_code enabled the legacy approach where
    ASL if statements are executed after the namespace object has
    been loaded.
B.) acpi_gbl_execute_tables_as_methods is currently used to enable the
    table load to be a method invocation. This meaning that ASL If
    statements are executed in-line rather than deferred until after
    the ACPI namespace has been populated. This is the correct
    behavior and option A will be removed in the future.

We do not support a table load behavior where these variables are
assigned the same value. In otherwords, we only support option A or B
and do not need acpi_gbl_group_module_level_code to enable A. From now on,
acpi_gbl_execute_tables_as_methods == 0 enables option A and
acpi_gbl_execute_tables_as_methods == 1 enables option B.

Note: option A is expected to be removed in the future and option B
will become the only supported table load behavior.
Signed-off-by: NErik Schmauss <erik.schmauss@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      08930d56
  11. 04 10月, 2018 1 次提交
  13. 15 8月, 2018 1 次提交
  15. 09 7月, 2018 1 次提交
  17. 06 6月, 2018 1 次提交
  19. 25 5月, 2018 1 次提交
  21. 18 5月, 2018 1 次提交
  23. 15 5月, 2018 1 次提交
  25. 19 3月, 2018 4 次提交
  27. 22 2月, 2018 2 次提交
  29. 06 2月, 2018 2 次提交
  31. 05 1月, 2018 1 次提交
  33. 27 11月, 2017 3 次提交
  35. 04 10月, 2017 1 次提交
  37. 04 8月, 2017 1 次提交
  39. 20 7月, 2017 2 次提交
  41. 28 6月, 2017 1 次提交
  43. 29 4月, 2017 1 次提交
  45. 09 2月, 2017 2 次提交
  47. 05 1月, 2017 1 次提交
  49. 21 12月, 2016 2 次提交
    • L
      ACPI / osl: Remove deprecated acpi_get_table_with_size()/early_acpi_os_unmap_memory() · 8d3523fb
      由 Lv Zheng 提交于 
      Since all users are cleaned up, remove the 2 deprecated APIs due to no
users.
As a Linux variable rather than an ACPICA variable, acpi_gbl_permanent_mmap
is renamed to acpi_permanent_mmap to have a consistent coding style across
entire Linux ACPI subsystem.
Signed-off-by: NLv Zheng <lv.zheng@intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      8d3523fb
    • L
      ACPICA: Tables: Back port acpi_get_table_with_size() and... · 174cc718
      由 Lv Zheng 提交于 
      ACPICA: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel

ACPICA commit cac6790954d4d752a083e6122220b8a22febcd07

This patch back ports Linux acpi_get_table_with_size() and
early_acpi_os_unmap_memory() into ACPICA upstream to reduce divergences.

The 2 APIs are used by Linux as table management APIs for long time, it
contains a hidden logic that during the early stage, the mapped tables
should be unmapped before the early stage ends.

During the early stage, tables are handled by the following sequence:
 acpi_get_table_with_size();
 parse the table
 early_acpi_os_unmap_memory();
During the late stage, tables are handled by the following sequence:
 acpi_get_table();
 parse the table
Linux uses acpi_gbl_permanent_mmap to distinguish the early stage and the
late stage.

The reasoning of introducing acpi_get_table_with_size() is: ACPICA will
remember the early mapped pointer in acpi_get_table() and Linux isn't able to
prevent ACPICA from using the wrong early mapped pointer during the late
stage as there is no API provided from ACPICA to be an inverse of
acpi_get_table() to forget the early mapped pointer.

But how ACPICA can work with the early/late stage requirement? Inside of
ACPICA, tables are ensured to be remained in "INSTALLED" state during the
early stage, and they are carefully not transitioned to "VALIDATED" state
until the late stage. So the same logic is in fact implemented inside of
ACPICA in a different way. The gap is only that the feature is not provided
to the OSPMs in an accessible external API style.

It then is possible to fix the gap by providing an inverse of
acpi_get_table() from ACPICA, so that the two Linux sequences can be
combined:
 acpi_get_table();
 parse the table
 acpi_put_table();
In order to work easier with the current Linux code, acpi_get_table() and
acpi_put_table() is implemented in a usage counting based style:
 1. When the usage count of the table is increased from 0 to 1, table is
    mapped and .Pointer is set with the mapping address (VALIDATED);
 2. When the usage count of the table is decreased from 1 to 0, .Pointer
    is unset and the mapping address is unmapped (INVALIDATED).
So that we can deploy the new APIs to Linux with minimal effort by just
invoking acpi_get_table() in acpi_get_table_with_size() and invoking
acpi_put_table() in early_acpi_os_unmap_memory(). Lv Zheng.

Link: https://github.com/acpica/acpica/commit/cac67909Signed-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>
      174cc718
  51. 21 10月, 2016 2 次提交
  53. 10 9月, 2016 1 次提交