From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Alexander Stein <alexander.stein@ew.tq-group.com>,
Lee Jones <lee@kernel.org>, Sasha Levin <sashal@kernel.org>,
mcoquelin.stm32@gmail.com, alexandre.torgue@foss.st.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Subject: [PATCH AUTOSEL 6.17-5.4] mfd: stmpe: Remove IRQ domain upon removal
Date: Thu, 9 Oct 2025 11:55:18 -0400 [thread overview]
Message-ID: <20251009155752.773732-52-sashal@kernel.org> (raw)
In-Reply-To: <20251009155752.773732-1-sashal@kernel.org>
From: Alexander Stein <alexander.stein@ew.tq-group.com>
[ Upstream commit 57bf2a312ab2d0bc8ee0f4e8a447fa94a2fc877d ]
The IRQ domain is (optionally) added during stmpe_probe, but never removed.
Add the call to stmpe_remove.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Link: https://lore.kernel.org/r/20250725070752.338376-1-alexander.stein@ew.tq-group.com
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
YES
- What changed
- Adds missing cleanup in `stmpe_remove()` to tear down the IRQ
domain: `drivers/mfd/stmpe.c:1486`
- New lines: `if (stmpe->domain) irq_domain_remove(stmpe->domain);`
- The IRQ domain is created in probe via
`irq_domain_create_simple(...)` in `stmpe_irq_init()`:
`drivers/mfd/stmpe.c:1222`
- The domain is passed to children via MFD core (`mfd_add_devices(...,
stmpe->domain)`), so it persists beyond probe:
`drivers/mfd/stmpe.c:1295`
- Why it matters
- Bug: Resource leak and stale IRQ domain on device removal/module
unload. The driver creates an IRQ domain during probe but never
removes it, leaving mappings/structures alive after unbind/unload.
- User impact: Rebind/unload scenarios can accumulate leaked IRQ
resources; at minimum this is a memory/resource leak, at worst it
risks stale references in debug/introspection paths.
- Scope and risk
- Minimal change (3 LOC), confined to removal path in
`stmpe_remove()`.
- No functional/architectural changes; no runtime behavior changes
while device is active.
- Standard API usage: `irq_domain_remove()` is the canonical teardown
for domains created with `irq_domain_create_*()`.
- Children devices don’t require `stmpe->domain` during removal;
`mfd_remove_devices()` triggers child driver unbinds using Linux IRQ
numbers, and `free_irq()` does not depend on the domain object. So
calling `irq_domain_remove()` at the start of `stmpe_remove()` is
safe.
- Historical/context checks
- Domain creation present: `stmpe_irq_init()` uses
`irq_domain_create_simple(...)`: `drivers/mfd/stmpe.c:1222`.
- MFD children use the domain only at registration time for IRQ
mapping: `mfd_add_devices(..., stmpe->domain)`:
`drivers/mfd/stmpe.c:1295`.
- Upstream commit already merged (57bf2a312ab2d), indicating
maintainer review and acceptance.
- Stable backport criteria
- Fixes a real bug (resource leak on driver removal) that can affect
users in unbind/rebind or module unload workflows.
- Small, self-contained, and low risk.
- No new features or architectural changes.
- Touches an MFD driver only; not a critical core subsystem.
- No external dependencies beyond long‑standing IRQ domain APIs.
- Notes
- This commit doesn’t address probe-failure paths (domain created then
probe fails before `stmpe_remove()`); that’s a separate improvement,
but not required for this backport.
- If any stable branch differs in function signatures/locations, the
change still trivially adapts: just add the
`irq_domain_remove(stmpe->domain)` in that branch’s `stmpe_remove()`
implementation.
drivers/mfd/stmpe.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/stmpe.c b/drivers/mfd/stmpe.c
index 819d19dc9b4a9..e1165f63aedae 100644
--- a/drivers/mfd/stmpe.c
+++ b/drivers/mfd/stmpe.c
@@ -1485,6 +1485,9 @@ int stmpe_probe(struct stmpe_client_info *ci, enum stmpe_partnum partnum)
void stmpe_remove(struct stmpe *stmpe)
{
+ if (stmpe->domain)
+ irq_domain_remove(stmpe->domain);
+
if (!IS_ERR(stmpe->vio) && regulator_is_enabled(stmpe->vio))
regulator_disable(stmpe->vio);
if (!IS_ERR(stmpe->vcc) && regulator_is_enabled(stmpe->vcc))
--
2.51.0
next prev parent reply other threads:[~2025-10-09 15:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251009155752.773732-1-sashal@kernel.org>
2025-10-09 15:54 ` [PATCH AUTOSEL 6.17-6.12] soc: apple: mailbox: Add Apple A11 and T2 mailbox support Sasha Levin
2025-10-10 2:22 ` Nick Chan
2025-11-04 0:22 ` Sasha Levin
2025-10-09 15:54 ` [PATCH AUTOSEL 6.17-6.12] soc: sunxi: sram: add entry for a523 Sasha Levin
2025-10-09 16:38 ` Andre Przywara
2025-11-04 0:22 ` Sasha Levin
2025-10-09 15:54 ` [PATCH AUTOSEL 6.17-5.10] pinctrl: single: fix bias pull up/down handling in pin_config_set Sasha Levin
2025-10-09 15:54 ` [PATCH AUTOSEL 6.17-6.16] soc: ti: k3-socinfo: Add information for AM62L SR1.1 Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17] mfd: macsmc: Add "apple,t8103-smc" compatible Sasha Levin
2025-10-09 15:55 ` Sasha Levin [this message]
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-5.4] cpufreq/longhaul: handle NULL policy in longhaul_exit Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-6.16] firmware: ti_sci: Enable abort handling of entry to LPM Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-5.15] soc: aspeed: socinfo: Add AST27xx silicon IDs Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-6.6] arm64: zynqmp: Revert usb node drive strength and slew rate for zcu106 Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-6.12] arm64: zynqmp: Disable coresight by default Sasha Levin
2025-10-09 15:55 ` [PATCH AUTOSEL 6.17-6.6] pmdomain: apple: Add "apple,t8103-pmgr-pwrstate" Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-6.16] arm64: versal-net: Update rtc calibration value Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-5.10] soc: ti: pruss: don't use %pK through printk Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-5.4] mfd: stmpe-i2c: Add missing MODULE_LICENSE Sasha Levin
2025-10-09 15:56 ` [PATCH AUTOSEL 6.17-5.4] irqchip/gic-v2m: Handle Multiple MSI base IRQ Alignment Sasha Levin
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=20251009155752.773732-52-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=alexander.stein@ew.tq-group.com \
--cc=alexandre.torgue@foss.st.com \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=patches@lists.linux.dev \
--cc=stable@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).