2019-05-27 08:55:06 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-07-12 01:47:00 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-09 23:24:08 +01:00
|
|
|
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 17:04:11 +09:00
|
|
|
|
2014-01-27 00:32:14 +00:00
|
|
|
|
2016-06-23 12:24:26 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2018-09-04 14:55:26 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
associated to each vIOMMU device. This needs to happen after
acpi_scan_init(), because it relies on the struct device and their
fwnode to be available.
(2) When probing the vIOMMU device, the driver registers its IOMMU ops
within the IOMMU subsystem. This step doesn't require any
intervention from the VIOT driver.
(3) viot_iommu_configure(): before binding the endpoint to a driver,
find the associated IOMMU ops. Register them, along with the
endpoint ID, into the device's iommu_fwspec.
If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 17:20:58 +02:00
|
|
|
|
2008-02-15 01:27:20 -08:00
|
|
|
|
2011-07-13 13:14:20 +08:00
|
|
|
|
2011-02-11 00:04:52 +01:00
|
|
|
|
ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype
Platform Runtime Mechanism (PRM) is a firmware interface that exposes
a set of binary executables that can either be called from the AML
interpreter or device drivers by bypassing the AML interpreter.
This change implements the AML interpreter path.
According to the specification [1], PRM services are listed in an
ACPI table called the PRMT. This patch parses module and handler
information listed in the PRMT and registers the PlatformRtMechanism
OpRegion handler before ACPI tables are loaded.
Each service is defined by a 16-byte GUID and called from writing a
26-byte ASL buffer containing the identifier to a FieldUnit object
defined inside a PlatformRtMechanism OperationRegion.
OperationRegion (PRMR, PlatformRtMechanism, 0, 26)
Field (PRMR, BufferAcc, NoLock, Preserve)
{
PRMF, 208 // Write to this field to invoke the OperationRegion Handler
}
The 26-byte ASL buffer is defined as the following:
Byte Offset Byte Length Description
=============================================================
0 1 PRM OperationRegion handler status
1 8 PRM service status
9 1 PRM command
10 16 PRM handler GUID
The ASL caller fills out a 26-byte buffer containing the PRM command
and the PRM handler GUID like so:
/* Local0 is the PRM data buffer */
Local0 = buffer (26){}
/* Create byte fields over the buffer */
CreateByteField (Local0, 0x9, CMD)
CreateField (Local0, 0x50, 0x80, GUID)
/* Fill in the command and data fields of the data buffer */
CMD = 0 // run command
GUID = ToUUID("xxxx-xx-xxx-xxxx")
/*
* Invoke PRM service with an ID that matches GUID and save the
* result.
*/
Local0 = (\_SB.PRMT.PRMF = Local0)
Byte offset 0 - 8 are written by the handler as a status passed back to AML
and used by ASL like so:
/* Create byte fields over the buffer */
CreateByteField (Local0, 0x0, PSTA)
CreateQWordField (Local0, 0x1, USTA)
In this ASL code, PSTA contains a status from the OperationRegion and
USTA contains a status from the PRM service.
The 26-byte buffer is recieved by acpi_platformrt_space_handler. This
handler will look at the command value and the handler guid and take
the approperiate actions.
Command value Action
=====================================================================
0 Run the PRM service indicated by the PRM handler
GUID (bytes 10-26)
1 Prevent PRM runtime updates from happening to the
service's parent module
2 Allow PRM updates from happening to the service's parent module
This patch enables command value 0.
Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-09 20:41:52 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-13 12:08:26 -06:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2010-05-12 09:26:48 +08:00
|
|
|
|
2014-05-12 15:50:16 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-12 15:50:16 +08:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
2018-07-19 19:00:30 +08:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
2010-09-28 22:57:02 -04:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-09-28 22:57:02 -04:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
|
|
|
|
|
2010-09-28 22:57:02 -04:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
2010-05-12 09:26:48 +08:00
|
|
|
|
|
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
2010-05-12 09:26:48 +08:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 19:30:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-26 16:02:56 +01:00
|
|
|
|
2009-09-21 19:30:01 +00:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-09-21 19:30:01 +00:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2021-11-22 18:05:31 +01:00
|
|
|
|
|
|
|
|
|
2017-04-21 12:47:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-01-26 16:02:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-09-21 19:30:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-04-30 18:02:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-22 21:56:06 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
2009-06-29 13:43:27 +08:00
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-20 20:59:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
|
|
|
|
|
2013-06-03 18:20:24 +00:00
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
2019-11-28 15:58:29 +05:30
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-20 20:59:21 +08:00
|
|
|
|
|
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-20 20:59:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-17 15:51:21 +08:00
|
|
|
|
2025-12-22 20:11:08 +01:00
|
|
|
|
|
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
2025-12-22 20:11:08 +01:00
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
|
|
|
|
|
2025-12-22 20:11:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
2016-06-16 17:23:09 +02:00
|
|
|
|
ACPI: bus: Fix handling of _OSC errors in acpi_run_osc()
The handling of _OSC errors in acpi_run_osc() is inconsistent and
arguably not compliant with the _OSC definition (cf. Section 6.2.12 of
ACPI 6.6 [1]).
Namely, if OSC_QUERY_ENABLE is not set in the capabilities buffer and
any of the error bits are set in the _OSC return buffer, acpi_run_osc()
returns an error code and the _OSC return buffer is discarded. However,
in that case, depending on what error bits are set, the return buffer
may contain acknowledged bits for features that need to be controlled by
the kernel going forward.
If the OSC_INVALID_UUID_ERROR bit is set, the request could not be
processed at all and so in that particular case discarding the _OSC
return buffer and returning an error is the right thing to do regardless
of whether or not OSC_QUERY_ENABLE is set in the capabilities buffer.
If OSC_QUERY_ENABLE is set in the capabilities buffer and the
OSC_REQUEST_ERROR or OSC_INVALID_REVISION_ERROR bits are set in the
return buffer, acpi_run_osc() may return an error and discard the _OSC
return buffer because in that case the platform configuration does not
change. However, if any of them is set in the return buffer when
OSC_QUERY_ENABLE is not set in the capabilities buffer, the feature
mask in the _OSC return buffer still represents a set of acknowleded
features as per the _OSC definition:
The platform acknowledges the Capabilities Buffer by returning a
buffer of DWORDs of the same length. Set bits indicate acknowledgment
that OSPM may take control of the capability and cleared bits indicate
that the platform either does not support the capability or that OSPM
may not assume control.
which is not conditional on the error bits being clear, so in that case,
discarding the _OSC return buffer is questionable. There is also no
reason to return an error and discard the _OSC return buffer if the
OSC_CAPABILITIES_MASK_ERROR bit is set in it, but printing diagnostic
messages is appropriate when that happens with OSC_QUERY_ENABLE clear
in the capabilities buffer.
Adress this issue by making acpi_run_osc() follow the rules outlined
above.
Moreover, make acpi_run_osc() only take the defined _OSC error bits into
account when checking _OSC errors.
Link: https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#osc-operating-system-capabilities [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
[ rjw: Corrected typo in the changelog ]
Link: https://patch.msgid.link/3042649.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-22 20:05:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-16 17:23:09 +02:00
|
|
|
|
2025-12-22 20:14:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-22 20:17:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-22 20:14:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-05 19:40:44 +03:00
|
|
|
|
2025-12-22 20:17:29 +01:00
|
|
|
|
2025-12-22 20:14:16 +01:00
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
2025-12-22 20:14:16 +01:00
|
|
|
|
2025-12-29 14:27:46 +01:00
|
|
|
|
2025-12-22 20:14:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
|
|
|
|
|
2009-12-23 17:04:11 +08:00
|
|
|
|
2025-12-22 20:17:29 +01:00
|
|
|
|
ACPI: bus: Fix handling of _OSC errors in acpi_run_osc()
The handling of _OSC errors in acpi_run_osc() is inconsistent and
arguably not compliant with the _OSC definition (cf. Section 6.2.12 of
ACPI 6.6 [1]).
Namely, if OSC_QUERY_ENABLE is not set in the capabilities buffer and
any of the error bits are set in the _OSC return buffer, acpi_run_osc()
returns an error code and the _OSC return buffer is discarded. However,
in that case, depending on what error bits are set, the return buffer
may contain acknowledged bits for features that need to be controlled by
the kernel going forward.
If the OSC_INVALID_UUID_ERROR bit is set, the request could not be
processed at all and so in that particular case discarding the _OSC
return buffer and returning an error is the right thing to do regardless
of whether or not OSC_QUERY_ENABLE is set in the capabilities buffer.
If OSC_QUERY_ENABLE is set in the capabilities buffer and the
OSC_REQUEST_ERROR or OSC_INVALID_REVISION_ERROR bits are set in the
return buffer, acpi_run_osc() may return an error and discard the _OSC
return buffer because in that case the platform configuration does not
change. However, if any of them is set in the return buffer when
OSC_QUERY_ENABLE is not set in the capabilities buffer, the feature
mask in the _OSC return buffer still represents a set of acknowleded
features as per the _OSC definition:
The platform acknowledges the Capabilities Buffer by returning a
buffer of DWORDs of the same length. Set bits indicate acknowledgment
that OSPM may take control of the capability and cleared bits indicate
that the platform either does not support the capability or that OSPM
may not assume control.
which is not conditional on the error bits being clear, so in that case,
discarding the _OSC return buffer is questionable. There is also no
reason to return an error and discard the _OSC return buffer if the
OSC_CAPABILITIES_MASK_ERROR bit is set in it, but printing diagnostic
messages is appropriate when that happens with OSC_QUERY_ENABLE clear
in the capabilities buffer.
Adress this issue by making acpi_run_osc() follow the rules outlined
above.
Moreover, make acpi_run_osc() only take the defined _OSC error bits into
account when checking _OSC errors.
Link: https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#osc-operating-system-capabilities [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
[ rjw: Corrected typo in the changelog ]
Link: https://patch.msgid.link/3042649.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-22 20:05:44 +01:00
|
|
|
|
2025-12-22 20:17:29 +01:00
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
2025-12-22 20:18:40 +01:00
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
ACPI: bus: Fix handling of _OSC errors in acpi_run_osc()
The handling of _OSC errors in acpi_run_osc() is inconsistent and
arguably not compliant with the _OSC definition (cf. Section 6.2.12 of
ACPI 6.6 [1]).
Namely, if OSC_QUERY_ENABLE is not set in the capabilities buffer and
any of the error bits are set in the _OSC return buffer, acpi_run_osc()
returns an error code and the _OSC return buffer is discarded. However,
in that case, depending on what error bits are set, the return buffer
may contain acknowledged bits for features that need to be controlled by
the kernel going forward.
If the OSC_INVALID_UUID_ERROR bit is set, the request could not be
processed at all and so in that particular case discarding the _OSC
return buffer and returning an error is the right thing to do regardless
of whether or not OSC_QUERY_ENABLE is set in the capabilities buffer.
If OSC_QUERY_ENABLE is set in the capabilities buffer and the
OSC_REQUEST_ERROR or OSC_INVALID_REVISION_ERROR bits are set in the
return buffer, acpi_run_osc() may return an error and discard the _OSC
return buffer because in that case the platform configuration does not
change. However, if any of them is set in the return buffer when
OSC_QUERY_ENABLE is not set in the capabilities buffer, the feature
mask in the _OSC return buffer still represents a set of acknowleded
features as per the _OSC definition:
The platform acknowledges the Capabilities Buffer by returning a
buffer of DWORDs of the same length. Set bits indicate acknowledgment
that OSPM may take control of the capability and cleared bits indicate
that the platform either does not support the capability or that OSPM
may not assume control.
which is not conditional on the error bits being clear, so in that case,
discarding the _OSC return buffer is questionable. There is also no
reason to return an error and discard the _OSC return buffer if the
OSC_CAPABILITIES_MASK_ERROR bit is set in it, but printing diagnostic
messages is appropriate when that happens with OSC_QUERY_ENABLE clear
in the capabilities buffer.
Adress this issue by making acpi_run_osc() follow the rules outlined
above.
Moreover, make acpi_run_osc() only take the defined _OSC error bits into
account when checking _OSC errors.
Link: https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#osc-operating-system-capabilities [1]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
[ rjw: Corrected typo in the changelog ]
Link: https://patch.msgid.link/3042649.e9J7NaK4W3@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-22 20:05:44 +01:00
|
|
|
|
2009-12-23 17:04:11 +08:00
|
|
|
|
2025-12-22 20:17:29 +01:00
|
|
|
|
2009-12-23 17:04:11 +08:00
|
|
|
|
|
|
|
|
|
2025-12-22 20:18:40 +01:00
|
|
|
|
2009-12-23 17:04:11 +08:00
|
|
|
|
|
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
2025-12-22 20:18:40 +01:00
|
|
|
|
|
|
|
|
|
2009-10-29 11:04:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-07-13 13:14:20 +08:00
|
|
|
|
2016-07-21 17:18:07 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-18 11:08:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-05 13:29:14 -05:00
|
|
|
|
2022-03-16 13:39:03 +01:00
|
|
|
|
2020-10-26 18:01:05 +03:00
|
|
|
|
2009-10-29 11:05:05 +08:00
|
|
|
|
2025-12-22 20:21:19 +01:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
2009-10-29 11:05:05 +08:00
|
|
|
|
|
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-14 16:01:55 +01:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
2015-09-14 16:01:55 +01:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
2024-03-09 21:13:06 +01:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
2024-06-20 21:14:10 +02:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
2011-07-13 13:14:20 +08:00
|
|
|
|
2021-07-02 15:03:50 +08:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
2022-11-18 14:00:59 +00:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
2016-11-22 12:23:59 -08:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
2011-07-13 13:14:20 +08:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
2009-10-29 11:05:05 +08:00
|
|
|
|
|
|
|
|
|
2020-10-26 18:01:05 +03:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2020-10-26 18:01:05 +03:00
|
|
|
|
|
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
2020-10-26 18:01:05 +03:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
2021-06-09 13:25:33 +03:00
|
|
|
|
2025-12-22 20:23:29 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-29 11:05:05 +08:00
|
|
|
|
|
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-02 16:54:25 +08:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-22 20:26:36 +01:00
|
|
|
|
|
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-12-26 14:48:45 +01:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
2025-12-22 20:26:36 +01:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
2025-12-22 20:26:36 +01:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2009-05-22 11:43:41 -06:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-02-06 13:58:13 +01:00
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2014-04-24 19:27:49 +02:00
|
|
|
|
2017-06-30 15:25:38 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-01 01:16:06 +02:00
|
|
|
|
|
|
|
|
|
2022-08-10 18:14:22 +02:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-07-12 19:24:50 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2022-06-18 13:23:11 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2022-06-18 13:23:11 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2023-06-04 17:23:40 +02:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2023-06-04 17:23:40 +02:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2023-06-04 17:23:40 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2023-06-04 17:23:40 +02:00
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
|
|
|
|
|
2023-06-04 17:23:40 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-14 16:00:48 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2023-07-03 11:02:44 +03:00
|
|
|
|
|
|
|
|
|
2023-10-06 17:32:51 +02:00
|
|
|
|
2023-07-03 11:02:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-10-06 17:32:51 +02:00
|
|
|
|
2023-07-03 11:02:44 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-23 12:24:26 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-14 15:59:52 +02:00
|
|
|
|
2016-06-23 12:24:26 -06:00
|
|
|
|
2023-04-14 15:59:52 +02:00
|
|
|
|
2016-06-23 12:24:26 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-16 15:52:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
|
|
|
|
|
2016-02-16 15:52:38 +03:00
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-16 15:52:38 +03:00
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-16 15:52:38 +03:00
|
|
|
|
|
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
|
|
|
|
|
2016-02-16 15:52:38 +03:00
|
|
|
|
|
|
|
|
|
2020-05-19 15:34:21 +03:00
|
|
|
|
2016-02-16 15:52:38 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
|
|
|
|
|
2015-07-29 23:57:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
2015-07-29 23:57:51 +02:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 14:00:23 +03:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-08-01 02:39:43 +02:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 14:00:23 +03:00
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-05 16:30:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-18 22:59:55 +02:00
|
|
|
|
2017-02-05 16:30:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-04-04 18:21:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-02-05 16:30:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-18 22:59:55 +02:00
|
|
|
|
2017-02-05 16:30:12 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-26 14:00:23 +03:00
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
2023-07-03 15:14:07 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-03 15:14:07 +03:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:36 +02:00
|
|
|
|
2017-12-13 02:20:48 -05:00
|
|
|
|
2022-08-26 20:16:35 +03:00
|
|
|
|
2026-01-14 13:53:06 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-13 02:20:48 -05:00
|
|
|
|
2026-01-14 13:53:06 +05:30
|
|
|
|
2017-12-13 02:20:48 -05:00
|
|
|
|
|
|
|
|
|
2026-01-14 13:53:06 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-13 02:20:48 -05:00
|
|
|
|
2018-02-09 17:38:35 +02:00
|
|
|
|
2017-12-13 02:20:48 -05:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-09 17:38:33 +02:00
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-26 20:16:35 +03:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
2022-08-26 20:16:35 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:53:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-28 20:49:11 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2024-03-28 20:49:11 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-28 20:49:11 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-28 20:49:11 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2022-08-24 07:53:06 +00:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2024-03-28 20:49:11 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-01 14:07:37 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2024-07-01 14:07:37 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-11 12:30:17 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-07-03 11:02:45 +03:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2023-07-03 11:02:45 +03:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-07-13 21:35:22 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
2022-06-18 13:23:11 +02:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2022-06-18 13:23:10 +02:00
|
|
|
|
2023-03-24 14:33:42 +01:00
|
|
|
|
2022-06-18 13:23:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-11 12:37:11 -03:00
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-22 20:51:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:01 +02:00
|
|
|
|
2022-04-22 17:13:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-04 17:21:50 +02:00
|
|
|
|
2022-04-22 17:13:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-13 20:26:03 +02:00
|
|
|
|
2022-04-22 17:13:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-04 17:21:50 +02:00
|
|
|
|
|
|
|
|
|
2022-06-13 20:26:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-03 18:20:24 +00:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-10 01:32:16 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-24 14:02:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-15 10:50:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2006-12-22 11:50:04 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-20 18:51:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-12 06:29:19 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-29 00:24:39 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ACPI / init: Switch over platform to the ACPI mode later
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
2015-06-10 01:33:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-03 18:20:24 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2006-03-17 16:44:00 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-12-14 15:04:46 +08:00
|
|
|
|
2007-02-02 19:48:19 +03:00
|
|
|
|
2018-09-04 14:55:26 +02:00
|
|
|
|
2018-07-19 19:00:30 +08:00
|
|
|
|
|
|
|
|
|
2018-09-04 14:55:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-19 19:00:30 +08:00
|
|
|
|
|
|
|
|
|
2018-09-04 14:55:26 +02:00
|
|
|
|
2010-04-08 14:34:27 +08:00
|
|
|
|
2007-02-02 19:48:19 +03:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2007-02-02 19:48:19 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-02-02 19:48:22 +03:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
ACPI / init: Switch over platform to the ACPI mode later
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
2015-06-10 01:33:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-04 11:13:59 +08:00
|
|
|
|
ACPI / init: Switch over platform to the ACPI mode later
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
2015-06-10 01:33:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-11-06 14:20:42 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
ACPI / init: Switch over platform to the ACPI mode later
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".
However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.
To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.
That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann <tolzmann@molgen.mpg.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Lee, Chun-Yi <jlee@suse.com>
2015-06-10 01:33:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2021-06-16 16:05:50 +02:00
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2013-06-03 18:20:24 +00:00
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-04 11:55:27 -08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2018-10-17 15:41:21 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2018-10-17 15:41:21 -07:00
|
|
|
|
2016-03-24 10:43:00 +08:00
|
|
|
|
|
|
|
|
|
ACPI: EC: Look for ECDT EC after calling acpi_load_tables()
Some systems have had functional issues since commit 5a8361f7ecce
(ACPICA: Integrate package handling with module-level code) that,
among other things, changed the initial values of the
acpi_gbl_group_module_level_code and acpi_gbl_parse_table_as_term_list
global flags in ACPICA which implicitly caused acpi_ec_ecdt_probe() to
be called before acpi_load_tables() on the vast majority of platforms.
Namely, before commit 5a8361f7ecce, acpi_load_tables() was called from
acpi_early_init() if acpi_gbl_parse_table_as_term_list was FALSE and
acpi_gbl_group_module_level_code was TRUE, which almost always was
the case as FALSE and TRUE were their initial values, respectively.
The acpi_gbl_parse_table_as_term_list value would be changed to TRUE
for a couple of platforms in acpi_quirks_dmi_table[], but it remained
FALSE in the vast majority of cases.
After commit 5a8361f7ecce, the initial values of the two flags have
been reversed, so in effect acpi_load_tables() has not been called
from acpi_early_init() any more. That, in turn, affects
acpi_ec_ecdt_probe() which is invoked before acpi_load_tables() now
and it is not possible to evaluate the _REG method for the EC address
space handler installed by it. That effectively causes the EC address
space to be inaccessible to AML on platforms with an ECDT matching the
EC device definition in the DSDT and functional problems ensue in
there.
Because the default behavior before commit 5a8361f7ecce was to call
acpi_ec_ecdt_probe() after acpi_load_tables(), it should be safe to
do that again. Moreover, the EC address space handler installed by
acpi_ec_ecdt_probe() is only needed for AML to be able to access the
EC address space and the only AML that can run during acpi_load_tables()
is module-level code which only is allowed to access address spaces
with default handlers (memory, I/O and PCI config space).
For this reason, move the acpi_ec_ecdt_probe() invocation back to
acpi_bus_init(), from where it was taken away by commit d737f333b211
(ACPI: probe ECDT before loading AML tables regardless of module-level
code flag), and put it after the invocation of acpi_load_tables() to
restore the original code ordering from before commit 5a8361f7ecce.
Fixes: 5a8361f7ecce ("ACPICA: Integrate package handling with module-level code")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=199981
Reported-by: step-ali <sunmooon15@gmail.com>
Reported-by: Charles Stanhope <charles.stanhope@gmail.com>
Tested-by: Charles Stanhope <charles.stanhope@gmail.com>
Reported-by: Paulo Nascimento <paulo.ulusu@googlemail.com>
Reported-by: David Purton <dcpurton@marshwiggle.net>
Reported-by: Adam Harvey <adam@adamharvey.name>
Reported-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Zhang Rui <rui.zhang@intel.com>
Tested-by: Jean-Marc Lenoir <archlinux@jihemel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-01-09 00:34:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-24 10:43:00 +08:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2016-03-24 10:43:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-16 16:30:21 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-26 18:01:05 +03:00
|
|
|
|
2020-02-18 16:02:45 +02:00
|
|
|
|
2012-07-16 16:30:21 +08:00
|
|
|
|
2010-10-26 10:06:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-07-08 19:13:09 +03:00
|
|
|
|
|
|
|
|
|
2010-10-26 10:06:54 +08:00
|
|
|
|
|
|
|
|
|
2023-07-10 17:03:36 +03:00
|
|
|
|
2009-12-20 12:19:09 -07:00
|
|
|
|
2008-10-06 10:31:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-06-03 10:26:12 +08:00
|
|
|
|
2008-10-06 10:31:36 +08:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2007-02-10 01:32:16 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-21 16:37:14 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-07-17 22:54:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-11-02 16:19:59 -07:00
|
|
|
|
2012-01-31 13:19:19 -05:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2024-11-21 22:25:21 +08:00
|
|
|
|
|
|
|
|
|
2005-08-05 00:44:28 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-02-15 21:22:24 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2021-01-20 19:59:05 +01:00
|
|
|
|
2006-06-27 00:41:40 -04:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
2007-11-05 13:16:15 -08:00
|
|
|
|
2025-05-18 20:51:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype
Platform Runtime Mechanism (PRM) is a firmware interface that exposes
a set of binary executables that can either be called from the AML
interpreter or device drivers by bypassing the AML interpreter.
This change implements the AML interpreter path.
According to the specification [1], PRM services are listed in an
ACPI table called the PRMT. This patch parses module and handler
information listed in the PRMT and registers the PlatformRtMechanism
OpRegion handler before ACPI tables are loaded.
Each service is defined by a 16-byte GUID and called from writing a
26-byte ASL buffer containing the identifier to a FieldUnit object
defined inside a PlatformRtMechanism OperationRegion.
OperationRegion (PRMR, PlatformRtMechanism, 0, 26)
Field (PRMR, BufferAcc, NoLock, Preserve)
{
PRMF, 208 // Write to this field to invoke the OperationRegion Handler
}
The 26-byte ASL buffer is defined as the following:
Byte Offset Byte Length Description
=============================================================
0 1 PRM OperationRegion handler status
1 8 PRM service status
9 1 PRM command
10 16 PRM handler GUID
The ASL caller fills out a 26-byte buffer containing the PRM command
and the PRM handler GUID like so:
/* Local0 is the PRM data buffer */
Local0 = buffer (26){}
/* Create byte fields over the buffer */
CreateByteField (Local0, 0x9, CMD)
CreateField (Local0, 0x50, 0x80, GUID)
/* Fill in the command and data fields of the data buffer */
CMD = 0 // run command
GUID = ToUUID("xxxx-xx-xxx-xxxx")
/*
* Invoke PRM service with an ID that matches GUID and save the
* result.
*/
Local0 = (\_SB.PRMT.PRMF = Local0)
Byte offset 0 - 8 are written by the handler as a status passed back to AML
and used by ASL like so:
/* Create byte fields over the buffer */
CreateByteField (Local0, 0x0, PSTA)
CreateQWordField (Local0, 0x1, USTA)
In this ASL code, PSTA contains a status from the OperationRegion and
USTA contains a status from the PRM service.
The 26-byte buffer is recieved by acpi_platformrt_space_handler. This
handler will look at the command value and the handler guid and take
the approperiate actions.
Command value Action
=====================================================================
0 Run the PRM service indicated by the PRM handler
GUID (bytes 10-26)
1 Prevent PRM runtime updates from happening to the
service's parent module
2 Allow PRM updates from happening to the service's parent module
This patch enables command value 0.
Link: https://uefi.org/sites/default/files/resources/Platform%20Runtime%20Mechanism%20-%20with%20legal%20notice.pdf # [1]
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2021-06-09 20:41:52 -07:00
|
|
|
|
ACPI: PCC: Implement OperationRegion handler for the PCC Type 3 subtype
PCC OpRegion provides a mechanism to communicate with the platform
directly from the AML. PCCT provides the list of PCC channel available
in the platform, a subset or all of them can be used in PCC Opregion.
This patch registers the PCC OpRegion handler before ACPI tables are
loaded. This relies on the special context data passed to identify and
set up the PCC channel before the OpRegion handler is executed for the
first time.
Typical PCC Opregion declaration looks like this:
OperationRegion (PFRM, PCC, 2, 0x74)
Field (PFRM, ByteAcc, NoLock, Preserve)
{
SIGN, 32,
FLGS, 32,
LEN, 32,
CMD, 32,
DATA, 800
}
It contains four named double words followed by 100 bytes of buffer
names DATA.
ASL can fill out the buffer something like:
/* Create global or local buffer */
Name (BUFF, Buffer (0x0C){})
/* Create double word fields over the buffer */
CreateDWordField (BUFF, 0x0, WD0)
CreateDWordField (BUFF, 0x04, WD1)
CreateDWordField (BUFF, 0x08, WD2)
/* Fill the named fields */
WD0 = 0x50434300
SIGN = BUFF
WD0 = 1
FLGS = BUFF
WD0 = 0x10
LEN = BUFF
/* Fill the payload in the DATA buffer */
WD0 = 0
WD1 = 0x08
WD2 = 0
DATA = BUFF
/* Write to CMD field to trigger handler */
WD0 = 0x4404
CMD = BUFF
This buffer is received by acpi_pcc_opregion_space_handler. This
handler will fetch the complete buffer via internal_pcc_buffer.
The setup handler will receive the special PCC context data which will
contain the PCC channel index which used to set up the channel. The
buffer pointer and length is saved in region context which is then used
in the handler.
(kernel test robot: Build failure with CONFIG_ACPI_DEBUGGER)
Link: https://lore.kernel.org/r/202201041539.feAV0l27-lkp@intel.com
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-01-04 19:51:08 +00:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2011-02-15 21:22:24 +01:00
|
|
|
|
2021-06-02 17:36:50 +08:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-24 16:49:38 -06:00
|
|
|
|
2011-02-15 21:22:24 +01:00
|
|
|
|
2022-11-18 14:00:59 +00:00
|
|
|
|
2009-03-24 16:49:38 -06:00
|
|
|
|
2011-02-15 21:22:24 +01:00
|
|
|
|
2022-06-30 11:40:59 +02:00
|
|
|
|
2022-02-27 20:25:45 +08:00
|
|
|
|
2022-02-27 20:25:46 +08:00
|
|
|
|
2024-11-21 22:25:21 +08:00
|
|
|
|
2009-03-24 16:49:43 -06:00
|
|
|
|
2009-03-24 16:49:48 -06:00
|
|
|
|
2010-07-15 10:46:15 +08:00
|
|
|
|
2009-03-24 16:50:14 -06:00
|
|
|
|
2009-03-24 16:50:19 -06:00
|
|
|
|
2015-12-03 10:43:14 +08:00
|
|
|
|
2016-06-23 12:24:26 -06:00
|
|
|
|
ACPI: Add driver for the VIOT table
The ACPI Virtual I/O Translation Table describes topology of
para-virtual platforms, similarly to vendor tables DMAR, IVRS and IORT.
For now it describes the relation between virtio-iommu and the endpoints
it manages.
Three steps are needed to configure DMA of endpoints:
(1) acpi_viot_init(): parse the VIOT table, find or create the fwnode
associated to each vIOMMU device. This needs to happen after
acpi_scan_init(), because it relies on the struct device and their
fwnode to be available.
(2) When probing the vIOMMU device, the driver registers its IOMMU ops
within the IOMMU subsystem. This step doesn't require any
intervention from the VIOT driver.
(3) viot_iommu_configure(): before binding the endpoint to a driver,
find the associated IOMMU ops. Register them, along with the
endpoint ID, into the device's iommu_fwspec.
If step (3) happens before step (2), it is deferred until the IOMMU is
initialized, then retried.
Tested-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Link: https://lore.kernel.org/r/20210618152059.1194210-4-jean-philippe@linaro.org
Signed-off-by: Joerg Roedel <jroedel@suse.de>
2021-06-18 17:20:58 +02:00
|
|
|
|
2011-02-15 21:22:24 +01:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
