Provide common creation code for the Alias operator. All objects
are now handled the same, with the only exception being the
Method() operator. It has a special internal Alias type.
The -vx [messageId] option, where the x stands for EXpect, allows the
compiler to expect that the compilation will result in an ASL exception
with a particular messageId. If this error is not raised. The
compilation will result in an error. This will help create a whole new
class of compilation tests in ASLTS.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
These tests compare a resource descriptor and an equivalent buffer to ensure
proper resource descriptor compilation. The buffer does not account for the
shared bit for V2 resource descriptors (see section 6.4.3.8.2.x in the ACPI
6.2 spec). This commit changes this test buffer to include the shared bit
(the 3rd bit of the 6th byte of V2 resource descriptors). The specification
is expected to reflect these changes (sections 6.4.3.8.2.1, 6.4.3.8.2.2, and
6.4.3.8.2.3).
Updated buffers include buffers equivalent to I2cSearialBusv2, SpiSerialBusv2,
and UartSerialBusv2
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Revert commit ba5020b2dbe (Disassembler: Enhance resource
descriptor detection) as it is based on an assumption that doesn't
hold all the time and causes problems to happen because of that.
Broken platform:
HPE Moonshot ProLiant DL380Gen9
HPE Moonshot M400 Server Cartridge
Reported-by: Linda Knippers <linda.knippers@hpe.com>
Reported-by: Graeme Gregory <graeme.gregory@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Linux guys start to define access size values for
ACPI_RESOURCE_GENERIC_REGISTER, while it should be better to just define
the access_size -> access_bit_width algorithm and deply it for both
ACPI_RESOURCE_GENERIC_REGISTER and ACPI_GENERIC_ADDRESS types. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This patch enables duplication check for late stage. The previous fixes
only prepare mechanism for late stage table verification and checksum
verification is enabled by default. But an explicit !Null TableIndex is
required to enable duplication check for late stage. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
This reverts commit d28f6c2927053d85f33780b66c0d9050f0e30d3a.
This appears to be a workaround for some bad ASL or other code. This
type of code should not be in the ACPICA code.
ARM IORT specification has provision to define Proximity domain
in SMMUv3 IORT table. Adding required changes to decode
Proximity domain of SMMUv3 IORT table.
Signed-off-by: Ganapatrao Kulkarni <ganapatrao.kulkarni@cavium.com>
Field unit objects now result in compilation error when
there is a declaration and an external declaration of the
field unit object within the same file.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
The following ACPI table contains an invalid target node within the
Alias operator:
DefinitionBlock ("", "SSDT", 1, "Bug", "BugTable", 0x00001000)
{
Scope (_SB)
{
Device (DEV0)
{
Name (_ADR, 1)
Device (DEV1)
{
Alias (_ADR, _ADR)
}
}
}
}
If an ACPI table contains such an invalid target node in an Alias
operator, a segmentation fault will occur when the target node is
dereferenced within AcpiExCreateAlias. Add a check for such an invalid
target node in AcpiExCreateAlias and return AE_NULL_OBJECT as suggested
by @acpibob.
This patch allows tables not verified in early stage verfied in
AcpiReallocateRootTable(). This is useful for OSPMs like linux where tables
cannot be verified in early stage due to early ioremp limitations on some
architectures. Reported by Hans de Geode, fixed by Lv Zheng.
Reported-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
They are all mechanisms used to verify if a table is qualified to be
installed and controlled by AcpiGbl_EnableTableValidation, so combine them
together. By doing so, table duplication check is applied to the statically
loaded tables (however whether it is actually enabled is still determined
by AcpiGbl_EnableTableValidation). Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
AcpiGbl_VerifyTableChecksum is used to avoid validating (mapping) an entire
table in OS boot stage. 2nd "Reload" check in AcpiTbInstallStandardTable()
is prepared for the same purpose. So this patch combines them together
using a renamed AcpiGbl_EnableTableValidation flag. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Windows seems to allow arbitrary table signatures for Load/LoadTable
opcodes:
ACPI BIOS Error (bug): Table has invalid signature [PRAD] (0x44415250)
So this patch removes dynamic load signature checks. However we need to
find a way to avoid table loading against tables like MADT. This is not
covered by this commit.
This Windows behavior has been validated on link #1. An end user bug
report can also be found on link #2.
This patch also includes simple cleanup for static load signature check
code. Reported by Ye Xiaolong, Fixed by Lv Zheng.
Link: https://github.com/acpica/acpica/pull/121 [#1]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=118601 [#2]
Reported-by: Ye Xiaolong <xiaolong.ye@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Recently, we allows the table mutex to be held in both early and late stage
APIs. This patch further cleans up the related code to reduce redundant
code related to AcpiGbl_TableHandler. Lv Zheng.
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
There is a hidden logic for AcpiTbInstallStandardTable():
1. When it is invoked from the OS boot stage, ACPICA mutex may not be
available, and thus no AcpiUtAcquireMutex()/AcpiUtReleaseMutex() are
invoked in these code paths:
AcpiInitializeTables
AcpiTbParseRootTable
AcpiTbInstallStandardTable (4 invocations)
AcpiInstallTable
AcpiTbInstallStandardTable
2. When it is invoked during the runtime, ACPICA mutex is correctly used:
AcpiExLoadOp
AcpiTbInstallAndLoadTable
Lock(TABLES)
AcpiTbInstallStandardTable
UnLock(TABLES)
AcpiLoadTable
AcpiTbInstallAndLoadTable
Lock(TABLES)
AcpiTbInstallStandardTable
UnLock(TABLES)
So the hidden logic is: AcpiTbInstallStandardTable() tries not to hold
mutexes to handle the difference of the boot stage and the runtime, but
leaves the mutexes held from some calling runtime APIs.
This introduces another problem in AcpiTbInstallStandardTable() where
AcpiGbl_TableHandler is invoked from and the lock contexts are thus not
consistent for the table handlers. Linux registers such a handler to track
the table installation and the handler is actually invoked from both
contexts. Since the handler also invokes AcpiGetTable(), when the following
commit corrected AcpiGetTable() to make it start to hold the table lock,
a regression is then triggered.
Commit: cac6790954d4d752a083e6122220b8a22febcd07
Subject: Tables: Back port acpi_get_table_with_size() and early_acpi_os_unmap_memory() from Linux kernel
The regression is noticed by LKP as new errors reported by ACPICA mutex
debugging facility.
[ 2.043693] ACPI Error: Mutex [ACPI_MTX_Tables] already acquired by this thread [497483776] (20160930/utmutex-254)
[ 2.054084] ACPI Error: Mutex [0x2] is not acquired, cannot release (20160930/utmutex-326)
And it triggers a dead lock:
[ 247.066214] INFO: task swapper/0:1 blocked for more than 120 seconds.
...
[ 247.091271] Call Trace:
...
[ 247.121523] down_timeout+0x47/0x50
[ 247.125065] acpi_os_wait_semaphore+0x47/0x62
[ 247.129475] acpi_ut_acquire_mutex+0x43/0x81
[ 247.133798] acpi_get_table+0x2d/0x84
[ 247.137513] acpi_table_attr_init+0xcd/0x100
[ 247.146590] acpi_sysfs_table_handler+0x5d/0xb8
[ 247.151174] acpi_bus_table_handler+0x23/0x2a
[ 247.155583] acpi_tb_install_standard_table+0xe0/0x213
[ 247.164489] acpi_tb_install_and_load_table+0x3a/0x82
[ 247.169592] acpi_ex_load_op+0x194/0x201
...
[ 247.200108] acpi_ns_evaluate+0x1bb/0x247
[ 247.204170] acpi_evaluate_object+0x178/0x274
[ 247.213249] acpi_processor_set_pdc+0x154/0x17b
...
The table mutex held in AcpiTbInstallAndLoadTable() is re-visited by
AcpiGetTable().
Noticing that the early mutex requirement actually belongs to the OSL layer
and has already been handled in Linux
acpi_os_wait_semaphore()/acpi_os_signal_semaphore(). This patch then can
fix the regression by removing this hidden logic from ACPICA core and
leaving it to OSPMs.
Tested-by: Tomi Sarvela <tomi.p.sarvela@intel.com>
Tested-by: Ye Xiaolong <xiaolong.ye@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
To avoid caller to trigger unexpected warning messages (Link #1):
ACPI Warning: Table ffffffffbb461d20, Validation count is zero before decrement
Which is reported from AcpiTbPutTable(). When the table is validated, the
pointer must be non-zero. Thus the message is not suitable for invalidated
tables. This patch fixes the callee side based on this fact. Reported by
Cristian Aravena Romero, Fixed by Lv Zheng.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=191221 [#1]
Reported-by: Cristian Aravena Romero <caravena@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
On linux, 2 ioremap() mechanisms are implemented for 2 stages:
1. During early boot, before memory manager is fully initialized.
2. For late boot and runtime, after memory manager is fully
initialized.
Maps mapped in the early stage cannot be used by late stage.
So for early stage, linux invokes AcpiGetTable()/AcpiPutTable() APIs to
free table mappings (means there is no imbalance), and for late stage,
linux mostly only invokes AcpiGetTable() table API (means there are
imbalances, and balances and imbalances co-exist).
The original mechanism is designed to allow:
1. early stage balances;
2. late stage co-existence of balances/imbalances.
But for the latter, it has a limitation, it doesn't allow balances to be
implemented for users who can easily increment ValidationCount to its
maximum value.
Considering this case:
1. A program opens a sysfs table file 65535 times, it can increase
ValidationCount and first increment causes the table to be mapped:
ValidationCount = 65535
2. AML execution causes "Load" to be executed on the same
table, this time it cannot increase ValidationCount, so
ValidationCount remains:
ValidationCount = 65535
3. The program closes sysfs table file 65535 times, it can decrease
ValidationCount and the last decrement cause the table to be
unmapped:
ValidationCount = 0
4. AML code still accessing the loaded table, kernel crash can be
observed.
This is because the original mechanism is only prepared for late stage
users that won't invoke AcpiPutTable() so often (means can only handle
co-existence of balanced non-frequent AcpiPutTable() invocations and
imbalanced AcpiGetTable() invocations), and cannot handle the
co-existence of balanced frequent AcpiPutTable() invocations and
imbalanced AcpiGetTable() invocations.
To prevent that from happening, add a ValidationCount threashold. When it
is reached, the ValidationCount can no longer be incremented/decremented to
invalidate the table descriptor (means preventing table unmappings). Now
the improved mechanism can handle co-existence of any balances/imbalances.
Note that code added in AcpiTbPutTable() is actually a no-op but changes
the warning message into a "warn once" one. Since all warning messages can
only appear once for one table descriptor, it is safe now to add them back
without worrying about log flooding. Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
On linux, 2 ioremap() mechanisms are implemented for 2 stages:
1. During early boot, before memory manager is fully initialized.
2. For late boot and runtime, after memory manager is fully
initialized.
Maps mapped in the early stage can not be used by late stage.
So for early stage, linux implements get/put like table APIs to free table
mappings, and for late stage, linux only invokes get table APIs.
We merged 2 implementations into single style API set:
AcpiGetTable() and AcpiPutTable(). During early stage, we want the
"ValidationCount" based mechanism to fully work to release table mappings,
while for late stages, if get/put invocations are balanced, we can free
mappings, but if not (we'll reach the warnings in
AcpiTbGetTable()/AcpiTbPutTable()), we should stop unmapping tables.
The design should work but unfortunately, "return_ACPI_STAUS(AE_LIMIT)"
prevents AcpiGetTable() from returning mapped table pointer to the
callers and the error message can flood kernel logs.
Thus this patch removes the error value returned by AcpiTbGetTable()
in that case along with the accompanying error message to fix the
issue.
Reported-by: Anush Seetharaman <anush.seetharaman@intel.com>
Reported-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Detected on the Surface 3:
The MSHW0011 driver uses Field Attrib Raw Process to return information
for the ACPI Battery. The DSDT declares a parameter of 2 though
functions like _BST or _BIX require a much bigger out buffer.
It looks like the incoming buffer has the requested size and we can
work around the issue by using this input size as the output and
parameters size.
As mentioned by Stephen Just on the kernel bugzilla (comment 44):
"Lv, after reading through 5.5.2.4.5.3 of the ACPI spec several times,
it appears that AccessLength is ignored for AttribRawProcessBytes
accesses - the access length is always specified by the user - and
in fact, the example omits the AccessLength argument entirely.
More specifically, comparing 5.5.2.4.5.3.9 and 5.5.2.4.5.3.10, it
appears that the only difference between AttribRawProcessBytes and
AttribRawBytes is that AttribRawProcessBytes does not seem to pay
attention to AccessLength, and lets the driver deal with it."
Link: https://bugzilla.kernel.org/show_bug.cgi?id=106231
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
