1. 12 10月, 2019 1 次提交
  2. 15 8月, 2018 3 次提交
  3. 09 8月, 2018 1 次提交
  4. 09 7月, 2018 1 次提交
  5. 20 6月, 2018 1 次提交
  6. 10 6月, 2018 1 次提交
  7. 06 6月, 2018 4 次提交
  8. 25 5月, 2018 1 次提交
  9. 18 5月, 2018 1 次提交
  10. 15 5月, 2018 2 次提交
  11. 12 5月, 2018 1 次提交
  12. 10 5月, 2018 1 次提交
  13. 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
  14. 24 4月, 2018 1 次提交
  15. 04 4月, 2018 1 次提交
  16. 21 3月, 2018 1 次提交
    • J
      xen/acpi: upload _PSD info for non Dom0 CPUs too · 4d0f1ce6
      Joao Martins 提交于
      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: NJoao Martins <joao.m.martins@oracle.com>
      Reviewed-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NBoris Ostrovsky <boris.ostrovsky@oracle.com>
      4d0f1ce6
  17. 19 3月, 2018 7 次提交
  18. 14 3月, 2018 1 次提交
  19. 22 2月, 2018 5 次提交
  20. 06 2月, 2018 2 次提交
  21. 04 2月, 2018 3 次提交