Re: [PATCH v2 3/4] ASoC: twl6040: cancel headset jack work on component removal

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] ASoC: twl6040: work cancelled before free_irq() in twl6040_remove()
--

commit c1e273e65955a707961d70889d530cc54f85f31c
Author: Tristan Madani <tristmd@gmail.com>

ASoC: twl6040: cancel headset jack work on component removal

This commit adds cancel_delayed_work_sync() in twl6040_remove() to cancel the
headset jack detection delayed work upon component removal.

> diff --git a/sound/soc/codecs/twl6040.c b/sound/soc/codecs/twl6040.c
> index 650836f9615fb..43feb660b635b 100644
> --- a/sound/soc/codecs/twl6040.c
> +++ b/sound/soc/codecs/twl6040.c
> @@ -1135,6 +1135,7 @@ static void twl6040_remove(struct snd_soc_component *component)
>  {
>  	struct twl6040_data *priv = snd_soc_component_get_drvdata(component);
>  
> +	cancel_delayed_work_sync(&priv->hs_jack.work);
>  	free_irq(priv->plug_irq, component);

[Severity: Critical]
Can priv->hs_jack.work be re-queued if priv->plug_irq fires after
cancel_delayed_work_sync() returns, but before free_irq() completes?

In sound/soc/codecs/twl6040.c, the threaded interrupt handler
twl6040_audio_handler() schedules the delayed work whenever priv->plug_irq
fires:

    queue_delayed_work(system_power_efficient_wq,
                       &priv->hs_jack.work, msecs_to_jiffies(200));

If twl6040_audio_handler() runs in the window between
cancel_delayed_work_sync() and free_irq() in twl6040_remove(),
priv->hs_jack.work will remain queued after removal completes, allowing
twl6040_accessory_work() to dereference priv and component after devres has
freed them.

Should free_irq(priv->plug_irq, component) be called before
cancel_delayed_work_sync(&priv->hs_jack.work), or should
disable_delayed_work_sync() be used instead?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261029212504.2997364-1-tristmd@gmail.com?part=3