2018-03-14 23:13:07 +00:00
|
|
|
// SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0
|
2005-04-16 22:20:36 +00:00
|
|
|
/******************************************************************************
|
|
|
|
*
|
|
|
|
* Module Name: evgpe - General Purpose Event handling and dispatch
|
|
|
|
*
|
2023-04-05 13:38:21 +00:00
|
|
|
* Copyright (C) 2000 - 2023, Intel Corp.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2018-03-14 23:13:07 +00:00
|
|
|
*****************************************************************************/
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#include <acpi/acpi.h>
|
2009-01-09 05:30:03 +00:00
|
|
|
#include "accommon.h"
|
|
|
|
#include "acevents.h"
|
|
|
|
#include "acnamesp.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
#define _COMPONENT ACPI_EVENTS
|
2005-08-05 04:44:28 +00:00
|
|
|
ACPI_MODULE_NAME("evgpe")
|
2012-02-14 10:14:27 +00:00
|
|
|
#if (!ACPI_REDUCED_HARDWARE) /* Entire module */
|
2005-04-19 02:49:35 +00:00
|
|
|
/* Local prototypes */
|
2005-08-05 04:44:28 +00:00
|
|
|
static void ACPI_SYSTEM_XFACE acpi_ev_asynch_execute_gpe_method(void *context);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-12-13 05:39:07 +00:00
|
|
|
static void ACPI_SYSTEM_XFACE acpi_ev_asynch_enable_gpe(void *context);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
2010-07-01 02:11:45 +00:00
|
|
|
* FUNCTION: acpi_ev_update_gpe_enable_mask
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* PARAMETERS: gpe_event_info - GPE to update
|
|
|
|
*
|
|
|
|
* RETURN: Status
|
|
|
|
*
|
2010-07-01 02:11:45 +00:00
|
|
|
* DESCRIPTION: Updates GPE register enable mask based upon whether there are
|
|
|
|
* runtime references to this GPE
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
acpi_status
|
2010-07-01 02:11:45 +00:00
|
|
|
acpi_ev_update_gpe_enable_mask(struct acpi_gpe_event_info *gpe_event_info)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-08-05 04:44:28 +00:00
|
|
|
struct acpi_gpe_register_info *gpe_register_info;
|
2010-06-08 08:48:26 +00:00
|
|
|
u32 register_bit;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-07-01 02:11:45 +00:00
|
|
|
ACPI_FUNCTION_TRACE(ev_update_gpe_enable_mask);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
gpe_register_info = gpe_event_info->register_info;
|
|
|
|
if (!gpe_register_info) {
|
2005-08-05 04:44:28 +00:00
|
|
|
return_ACPI_STATUS(AE_NOT_EXIST);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2009-03-06 02:05:18 +00:00
|
|
|
|
2012-08-17 03:10:02 +00:00
|
|
|
register_bit = acpi_hw_get_gpe_register_bit(gpe_event_info);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-07-01 02:11:45 +00:00
|
|
|
/* Clear the run bit up front */
|
2010-04-06 06:52:37 +00:00
|
|
|
|
2010-02-17 22:41:07 +00:00
|
|
|
ACPI_CLEAR_BIT(gpe_register_info->enable_for_run, register_bit);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-07-01 02:11:45 +00:00
|
|
|
/* Set the mask bit only if there are references to this GPE */
|
2010-04-06 06:52:37 +00:00
|
|
|
|
|
|
|
if (gpe_event_info->runtime_count) {
|
2012-10-31 02:25:45 +00:00
|
|
|
ACPI_SET_BIT(gpe_register_info->enable_for_run,
|
|
|
|
(u8)register_bit);
|
2010-04-06 06:52:37 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-12-29 05:54:36 +00:00
|
|
|
gpe_register_info->enable_mask = gpe_register_info->enable_for_run;
|
2005-08-05 04:44:28 +00:00
|
|
|
return_ACPI_STATUS(AE_OK);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2010-07-01 03:01:12 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_enable_gpe
|
|
|
|
*
|
2014-10-10 02:39:39 +00:00
|
|
|
* PARAMETERS: gpe_event_info - GPE to enable
|
2010-07-01 03:01:12 +00:00
|
|
|
*
|
|
|
|
* RETURN: Status
|
|
|
|
*
|
2018-03-14 23:12:57 +00:00
|
|
|
* DESCRIPTION: Enable a GPE.
|
2010-07-01 03:01:12 +00:00
|
|
|
*
|
|
|
|
******************************************************************************/
|
2014-10-10 02:39:39 +00:00
|
|
|
|
2012-10-31 02:25:45 +00:00
|
|
|
acpi_status acpi_ev_enable_gpe(struct acpi_gpe_event_info *gpe_event_info)
|
2010-07-01 03:01:12 +00:00
|
|
|
{
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
ACPI_FUNCTION_TRACE(ev_enable_gpe);
|
|
|
|
|
2019-03-20 22:28:44 +00:00
|
|
|
/* Enable the requested GPE */
|
2019-04-30 09:18:21 +00:00
|
|
|
|
2015-04-15 02:00:27 +00:00
|
|
|
status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_ENABLE);
|
2010-07-01 03:01:12 +00:00
|
|
|
return_ACPI_STATUS(status);
|
|
|
|
}
|
|
|
|
|
2016-08-04 08:43:39 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_mask_gpe
|
|
|
|
*
|
|
|
|
* PARAMETERS: gpe_event_info - GPE to be blocked/unblocked
|
|
|
|
* is_masked - Whether the GPE is masked or not
|
|
|
|
*
|
|
|
|
* RETURN: Status
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Unconditionally mask/unmask a GPE during runtime.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
acpi_status
|
|
|
|
acpi_ev_mask_gpe(struct acpi_gpe_event_info *gpe_event_info, u8 is_masked)
|
|
|
|
{
|
|
|
|
struct acpi_gpe_register_info *gpe_register_info;
|
|
|
|
u32 register_bit;
|
|
|
|
|
|
|
|
ACPI_FUNCTION_TRACE(ev_mask_gpe);
|
|
|
|
|
|
|
|
gpe_register_info = gpe_event_info->register_info;
|
|
|
|
if (!gpe_register_info) {
|
|
|
|
return_ACPI_STATUS(AE_NOT_EXIST);
|
|
|
|
}
|
|
|
|
|
|
|
|
register_bit = acpi_hw_get_gpe_register_bit(gpe_event_info);
|
|
|
|
|
|
|
|
/* Perform the action */
|
|
|
|
|
|
|
|
if (is_masked) {
|
|
|
|
if (register_bit & gpe_register_info->mask_for_run) {
|
|
|
|
return_ACPI_STATUS(AE_BAD_PARAMETER);
|
|
|
|
}
|
|
|
|
|
|
|
|
(void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE);
|
|
|
|
ACPI_SET_BIT(gpe_register_info->mask_for_run, (u8)register_bit);
|
|
|
|
} else {
|
|
|
|
if (!(register_bit & gpe_register_info->mask_for_run)) {
|
|
|
|
return_ACPI_STATUS(AE_BAD_PARAMETER);
|
|
|
|
}
|
|
|
|
|
|
|
|
ACPI_CLEAR_BIT(gpe_register_info->mask_for_run,
|
|
|
|
(u8)register_bit);
|
|
|
|
if (gpe_event_info->runtime_count
|
|
|
|
&& !gpe_event_info->disable_for_dispatch) {
|
|
|
|
(void)acpi_hw_low_set_gpe(gpe_event_info,
|
|
|
|
ACPI_GPE_ENABLE);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return_ACPI_STATUS(AE_OK);
|
|
|
|
}
|
|
|
|
|
2010-08-03 21:55:14 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
2010-12-13 05:36:15 +00:00
|
|
|
* FUNCTION: acpi_ev_add_gpe_reference
|
2010-08-03 21:55:14 +00:00
|
|
|
*
|
2010-12-13 05:39:37 +00:00
|
|
|
* PARAMETERS: gpe_event_info - Add a reference to this GPE
|
ACPICA: Clear status of GPEs on first direct enable
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>
2019-06-17 11:31:45 +00:00
|
|
|
* clear_on_enable - Clear GPE status before enabling it
|
2010-08-03 21:55:14 +00:00
|
|
|
*
|
|
|
|
* RETURN: Status
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Add a reference to a GPE. On the first reference, the GPE is
|
|
|
|
* hardware-enabled.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
2012-10-31 02:25:45 +00:00
|
|
|
acpi_status
|
ACPICA: Clear status of GPEs on first direct enable
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>
2019-06-17 11:31:45 +00:00
|
|
|
acpi_ev_add_gpe_reference(struct acpi_gpe_event_info *gpe_event_info,
|
|
|
|
u8 clear_on_enable)
|
2010-08-03 21:55:14 +00:00
|
|
|
{
|
|
|
|
acpi_status status = AE_OK;
|
|
|
|
|
2010-12-13 05:36:15 +00:00
|
|
|
ACPI_FUNCTION_TRACE(ev_add_gpe_reference);
|
|
|
|
|
2010-08-03 21:55:14 +00:00
|
|
|
if (gpe_event_info->runtime_count == ACPI_UINT8_MAX) {
|
|
|
|
return_ACPI_STATUS(AE_LIMIT);
|
|
|
|
}
|
|
|
|
|
|
|
|
gpe_event_info->runtime_count++;
|
|
|
|
if (gpe_event_info->runtime_count == 1) {
|
2010-12-13 05:39:37 +00:00
|
|
|
|
|
|
|
/* Enable on first reference */
|
|
|
|
|
ACPICA: Clear status of GPEs on first direct enable
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>
2019-06-17 11:31:45 +00:00
|
|
|
if (clear_on_enable) {
|
|
|
|
(void)acpi_hw_clear_gpe(gpe_event_info);
|
|
|
|
}
|
|
|
|
|
2010-08-03 21:55:14 +00:00
|
|
|
status = acpi_ev_update_gpe_enable_mask(gpe_event_info);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
status = acpi_ev_enable_gpe(gpe_event_info);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
gpe_event_info->runtime_count--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return_ACPI_STATUS(status);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
*
|
2010-12-13 05:36:15 +00:00
|
|
|
* FUNCTION: acpi_ev_remove_gpe_reference
|
2010-08-03 21:55:14 +00:00
|
|
|
*
|
2010-12-13 05:39:37 +00:00
|
|
|
* PARAMETERS: gpe_event_info - Remove a reference to this GPE
|
2010-08-03 21:55:14 +00:00
|
|
|
*
|
|
|
|
* RETURN: Status
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Remove a reference to a GPE. When the last reference is
|
|
|
|
* removed, the GPE is hardware-disabled.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
2012-10-31 02:25:45 +00:00
|
|
|
acpi_status
|
|
|
|
acpi_ev_remove_gpe_reference(struct acpi_gpe_event_info *gpe_event_info)
|
2010-08-03 21:55:14 +00:00
|
|
|
{
|
|
|
|
acpi_status status = AE_OK;
|
|
|
|
|
2010-12-13 05:36:15 +00:00
|
|
|
ACPI_FUNCTION_TRACE(ev_remove_gpe_reference);
|
|
|
|
|
2010-08-03 21:55:14 +00:00
|
|
|
if (!gpe_event_info->runtime_count) {
|
|
|
|
return_ACPI_STATUS(AE_LIMIT);
|
|
|
|
}
|
|
|
|
|
|
|
|
gpe_event_info->runtime_count--;
|
|
|
|
if (!gpe_event_info->runtime_count) {
|
2010-12-13 05:39:37 +00:00
|
|
|
|
|
|
|
/* Disable on last reference */
|
|
|
|
|
2010-08-03 21:55:14 +00:00
|
|
|
status = acpi_ev_update_gpe_enable_mask(gpe_event_info);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
2012-10-31 02:25:45 +00:00
|
|
|
status =
|
|
|
|
acpi_hw_low_set_gpe(gpe_event_info,
|
2015-04-15 02:00:27 +00:00
|
|
|
ACPI_GPE_DISABLE);
|
2010-08-03 21:55:14 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
gpe_event_info->runtime_count++;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return_ACPI_STATUS(status);
|
|
|
|
}
|
|
|
|
|
2010-04-06 06:52:37 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_low_get_gpe_info
|
|
|
|
*
|
|
|
|
* PARAMETERS: gpe_number - Raw GPE number
|
|
|
|
* gpe_block - A GPE info block
|
|
|
|
*
|
|
|
|
* RETURN: A GPE event_info struct. NULL if not a valid GPE (The gpe_number
|
|
|
|
* is not within the specified GPE block)
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Returns the event_info struct associated with this GPE. This is
|
|
|
|
* the low-level implementation of ev_get_gpe_event_info.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
struct acpi_gpe_event_info *acpi_ev_low_get_gpe_info(u32 gpe_number,
|
|
|
|
struct acpi_gpe_block_info
|
|
|
|
*gpe_block)
|
|
|
|
{
|
|
|
|
u32 gpe_index;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Validate that the gpe_number is within the specified gpe_block.
|
|
|
|
* (Two steps)
|
|
|
|
*/
|
|
|
|
if (!gpe_block || (gpe_number < gpe_block->block_base_number)) {
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
gpe_index = gpe_number - gpe_block->block_base_number;
|
|
|
|
if (gpe_index >= gpe_block->gpe_count) {
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
return (&gpe_block->event_info[gpe_index]);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_get_gpe_event_info
|
|
|
|
*
|
2008-11-12 08:01:56 +00:00
|
|
|
* PARAMETERS: gpe_device - Device node. NULL for GPE0/GPE1
|
2005-04-16 22:20:36 +00:00
|
|
|
* gpe_number - Raw GPE number
|
|
|
|
*
|
|
|
|
* RETURN: A GPE event_info struct. NULL if not a valid GPE
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Returns the event_info struct associated with this GPE.
|
|
|
|
* Validates the gpe_block and the gpe_number
|
|
|
|
*
|
|
|
|
* Should be called only when the GPE lists are semaphore locked
|
|
|
|
* and not subject to change.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
2005-08-05 04:44:28 +00:00
|
|
|
struct acpi_gpe_event_info *acpi_ev_get_gpe_event_info(acpi_handle gpe_device,
|
|
|
|
u32 gpe_number)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-08-05 04:44:28 +00:00
|
|
|
union acpi_operand_object *obj_desc;
|
2010-04-06 06:52:37 +00:00
|
|
|
struct acpi_gpe_event_info *gpe_info;
|
2008-06-10 05:42:13 +00:00
|
|
|
u32 i;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-08-05 04:44:28 +00:00
|
|
|
ACPI_FUNCTION_ENTRY();
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-04-27 03:32:28 +00:00
|
|
|
/* A NULL gpe_device means use the FADT-defined GPE block(s) */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (!gpe_device) {
|
2006-10-02 04:00:00 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Examine GPE Block 0 and 1 (These blocks are permanent) */
|
|
|
|
|
|
|
|
for (i = 0; i < ACPI_MAX_GPE_BLOCKS; i++) {
|
2010-04-06 06:52:37 +00:00
|
|
|
gpe_info = acpi_ev_low_get_gpe_info(gpe_number,
|
|
|
|
acpi_gbl_gpe_fadt_blocks
|
|
|
|
[i]);
|
|
|
|
if (gpe_info) {
|
|
|
|
return (gpe_info);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* The gpe_number was not in the range of either FADT GPE block */
|
|
|
|
|
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* A Non-NULL gpe_device means this is a GPE Block Device */
|
|
|
|
|
2012-10-31 02:25:45 +00:00
|
|
|
obj_desc =
|
|
|
|
acpi_ns_get_attached_object((struct acpi_namespace_node *)
|
2007-05-10 03:34:35 +00:00
|
|
|
gpe_device);
|
2005-08-05 04:44:28 +00:00
|
|
|
if (!obj_desc || !obj_desc->device.gpe_block) {
|
2005-04-16 22:20:36 +00:00
|
|
|
return (NULL);
|
|
|
|
}
|
|
|
|
|
2010-04-06 06:52:37 +00:00
|
|
|
return (acpi_ev_low_get_gpe_info
|
|
|
|
(gpe_number, obj_desc->device.gpe_block));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_gpe_detect
|
|
|
|
*
|
|
|
|
* PARAMETERS: gpe_xrupt_list - Interrupt block for this interrupt.
|
|
|
|
* Can have multiple GPE blocks attached.
|
|
|
|
*
|
|
|
|
* RETURN: INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED
|
|
|
|
*
|
2008-11-12 08:01:56 +00:00
|
|
|
* DESCRIPTION: Detect if any GP events have occurred. This function is
|
2005-04-16 22:20:36 +00:00
|
|
|
* executed at interrupt level.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
2014-10-10 02:39:39 +00:00
|
|
|
u32 acpi_ev_gpe_detect(struct acpi_gpe_xrupt_info *gpe_xrupt_list)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-10-21 04:00:00 +00:00
|
|
|
struct acpi_gpe_block_info *gpe_block;
|
2015-02-05 07:20:22 +00:00
|
|
|
struct acpi_namespace_node *gpe_device;
|
2005-10-21 04:00:00 +00:00
|
|
|
struct acpi_gpe_register_info *gpe_register_info;
|
2015-02-05 07:20:22 +00:00
|
|
|
struct acpi_gpe_event_info *gpe_event_info;
|
|
|
|
u32 gpe_number;
|
2005-08-05 04:44:28 +00:00
|
|
|
u32 int_status = ACPI_INTERRUPT_NOT_HANDLED;
|
2006-01-27 21:43:00 +00:00
|
|
|
acpi_cpu_flags flags;
|
2008-06-10 05:42:13 +00:00
|
|
|
u32 i;
|
|
|
|
u32 j;
|
2005-08-05 04:44:28 +00:00
|
|
|
|
ACPI: ACPICA 20060421
Removed a device initialization optimization introduced in
20051216 where the _STA method was not run unless an _INI
was also present for the same device. This optimization
could cause problems because it could allow _INI methods
to be run within a not-present device subtree (If a
not-present device had no _INI, _STA would not be run,
the not-present status would not be discovered, and the
children of the device would be incorrectly traversed.)
Implemented a new _STA optimization where namespace
subtrees that do not contain _INI are identified and
ignored during device initialization. Selectively running
_STA can significantly improve boot time on large machines
(with assistance from Len Brown.)
Implemented support for the device initialization case
where the returned _STA flags indicate a device not-present
but functioning. In this case, _INI is not run, but the
device children are examined for presence, as per the
ACPI specification.
Implemented an additional change to the IndexField support
in order to conform to MS behavior. The value written to
the Index Register is not simply a byte offset, it is a
byte offset in units of the access width of the parent
Index Field. (Fiodor Suietov)
Defined and deployed a new OSL interface,
acpi_os_validate_address(). This interface is called during
the creation of all AML operation regions, and allows
the host OS to exert control over what addresses it will
allow the AML code to access. Operation Regions whose
addresses are disallowed will cause a runtime exception
when they are actually accessed (will not affect or abort
table loading.)
Defined and deployed a new OSL interface,
acpi_os_validate_interface(). This interface allows the host OS
to match the various "optional" interface/behavior strings
for the _OSI predefined control method as appropriate
(with assistance from Bjorn Helgaas.)
Restructured and corrected various problems in the
exception handling code paths within DsCallControlMethod
and DsTerminateControlMethod in dsmethod (with assistance
from Takayoshi Kochi.)
Modified the Linux source converter to ignore quoted string
literals while converting identifiers from mixed to lower
case. This will correct problems with the disassembler
and other areas where such strings must not be modified.
The ACPI_FUNCTION_* macros no longer require quotes around
the function name. This allows the Linux source converter
to convert the names, now that the converter ignores
quoted strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-21 21:15:00 +00:00
|
|
|
ACPI_FUNCTION_NAME(ev_gpe_detect);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Check for the case where there are no GPEs */
|
|
|
|
|
|
|
|
if (!gpe_xrupt_list) {
|
|
|
|
return (int_status);
|
|
|
|
}
|
|
|
|
|
2006-06-23 21:04:00 +00:00
|
|
|
/*
|
|
|
|
* We need to obtain the GPE lock for both the data structs and registers
|
2008-11-12 08:01:56 +00:00
|
|
|
* Note: Not necessary to obtain the hardware lock, since the GPE
|
|
|
|
* registers are owned by the gpe_lock.
|
2006-06-23 21:04:00 +00:00
|
|
|
*/
|
2005-08-05 04:44:28 +00:00
|
|
|
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
|
2006-06-08 20:29:00 +00:00
|
|
|
|
|
|
|
/* Examine all GPE blocks attached to this interrupt level */
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
gpe_block = gpe_xrupt_list->gpe_block_list_head;
|
|
|
|
while (gpe_block) {
|
2015-02-05 07:20:22 +00:00
|
|
|
gpe_device = gpe_block->node;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2008-11-12 08:01:56 +00:00
|
|
|
* Read all of the 8-bit GPE status and enable registers in this GPE
|
|
|
|
* block, saving all of them. Find all currently active GP events.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
|
|
|
for (i = 0; i < gpe_block->register_count; i++) {
|
2006-10-02 04:00:00 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Get the next status/enable pair */
|
|
|
|
|
|
|
|
gpe_register_info = &gpe_block->register_info[i];
|
|
|
|
|
2011-02-14 07:29:34 +00:00
|
|
|
/*
|
|
|
|
* Optimization: If there are no GPEs enabled within this
|
|
|
|
* register, we can safely ignore the entire register.
|
|
|
|
*/
|
|
|
|
if (!(gpe_register_info->enable_for_run |
|
|
|
|
gpe_register_info->enable_for_wake)) {
|
2012-08-17 02:55:14 +00:00
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INTERRUPTS,
|
2014-04-30 02:06:15 +00:00
|
|
|
"Ignore disabled registers for GPE %02X-%02X: "
|
2012-08-17 02:55:14 +00:00
|
|
|
"RunEnable=%02X, WakeEnable=%02X\n",
|
|
|
|
gpe_register_info->
|
|
|
|
base_gpe_number,
|
|
|
|
gpe_register_info->
|
|
|
|
base_gpe_number +
|
|
|
|
(ACPI_GPE_REGISTER_WIDTH - 1),
|
|
|
|
gpe_register_info->
|
|
|
|
enable_for_run,
|
|
|
|
gpe_register_info->
|
|
|
|
enable_for_wake));
|
2011-02-14 07:29:34 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Now look at the individual GPEs in this byte register */
|
|
|
|
|
|
|
|
for (j = 0; j < ACPI_GPE_REGISTER_WIDTH; j++) {
|
2006-10-02 04:00:00 +00:00
|
|
|
|
ACPICA: Events: Add parallel GPE handling support to fix potential redundant _Exx evaluations
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>
2018-03-14 23:12:58 +00:00
|
|
|
/* Detect and dispatch one GPE bit */
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2015-02-05 07:20:22 +00:00
|
|
|
gpe_event_info =
|
|
|
|
&gpe_block->
|
2016-05-05 04:57:53 +00:00
|
|
|
event_info[((acpi_size)i *
|
2015-02-05 07:20:22 +00:00
|
|
|
ACPI_GPE_REGISTER_WIDTH) + j];
|
|
|
|
gpe_number =
|
|
|
|
j + gpe_register_info->base_gpe_number;
|
ACPICA: Events: Add parallel GPE handling support to fix potential redundant _Exx evaluations
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>
2018-03-14 23:12:58 +00:00
|
|
|
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
|
|
|
|
int_status |=
|
|
|
|
acpi_ev_detect_gpe(gpe_device,
|
|
|
|
gpe_event_info,
|
|
|
|
gpe_number);
|
|
|
|
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
gpe_block = gpe_block->next;
|
|
|
|
}
|
|
|
|
|
2005-08-05 04:44:28 +00:00
|
|
|
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
|
2005-04-16 22:20:36 +00:00
|
|
|
return (int_status);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_asynch_execute_gpe_method
|
|
|
|
*
|
|
|
|
* PARAMETERS: Context (gpe_event_info) - Info for this GPE
|
|
|
|
*
|
|
|
|
* RETURN: None
|
|
|
|
*
|
2006-05-26 20:36:00 +00:00
|
|
|
* DESCRIPTION: Perform the actual execution of a GPE control method. This
|
|
|
|
* function is called from an invocation of acpi_os_execute and
|
|
|
|
* therefore does NOT execute at interrupt level - so that
|
2005-04-16 22:20:36 +00:00
|
|
|
* the control method itself is not executed in the context of
|
|
|
|
* an interrupt handler.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
2005-08-05 04:44:28 +00:00
|
|
|
static void ACPI_SYSTEM_XFACE acpi_ev_asynch_execute_gpe_method(void *context)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2010-12-13 05:39:07 +00:00
|
|
|
struct acpi_gpe_event_info *gpe_event_info = context;
|
2015-02-05 07:20:07 +00:00
|
|
|
acpi_status status = AE_OK;
|
2006-05-26 20:36:00 +00:00
|
|
|
struct acpi_evaluate_info *info;
|
2012-06-29 02:04:17 +00:00
|
|
|
struct acpi_gpe_notify_info *notify;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
ACPI: ACPICA 20060421
Removed a device initialization optimization introduced in
20051216 where the _STA method was not run unless an _INI
was also present for the same device. This optimization
could cause problems because it could allow _INI methods
to be run within a not-present device subtree (If a
not-present device had no _INI, _STA would not be run,
the not-present status would not be discovered, and the
children of the device would be incorrectly traversed.)
Implemented a new _STA optimization where namespace
subtrees that do not contain _INI are identified and
ignored during device initialization. Selectively running
_STA can significantly improve boot time on large machines
(with assistance from Len Brown.)
Implemented support for the device initialization case
where the returned _STA flags indicate a device not-present
but functioning. In this case, _INI is not run, but the
device children are examined for presence, as per the
ACPI specification.
Implemented an additional change to the IndexField support
in order to conform to MS behavior. The value written to
the Index Register is not simply a byte offset, it is a
byte offset in units of the access width of the parent
Index Field. (Fiodor Suietov)
Defined and deployed a new OSL interface,
acpi_os_validate_address(). This interface is called during
the creation of all AML operation regions, and allows
the host OS to exert control over what addresses it will
allow the AML code to access. Operation Regions whose
addresses are disallowed will cause a runtime exception
when they are actually accessed (will not affect or abort
table loading.)
Defined and deployed a new OSL interface,
acpi_os_validate_interface(). This interface allows the host OS
to match the various "optional" interface/behavior strings
for the _OSI predefined control method as appropriate
(with assistance from Bjorn Helgaas.)
Restructured and corrected various problems in the
exception handling code paths within DsCallControlMethod
and DsTerminateControlMethod in dsmethod (with assistance
from Takayoshi Kochi.)
Modified the Linux source converter to ignore quoted string
literals while converting identifiers from mixed to lower
case. This will correct problems with the disassembler
and other areas where such strings must not be modified.
The ACPI_FUNCTION_* macros no longer require quotes around
the function name. This allows the Linux source converter
to convert the names, now that the converter ignores
quoted strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-21 21:15:00 +00:00
|
|
|
ACPI_FUNCTION_TRACE(ev_asynch_execute_gpe_method);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-12-13 05:39:17 +00:00
|
|
|
/* Do the correct dispatch - normal method or implicit notify */
|
|
|
|
|
2015-02-05 07:20:29 +00:00
|
|
|
switch (ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags)) {
|
2010-12-13 05:39:17 +00:00
|
|
|
case ACPI_GPE_DISPATCH_NOTIFY:
|
|
|
|
/*
|
|
|
|
* Implicit notify.
|
|
|
|
* Dispatch a DEVICE_WAKE notify to the appropriate handler.
|
|
|
|
* NOTE: the request is queued for execution after this method
|
|
|
|
* completes. The notify handlers are NOT invoked synchronously
|
|
|
|
* from this thread -- because handlers may in turn run other
|
|
|
|
* control methods.
|
2012-06-29 02:04:17 +00:00
|
|
|
*
|
|
|
|
* June 2012: Expand implicit notify mechanism to support
|
|
|
|
* notifies on multiple device objects.
|
2010-12-13 05:39:17 +00:00
|
|
|
*/
|
2015-02-05 07:20:01 +00:00
|
|
|
notify = gpe_event_info->dispatch.notify_list;
|
2012-06-29 02:04:17 +00:00
|
|
|
while (ACPI_SUCCESS(status) && notify) {
|
|
|
|
status =
|
|
|
|
acpi_ev_queue_notify_request(notify->device_node,
|
|
|
|
ACPI_NOTIFY_DEVICE_WAKE);
|
|
|
|
|
|
|
|
notify = notify->next;
|
2011-02-24 18:59:21 +00:00
|
|
|
}
|
|
|
|
|
2010-12-13 05:39:17 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case ACPI_GPE_DISPATCH_METHOD:
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-05-26 20:36:00 +00:00
|
|
|
/* Allocate the evaluation information block */
|
|
|
|
|
|
|
|
info = ACPI_ALLOCATE_ZEROED(sizeof(struct acpi_evaluate_info));
|
|
|
|
if (!info) {
|
|
|
|
status = AE_NO_MEMORY;
|
|
|
|
} else {
|
|
|
|
/*
|
2012-12-19 05:36:49 +00:00
|
|
|
* Invoke the GPE Method (_Lxx, _Exx) i.e., evaluate the
|
|
|
|
* _Lxx/_Exx control method that corresponds to this GPE
|
2006-05-26 20:36:00 +00:00
|
|
|
*/
|
|
|
|
info->prefix_node =
|
2015-02-05 07:20:01 +00:00
|
|
|
gpe_event_info->dispatch.method_node;
|
2006-05-26 20:36:00 +00:00
|
|
|
info->flags = ACPI_IGNORE_RETURN_VALUE;
|
|
|
|
|
|
|
|
status = acpi_ns_evaluate(info);
|
|
|
|
ACPI_FREE(info);
|
|
|
|
}
|
|
|
|
|
2005-08-05 04:44:28 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2006-01-27 21:43:00 +00:00
|
|
|
ACPI_EXCEPTION((AE_INFO, status,
|
2007-02-02 16:48:18 +00:00
|
|
|
"while evaluating GPE method [%4.4s]",
|
2015-02-05 07:20:01 +00:00
|
|
|
acpi_ut_get_node_name(gpe_event_info->
|
|
|
|
dispatch.
|
|
|
|
method_node)));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2010-12-13 05:39:17 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2013-06-08 00:58:14 +00:00
|
|
|
|
2015-02-05 07:20:01 +00:00
|
|
|
goto error_exit; /* Should never happen */
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2010-12-13 05:39:07 +00:00
|
|
|
|
2007-11-13 10:05:45 +00:00
|
|
|
/* Defer enabling of GPE until all notify handlers are done */
|
2010-12-13 05:39:07 +00:00
|
|
|
|
|
|
|
status = acpi_os_execute(OSL_NOTIFY_HANDLER,
|
2015-02-05 07:20:01 +00:00
|
|
|
acpi_ev_asynch_enable_gpe, gpe_event_info);
|
|
|
|
if (ACPI_SUCCESS(status)) {
|
|
|
|
return_VOID;
|
2010-12-13 05:39:07 +00:00
|
|
|
}
|
2015-02-05 07:20:01 +00:00
|
|
|
|
|
|
|
error_exit:
|
|
|
|
acpi_ev_asynch_enable_gpe(gpe_event_info);
|
2007-11-13 10:05:45 +00:00
|
|
|
return_VOID;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-12-13 05:39:17 +00:00
|
|
|
|
2010-12-13 05:39:07 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_asynch_enable_gpe
|
|
|
|
*
|
|
|
|
* PARAMETERS: Context (gpe_event_info) - Info for this GPE
|
|
|
|
* Callback from acpi_os_execute
|
|
|
|
*
|
|
|
|
* RETURN: None
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Asynchronous clear/enable for GPE. This allows the GPE to
|
2010-12-13 05:39:17 +00:00
|
|
|
* complete (i.e., finish execution of Notify)
|
2010-12-13 05:39:07 +00:00
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
static void ACPI_SYSTEM_XFACE acpi_ev_asynch_enable_gpe(void *context)
|
2007-11-13 10:05:45 +00:00
|
|
|
{
|
|
|
|
struct acpi_gpe_event_info *gpe_event_info = context;
|
2014-12-02 00:56:55 +00:00
|
|
|
acpi_cpu_flags flags;
|
2010-12-13 05:39:17 +00:00
|
|
|
|
2014-12-02 00:56:55 +00:00
|
|
|
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
|
2010-12-13 05:39:17 +00:00
|
|
|
(void)acpi_ev_finish_gpe(gpe_event_info);
|
2014-12-02 00:56:55 +00:00
|
|
|
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
|
2010-12-13 05:39:17 +00:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_finish_gpe
|
|
|
|
*
|
|
|
|
* PARAMETERS: gpe_event_info - Info for this GPE
|
|
|
|
*
|
|
|
|
* RETURN: Status
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Clear/Enable a GPE. Common code that is used after execution
|
|
|
|
* of a GPE method or a synchronous or asynchronous GPE handler.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
2016-05-05 04:57:53 +00:00
|
|
|
acpi_status acpi_ev_finish_gpe(struct acpi_gpe_event_info *gpe_event_info)
|
2010-12-13 05:39:17 +00:00
|
|
|
{
|
2007-11-13 10:05:45 +00:00
|
|
|
acpi_status status;
|
2010-12-13 05:39:07 +00:00
|
|
|
|
2007-11-13 10:05:45 +00:00
|
|
|
if ((gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) ==
|
2005-08-05 04:44:28 +00:00
|
|
|
ACPI_GPE_LEVEL_TRIGGERED) {
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2010-12-13 05:39:17 +00:00
|
|
|
* GPE is level-triggered, we clear the GPE status bit after
|
|
|
|
* handling the event.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2007-11-13 10:05:45 +00:00
|
|
|
status = acpi_hw_clear_gpe(gpe_event_info);
|
2005-08-05 04:44:28 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2010-12-13 05:39:17 +00:00
|
|
|
return (status);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-07-06 02:30:37 +00:00
|
|
|
/*
|
2010-12-13 05:39:17 +00:00
|
|
|
* Enable this GPE, conditionally. This means that the GPE will
|
2014-12-01 22:50:16 +00:00
|
|
|
* only be physically enabled if the enable_mask bit is set
|
2010-12-13 05:39:17 +00:00
|
|
|
* in the event_info.
|
2010-07-06 02:30:37 +00:00
|
|
|
*/
|
2010-12-13 05:36:15 +00:00
|
|
|
(void)acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_CONDITIONAL_ENABLE);
|
2016-08-04 08:43:39 +00:00
|
|
|
gpe_event_info->disable_for_dispatch = FALSE;
|
2010-12-13 05:39:17 +00:00
|
|
|
return (AE_OK);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2010-12-13 05:39:17 +00:00
|
|
|
|
ACPICA: Events: Add parallel GPE handling support to fix potential redundant _Exx evaluations
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>
2018-03-14 23:12:58 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_detect_gpe
|
|
|
|
*
|
|
|
|
* PARAMETERS: gpe_device - Device node. NULL for GPE0/GPE1
|
|
|
|
* gpe_event_info - Info for this GPE
|
|
|
|
* gpe_number - Number relative to the parent GPE block
|
|
|
|
*
|
|
|
|
* RETURN: INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Detect and dispatch a General Purpose Event to either a function
|
|
|
|
* (e.g. EC) or method (e.g. _Lxx/_Exx) handler.
|
|
|
|
* NOTE: GPE is W1C, so it is possible to handle a single GPE from both
|
|
|
|
* task and irq context in parallel as long as the process to
|
|
|
|
* detect and mask the GPE is atomic.
|
|
|
|
* However the atomicity of ACPI_GPE_DISPATCH_RAW_HANDLER is
|
|
|
|
* dependent on the raw handler itself.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
u32
|
|
|
|
acpi_ev_detect_gpe(struct acpi_namespace_node *gpe_device,
|
|
|
|
struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
|
|
|
|
{
|
|
|
|
u32 int_status = ACPI_INTERRUPT_NOT_HANDLED;
|
|
|
|
u8 enabled_status_byte;
|
|
|
|
u64 status_reg;
|
|
|
|
u64 enable_reg;
|
|
|
|
u32 register_bit;
|
|
|
|
struct acpi_gpe_register_info *gpe_register_info;
|
|
|
|
struct acpi_gpe_handler_info *gpe_handler_info;
|
|
|
|
acpi_cpu_flags flags;
|
|
|
|
acpi_status status;
|
|
|
|
|
|
|
|
ACPI_FUNCTION_TRACE(ev_gpe_detect);
|
|
|
|
|
|
|
|
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
|
|
|
|
|
2018-05-25 08:30:35 +00:00
|
|
|
if (!gpe_event_info) {
|
|
|
|
gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
|
|
|
|
if (!gpe_event_info)
|
|
|
|
goto error_exit;
|
|
|
|
}
|
|
|
|
|
ACPICA: Events: Add parallel GPE handling support to fix potential redundant _Exx evaluations
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>
2018-03-14 23:12:58 +00:00
|
|
|
/* Get the info block for the entire GPE register */
|
|
|
|
|
|
|
|
gpe_register_info = gpe_event_info->register_info;
|
|
|
|
|
|
|
|
/* Get the register bitmask for this GPE */
|
|
|
|
|
|
|
|
register_bit = acpi_hw_get_gpe_register_bit(gpe_event_info);
|
|
|
|
|
|
|
|
/* GPE currently enabled (enable bit == 1)? */
|
|
|
|
|
2020-09-04 16:27:43 +00:00
|
|
|
status = acpi_hw_gpe_read(&enable_reg, &gpe_register_info->enable_address);
|
ACPICA: Events: Add parallel GPE handling support to fix potential redundant _Exx evaluations
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>
2018-03-14 23:12:58 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
goto error_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* GPE currently active (status bit == 1)? */
|
|
|
|
|
2020-09-04 16:27:43 +00:00
|
|
|
status = acpi_hw_gpe_read(&status_reg, &gpe_register_info->status_address);
|
ACPICA: Events: Add parallel GPE handling support to fix potential redundant _Exx evaluations
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>
2018-03-14 23:12:58 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
goto error_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check if there is anything active at all in this GPE */
|
|
|
|
|
|
|
|
ACPI_DEBUG_PRINT((ACPI_DB_INTERRUPTS,
|
|
|
|
"Read registers for GPE %02X: Status=%02X, Enable=%02X, "
|
|
|
|
"RunEnable=%02X, WakeEnable=%02X\n",
|
|
|
|
gpe_number,
|
|
|
|
(u32)(status_reg & register_bit),
|
|
|
|
(u32)(enable_reg & register_bit),
|
|
|
|
gpe_register_info->enable_for_run,
|
|
|
|
gpe_register_info->enable_for_wake));
|
|
|
|
|
|
|
|
enabled_status_byte = (u8)(status_reg & enable_reg);
|
|
|
|
if (!(enabled_status_byte & register_bit)) {
|
|
|
|
goto error_exit;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Invoke global event handler if present */
|
|
|
|
|
|
|
|
acpi_gpe_count++;
|
|
|
|
if (acpi_gbl_global_event_handler) {
|
|
|
|
acpi_gbl_global_event_handler(ACPI_EVENT_TYPE_GPE,
|
|
|
|
gpe_device, gpe_number,
|
|
|
|
acpi_gbl_global_event_handler_context);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Found an active GPE */
|
|
|
|
|
|
|
|
if (ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) ==
|
|
|
|
ACPI_GPE_DISPATCH_RAW_HANDLER) {
|
|
|
|
|
|
|
|
/* Dispatch the event to a raw handler */
|
|
|
|
|
|
|
|
gpe_handler_info = gpe_event_info->dispatch.handler;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There is no protection around the namespace node
|
|
|
|
* and the GPE handler to ensure a safe destruction
|
|
|
|
* because:
|
|
|
|
* 1. The namespace node is expected to always
|
|
|
|
* exist after loading a table.
|
|
|
|
* 2. The GPE handler is expected to be flushed by
|
|
|
|
* acpi_os_wait_events_complete() before the
|
|
|
|
* destruction.
|
|
|
|
*/
|
|
|
|
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
|
|
|
|
int_status |=
|
|
|
|
gpe_handler_info->address(gpe_device, gpe_number,
|
|
|
|
gpe_handler_info->context);
|
|
|
|
flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
|
|
|
|
} else {
|
|
|
|
/* Dispatch the event to a standard handler or method. */
|
|
|
|
|
|
|
|
int_status |= acpi_ev_gpe_dispatch(gpe_device,
|
|
|
|
gpe_event_info, gpe_number);
|
|
|
|
}
|
|
|
|
|
|
|
|
error_exit:
|
|
|
|
acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
|
|
|
|
return (int_status);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*******************************************************************************
|
|
|
|
*
|
|
|
|
* FUNCTION: acpi_ev_gpe_dispatch
|
|
|
|
*
|
2014-10-10 02:39:39 +00:00
|
|
|
* PARAMETERS: gpe_device - Device node. NULL for GPE0/GPE1
|
|
|
|
* gpe_event_info - Info for this GPE
|
|
|
|
* gpe_number - Number relative to the parent GPE block
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* RETURN: INTERRUPT_HANDLED or INTERRUPT_NOT_HANDLED
|
|
|
|
*
|
|
|
|
* DESCRIPTION: Dispatch a General Purpose Event to either a function (e.g. EC)
|
|
|
|
* or method (e.g. _Lxx/_Exx) handler.
|
|
|
|
*
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
u32
|
2010-12-13 05:38:46 +00:00
|
|
|
acpi_ev_gpe_dispatch(struct acpi_namespace_node *gpe_device,
|
2014-10-10 02:39:39 +00:00
|
|
|
struct acpi_gpe_event_info *gpe_event_info, u32 gpe_number)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2005-08-05 04:44:28 +00:00
|
|
|
acpi_status status;
|
2010-12-13 05:39:17 +00:00
|
|
|
u32 return_value;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
ACPI: ACPICA 20060421
Removed a device initialization optimization introduced in
20051216 where the _STA method was not run unless an _INI
was also present for the same device. This optimization
could cause problems because it could allow _INI methods
to be run within a not-present device subtree (If a
not-present device had no _INI, _STA would not be run,
the not-present status would not be discovered, and the
children of the device would be incorrectly traversed.)
Implemented a new _STA optimization where namespace
subtrees that do not contain _INI are identified and
ignored during device initialization. Selectively running
_STA can significantly improve boot time on large machines
(with assistance from Len Brown.)
Implemented support for the device initialization case
where the returned _STA flags indicate a device not-present
but functioning. In this case, _INI is not run, but the
device children are examined for presence, as per the
ACPI specification.
Implemented an additional change to the IndexField support
in order to conform to MS behavior. The value written to
the Index Register is not simply a byte offset, it is a
byte offset in units of the access width of the parent
Index Field. (Fiodor Suietov)
Defined and deployed a new OSL interface,
acpi_os_validate_address(). This interface is called during
the creation of all AML operation regions, and allows
the host OS to exert control over what addresses it will
allow the AML code to access. Operation Regions whose
addresses are disallowed will cause a runtime exception
when they are actually accessed (will not affect or abort
table loading.)
Defined and deployed a new OSL interface,
acpi_os_validate_interface(). This interface allows the host OS
to match the various "optional" interface/behavior strings
for the _OSI predefined control method as appropriate
(with assistance from Bjorn Helgaas.)
Restructured and corrected various problems in the
exception handling code paths within DsCallControlMethod
and DsTerminateControlMethod in dsmethod (with assistance
from Takayoshi Kochi.)
Modified the Linux source converter to ignore quoted string
literals while converting identifiers from mixed to lower
case. This will correct problems with the disassembler
and other areas where such strings must not be modified.
The ACPI_FUNCTION_* macros no longer require quotes around
the function name. This allows the Linux source converter
to convert the names, now that the converter ignores
quoted strings.
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2006-04-21 21:15:00 +00:00
|
|
|
ACPI_FUNCTION_TRACE(ev_gpe_dispatch);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/*
|
2010-12-13 05:39:17 +00:00
|
|
|
* Always disable the GPE so that it does not keep firing before
|
|
|
|
* any asynchronous activity completes (either from the execution
|
|
|
|
* of a GPE method or an asynchronous GPE handler.)
|
|
|
|
*
|
|
|
|
* If there is no handler or method to run, just disable the
|
|
|
|
* GPE and leave it disabled permanently to prevent further such
|
|
|
|
* pointless events from firing.
|
|
|
|
*/
|
|
|
|
status = acpi_hw_low_set_gpe(gpe_event_info, ACPI_GPE_DISABLE);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
ACPI_EXCEPTION((AE_INFO, status,
|
2014-04-30 02:06:15 +00:00
|
|
|
"Unable to disable GPE %02X", gpe_number));
|
2013-03-08 09:22:23 +00:00
|
|
|
return_UINT32(ACPI_INTERRUPT_NOT_HANDLED);
|
2010-12-13 05:39:17 +00:00
|
|
|
}
|
|
|
|
|
2014-06-15 00:42:31 +00:00
|
|
|
/*
|
|
|
|
* If edge-triggered, clear the GPE status bit now. Note that
|
|
|
|
* level-triggered events are cleared after the GPE is serviced.
|
|
|
|
*/
|
|
|
|
if ((gpe_event_info->flags & ACPI_GPE_XRUPT_TYPE_MASK) ==
|
|
|
|
ACPI_GPE_EDGE_TRIGGERED) {
|
|
|
|
status = acpi_hw_clear_gpe(gpe_event_info);
|
|
|
|
if (ACPI_FAILURE(status)) {
|
|
|
|
ACPI_EXCEPTION((AE_INFO, status,
|
|
|
|
"Unable to clear GPE %02X",
|
|
|
|
gpe_number));
|
|
|
|
(void)acpi_hw_low_set_gpe(gpe_event_info,
|
|
|
|
ACPI_GPE_CONDITIONAL_ENABLE);
|
|
|
|
return_UINT32(ACPI_INTERRUPT_NOT_HANDLED);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-08-04 08:43:39 +00:00
|
|
|
gpe_event_info->disable_for_dispatch = TRUE;
|
|
|
|
|
2010-12-13 05:39:17 +00:00
|
|
|
/*
|
|
|
|
* Dispatch the GPE to either an installed handler or the control
|
|
|
|
* method associated with this GPE (_Lxx or _Exx). If a handler
|
|
|
|
* exists, we invoke it and do not attempt to run the method.
|
|
|
|
* If there is neither a handler nor a method, leave the GPE
|
|
|
|
* disabled.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2015-02-05 07:20:29 +00:00
|
|
|
switch (ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
case ACPI_GPE_DISPATCH_HANDLER:
|
|
|
|
|
2010-12-13 05:39:17 +00:00
|
|
|
/* Invoke the installed handler (at interrupt level) */
|
|
|
|
|
|
|
|
return_value =
|
|
|
|
gpe_event_info->dispatch.handler->address(gpe_device,
|
|
|
|
gpe_number,
|
|
|
|
gpe_event_info->
|
|
|
|
dispatch.handler->
|
|
|
|
context);
|
|
|
|
|
2019-02-15 21:36:19 +00:00
|
|
|
/* If requested, clear (if level-triggered) and re-enable the GPE */
|
2010-12-13 05:39:17 +00:00
|
|
|
|
|
|
|
if (return_value & ACPI_REENABLE_GPE) {
|
|
|
|
(void)acpi_ev_finish_gpe(gpe_event_info);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
case ACPI_GPE_DISPATCH_METHOD:
|
2010-12-13 05:39:17 +00:00
|
|
|
case ACPI_GPE_DISPATCH_NOTIFY:
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Execute the method associated with the GPE
|
|
|
|
* NOTE: Level-triggered GPEs are cleared after the method completes.
|
|
|
|
*/
|
2006-05-12 21:12:00 +00:00
|
|
|
status = acpi_os_execute(OSL_GPE_HANDLER,
|
|
|
|
acpi_ev_asynch_execute_gpe_method,
|
|
|
|
gpe_event_info);
|
2005-08-05 04:44:28 +00:00
|
|
|
if (ACPI_FAILURE(status)) {
|
2006-01-27 21:43:00 +00:00
|
|
|
ACPI_EXCEPTION((AE_INFO, status,
|
2014-04-30 02:06:15 +00:00
|
|
|
"Unable to queue handler for GPE %02X - event disabled",
|
2006-01-27 21:43:00 +00:00
|
|
|
gpe_number));
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
|
|
|
|
default:
|
2010-04-06 06:52:37 +00:00
|
|
|
/*
|
|
|
|
* No handler or method to run!
|
|
|
|
* 03/2010: This case should no longer be possible. We will not allow
|
|
|
|
* a GPE to be enabled if it has no handler or method.
|
|
|
|
*/
|
2006-01-27 21:43:00 +00:00
|
|
|
ACPI_ERROR((AE_INFO,
|
2014-04-30 02:06:15 +00:00
|
|
|
"No handler or method for GPE %02X, disabling event",
|
2006-01-27 21:43:00 +00:00
|
|
|
gpe_number));
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-03-08 09:22:23 +00:00
|
|
|
return_UINT32(ACPI_INTERRUPT_HANDLED);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2012-02-14 10:14:27 +00:00
|
|
|
|
|
|
|
#endif /* !ACPI_REDUCED_HARDWARE */
|