From: "Rafael J. Wysocki" <rjw@rjwysocki.net>
To: Linux ACPI <linux-acpi@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Zhang Rui <rui.zhang@intel.com>,
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
Michal Wilczynski <michal.wilczynski@intel.com>,
Hans de Goede <hdegoede@redhat.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>,
Mario Limonciello <mario.limonciello@amd.com>
Subject: [RFT][PATCH v1] ACPI: OSL: Use a threaded interrupt handler for SCI
Date: Mon, 27 Nov 2023 20:57:43 +0100 [thread overview]
Message-ID: <5745568.DvuYhMxLoT@kreacher> (raw)
From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
In the current arrangement, all of the acpi_ev_sci_xrupt_handler() code
is run as an interrupt handler for the SCI, in interrupt context. Among
other things, this causes it to run with local interrupts off which
can be problematic if many GPEs are enabled and they are located in the
I/O address space, for example (because in that case local interrupts
will be off for the duration of all of the GPE hardware accesses carried
out while handling an SCI combined and that may be quite a bit of time
in extreme scenarios).
However, there is no particular reason why the code in question really
needs to run in interrupt context and in particular, it has no specific
reason to run with local interrupts off. The only real requirement is
to prevent multiple instences of it from running in parallel with each
other, but that can be achieved regardless.
For this reason, use request_threaded_irq() instead of request_irq() for
the ACPI SCI and pass IRQF_ONESHOT to it in flags to indicate that the
interrupt needs to be masked while its handling thread is running so as
to prevent it from re-triggering while it is being handled (and in
particular until the final handled/not handled outcome is determined).
While at it, drop a redundant local variable from acpi_irq().
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
The code inspection and (necessarily limited) testing carried out by me
are good indications that this should just always work, but there may
be still some really odd platform configurations I'm overlooking, so if
you have a way to give it a go, please do so.
---
drivers/acpi/osl.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
Index: linux-pm/drivers/acpi/osl.c
===================================================================
--- linux-pm.orig/drivers/acpi/osl.c
+++ linux-pm/drivers/acpi/osl.c
@@ -544,11 +544,7 @@ acpi_os_predefined_override(const struct
static irqreturn_t acpi_irq(int irq, void *dev_id)
{
- u32 handled;
-
- handled = (*acpi_irq_handler) (acpi_irq_context);
-
- if (handled) {
+ if ((*acpi_irq_handler)(acpi_irq_context)) {
acpi_irq_handled++;
return IRQ_HANDLED;
} else {
@@ -582,7 +578,8 @@ acpi_os_install_interrupt_handler(u32 gs
acpi_irq_handler = handler;
acpi_irq_context = context;
- if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
+ if (request_threaded_irq(irq, NULL, acpi_irq, IRQF_SHARED | IRQF_ONESHOT,
+ "acpi", acpi_irq)) {
pr_err("SCI (IRQ%d) allocation failed\n", irq);
acpi_irq_handler = NULL;
return AE_NOT_ACQUIRED;
next reply other threads:[~2023-11-27 19:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 19:57 Rafael J. Wysocki [this message]
2023-11-28 14:27 ` [RFT][PATCH v1] ACPI: OSL: Use a threaded interrupt handler for SCI Mario Limonciello
2023-11-29 8:56 ` Mika Westerberg
2023-11-30 13:28 ` Rafael J. Wysocki
2024-01-23 16:39 ` Christian Heusel
2024-01-23 17:51 ` 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=5745568.DvuYhMxLoT@kreacher \
--to=rjw@rjwysocki.net \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hdegoede@redhat.com \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=michal.wilczynski@intel.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rui.zhang@intel.com \
--cc=srinivas.pandruvada@linux.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