linux-toradex.git/drivers/xen/xen-acpi-processor.c, branch v4.9.97

xen/acpi: upload PM state from init-domain to Xen

2017-03-30T07:41:26+00:00

commit 1914f0cd203c941bba72f9452c8290324f1ef3dc upstream.

This was broken in commit cd979883b9ed ("xen/acpi-processor:
fix enabling interrupts on syscore_resume"). do_suspend (from
xen/manage.c) and thus xen_resume_notifier never get called on
the initial-domain at resume (it is if running as guest.)

The rationale for the breaking change was that upload_pm_data()
potentially does blocking work in syscore_resume(). This patch
addresses the original issue by scheduling upload_pm_data() to
execute in workqueue context.

Cc: Stanislaw Gruszka 
Based-on-patch-by: Konrad Wilk 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Stanislaw Gruszka 
Signed-off-by: Ankur Arora 
Signed-off-by: Boris Ostrovsky 
Signed-off-by: Greg Kroah-Hartman

xen/acpi: allow xen-acpi-processor driver to load on Xen 4.7

2016-07-08T13:53:13+00:00

As of Xen 4.7 PV CPUID doesn't expose either of CPUID[1].ECX[7] and
CPUID[0x80000007].EDX[7] anymore, causing the driver to fail to load on
both Intel and AMD systems. Doing any kind of hardware capability
checks in the driver as a prerequisite was wrong anyway: With the
hypervisor being in charge, all such checking should be done by it. If
ACPI data gets uploaded despite some missing capability, the hypervisor
is free to ignore part or all of that data.

Ditch the entire check_prereq() function, and do the only valid check
(xen_initial_domain()) in the caller in its place.

Signed-off-by: Jan Beulich 
Cc: 
Signed-off-by: David Vrabel

xen: rename dom0_op to platform_op

2015-12-21T14:40:55+00:00

The dom0_op hypercall has been renamed to platform_op since Xen 3.2,
which is ancient, and modern upstream Linux kernels cannot run as dom0
and it anymore anyway.

Signed-off-by: Stefano Stabellini 
Reviewed-by: Boris Ostrovsky

ACPI / processor: Drop an unused argument of a cleanup routine

2015-07-22T20:11:16+00:00

acpi_processor_unregister_performance() actually doesn't use its
first argument, so drop it and update the callers accordingly.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Viresh Kumar

xen-acpi-processor: Don't display errors when we get -ENOSYS

2014-05-23T16:34:00+00:00

which is a perfectly legal error. This can be triggered if the
user has booted Xen with the no-cpuidle parameter.

Reported-by-and-Tested-by: Don Slutz 
Signed-off-by: Konrad Rzeszutek Wilk

xen/acpi-processor: fix enabling interrupts on syscore_resume

2014-03-18T14:40:20+00:00

syscore->resume() callback is expected to do not enable interrupts,
it generates warning like below otherwise:

[ 9386.365390] WARNING: CPU: 0 PID: 6733 at drivers/base/syscore.c:104 syscore_resume+0x9a/0xe0()
[ 9386.365403] Interrupts enabled after xen_acpi_processor_resume+0x0/0x34 [xen_acpi_processor]
...
[ 9386.365429] Call Trace:
[ 9386.365434]  [] dump_stack+0x45/0x56
[ 9386.365437]  [] warn_slowpath_common+0x7d/0xa0
[ 9386.365439]  [] warn_slowpath_fmt+0x4c/0x50
[ 9386.365442]  [] ? xen_upload_processor_pm_data+0x300/0x300 [xen_acpi_processor]
[ 9386.365443]  [] syscore_resume+0x9a/0xe0
[ 9386.365445]  [] suspend_devices_and_enter+0x402/0x470
[ 9386.365447]  [] pm_suspend+0x178/0x260

On xen_acpi_processor_resume() we call various procedures, which are
non atomic and can enable interrupts. To prevent the issue introduce
separate resume notify called after we enable interrupts on resume
and before we call other drivers resume callbacks.

Signed-off-by: Stanislaw Gruszka 
Signed-off-by: Konrad Rzeszutek Wilk

ACPI: Clean up inclusions of ACPI header files

2013-12-07T00:03:14+00:00

Replace direct inclusions of ,  and
, which are incorrect, with 
inclusions and remove some inclusions of those files that aren't
necessary.

First of all, ,  and 
should not be included directly from any files that are built for
CONFIG_ACPI unset, because that generally leads to build warnings about
undefined symbols in !CONFIG_ACPI builds.  For CONFIG_ACPI set,
 includes those files and for CONFIG_ACPI unset it
provides stub ACPI symbols to be used in that case.

Second, there are ordering dependencies between those files that always
have to be met.  Namely, it is required that  be included
prior to  so that the acpi_pci_root declarations the
latter depends on are always there.  And  which provides
basic ACPICA type declarations should always be included prior to any other
ACPI headers in CONFIG_ACPI builds.  That also is taken care of including
 as appropriate.

Signed-off-by: Lv Zheng 
Cc: Greg Kroah-Hartman 
Cc: Matthew Garrett 
Cc: Tony Luck 
Cc: "H. Peter Anvin" 
Acked-by: Bjorn Helgaas  (drivers/pci stuff)
Acked-by: Konrad Rzeszutek Wilk  (Xen stuff)
Signed-off-by: Rafael J. Wysocki

xen: Convert printks to pr_

2013-06-28T15:19:58+00:00

Convert printks to pr_ (excludes printk(KERN_DEBUG...)
to be more consistent throughout the xen subsystem.

Add pr_fmt with KBUILD_MODNAME or "xen:" KBUILD_MODNAME
Coalesce formats and add missing word spaces
Add missing newlines
Align arguments and reflow to 80 columns
Remove DRV_NAME from formats as pr_fmt adds the same content

This does change some of the prefixes of these messages
but it also does make them more consistent.

Signed-off-by: Joe Perches 
Signed-off-by: Konrad Rzeszutek Wilk

xen: resolve section mismatch warnings in xen-acpi-processor

2013-04-19T14:44:23+00:00

The following resolves a section mismatch warning below in xen-acpi-processor introduced by
3fac10145b766a2244422788f62dc35978613fd8 [13/13] xen: Re-upload processor PM data to hypervisor after S3 resume (v2)

Warning:
WARNING: drivers/xen/built-in.o(.text+0x2056a): Section mismatch in reference from the function xen_upload_processor_pm_data() to the function .init.text:read_acpi_id()
   The function xen_upload_processor_pm_data() references
   the function __init read_acpi_id().
   This is often because xen_upload_processor_pm_data lacks a __init
   annotation or the annotation of read_acpi_id is wrong.

Reported-by: kbuild test robot 

Signed-off-by: Ben Guthro 
Signed-off-by: Konrad Rzeszutek Wilk

xen: Re-upload processor PM data to hypervisor after S3 resume (v2)

2013-04-17T14:43:56+00:00

Upon resume, it was found that ACPI C-states were missing from non-boot CPUs.
This change registers a syscore_ops handler for this case, and re-uploads the
PM information to the hypervisor to properly reset the C-state on these
processors.

v2:
v1 did not go through the check_acpi_ids() code-path, and missed some cases when
xen was running with the dom0_max_vcpus= command line parameter.

Signed-Off-By: Ben Guthro 
[v3: Ate some tabs, s/printk/pr_info/]
Signed-off-by: Konrad Rzeszutek Wilk