1. 18 Oct, 2018 1 commit
    • Erik Schmauss's avatar
      ACPICA: Remove acpi_gbl_group_module_level_code and only use... · 08930d56
      Erik Schmauss authored
      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: default avatarErik Schmauss <erik.schmauss@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      08930d56
  2. 16 Oct, 2018 1 commit
  3. 04 Oct, 2018 3 commits
  4. 02 Oct, 2018 1 commit
  5. 08 Sep, 2018 1 commit
  6. 14 Aug, 2018 3 commits
  7. 09 Aug, 2018 1 commit
  8. 09 Jul, 2018 1 commit
  9. 20 Jun, 2018 1 commit
  10. 10 Jun, 2018 1 commit
  11. 06 Jun, 2018 4 commits
  12. 25 May, 2018 1 commit
  13. 18 May, 2018 1 commit
  14. 15 May, 2018 2 commits
  15. 12 May, 2018 1 commit
  16. 10 May, 2018 1 commit
  17. 02 May, 2018 1 commit
    • Borislav Petkov's avatar
      ghes, EDAC: Fix ghes_edac registration · cc7f3f13
      Borislav Petkov authored
      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: default avatarToshi Kani <toshi.kani@hpe.com>
      Tested-by: default avatarSughosh Ganu <sughosh.ganu@arm.com>
      Signed-off-by: default avatarBorislav 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
  18. 24 Apr, 2018 1 commit
  19. 04 Apr, 2018 1 commit
  20. 21 Mar, 2018 1 commit
    • Joao Martins's avatar
      xen/acpi: upload _PSD info for non Dom0 CPUs too · 4d0f1ce6
      Joao Martins authored
      All uploaded PM data from non-dom0 CPUs takes the info from vCPU 0 and
      changing only the acpi_id. For processors which P-state coordination type
      is HW_ALL (0xFD) it is OK to upload bogus P-state dependency information
      (_PSD), because Xen will ignore any cpufreq domains created for past CPUs.
      
      Albeit for platforms which expose coordination types as SW_ANY or SW_ALL,
      this will have some unintended side effects. Effectively, it will look at
      the P-state domain existence and *if it already exists* it will skip the
      acpi-cpufreq initialization and thus inherit the policy from the first CPU
      in the cpufreq domain. This will finally lead to the original cpu not
      changing target freq to P0 other than the first in the domain. Which will
      make turbo boost not getting enabled (e.g. for 'performance' governor) for
      all cpus.
      
      This patch fixes that, by also evaluating _PSD when we enumerate all ACPI
      processors and thus always uploading the correct info to Xen. We export
      acpi_processor_get_psd() for that this purpose, but change signature
      to not assume an existent of acpi_processor given that ACPI isn't creating
      an acpi_processor for non-dom0 CPUs.
      Signed-off-by: default avatarJoao Martins <joao.m.martins@oracle.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      4d0f1ce6
  21. 18 Mar, 2018 7 commits
  22. 14 Mar, 2018 1 commit
  23. 21 Feb, 2018 4 commits