Re: [PATCH v2] mfd: da903x: cancel IRQ work during teardown

[Lee Jones]

On Thu, 06 Aug 2026, Hongyan Xu wrote:

> The IRQ handler disables the IRQ and schedules irq_work. Releasing the
> IRQ does not drain that work, which can continue to use the devm-allocated
> chip and notifier state.
> 
> Add a devm action after requesting the IRQ. The action disables the IRQ
> and cancels the work before automatic IRQ release. Run the same action
> before removing child devices on normal detach.
> 
> If da903x_add_subdevs() fails, it removes already-created child devices
> before returning from probe. Release the action explicitly before that
> cleanup so the work is stopped before child-device teardown.
> 
> This issue was found by the author's in-house static analysis tool.
> The patch was reviewed by the author against the latest mainline tree.
> 
> Fixes: 26b8f5e1e2d1 ("mfd: add base support for Dialog DA9030/DA9034 PMICs")
> Cc: stable@xxxxxxxxxxxxxxx
> Assisted-by: Codex:GPT-5
> Signed-off-by: Hongyan Xu <getshell@xxxxxxxxxx>
> ---
>  drivers/mfd/da903x.c | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git "a/drivers/mfd/da903x.c" "b/drivers/mfd/da903x.c"
> index e86b39de3303..f3e983bd21b0 100644
> --- "a/drivers/mfd/da903x.c"
> +++ "b/drivers/mfd/da903x.c"
> @@ -421,6 +421,14 @@ static irqreturn_t da903x_irq_handler(int irq, void *data)
>  	return IRQ_HANDLED;
>  }
>  
> +static void da903x_cancel_irq_work(void *data)
> +{
> +	struct da903x_chip *chip = data;
> +
> +	disable_irq(chip->client->irq);
> +	cancel_work_sync(&chip->irq_work);
> +}
> +
>  static const struct da903x_chip_ops da903x_ops[] = {
>  	[0] = {
>  		.init_chip	= da9030_init_chip,
> @@ -484,6 +492,7 @@ static int da903x_add_subdevs(struct da903x_chip *chip,
>  	return 0;
>  
>  failed:
> +	devm_release_action(chip->dev, da903x_cancel_irq_work, chip);

Manually calling 'devm_release_action' here and in 'da903x_remove' somewhat
defeats the purpose of using managed resources. Should we instead register
the subdevice removal as a devm action as well?

If we register the subdevices' cleanup as a devm action before the IRQ
cancel action, devres will execute them in reverse order during cleanup.
This would allow us to eliminate the '.remove' callback entirely.

>  	da903x_remove_subdevs(chip);
>  	return ret;
>  }
> @@ -529,6 +538,11 @@ static int da903x_probe(struct i2c_client *client)
>  		return ret;
>  	}
>  
> +	ret = devm_add_action_or_reset(&client->dev, da903x_cancel_irq_work,
> +				       chip);
> +	if (ret)
> +		return ret;
> +

If we transition to using a devm action for the subdevice removal, we
could call 'da903x_add_subdevs' first, register its cleanup action, and
then register 'da903x_cancel_irq_work'. This would guarantee that the
IRQ work is cancelled before the subdevices are removed during any
unwinding or driver removal.

>  	return da903x_add_subdevs(chip, pdata);
>  }
>  
> @@ -536,6 +550,7 @@ static void da903x_remove(struct i2c_client *client)
>  {
>  	struct da903x_chip *chip = i2c_get_clientdata(client);
>  
> +	devm_release_action(&client->dev, da903x_cancel_irq_work, chip);

With both cleanup steps handled by devres in the correct order, we should
be able to remove 'da903x_remove' entirely, simplifying the driver.

>  	da903x_remove_subdevs(chip);
>  }
>  
> -- 
> 2.50.1.windows.1
> 

-- 
Lee Jones