From: Ju Nan <junan76@163.com>
To: junan76@163.com, antonio.borneo@foss.st.com, linusw@kernel.org
Cc: alexandre.torgue@foss.st.com, arnd@arndb.de,
bigeasy@linutronix.de, clrkwllms@kernel.org, lee@kernel.org,
linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rt-devel@lists.linux.dev,
linux-stm32@st-md-mailman.stormreply.com,
mcoquelin.stm32@gmail.com, mfd@lists.linux.dev,
rostedt@goodmis.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
Subject: [PATCH v3] pinctrl: stm32: program the EXTI mux from .alloc instead of .activate
Date: Tue, 4 Aug 2026 22:14:03 +0800 [thread overview]
Message-ID: <20260804141402.86911-2-junan76@163.com> (raw)
In-Reply-To: <20260803061718.43210-1-junan76@163.com>
stm32_gpio_domain_activate() writes the EXTI interrupt multiplexer
through a regmap obtained from the generic syscon driver. The irq core
calls .activate from __setup_irq() with the raw desc->lock held, so this
happens in a raw atomic section. regmap-mmio sets fast_io, and syscon
does not ask for a raw spinlock, so the regmap is protected by a
spinlock_t. On PREEMPT_RT that is a sleeping lock, which must not be
taken there. lockdep reports it as soon as a GPIO interrupt is
requested:
BUG: Invalid wait context
6.17.0 #4 Not tainted
-----------------------------
kworker/u8:0/12 is trying to lock:
(&syscon_config)->lock){....}-{3:3}, at: regmap_lock_spinlock
other info that might help us debug this:
6 locks held by kworker/u8:0/12:
#5: (&irq_desc_lock_class){-...}-{2:2}, at: __setup_irq
stack backtrace:
regmap_lock_spinlock
regmap_field_update_bits_base
stm32_gpio_domain_activate
irq_domain_activate_irq
__setup_irq
request_threaded_irq
The driver was already aware of running in atomic context there: it uses
the _in_atomic() hwspinlock primitives around the very same access. The
syscon lock is the one lock in that section it does not control.
Program the mux from .alloc instead, which runs in a sleepable context.
That callback already owns this resource: it reserves the mux line in
pctl->irqmux_map under irqmux_lock, so writing the value it just claimed
is a natural fit, and the value only depends on the bank.
Nothing requires the mux to be reprogrammed at interrupt startup time:
the domain has no .deactivate, .free() only releases the irqmux_map bit
without touching the registers, and the resume path reprograms the mux
itself in stm32_pinctrl_restore_gpio_regs().
Keep the access inside the existing irqmux_lock section rather than
after it. hwspin_lock_timeout_in_atomic() deliberately skips the local
lock that the other hwspinlock modes take, so its caller is responsible
for disabling preemption and for excluding other local contexts; every
other hwspinlock user in this driver relies on bank->lock for that.
irqmux_lock plays the same role here, and it also turns the mux
reservation and the mux write into a single critical section. Nesting
the regmap spinlock_t inside irqmux_lock, itself a spinlock_t, is what
the wait-context checker expects.
Note that this bounds the semaphore hold time on !PREEMPT_RT only. On
PREEMPT_RT spinlock_t disables neither interrupts nor preemption, so the
hardware semaphore can be held across a preemptible section and a
coprocessor contending for it may poll for an unbounded time. That is
not introduced here: bank->lock is a spinlock_t too, so every existing
hwspinlock user in this driver behaves the same way on PREEMPT_RT.
Removing that exposure requires the EXTI mux regmap to be raw-spinlock
based, which the syscon core does not currently offer, and is left for a
separate change.
While moving the code, release the mux reservation when the hwspinlock
cannot be taken, which the .activate callback had no way of doing.
Reported-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Closes: https://lore.kernel.org/all/20220202174430.pf37tt6lua2op3gc@pengutronix.de/
Signed-off-by: Ju Nan <junan76@163.com>
---
Changes in v3:
- Keep the mux write inside the existing irqmux_lock critical section
rather than after it.
v2: https://lore.kernel.org/all/20260804032227.35017-3-junan76@163.com/
v1: https://lore.kernel.org/all/20260803061718.43210-1-junan76@163.com/
---
drivers/pinctrl/stm32/pinctrl-stm32.c | 55 +++++++++++++--------------
1 file changed, 26 insertions(+), 29 deletions(-)
diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 6a99708a5a23..d97057ec28af 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -600,30 +600,6 @@ static int stm32_gpio_domain_translate(struct irq_domain *d,
return 0;
}
-static int stm32_gpio_domain_activate(struct irq_domain *d,
- struct irq_data *irq_data, bool reserve)
-{
- struct stm32_gpio_bank *bank = d->host_data;
- struct stm32_pinctrl *pctl = dev_get_drvdata(bank->gpio_chip.parent);
- int ret = 0;
-
- if (pctl->hwlock) {
- ret = hwspin_lock_timeout_in_atomic(pctl->hwlock,
- HWSPNLCK_TIMEOUT);
- if (ret) {
- dev_err(pctl->dev, "Can't get hwspinlock\n");
- return ret;
- }
- }
-
- regmap_field_write(pctl->irqmux[irq_data->hwirq], bank->bank_ioport_nr);
-
- if (pctl->hwlock)
- hwspin_unlock_in_atomic(pctl->hwlock);
-
- return ret;
-}
-
static int stm32_gpio_domain_alloc(struct irq_domain *d,
unsigned int virq,
unsigned int nr_irqs, void *data)
@@ -637,18 +613,40 @@ static int stm32_gpio_domain_alloc(struct irq_domain *d,
int ret = 0;
/*
- * Check first that the IRQ MUX of that line is free.
- * gpio irq mux is shared between several banks, protect with a lock
+ * Check first that the IRQ MUX of that line is free, then point it at
+ * this bank. The mux is shared between several banks, and the register
+ * is shared with a coprocessor, so hold both irqmux_lock and the
+ * hwspinlock across the update. irqmux_lock also provides the local
+ * exclusion and the preemption disabling that the _in_atomic()
+ * hwspinlock primitives leave to their caller, as it does for the other
+ * hwspinlock users in this driver.
*/
spin_lock_irqsave(&pctl->irqmux_lock, flags);
if (pctl->irqmux_map & BIT(hwirq)) {
dev_err(pctl->dev, "irq line %ld already requested.\n", hwirq);
ret = -EBUSY;
- } else {
- pctl->irqmux_map |= BIT(hwirq);
+ goto unlock;
+ }
+
+ pctl->irqmux_map |= BIT(hwirq);
+
+ if (pctl->hwlock) {
+ ret = hwspin_lock_timeout_in_atomic(pctl->hwlock,
+ HWSPNLCK_TIMEOUT);
+ if (ret) {
+ dev_err(pctl->dev, "Can't get hwspinlock\n");
+ pctl->irqmux_map &= ~BIT(hwirq);
+ goto unlock;
+ }
}
+ regmap_field_write(pctl->irqmux[hwirq], bank->bank_ioport_nr);
+
+ if (pctl->hwlock)
+ hwspin_unlock_in_atomic(pctl->hwlock);
+
+unlock:
spin_unlock_irqrestore(&pctl->irqmux_lock, flags);
if (ret)
return ret;
@@ -683,7 +681,6 @@ static const struct irq_domain_ops stm32_gpio_domain_ops = {
.translate = stm32_gpio_domain_translate,
.alloc = stm32_gpio_domain_alloc,
.free = stm32_gpio_domain_free,
- .activate = stm32_gpio_domain_activate,
};
/* Pinctrl functions */
--
2.55.0
next prev parent reply other threads:[~2026-08-04 14:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-03 6:17 [PATCH] pinctrl: stm32: use a raw spinlock regmap to program the EXTI mux Ju Nan
2026-08-03 6:34 ` sashiko-bot
2026-08-04 3:03 ` Ju Nan
2026-08-04 3:22 ` [PATCH v2] pinctrl: stm32: program the EXTI mux from .alloc instead of .activate Ju Nan
2026-08-04 3:38 ` sashiko-bot
2026-08-04 14:14 ` Ju Nan [this message]
2026-08-04 15:12 ` [PATCH v3] " sashiko-bot
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=20260804141402.86911-2-junan76@163.com \
--to=junan76@163.com \
--cc=alexandre.torgue@foss.st.com \
--cc=antonio.borneo@foss.st.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=clrkwllms@kernel.org \
--cc=lee@kernel.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rt-devel@lists.linux.dev \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=mfd@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=u.kleine-koenig@pengutronix.de \
/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