Re: [PATCH v2] mfd: intel_soc_pmic_crc: Balance IRQ wake enable
From: Myeonghun Pak
Date: Thu Sep 17 2026 - 16:09:58 EST
Hello Andy,
Thanks for the feedback. I’ll use non-devm wake handling and drop the
shutdown changes in v3.
Best regards,
Myeonghun Pak
2026년 9월 15일 (화) 오전 4:16, Andy Shevchenko <andriy.shevchenko@xxxxxxxxx>님이 작성:
>
> On Mon, Sep 14, 2026 at 03:18:51PM -0700, Myeonghun Pak wrote:
> > The INT33FD Crystal Cove driver enables the parent IRQ as a wake source
> > after registering its regmap IRQ chip. When that succeeds, a later
> > mfd_add_devices() failure or driver removal leaves the wake enable
> > unbalanced. Shutdown only disables IRQ handling, leaving IRQ wake enabled.
> >
> > Register a managed action only after enable_irq_wake() succeeds. Since
> > the action is registered after the managed regmap IRQ chip, reverse devres
> > order disables IRQ wake before tearing down the IRQ chip. Keep warning and
> > continuing when enable_irq_wake() itself fails.
>
> > Shutdown does not release managed resources, so explicitly release the
> > wake-disable action there if it was registered. This also removes the
> > action, preventing a second disable during subsequent managed cleanup.
>
> Why? If it goes to shutdown, cleaning resources makes a little sense, no?
>
> > This is limited to the Bay Trail and Cherry Trail Crystal Cove PMIC
> > variants using the INT33FD ACPI ID.
> >
> > This issue was identified during our ongoing static-analysis research while
> > reviewing kernel code.
>
> ...
>
> > static void crystal_cove_shutdown(struct i2c_client *i2c)
> > {
> > struct intel_soc_pmic *pmic = i2c_get_clientdata(i2c);
> >
> > + if (devm_is_action_added(&i2c->dev, crystal_cove_disable_irq_wake, pmic))
> > + devm_release_action(&i2c->dev, crystal_cove_disable_irq_wake, pmic);
>
> Is it legit to call devm at this point? When is .shutdown() called and what are
> the assumptions before and after for a certain device?
>
> > disable_irq(pmic->irq);
>
> This looks a bit ugly. Can we start with no-devm? This will solve the above
> question as well.
>
> --
> With Best Regards,
> Andy Shevchenko
>
>