Re: [PATCH v2] mfd: intel_soc_pmic_crc: Balance IRQ wake enable

[Andy Shevchenko]

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