Fixing the ACPI_ERROR_NAMESPACE macros created an "unused variable"
compile error when ACPI_NO_ERROR_MESSAGES was defined. This commit
also fixes the above compilation errors by surrounding variables
meant for debugging inside a new ACPI_ERROR_ONLY macro.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
As the documentatuon above its declaration indicates, acpi_get_object_info()
is intended for early probe usage and as such should not call any methods
which may rely on op_regions, before this commit it was also calling _STA,
which on some systems does rely on op_regions.
Calling _STA before things are ready leads to errors such as these
(under Linux, on some hardware):
[ 0.123579] ACPI Error: No handler for Region [ECRM] (00000000ba9edc4c)
[generic_serial_bus] (20170831/evregion-166)
[ 0.123601] ACPI Error: Region generic_serial_bus (ID=9) has no handler
(20170831/exfldio-299)
[ 0.123618] ACPI Error: Method parse/execution failed
\_SB.I2C1.BAT1._STA, AE_NOT_EXIST (20170831/psparse-550)
End 2015 support for the _SUB method was removed for exactly the same
reason. Removing current_status from struct acpi_device_info only has a limited
impact. Within ACPICA it is only used by 2 debug messages, both
of which are modified to no longer print it with this commit.
Outside of ACPICA, there was one user in Linux, which has been patched to
no longer use current_status in Torvald's current master.
I've not checked if free_BSD or others are using the current_status field.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After being enabled for the first time, the GPEs may have STS bits already
set. Setting EN bits is not sufficient to trigger the GPEs again, so this
patch polls GPEs after enabling them for the first time.
This is a cleaner version on top of the "GPE clear" fix generated according
to Mika's report and Rafael's original Linux based fix. Based on Linux
commit originated from Rafael J. Wysocki, fixed by Lv Zheng.
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a risk that a GPE method/handler may be invoked twice. Let's
consider a case, both GPE0(RAW_HANDLER) and GPE1(_Exx) is triggered.
=======================================+=============================
IRQ handler (top-half) |IRQ polling
=======================================+=============================
acpi_ev_detect_gpe() |
LOCK() |
READ (GPE0-7 enable/status registers)|
^^^^^^^^^^^^ROOT CAUSE^^^^^^^^^^^^^^^|
Walk GPE0 |
UNLOCK() |LOCK()
Invoke GPE0 RAW_HANDLER |READ (GPE1 enable/status bit)
|acpi_ev_gpe_dispatch(irq=false)
| CLEAR (GPE1 enable bit)
| CLEAR (GPE1 status bit)
LOCK() |UNLOCK()
Walk GPE1 +=============================
acpi_ev_gpe_dispatch(irq=true) |IRQ polling (defer)
CLEAR (GPE1 enable bit) +=============================
CLEAR (GPE1 status bit) |acpi_ev_async_execute_gpe_method()
Walk others | Evaluate GPE1 _Exx
fi | acpi_ev_async_enable_gpe()
UNLOCK() | LOCK()
=======================================+ SET (GPE enable bit)
IRQ handler (bottom-half) | UNLOCK()
=======================================+
acpi_ev_async_execute_gpe_method() |
Evaluate GPE1 _Exx |
acpi_ev_async_enable_gpe() |
LOCK() |
SET (GPE1 enable bit) |
UNLOCK() |
=======================================+=============================
If acpi_ev_detect_gpe() is only invoked from the IRQ context, there won't be
more than one _Lxx/_Exx evaluations for one status bit flagging if the IRQ
handlers controlled by the underlying IRQ chip/driver (ex. APIC) are run in
serial. Note that, this is a known potential gap and we had an approach,
locking entire non-raw-handler processes in the top-half IRQ handler and
handling all raw-handlers out of the locked loop to be friendly to those
IRQ chip/driver. But the approach is too complicated while the issue is not
so real, thus ACPICA treated such issue (if any) as a parallelism/quality
issue of the underlying IRQ chip/driver to stop putting it on the radar.
Bug in link #1 is suspiciously reflecting the same cause, and if so, it can
also be fixed by this simpler approach.
But it will be no excuse an ACPICA problem now if ACPICA starts to poll
IRQs itself. In the changed scenario, _Exx will be evaluated from the task
context due to new ACPICA provided "polling after enabling GPEs" mechanism.
And the above figure uses edge-triggered GPEs demonstrating the possibility
of evaluating _Exx twice for one status bit flagging.
As a conclusion, there is now an increased chance of evaluating _Lxx/_Exx
more than once for one status bit flagging.
However this is still not a real problem if the _Lxx/_Exx checks the
underlying hardware IRQ reasoning and finally just changes the 2nd and the
follow-up evaluations into no-ops. Note that _Lxx should always be written
in this way as a level-trigger GPE could have it's status wrongly
duplicated by the underlying IRQ delivery mechanisms. But _Exx may have
very low quality BIOS by BIOS to trigger real issues. For example, trigger
duplicated button notifications.
To solve this issue, we need to stop reading a bunch of enable/status
register bits, but read only one GPE's enable/status bit. And GPE status
register's W1C nature ensures that acknowledging one GPE won't affect
another GPEs' status bits. Thus the hardware GPE architecture has already
provided us with the mechanism of implementing such parallelism.
So we can lock around one GPE handling process to achieve the parallelism:
1. If we can incorporate GPE enable bit check in detection and ensure the
atomicity of the following process (top-half IRQ handler):
READ (enable/status bit)
if (enabled && raised)
CLEAR (enable bit)
and handle the GPE after this process, we can ensure that we will only
invoke GPE handler once for one status bit flagging.
2. In addtion for edge-triggered GPEs, if we can ensure the atomicity of
the following process (top-half IRQ handler):
READ (enable/status bit)
if (enabled && raised)
CLEAR (enable bit)
CLEAR (status bit)
and handle the GPE after this process, we can ensure that we will only
invoke GPE handler once for one status bit flagging.
By doing a cleanup in this way, we can remove duplicate GPE handling code
and ensure that all logics are collected in 1 function. And the function
will be safe for both IRQ interrupt and IRQ polling, and will be safe for
us to release and re-acquire acpi_gbl_gpe_lock at any time rather than raw
handler only during the top-half IRQ handler. Lv Zheng.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196703 [#1]
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Unconditionally clearing ACPI IRQs during suspend/resume can lead to
unexpected IRQ losts. This patch fixes this issue by removing such IRQ
clearing code.
If this patch triggers regression, the regression should be in the GPE
handlers that cannot correctly determine some spurious triggered events as
no-ops. Please report any regression related to this commit to the ACPI
component on kernel bugzilla. Lv Zheng.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196249
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Reported-and-tested-by: Eric Bakula-Davis <ericbakuladavis@gmail.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 0e44fee13434766ebbb4d156e3ed45604508d7c3
This reverts commit e1342c9f2dde37a67e916099658b65984ef8a434.
Implicit conversion should in fact be disabled for the "explicit
conversion" operators. This is stated in the ACPI specification.
The operators affected are:
to_integer
to_string
to_buffer
to_decimal_string
to_hex_string
to_BCD
from_BCD
Link: https://github.com/acpica/acpica/commit/0e44fee1
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit c75af007d35c0afe8791ac39b7749c7442f49912
The %*s format specifier prints a string with a width indicated by an integer.
In the case of acpi_os_printf() ("%*s", acpi_gbl_nesting_level, " "),
a single space is printed to the console when acpi_gbl_nesting_level
is 0 or 1. This change increments acpi_gbl_nesting_level so that there
is one space printed when acpi_gbl_nesting_level is 0 and two spaces
printed when acpi_gbl_nesting_level is 1.
Link: https://github.com/acpica/acpica/commit/c75af007
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There is a variable name mismatch in acpi_ut_strtoul_multiply64()
between the ACPICA code in the kernel and the corresponding upstream
code which may be problematic if changes to this particular piece of
code are made upstream and ported to Linux, so rename the variable
in question to match its name in the upstream code.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit b2858b2cc83e1481950a2c976f62d4e1d758bc85
Changes line prefix from "ACPI Exception" to simply "ACPI Error"
to match the ACPI_ERROR macro. ACPI_EXCEPTION takes the ACPI status
as an argument, decodes and displays it along with the error
message.
Link: https://github.com/acpica/acpica/commit/b2858b2c
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit aa866a9b4f24bbec9f158d10325b486d7d12d90f
The declaration External (ABCD.EFGH) creates two nodes in the namespace: ABCD
and EFGH where ABCD is marked as an implicit external node. ABCD is labeled as
implicit because there does not exist a specific External (ABCD) declaration.
Before this change, the declaration External (ABCD.EFGH) and
External (ABCD.EFGH.IJKL) creates the namespace nodes ABCD, EFGH, and IJKL
where ABCD and EFGH are labeled as implicit external nodes. This is incorrect.
The only implicit node should be ABCD because EFGH and IJKL are explicit nodes.
This change fixes the labeling procecess of external op namespace nodes so that
nodes are properly labeled as implicit external.
Due to this commit, the below ASL code results in a compilation error.
definition_block ("DSDT.aml", "DSDT", 0x02, "INTEL", "BDW ", 0x0)
{
External(\_SB.PCI0.GFX0, device_obj)
External(\_SB.PCI0.GFX0.ALSI)
Scope(\_SB)
{
Device(PCI0)
{
Device(GFX0)
{
Name(_ADR, 0x00020000)
}
}
}
}
Link: https://github.com/acpica/acpica/commit/aa866a9b
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 9605023e7e6d1f05581502766c8cf2905bcc03d9
This patch implements a new infinite loop detection mechanism to replace
the old one, it uses acpi_os_get_timer() to limit loop execution into a
determined time slice.
This is useful in case some hardware/firmware operations really require the
AML interpreter to wait while the old mechanism could expire too fast on
recent machines.
The new mechanism converts old acpi_gbl_max_loop_iterations to store the user
configurable value for the new mechanism in order to allow users to be
still able to configure this value for acpiexec via command line. This
patch also removes wrong initilization code of acpi_gbl_max_loop_iterations
accordingly (it should have been initialized by ACPI_INIT_GLOBAL, and the
default value is also properly tuned for acpiexec). Reported by M. Foronda,
fixed by Lv Zheng.
Link: https://github.com/acpica/acpica/commit/9605023e
Link: https://bugzilla.kernel.org/show_bug.cgi?id=156501
Reported-by: M. Foronda <josemauricioforonda@gmail.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit 08a00639b0d6756e8ba1421419fc3728904651d9
The calls to acpi_os_acquire_object can result in a null being assigned
to Op (for example if a mutex acquire fails) which can lead to a
null pointer dereference on Op on the call to ASL_CV_TRANSFER_COMMENTS
(via function cv_transfer_comments). Move the block into the previous
block that checks for a null Op so that we never can call
cv_transfer_comments with a null Op.
Detected by: coverity_scan CID#1371660 ("Dereference after null check")
Link: https://github.com/acpica/acpica/commit/08a00639
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
ACPICA commit b4fd33f3c2af014aeec978d46392d286fd7f52b3
Delta calculation has an off-by-one error when there is a rollover.
For example, when start_ticks is 0x00FFFFFF and end_ticks is 0x00000000
(for 24-bit timer), delta_ticks should be 1 (one) but it was 0 (zero).
Link: https://github.com/acpica/acpica/commit/b4fd33f3
Signed-off-by: Jung-uk Kim <jkim@free_BSD.org>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpica:
ACPICA: Update version to 20170831
ACPICA: Update acpi_get_timer for 64-bit interface to acpi_hw_read
ACPICA: String conversions: Update to add new behaviors
ACPICA: String conversions: Cleanup/format comments. No functional changes
ACPICA: Restructure/cleanup all string-to-integer conversion functions
ACPICA: Header support for the PDTT ACPI table
ACPICA: acpiexec: Add testability of deferred table verification
ACPICA: Hardware: Enable 64-bit support of hardware accesses
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
ACPICA commit e3574138af82a25d76324559848689946982dbd0
1) Allow whitespace in string before the constant
2) ut_strtoul64 now always creates a 64-bit integer; iASL will
truncate this to the lower 32-bits if the table being compiled
is a 32-bit table (DSDT revision less than 2).
Link: https://github.com/acpica/acpica/commit/e3574138af82
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Lv Zheng <lv.zheng@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
