From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Matthew Garrett <mjg@redhat.com>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, "Moore,
Robert" <robert.moore@intel.com>
Subject: Re: [PATCH 1/5] ACPI: Allow handlers to be installed at the same time as methods
Date: Wed, 6 Oct 2010 01:18:50 +0200 [thread overview]
Message-ID: <201010060118.50875.rjw@sisk.pl> (raw)
In-Reply-To: <1286216549-5438-2-git-send-email-mjg@redhat.com>
On Monday, October 04, 2010, Matthew Garrett wrote:
> There are circumstances under which it may be desirable for GPE handlers
> to be installable without displacing the existing GPE method. Add support
> for this via a boolean argument to acpi_install_gpe_handler, and fix up the
> existing users to ensure that their behaviour doesn't change.
Hmm. I'm not sure this is the best way to do that.
In fact, what we need to handle is the case in which a GPE is pointed to by
a _PRW method somewhere and we presume that it's necessary to execute
Notify() for it regardless of whether or not it has a method, right?
So, this GPE will have ACPI_GPE_CAN_WAKE, so can we just put something like
if (gpe_event_info->flags & ACPI_GPE_CAN_WAKE)
execute Notify()
somewhere around the switch statement in acpi_ev_gpe_dispatch()?
Or perhaps replace acpi_ev_asynch_enable_gpe() with something that will
execute Notify() and then do what the original acpi_ev_asynch_enable_gpe() does?
That should be easier to implement after the changes we've been discussing with
Bob recently (basically, handle both GPE handlers and _Lxx/_Exx analogously).
Rafael
next prev parent reply other threads:[~2010-10-05 23:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-04 18:22 Runtime PM: Improve support for PCI devices Matthew Garrett
2010-10-04 18:22 ` [PATCH 1/5] ACPI: Allow handlers to be installed at the same time as methods Matthew Garrett
2010-10-05 23:18 ` Rafael J. Wysocki [this message]
2010-10-06 2:09 ` Moore, Robert
2010-10-06 16:14 ` Moore, Robert
2010-10-06 16:18 ` Matthew Garrett
2010-10-06 19:30 ` Rafael J. Wysocki
2010-10-06 19:32 ` Matthew Garrett
2010-10-06 19:47 ` Moore, Robert
2010-10-04 18:22 ` [PATCH 2/5] pci: Export some PCI PM functionality Matthew Garrett
2010-10-05 23:20 ` Rafael J. Wysocki
2010-10-15 20:10 ` Jesse Barnes
2010-10-04 18:22 ` [PATCH 3/5] ACPI: Bind implicit GPE dependencies to PCI devices Matthew Garrett
2010-10-05 23:37 ` Rafael J. Wysocki
2010-10-04 18:22 ` [PATCH 4/5] ACPI: Missing _S0W shouldn't disable runtime PM Matthew Garrett
2010-10-04 18:22 ` [PATCH 5/5] pci: Add support for polling PME state on suspended legacy PCI devices Matthew Garrett
2010-10-05 23:45 ` Rafael J. Wysocki
2010-10-15 20:10 ` Jesse Barnes
2010-10-15 20:39 ` Rafael J. Wysocki
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=201010060118.50875.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mjg@redhat.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