[PATCH] mfd: da9150: fix IRQ action memory leak on removal

[PATCH] mfd: da9150: fix IRQ action memory leak on removal

[Guangshuo Li]

da9150_remove() currently removes the regmap IRQ chip before removing
the MFD child devices. regmap_del_irq_chip() disposes the child IRQ
mappings and removes their IRQ descriptors.

The GPADC child registers an interrupt handler using
devm_request_threaded_irq(). When the child device is subsequently
removed, its device-managed cleanup calls free_irq(), which can no
longer find the corresponding IRQ descriptor. As a result, the
allocated struct irqaction is not freed, causing a memory leak.
The associated IRQ thread also cannot be stopped normally.

Remove the MFD child devices first so their interrupt handlers are
released while the IRQ mappings are still valid. Then remove the
regmap IRQ chip and its IRQ domain.

This issue was found by our static analysis tool under development.

Fixes: b8fce55c09d3 ("mfd: Add support for DA9150 combined charger & fuel-gauge device")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
 drivers/mfd/da9150-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/da9150-core.c b/drivers/mfd/da9150-core.c
index 5c59cc869fb3..1b6dbbed60e7 100644
--- a/drivers/mfd/da9150-core.c
+++ b/drivers/mfd/da9150-core.c
@@ -474,8 +474,8 @@ static void da9150_remove(struct i2c_client *client)
 {
 	struct da9150 *da9150 = i2c_get_clientdata(client);
 
-	regmap_del_irq_chip(da9150->irq, da9150->regmap_irq_data);
 	mfd_remove_devices(da9150->dev);
+	regmap_del_irq_chip(da9150->irq, da9150->regmap_irq_data);
 	i2c_unregister_device(da9150->core_qif);
 }
 
-- 
2.43.0

Re: [PATCH] mfd: da9150: fix IRQ action memory leak on removal

[Krzysztof Kozlowski]

On 27/10/2026 04:08, Guangshuo Li wrote:
> da9150_remove() currently removes the regmap IRQ chip before removing
> the MFD child devices. regmap_del_irq_chip() disposes the child IRQ
> mappings and removes their IRQ descriptors.
> 
> The GPADC child registers an interrupt handler using
> devm_request_threaded_irq(). When the child device is subsequently
> removed, its device-managed cleanup calls free_irq(), which can no
> longer find the corresponding IRQ descriptor. As a result, the
> allocated struct irqaction is not freed, causing a memory leak.
> The associated IRQ thread also cannot be stopped normally.
> 
> Remove the MFD child devices first so their interrupt handlers are
> released while the IRQ mappings are still valid. Then remove the
> regmap IRQ chip and its IRQ domain.
> 
> This issue was found by our static analysis tool under development.

So you just keep ignoring and ignoring our feedback. It's just bot, so
little point to discuss with bot.

Best regards,
Krzysztof

Re: [PATCH] mfd: da9150: fix IRQ action memory leak on removal

[Guangshuo Li]

Hi Krzysztof,

On Tue, 27 Oct 2026 at 23:26, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 27/10/2026 04:08, Guangshuo Li wrote:
> > da9150_remove() currently removes the regmap IRQ chip before removing
> > the MFD child devices. regmap_del_irq_chip() disposes the child IRQ
> > mappings and removes their IRQ descriptors.
> >
> > The GPADC child registers an interrupt handler using
> > devm_request_threaded_irq(). When the child device is subsequently
> > removed, its device-managed cleanup calls free_irq(), which can no
> > longer find the corresponding IRQ descriptor. As a result, the
> > allocated struct irqaction is not freed, causing a memory leak.
> > The associated IRQ thread also cannot be stopped normally.
> >
> > Remove the MFD child devices first so their interrupt handlers are
> > released while the IRQ mappings are still valid. Then remove the
> > regmap IRQ chip and its IRQ domain.
> >
> > This issue was found by our static analysis tool under development.
>
> So you just keep ignoring and ignoring our feedback. It's just bot, so
> little point to discuss with bot.
>
> Best regards,
> Krzysztof

Thank you for your feedback, and I apologize if our recent submissions
gave the impression that we were ignoring your previous comments.

We did take your earlier suggestions into account and subsequently
submitted a patch series accordingly.

For the more recent patches, however, since they address issues in
different drivers, we thought it would be more appropriate to submit
them separately rather than group them into a single series.

We certainly did not intend to disregard your feedback. We appreciate
your time and guidance, and we will be more careful with our future
submissions.

Thank you for your understanding.

Best regards,
Guangshuo Li