In some cases it is useful to know whether or not the
AcpiEvDetectGpe() called by AcpiDispatchGpe() has found the GPE to be
active, so return the return value of it (whose data type is UINT32)
from latter.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Introduce acpi_dispatch_gpe() as a wrapper around AcpiEvDetectGpe()
for checking if the given GPE (as represented by a GPE device handle
and a GPE number) is currently active and dispatching it (if that's
the case) outside of interrupt context.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Pointer ObjDesc is being initialized with a value that is never
read and it is being updated later with a new value. The initialization
is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
ACPI GPEs (other than the EC one) can be enabled in two situations.
First, the GPEs with existing _Lxx and _Exx methods are enabled
implicitly by ACPICA during system initialization. Second, the GPEs
without these methods (like GPEs listed by _PRW objects for wakeup
devices) need to be enabled directly by the code that is going to use
them (e.g. ACPI power management or device drivers).
In the former case, if the status of a given GPE is set to start
with, its handler method (either _Lxx or _Exx) needs to be invoked to
take care of the events (possibly) signaled before the GPE was
enabled. In the latter case, however, the first caller of
acpi_enable_gpe() for a given GPE should not be expected to care
about any events that might be signaled through it earlier. In that
case, it is better to clear the status of the GPE before enabling it,
to prevent stale events from triggering unwanted actions (like
spurious system resume, for example).
For this reason, modify acpi_ev_add_gpe_reference() to take an
additional boolean argument indicating whether or not the GPE status
needs to be cleared when its reference counter changes from zero to
one and make acpi_enable_gpe() pass TRUE to it through that new
argument.
Fixes: 18996f2db918 ("ACPICA: Events: Stop unconditionally clearing ACPI IRQs during suspend/resume")
Reported-by: Furquan Shaikh <furquan@google.com>
Tested-by: Furquan Shaikh <furquan@google.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
There have been several places that has been calling functions
regarding module level code blocks. This change removes all old
vestiges in the codebase. This is dead code.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
For the objects that are created by default (_GPE, _SB_, etc)
there is no need to use the heavyweight NsLookup function.
Instead, simply create each object and link it in as the namespace
is built.
Implemented additional buffer overflow analysis for BufferField
declarations. Check if a buffer index argument to a create buffer
field operation is beyond the end of the target buffer.
*
* This affects these AML operators:
*
* AML_CREATE_FIELD_OP
* AML_CREATE_BIT_FIELD_OP
* AML_CREATE_BYTE_FIELD_OP
* AML_CREATE_WORD_FIELD_OP
* AML_CREATE_DWORD_FIELD_OP
* AML_CREATE_QWORD_FIELD_OP
This change improves forward reference detection for named objects
inside of scopes.
If a parse object has the OP_NOT_FOUND_DURING_LOAD set, it means that
Op is a reference to a named object that is declared later in the AML
bytecode. This is allowed if the reference is inside of a method and
the declaration is outside of a method like so:
DefinitionBlock(...)
{
Method (TEST)
{
Return (NUM0)
}
Name (NUM0,0)
}
However, if the declaration and reference are both in the same method
or outside any methods, this is a forward reference and should be
marked as an error because it would result in runtime errors.
DefinitionBlock(...)
{
Name (BUFF, Buffer (NUM0) {}) // Forward reference
Name (NUM0, 0x0)
Method (TEST)
{
Local0 = NUM1
Name (NUM1, 0x1) // Forward reference
return (Local0)
}
}
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
Create___Field declares a BufferField over an existing buffer. This
change adds an additional check to analyze constant values in the
declarations of these buffer fields. This attempt to detect that the
new buffer does not overrun the original source buffer.
There have been 2 more compiler remarks added. One that states that
the starting index of the new buffer field is beyond the end of the
buffer and another message indicating that the this new buffer
extends beyond the end of the source buffer.
We initially thought that this would actually be an error. However,
consider the following case:
Name (BUF0, buffer(0){}) // Create an empty buffer
Name (BUF1, buffer(0x5){0x0,0x1,0x2,0x3,0x4})
BUF0 = BUF1
CreateByteField (BUF0, 0x0, BYTE) // this is valid!
This code runs without issues because BUF0 gets assigned to BUF1. Due
to the lack of usage analysis in iASL, the source buffer can change
throughout table load or a control method execution.
In order to make this analysis check result as an error, we need to
add additional steps to analyze the usage of BUF0 between its
declaration and it's use in CreateByteField.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
This reverts commit 3132320003b348bcf48274d4e326e496ffc4b23b.
This commit unintentionally emitted AML bytecode with incorrect
package lengths for some ASL code related to Fields and
OperationRegions. This mal-formed AML can cause systems to crash
during boot.
Signed-off-by: Erik Schmauss <erik.schmauss@intel.com>
This reverts ACPICA commit 6c43e1acdf93a04ca32898d1d89d93fde04d121a.
Revert "ACPICA: Clear status of GPEs before enabling them"
Revert commit c8b1917c8987 ("ACPICA: Clear status of GPEs before
enabling them") that causes problems with Thunderbolt controllers
to occur if a dock device is connected at init time (the xhci_hcd
and thunderbolt modules crash which prevents peripherals connected
through them from working).
Commit c8b1917c8987 effectively causes commit ecc1165b8b74 ("ACPICA:
Dispatch active GPEs at init time") to get undone, so the problem
addressed by commit ecc1165b8b74 appears again as a result of it.
Fixes: c8b1917c8987 ("ACPICA: Clear status of GPEs before enabling them")
Link: https://lore.kernel.org/lkml/s5hy33siofw.wl-tiwai@suse.de/T/#u
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1132943
Reported-by: Michael Hirmke <opensuse@mike.franken.de>
Reported-by: Takashi Iwai <tiwai@suse.de>
Cc: 4.17+ <stable@vger.kernel.org> # 4.17+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
