From: Hans de Goede <hansg@kernel.org>
To: Sakari Ailus <sakari.ailus@linux.intel.com>,
Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>,
Alexander Usyskin <alexander.usyskin@intel.com>
Cc: Hans de Goede <hansg@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org
Subject: [PATCH 08/10] mei: vsc: Run event callback from a workqueue
Date: Mon, 23 Jun 2025 10:50:50 +0200 [thread overview]
Message-ID: <20250623085052.12347-9-hansg@kernel.org> (raw)
In-Reply-To: <20250623085052.12347-1-hansg@kernel.org>
The event_notify callback in some cases calls vsc_tp_xfer(), which checks
tp->assert_cnt and waits for it through the tp->xfer_wait wait-queue.
And tp->assert_cnt is increased and the tp->xfer_wait queue is woken o
from the interrupt handler.
So the interrupt handler which is running the event callback is waiting for
itself to signal that it can continue.
This happens to work because the event callback runs from the threaded
ISR handler and while that is running the hard ISR handler will still
get called a second / third time for further interrupts and it is the hard
ISR handler which does the atomic_inc() and wake_up() calls.
But having the threaded ISR handler wait for its own interrupt to trigger
again is not how a threaded ISR handler is supposed to be used.
Move the running of the event callback from a threaded interrupt handler
to a workqueue since a threaded ISR should not wait for events from its
own interrupt.
This is a preparation patch for moving the atomic_inc() and wake_up() calls
to the threaded ISR handler, which is necessary to fix a locking issue.
Fixes: 566f5ca97680 ("mei: Add transport driver for IVSC device")
Signed-off-by: Hans de Goede <hansg@kernel.org>
---
drivers/misc/mei/vsc-tp.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/mei/vsc-tp.c b/drivers/misc/mei/vsc-tp.c
index 76a6aa606a26..f5ea38f22419 100644
--- a/drivers/misc/mei/vsc-tp.c
+++ b/drivers/misc/mei/vsc-tp.c
@@ -18,6 +18,7 @@
#include <linux/platform_device.h>
#include <linux/spi/spi.h>
#include <linux/types.h>
+#include <linux/workqueue.h>
#include "vsc-tp.h"
@@ -76,6 +77,7 @@ struct vsc_tp {
atomic_t assert_cnt;
wait_queue_head_t xfer_wait;
+ struct work_struct event_work;
vsc_tp_event_cb_t event_notify;
void *event_notify_context;
@@ -105,19 +107,19 @@ static irqreturn_t vsc_tp_isr(int irq, void *data)
wake_up(&tp->xfer_wait);
- return IRQ_WAKE_THREAD;
+ schedule_work(&tp->event_work);
+
+ return IRQ_HANDLED;
}
-static irqreturn_t vsc_tp_thread_isr(int irq, void *data)
+static void vsc_tp_event_work(struct work_struct *work)
{
- struct vsc_tp *tp = data;
+ struct vsc_tp *tp = container_of(work, struct vsc_tp, event_work);
guard(mutex)(&tp->event_notify_mutex);
if (tp->event_notify)
tp->event_notify(tp->event_notify_context);
-
- return IRQ_HANDLED;
}
/* wakeup firmware and wait for response */
@@ -495,7 +497,7 @@ static int vsc_tp_probe(struct spi_device *spi)
tp->spi = spi;
irq_set_status_flags(spi->irq, IRQ_DISABLE_UNLAZY);
- ret = request_threaded_irq(spi->irq, vsc_tp_isr, vsc_tp_thread_isr,
+ ret = request_threaded_irq(spi->irq, vsc_tp_isr, NULL,
IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
dev_name(dev), tp);
if (ret)
@@ -503,6 +505,7 @@ static int vsc_tp_probe(struct spi_device *spi)
mutex_init(&tp->mutex);
mutex_init(&tp->event_notify_mutex);
+ INIT_WORK(&tp->event_work, vsc_tp_event_work);
/* only one child acpi device */
ret = acpi_dev_for_each_child(ACPI_COMPANION(dev),
@@ -527,6 +530,7 @@ static int vsc_tp_probe(struct spi_device *spi)
err_destroy_lock:
free_irq(spi->irq, tp);
+ cancel_work_sync(&tp->event_work);
mutex_destroy(&tp->event_notify_mutex);
mutex_destroy(&tp->mutex);
@@ -542,6 +546,7 @@ static void vsc_tp_remove(struct spi_device *spi)
free_irq(spi->irq, tp);
+ cancel_work_sync(&tp->event_work);
mutex_destroy(&tp->event_notify_mutex);
mutex_destroy(&tp->mutex);
}
--
2.49.0
next prev parent reply other threads:[~2025-06-23 8:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-23 8:50 [PATCH 00/10] mei: vsc: Various bug-fixes Hans de Goede
2025-06-23 8:50 ` [PATCH 01/10] mei: vsc: Drop unused vsc_tp_request_irq() and vsc_tp_free_irq() Hans de Goede
2025-06-24 6:06 ` Usyskin, Alexander
2025-06-24 8:43 ` Hans de Goede
2025-06-23 8:50 ` [PATCH 02/10] mei: vsc: Don't re-init VSC from mei_vsc_hw_reset() on stop Hans de Goede
2025-06-24 7:00 ` Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 03/10] mei: vsc: Don't call vsc_tp_reset() a second time on shutdown Hans de Goede
2025-06-25 7:59 ` Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 04/10] mei: vsc: Use vsc_tp_remove() as shutdown handler Hans de Goede
2025-06-25 8:02 ` Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 05/10] mei: vsc: Destroy mutex after freeing the IRQ Hans de Goede
2025-06-25 8:03 ` Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 06/10] mei: vsc: Event notifier fixes Hans de Goede
2025-06-25 9:12 ` Usyskin, Alexander
2025-06-25 9:23 ` Hans de Goede
2025-06-25 9:26 ` Hans de Goede
2025-06-25 9:36 ` Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 07/10] mei: vsc: Unset the event callback on remove and probe errors Hans de Goede
2025-06-25 10:01 ` Usyskin, Alexander
2025-06-23 8:50 ` Hans de Goede [this message]
2025-06-25 10:07 ` [PATCH 08/10] mei: vsc: Run event callback from a workqueue Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 09/10] mei: vsc: Fix "BUG: Invalid wait context" lockdep error Hans de Goede
2025-06-25 10:12 ` Usyskin, Alexander
2025-06-23 8:50 ` [PATCH 10/10] mei: bus: Check for still connected devices in mei_cl_bus_dev_release() Hans de Goede
2025-06-25 10:25 ` Usyskin, Alexander
2025-06-25 9:52 ` [PATCH 00/10] mei: vsc: Various bug-fixes Sakari Ailus
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=20250623085052.12347-9-hansg@kernel.org \
--to=hansg@kernel.org \
--cc=alexander.usyskin@intel.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sakari.ailus@linux.intel.com \
--cc=stanislaw.gruszka@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.