Re: [PATCH] mfd: twl6040: fix IRQ action memory leaks during teardown

[Guangshuo Li]

Hi Krzysztof,

Thank you for your feedback.

On Wed, 28 Oct 2026 at 00:44, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
>
> On 27/10/2026 17:22, Guangshuo Li wrote:
> > Hi Krzysztof,
> >
> > On Tue, 27 Oct 2026 at 23:33, Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >>
> >> On 27/10/2026 04:26, Guangshuo Li wrote:
> >>> twl6040_remove() currently removes the regmap IRQ chip before
> >>> removing the MFD child devices. This destroys the IRQ mappings
> >>> before the child drivers can release their interrupt handlers.
> >>>
> >>> The parent driver also registers READY and thermal interrupt
> >>> handlers using devm_request_threaded_irq(). These handlers are
> >>> normally released by device-managed cleanup after remove returns,
> >>> when the corresponding IRQ descriptors have already been removed.
> >>>
> >>> Consequently, free_irq() cannot find the IRQ descriptors and the
> >>> allocated struct irqaction objects are not freed. The associated
> >>> IRQ threads also cannot be stopped through the normal cleanup path.
> >>>
> >>> The probe error paths have a similar issue, as they destroy the IRQ
> >>> chip before the device-managed IRQ handlers are released.
> >>>
> >>> Remove the MFD child devices first, then explicitly free the
> >>> parent's READY and thermal IRQ handlers using devm_free_irq()
> >>> before removing the regmap IRQ chip.
> >>>
> >>> Also update the probe error paths to release successfully requested
> >>> IRQs before destroying their mappings.
> >>>
> >>
> >> More of postings by bot ignoring any feedback.
> >>
> >> 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.
>
> How this that differ from last time, explain me please.
>
> Last time you sent x separate patches for subsystem foo. I asked to send
> them as patchset.
>
> Now you sent y separate patches for subsystem bar. You keep repeating
> the same.
>
> Best regards,
> Krzysztof

We did follow your earlier advice and submitted a patch series, which
also received feedback from the maintainer:

Series:
https://lkml.iu.edu/2607.2/05103.html

Maintainer replies:
https://lists.openwall.net/linux-kernel/2026/09/28/2917
https://lists.openwall.net/linux-kernel/2026/09/28/2932

However, you're right about this batch. When manually sorting the
patches, we failed to group the related fixes into a series. This was
our oversight, and I sincerely apologize.

We'll be more careful and submit the related MFD fixes as a series in v2.

Best regards,
Guangshuo Li