From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: "Moore, Robert" <robert.moore@intel.com>
Cc: "Lin, Ming M" <ming.m.lin@intel.com>, lenb <lenb@kernel.org>,
linux-acpi <linux-acpi@vger.kernel.org>
Subject: Re: [PATCH] acpi: update return value in EC gpe handler
Date: Fri, 17 Dec 2010 23:17:21 +0100 [thread overview]
Message-ID: <201012172317.21272.rjw@sisk.pl> (raw)
In-Reply-To: <4911F71203A09E4D9981D27F9D830858BF9AAEB9@orsmsx503.amr.corp.intel.com>
On Wednesday, December 15, 2010, Moore, Robert wrote:
> I'm not sure that this is the correct thing to do.
>
> ACPI_REENABLE_GPE is a new GPE handler return value that implies to ACPICA that the GPE has been fully handled within the (synchronous, interrupt-level) GPE handler and is ready to be cleared (if necessary) and re-enabled.
>
> The acpi_finish_gpe is a new interface does the same thing, but is intended to be called from an asynchronous GPE handler after the GPE processing is completed. It looks to me that the EC GPE handler is mostly asynchronous, so I suspect that somewhere in the EC driver, a call to acpi_finish_gpe should replace a couple of calls to clear the GPE and re-enable it. That is the purpose of this interface, to relieve the handler of deciding whether to clear the GPE or not (level vs. edge) and then re-enabling it.
You're generally right, but that would involve a major rework of the EC driver,
while I think at the moment we should try to retain the current behavior.
I wonder, though, if the return value should be
(ACPI_INTERRUPT_HANDLED | ACPI_REENABLE_GPE)
Thanks,
Rafael
> -----Original Message-----
> From: Lin, Ming M
> Sent: Tuesday, December 14, 2010 11:47 PM
> To: lenb
> Cc: Moore, Robert; Rafael J. Wysocki; linux-acpi
> Subject: [PATCH] acpi: update return value in EC gpe handler
>
> EC gpe handler should return ACPI_REENABLE_GPE, so acpi_ev_gpe_dispatch
> can clear and reenable the GPE.
>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> ---
>
> Len,
>
> I forgot to update EC gpe handler return value in the series of
> "[PATCH v2 0/8] Minimize ACPICA/linux GPE code divergence".
> This is the fix.
>
> drivers/acpi/ec.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index e15439a..8a0e907 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -619,7 +619,7 @@ static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
> wake_up(&ec->wait);
> ec_check_sci(ec, acpi_ec_read_status(ec));
> }
> - return ACPI_INTERRUPT_HANDLED;
> + return ACPI_REENABLE_GPE;
> }
>
> /* --------------------------------------------------------------------------
>
>
>
prev parent reply other threads:[~2010-12-17 22:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-15 7:47 [PATCH] acpi: update return value in EC gpe handler Lin Ming
2010-12-15 20:04 ` Moore, Robert
2010-12-17 22:17 ` Rafael J. Wysocki [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201012172317.21272.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=robert.moore@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox