Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 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. 07 2月, 2019 1 次提交
  5. 16 1月, 2019 3 次提交
  7. 20 12月, 2018 2 次提交
  9. 14 12月, 2018 5 次提交
  11. 08 12月, 2018 1 次提交
    • B
      x86/kernel: Fix more -Wmissing-prototypes warnings · ad3bc25a
      由 Borislav Petkov 提交于 
      ... with the goal of eventually enabling -Wmissing-prototypes by
default. At least on x86.

Make functions static where possible, otherwise add prototypes or make
them visible through includes.

asm/trace/ changes courtesy of Steven Rostedt <rostedt@goodmis.org>.
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
Reviewed-by: NIngo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> # ACPI + cpufreq bits
Cc: Andrew Banman <andrew.banman@hpe.com>
Cc: Dimitri Sivanich <dimitri.sivanich@hpe.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mike Travis <mike.travis@hpe.com>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yi Wang <wang.yi59@zte.com.cn>
Cc: linux-acpi@vger.kernel.org
      ad3bc25a
  13. 09 11月, 2018 2 次提交
  15. 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
  17. 16 10月, 2018 1 次提交
  19. 04 10月, 2018 3 次提交
  21. 03 10月, 2018 1 次提交
  23. 08 9月, 2018 1 次提交
  25. 15 8月, 2018 3 次提交
  27. 09 8月, 2018 1 次提交
  29. 09 7月, 2018 1 次提交
  31. 20 6月, 2018 1 次提交
  33. 10 6月, 2018 1 次提交
  35. 06 6月, 2018 4 次提交
  37. 25 5月, 2018 1 次提交
  39. 18 5月, 2018 1 次提交
  41. 15 5月, 2018 2 次提交
  43. 12 5月, 2018 1 次提交
  45. 10 5月, 2018 1 次提交
  47. 02 5月, 2018 1 次提交
    • B
      ghes, EDAC: Fix ghes_edac registration · cc7f3f13
      由 Borislav Petkov 提交于 
      Tony reported seeing

  "Internal error: Can't find EDAC structure"

when injecting correctable errors due to the fact that ghes_edac would
still load even if the whitelist won't hit. Drop the pr_err() in
ghes_edac_report_mem_error() for now due to the hacky way how ghes_edac
depends on ghes.c.

While at it, make ghes_edac_register() return an error if it doesn't hit
in the whitelist as it is the only sensible thing to do in that
situation.

Furthermore, move the call to it to happen last in ghes_probe() so that
GHES initializing properly does not depend on ghes_edac init at all
as latter is only reporting errors and not required for GHES's proper
functioning.
Reviewed-by: NToshi Kani <toshi.kani@hpe.com>
Tested-by: NSughosh Ganu <sughosh.ganu@arm.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Tony Luck <tony.luck@intel.com>
Link: https://lkml.kernel.org/r/20180420182015.zao3olss4tvvlxki@agluck-desk
      cc7f3f13