* [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods.
2014-07-08 6:57 [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method Lan Tianyu
@ 2014-07-08 6:57 ` Lan Tianyu
2014-07-08 13:26 ` Rafael J. Wysocki
2014-07-08 13:19 ` [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method Rafael J. Wysocki
2014-07-10 19:32 ` Moore, Robert
2 siblings, 1 reply; 8+ messages in thread
From: Lan Tianyu @ 2014-07-08 6:57 UTC (permalink / raw)
To: rjw, lenb; +Cc: Lan Tianyu, linux-acpi, linux-kernel
The button wakeup GPEs are enabled unconditionally in the current world by
commit 2a5d24(ACPI / Wakeup: Enable button GPEs unconditionally during
initialization). Because button's GPE methods needs to be run to clear
GPE status on some machines when there is GPE interrupt. If not, it will
cause machines resume immediately after being suspended since GPE status
isn't cleared correctly.
But if there is no GPE method for button wakeup GPE, these GPEs should not
be enabled since nothing needs to be done when they are triggered and this
also causes LID GPE storm on Lenovo Ideapad y560p.
This patch is to check Button GPE method and enable it if there is associated
GPE method.
Reference: https://bugzilla.kernel.org/show_bug.cgi?id=61051
Reported-by: James Tocknell<aragilar@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
---
drivers/acpi/wakeup.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
index 1638401..5b20ae4 100644
--- a/drivers/acpi/wakeup.c
+++ b/drivers/acpi/wakeup.c
@@ -86,9 +86,14 @@ int __init acpi_wakeup_device_init(void)
struct acpi_device,
wakeup_list);
if (device_can_wakeup(&dev->dev)) {
- /* Button GPEs are supposed to be always enabled. */
- acpi_enable_gpe(dev->wakeup.gpe_device,
- dev->wakeup.gpe_number);
+ /*
+ * Button GPEs are supposed to be always enabled if
+ * they have associated GPE methods.
+ */
+ if (ACPI_SUCCESS(acpi_check_gpe_method(
+ dev->wakeup.gpe_device, dev->wakeup.gpe_number)))
+ acpi_enable_gpe(dev->wakeup.gpe_device,
+ dev->wakeup.gpe_number);
device_set_wakeup_enable(&dev->dev, true);
}
}
--
1.8.4.rc0.1.g8f6a3e5.dirty
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods.
2014-07-08 6:57 ` [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods Lan Tianyu
@ 2014-07-08 13:26 ` Rafael J. Wysocki
2014-07-09 3:08 ` Lan Tianyu
0 siblings, 1 reply; 8+ messages in thread
From: Rafael J. Wysocki @ 2014-07-08 13:26 UTC (permalink / raw)
To: Lan Tianyu; +Cc: lenb, linux-acpi, linux-kernel
On Tuesday, July 08, 2014 02:57:58 PM Lan Tianyu wrote:
> The button wakeup GPEs are enabled unconditionally in the current world by
> commit 2a5d24(ACPI / Wakeup: Enable button GPEs unconditionally during
> initialization). Because button's GPE methods needs to be run to clear
> GPE status on some machines when there is GPE interrupt. If not, it will
> cause machines resume immediately after being suspended since GPE status
> isn't cleared correctly.
>
> But if there is no GPE method for button wakeup GPE, these GPEs should not
> be enabled since nothing needs to be done when they are triggered and this
> also causes LID GPE storm on Lenovo Ideapad y560p.
>
> This patch is to check Button GPE method and enable it if there is associated
> GPE method.
Part of the problem is that we call acpi_setup_gpe_for_wake() for buttons too
and it sets ACPI_GPE_DISPATCH_NOTIFY unconditionally. While we could address
this the way you're proposing, it seems a bit less than straightforward so to
speak.
Let me think more about how to address that.
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=61051
> Reported-by: James Tocknell<aragilar@gmail.com>
> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
> ---
> drivers/acpi/wakeup.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
> index 1638401..5b20ae4 100644
> --- a/drivers/acpi/wakeup.c
> +++ b/drivers/acpi/wakeup.c
> @@ -86,9 +86,14 @@ int __init acpi_wakeup_device_init(void)
> struct acpi_device,
> wakeup_list);
> if (device_can_wakeup(&dev->dev)) {
> - /* Button GPEs are supposed to be always enabled. */
> - acpi_enable_gpe(dev->wakeup.gpe_device,
> - dev->wakeup.gpe_number);
> + /*
> + * Button GPEs are supposed to be always enabled if
> + * they have associated GPE methods.
> + */
> + if (ACPI_SUCCESS(acpi_check_gpe_method(
> + dev->wakeup.gpe_device, dev->wakeup.gpe_number)))
> + acpi_enable_gpe(dev->wakeup.gpe_device,
> + dev->wakeup.gpe_number);
> device_set_wakeup_enable(&dev->dev, true);
> }
> }
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods.
2014-07-08 13:26 ` Rafael J. Wysocki
@ 2014-07-09 3:08 ` Lan Tianyu
2014-07-09 13:00 ` Rafael J. Wysocki
0 siblings, 1 reply; 8+ messages in thread
From: Lan Tianyu @ 2014-07-09 3:08 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: lenb, linux-acpi, linux-kernel
On 2014年07月08日 21:26, Rafael J. Wysocki wrote:
> On Tuesday, July 08, 2014 02:57:58 PM Lan Tianyu wrote:
>> The button wakeup GPEs are enabled unconditionally in the current world by
>> commit 2a5d24(ACPI / Wakeup: Enable button GPEs unconditionally during
>> initialization). Because button's GPE methods needs to be run to clear
>> GPE status on some machines when there is GPE interrupt. If not, it will
>> cause machines resume immediately after being suspended since GPE status
>> isn't cleared correctly.
>>
>> But if there is no GPE method for button wakeup GPE, these GPEs should not
>> be enabled since nothing needs to be done when they are triggered and this
>> also causes LID GPE storm on Lenovo Ideapad y560p.
>>
>> This patch is to check Button GPE method and enable it if there is associated
>> GPE method.
>
> Part of the problem is that we call acpi_setup_gpe_for_wake() for buttons too
> and it sets ACPI_GPE_DISPATCH_NOTIFY unconditionally.
Yes, this is why the GPE wasn't disabled by CA. From my opinion,
original reason of enabling button wakeup GPE in the runtime is that it
may have associated GPE method and the method will notify button driver
and clear some hardware status. But if it didn't have GPE method, I
don't why we need to enable the GPE. I check some machines and they use
EC Query event to notify button driver.
> While we could address
> this the way you're proposing, it seems a bit less than straightforward so to
> speak.
>
> Let me think more about how to address that.
Ok. I get it.
>
>> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=61051
>> Reported-by: James Tocknell<aragilar@gmail.com>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>> ---
>> drivers/acpi/wakeup.c | 11 ++++++++---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/acpi/wakeup.c b/drivers/acpi/wakeup.c
>> index 1638401..5b20ae4 100644
>> --- a/drivers/acpi/wakeup.c
>> +++ b/drivers/acpi/wakeup.c
>> @@ -86,9 +86,14 @@ int __init acpi_wakeup_device_init(void)
>> struct acpi_device,
>> wakeup_list);
>> if (device_can_wakeup(&dev->dev)) {
>> - /* Button GPEs are supposed to be always enabled. */
>> - acpi_enable_gpe(dev->wakeup.gpe_device,
>> - dev->wakeup.gpe_number);
>> + /*
>> + * Button GPEs are supposed to be always enabled if
>> + * they have associated GPE methods.
>> + */
>> + if (ACPI_SUCCESS(acpi_check_gpe_method(
>> + dev->wakeup.gpe_device, dev->wakeup.gpe_number)))
>> + acpi_enable_gpe(dev->wakeup.gpe_device,
>> + dev->wakeup.gpe_number);
>> device_set_wakeup_enable(&dev->dev, true);
>> }
>> }
>>
>
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods.
2014-07-09 3:08 ` Lan Tianyu
@ 2014-07-09 13:00 ` Rafael J. Wysocki
0 siblings, 0 replies; 8+ messages in thread
From: Rafael J. Wysocki @ 2014-07-09 13:00 UTC (permalink / raw)
To: Lan Tianyu; +Cc: lenb, linux-acpi, linux-kernel
On Wednesday, July 09, 2014 11:08:42 AM Lan Tianyu wrote:
> On 2014年07月08日 21:26, Rafael J. Wysocki wrote:
> > On Tuesday, July 08, 2014 02:57:58 PM Lan Tianyu wrote:
> >> The button wakeup GPEs are enabled unconditionally in the current world by
> >> commit 2a5d24(ACPI / Wakeup: Enable button GPEs unconditionally during
> >> initialization). Because button's GPE methods needs to be run to clear
> >> GPE status on some machines when there is GPE interrupt. If not, it will
> >> cause machines resume immediately after being suspended since GPE status
> >> isn't cleared correctly.
> >>
> >> But if there is no GPE method for button wakeup GPE, these GPEs should not
> >> be enabled since nothing needs to be done when they are triggered and this
> >> also causes LID GPE storm on Lenovo Ideapad y560p.
> >>
> >> This patch is to check Button GPE method and enable it if there is associated
> >> GPE method.
> >
> > Part of the problem is that we call acpi_setup_gpe_for_wake() for buttons too
> > and it sets ACPI_GPE_DISPATCH_NOTIFY unconditionally.
>
> Yes, this is why the GPE wasn't disabled by CA. From my opinion,
> original reason of enabling button wakeup GPE in the runtime is that it
> may have associated GPE method and the method will notify button driver
> and clear some hardware status. But if it didn't have GPE method, I
> don't why we need to enable the GPE.
I think you're right, but "is there a handler method for that GPE present?"
is a bit too low-level question to ask from outside of ACPICA. We should be
asking "is there any kind of handling registered for it?" if anything, but in
my opinion the cleanest approach would be to modify acpi_enable_gpe() to
return an error code if there's no handler/method/notify for the GPE in
question.
The patch I attached to the BZ entry doesn't do that just yet, because I'm
wondering whether or not it will make the ACPICA's auto-disabling trigger. :-)
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method
2014-07-08 6:57 [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method Lan Tianyu
2014-07-08 6:57 ` [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods Lan Tianyu
@ 2014-07-08 13:19 ` Rafael J. Wysocki
2014-07-10 19:32 ` Moore, Robert
2 siblings, 0 replies; 8+ messages in thread
From: Rafael J. Wysocki @ 2014-07-08 13:19 UTC (permalink / raw)
To: Lan Tianyu
Cc: robert.moore, lv.zheng, rafael.j.wysocki, lenb, linux-acpi,
linux-kernel
On Tuesday, July 08, 2014 02:57:57 PM Lan Tianyu wrote:
> This patch is to expose acpi_check_gpe_method() to check whether there
> is a GPE method for the given gpe. Enabling ACPI button devices' gpes
> will depend on the new function's result.
>
> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
> ---
> drivers/acpi/acpica/evxface.c | 39 ++++++++++++++++++++++++++++++++++++++-
> include/acpi/acpixf.h | 3 +++
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
> index 11e5803..0fcb248 100644
> --- a/drivers/acpi/acpica/evxface.c
> +++ b/drivers/acpi/acpica/evxface.c
> @@ -717,6 +717,44 @@ ACPI_EXPORT_SYMBOL(acpi_remove_fixed_event_handler)
>
> /*******************************************************************************
> *
> + * FUNCTION: acpi_check_gpe_method
> + *
> + * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for FADT
> + * defined GPEs)
> + * gpe_number - The event to remove a handler
> + *
> + * RETURN: Status
> + *
> + * DESCRIPTION: Check whether the given GPE has associated event method.
> + *
> + ******************************************************************************/
> +acpi_status
> +acpi_check_gpe_method(acpi_handle gpe_device, u32 gpe_number)
This should be a boolean routine (ie. returning 0 or 1) called something like
acpi_gpe_has_method() that will return 1 if there's a method for the given GPE
and 0 otherwise.
> +{
> + struct acpi_gpe_event_info *gpe_event_info;
> + acpi_status status = AE_NOT_EXIST;
> + acpi_cpu_flags flags;
> +
> + ACPI_FUNCTION_TRACE(acpi_check_gpe_method);
> +
> + flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
> + if (!gpe_event_info) {
> + status = AE_ERROR;
> + goto unlock_and_exit;
> + }
> +
> + if (gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD)
> + status = AE_OK;
> +
> +unlock_and_exit:
> + acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
> + return status;
> +}
> +ACPI_EXPORT_SYMBOL(acpi_check_gpe_method)
> +
> +/*******************************************************************************
> + *
> * FUNCTION: acpi_install_gpe_handler
> *
> * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for FADT
> @@ -821,7 +859,6 @@ free_and_exit:
> ACPI_FREE(handler);
> goto unlock_and_exit;
> }
> -
> ACPI_EXPORT_SYMBOL(acpi_install_gpe_handler)
>
> /*******************************************************************************
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
> index 35b525c..5b475c6 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -554,6 +554,9 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> address,
> void *context))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> + acpi_check_gpe_method(acpi_handle gpe_device,
> + u32 gpe_number))
> +ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_remove_gpe_handler(acpi_handle gpe_device,
> u32 gpe_number,
> acpi_gpe_handler
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method
2014-07-08 6:57 [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method Lan Tianyu
2014-07-08 6:57 ` [RFC PATCH 2/2] ACPI/Wakup: Enable button wakeup GPEs if these GPEs have associated GPE methods Lan Tianyu
2014-07-08 13:19 ` [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method Rafael J. Wysocki
@ 2014-07-10 19:32 ` Moore, Robert
2014-07-11 2:35 ` Lan Tianyu
2 siblings, 1 reply; 8+ messages in thread
From: Moore, Robert @ 2014-07-10 19:32 UTC (permalink / raw)
To: Lan, Tianyu, Zheng, Lv, Wysocki, Rafael J, lenb@kernel.org
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Since what is returned by this interface is essentially a piece of information about the particular GPE, I think that it might be better to generalize this interface to a "GetInfo" type of interface that returns a few pieces of information about the GPE.
> -----Original Message-----
> From: Lan, Tianyu
> Sent: Monday, July 07, 2014 11:58 PM
> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; lenb@kernel.org
> Cc: Lan, Tianyu; linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE
> method
>
> This patch is to expose acpi_check_gpe_method() to check whether there is
> a GPE method for the given gpe. Enabling ACPI button devices' gpes will
> depend on the new function's result.
>
> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
> ---
> drivers/acpi/acpica/evxface.c | 39
> ++++++++++++++++++++++++++++++++++++++-
> include/acpi/acpixf.h | 3 +++
> 2 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
> index 11e5803..0fcb248 100644
> --- a/drivers/acpi/acpica/evxface.c
> +++ b/drivers/acpi/acpica/evxface.c
> @@ -717,6 +717,44 @@ ACPI_EXPORT_SYMBOL(acpi_remove_fixed_event_handler)
>
>
> /*************************************************************************
> ******
> *
> + * FUNCTION: acpi_check_gpe_method
> + *
> + * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for
> FADT
> + * defined GPEs)
> + * gpe_number - The event to remove a handler
> + *
> + * RETURN: Status
> + *
> + * DESCRIPTION: Check whether the given GPE has associated event method.
> + *
> +
> +***********************************************************************
> +*******/
> +acpi_status
> +acpi_check_gpe_method(acpi_handle gpe_device, u32 gpe_number) {
> + struct acpi_gpe_event_info *gpe_event_info;
> + acpi_status status = AE_NOT_EXIST;
> + acpi_cpu_flags flags;
> +
> + ACPI_FUNCTION_TRACE(acpi_check_gpe_method);
> +
> + flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
> + if (!gpe_event_info) {
> + status = AE_ERROR;
> + goto unlock_and_exit;
> + }
> +
> + if (gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD)
> + status = AE_OK;
> +
> +unlock_and_exit:
> + acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
> + return status;
> +}
> +ACPI_EXPORT_SYMBOL(acpi_check_gpe_method)
> +
> +/**********************************************************************
> +*********
> + *
> * FUNCTION: acpi_install_gpe_handler
> *
> * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for
> FADT
> @@ -821,7 +859,6 @@ free_and_exit:
> ACPI_FREE(handler);
> goto unlock_and_exit;
> }
> -
> ACPI_EXPORT_SYMBOL(acpi_install_gpe_handler)
>
>
> /*************************************************************************
> ******
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index
> 35b525c..5b475c6 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -554,6 +554,9 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> address,
> void *context))
> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> + acpi_check_gpe_method(acpi_handle gpe_device,
> + u32 gpe_number))
> +ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
> acpi_remove_gpe_handler(acpi_handle gpe_device,
> u32 gpe_number,
> acpi_gpe_handler
> --
> 1.8.4.rc0.1.g8f6a3e5.dirty
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE method
2014-07-10 19:32 ` Moore, Robert
@ 2014-07-11 2:35 ` Lan Tianyu
0 siblings, 0 replies; 8+ messages in thread
From: Lan Tianyu @ 2014-07-11 2:35 UTC (permalink / raw)
To: Moore, Robert
Cc: Zheng, Lv, Wysocki, Rafael J, lenb@kernel.org,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
On 2014年07月11日 03:32, Moore, Robert wrote:
> Since what is returned by this interface is essentially a piece of information about the particular GPE, I think that it might be better to generalize this interface to a "GetInfo" type of interface that returns a few pieces of information about the GPE.
>
Hi Bob:
Thanks for your review. Yes, that's good suggestion. But Rafael has new
solution to fix the issue. So this patch maybe not necessary.
>
>
>> -----Original Message-----
>> From: Lan, Tianyu
>> Sent: Monday, July 07, 2014 11:58 PM
>> To: Moore, Robert; Zheng, Lv; Wysocki, Rafael J; lenb@kernel.org
>> Cc: Lan, Tianyu; linux-acpi@vger.kernel.org; linux-kernel@vger.kernel.org
>> Subject: [RFC PATCH 1/2] ACPICA: Add acpi_check_gpe_method() to check GPE
>> method
>>
>> This patch is to expose acpi_check_gpe_method() to check whether there is
>> a GPE method for the given gpe. Enabling ACPI button devices' gpes will
>> depend on the new function's result.
>>
>> Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
>> ---
>> drivers/acpi/acpica/evxface.c | 39
>> ++++++++++++++++++++++++++++++++++++++-
>> include/acpi/acpixf.h | 3 +++
>> 2 files changed, 41 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/acpi/acpica/evxface.c b/drivers/acpi/acpica/evxface.c
>> index 11e5803..0fcb248 100644
>> --- a/drivers/acpi/acpica/evxface.c
>> +++ b/drivers/acpi/acpica/evxface.c
>> @@ -717,6 +717,44 @@ ACPI_EXPORT_SYMBOL(acpi_remove_fixed_event_handler)
>>
>>
>> /*************************************************************************
>> ******
>> *
>> + * FUNCTION: acpi_check_gpe_method
>> + *
>> + * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for
>> FADT
>> + * defined GPEs)
>> + * gpe_number - The event to remove a handler
>> + *
>> + * RETURN: Status
>> + *
>> + * DESCRIPTION: Check whether the given GPE has associated event method.
>> + *
>> +
>> +***********************************************************************
>> +*******/
>> +acpi_status
>> +acpi_check_gpe_method(acpi_handle gpe_device, u32 gpe_number) {
>> + struct acpi_gpe_event_info *gpe_event_info;
>> + acpi_status status = AE_NOT_EXIST;
>> + acpi_cpu_flags flags;
>> +
>> + ACPI_FUNCTION_TRACE(acpi_check_gpe_method);
>> +
>> + flags = acpi_os_acquire_lock(acpi_gbl_gpe_lock);
>> + gpe_event_info = acpi_ev_get_gpe_event_info(gpe_device, gpe_number);
>> + if (!gpe_event_info) {
>> + status = AE_ERROR;
>> + goto unlock_and_exit;
>> + }
>> +
>> + if (gpe_event_info->flags & ACPI_GPE_DISPATCH_METHOD)
>> + status = AE_OK;
>> +
>> +unlock_and_exit:
>> + acpi_os_release_lock(acpi_gbl_gpe_lock, flags);
>> + return status;
>> +}
>> +ACPI_EXPORT_SYMBOL(acpi_check_gpe_method)
>> +
>> +/**********************************************************************
>> +*********
>> + *
>> * FUNCTION: acpi_install_gpe_handler
>> *
>> * PARAMETERS: gpe_device - Namespace node for the GPE (NULL for
>> FADT
>> @@ -821,7 +859,6 @@ free_and_exit:
>> ACPI_FREE(handler);
>> goto unlock_and_exit;
>> }
>> -
>> ACPI_EXPORT_SYMBOL(acpi_install_gpe_handler)
>>
>>
>> /*************************************************************************
>> ******
>> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h index
>> 35b525c..5b475c6 100644
>> --- a/include/acpi/acpixf.h
>> +++ b/include/acpi/acpixf.h
>> @@ -554,6 +554,9 @@ ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>> address,
>> void *context))
>> ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>> + acpi_check_gpe_method(acpi_handle gpe_device,
>> + u32 gpe_number))
>> +ACPI_HW_DEPENDENT_RETURN_STATUS(acpi_status
>> acpi_remove_gpe_handler(acpi_handle gpe_device,
>> u32 gpe_number,
>> acpi_gpe_handler
>> --
>> 1.8.4.rc0.1.g8f6a3e5.dirty
>
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 8+ messages in thread