Linux Sound subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tristan Madani" <tristmd@gmail.com>
Cc: linux-sound@vger.kernel.org
Subject: Re: [PATCH] ASoC: rt5668: fix teardown order and stale state across card rebind
Date: Sat, 07 Nov 2026 13:28:13 +0000	[thread overview]
Message-ID: <sashiko-outbox-202925@kernel.org> (raw)
In-Reply-To: <20261107130651.2059891-1-tristan@talencesecurity.com>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] ASoC: rt5668: stale jack and button state synced on rebind in
  rt5668_probe()
- [Low] ASoC: rt5668: duplicate disable_irq() in rt5668_i2c_shutdown()
  when unbound
It also noticed 2 related pre-existing issues this patch does not
introduce:
- [High] ASoC: rt5668: delayed work re-armed when hs_jack is NULL in
  rt5668_set_jack_detect() [1]
- [High] ASoC: rt5668: uninitialized mutex locked in rt5668_calibrate()
  [2]
--

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

ASoC: rt5668: fix teardown order and stale state across card rebind

This commit clears jack state and marks the regmap cache dirty in
rt5668_remove(), syncs the cache in rt5668_probe(), and registers a devm
action and shutdown handler to disable the IRQ and cancel delayed works.

> diff --git a/sound/soc/codecs/rt5668.c b/sound/soc/codecs/rt5668.c
> index 29d70802a046a..2ceae9d9f40f6 100644
> --- a/sound/soc/codecs/rt5668.c
> +++ b/sound/soc/codecs/rt5668.c
[ ... ]
> @@ -2213,14 +2214,26 @@ static int rt5668_set_bias_level(struct snd_soc_component *component,
>  	return 0;
>  }
>  
> +static void rt5668_i2c_disable_irq_and_cancel_work(void *data)
> +{
> +	struct rt5668_priv *rt5668 = data;
> +
> +	if (rt5668->irq_acquired && !rt5668->irq_disabled)
> +		disable_irq(rt5668->i2c->irq);
> +	cancel_delayed_work_sync(&rt5668->jack_detect_work);
> +	cancel_delayed_work_sync(&rt5668->jd_check_work);
> +}
> +
>  static int rt5668_probe(struct snd_soc_component *component)
>  {
>  	struct rt5668_priv *rt5668 = snd_soc_component_get_drvdata(component);
>  
>  	rt5668->component = component;
>  
> +	regcache_sync(rt5668->regmap);
> +
>  	if (rt5668->irq_disabled) {
> -		enable_irq(to_i2c_client(component->dev)->irq);
> +		enable_irq(rt5668->i2c->irq);
>  		rt5668->irq_disabled = false;
>  	}
>  
> @@ -2230,17 +2243,21 @@ static int rt5668_probe(struct snd_soc_component *component)
>  static void rt5668_remove(struct snd_soc_component *component)
>  {
>  	struct rt5668_priv *rt5668 = snd_soc_component_get_drvdata(component);
> -	struct i2c_client *i2c = to_i2c_client(component->dev);
>  
>  	if (rt5668->irq_acquired) {
> -		disable_irq(i2c->irq);
> +		disable_irq(rt5668->i2c->irq);
>  		rt5668->irq_disabled = true;
>  	}
>  
>  	cancel_delayed_work_sync(&rt5668->jack_detect_work);
>  	cancel_delayed_work_sync(&rt5668->jd_check_work);
>  
> +	rt5668->hs_jack = NULL;
> +	rt5668->jack_type = 0;
> +	rt5668->component = NULL;

[Severity: High]
This problem wasn't introduced by this patch, but can
rt5668_set_jack_detect() re-arm rt5668->jack_detect_work after
rt5668_remove() has cancelled it [1]?

During card teardown, soc_cleanup_card_resources() runs
snd_soc_component_remove() (invoking rt5668_remove()) before
snd_card_free() -> snd_jack_dev_free(), where jack->private_free() calls
snd_soc_component_set_jack(component, NULL, NULL).  When pdata.jd_src is
RT5668_JD1, rt5668_set_jack_detect() does not check whether hs_jack is
NULL before enabling RT5668_JD1_EN and queuing rt5668->jack_detect_work:

sound/soc/codecs/rt5668.c:rt5668_set_jack_detect() {
	switch (rt5668->pdata.jd_src) {
	case RT5668_JD1:
		...
		regmap_update_bits(rt5668->regmap, RT5668_IRQ_CTRL_2,
			RT5668_JD1_EN_MASK | RT5668_JD1_POL_MASK,
			RT5668_JD1_EN | RT5668_JD1_POL_NOR);
		mod_delayed_work(system_power_efficient_wq,
			   &rt5668->jack_detect_work, msecs_to_jiffies(250));
		break;
}

When rt5668_jack_detect_handler() runs 250 ms later, rt5668->component is
NULL, so the handler reschedules itself every 15 ms until the I2C device
is unbound.

> +
>  	rt5668_reset(rt5668->regmap);
> +	regcache_mark_dirty(rt5668->regmap);
>  }

[Severity: Medium]
Does regcache_sync() in rt5668_probe() restore stale headset and
button-detection register state when rebinding after a 4-pole headset was
plugged in?

When a 4-pole headset is detected, rt5668_headset_detect(component, 1) and
rt5668_enable_push_button_irq(component, true) update non-volatile cached
registers: RT5668_CBJ_CTRL_1 (RT5668_TRIG_JD_HIGH), RT5668_SAR_IL_CMD_1
(RT5668_SAR_BUTT_DET_EN), RT5668_SAR_IL_CMD_13 (switching the SAR source
from RT5668_SAR_SOUR_TYPE to RT5668_SAR_SOUR_BTN), RT5668_4BTN_IL_CMD_2,
and RT5668_IRQ_CTRL_3 (RT5668_IL_IRQ_EN).

In rt5668_remove(), rt5668->jack_type is cleared to 0 and the hardware is
reset, but regcache_mark_dirty() preserves those non-default values in the
cache.  On card rebind, regcache_sync() writes them back to the codec
while rt5668->jack_type is 0.  Because neither rt5668_set_jack_detect()
nor the jack_insert branch of rt5668_headset_detect() switches
RT5668_SAR_IL_CMD_13 back to RT5668_SAR_SOUR_TYPE or disables push-button
IRQ, combo-jack type detection runs with the SAR source stuck on button
mode and leaves RT5668_IL_IRQ_EN enabled even if a 3-pole headphone is
connected.

Calling rt5668_headset_detect(component, 0) in rt5668_remove() before
rt5668_reset() (or reinitializing the cache to defaults) would clear the
cached headset and button state.

[ ... ]
> @@ -2576,6 +2593,13 @@ static int rt5668_i2c_probe(struct i2c_client *i2c)
>  			rt5668->irq_acquired = true;
>  	}
>  
> +	rt5668->i2c = i2c;
> +	ret = devm_add_action_or_reset(&i2c->dev,
> +				      rt5668_i2c_disable_irq_and_cancel_work,
> +				      rt5668);
> +	if (ret)
> +		return ret;
> +
>  	return devm_snd_soc_register_component(&i2c->dev, &soc_component_dev_rt5668,
>  			rt5668_dai, ARRAY_SIZE(rt5668_dai));
>  }

[Severity: High]
This problem wasn't introduced by this patch, but earlier in
rt5668_i2c_probe(), rt5668_calibrate() is called before
mutex_init(&rt5668->calibrate_mutex) [2]:

sound/soc/codecs/rt5668.c:rt5668_calibrate() {
	int value, count;

	guard(mutex)(&rt5668->calibrate_mutex);
	...
}

sound/soc/codecs/rt5668.c:rt5668_i2c_probe() {
	...
	rt5668_calibrate(rt5668);
	...
	mutex_init(&rt5668->calibrate_mutex);
}

guard(mutex) locks and unlocks a zero-initialized mutex during probe,
triggering CONFIG_DEBUG_MUTEXES / lockdep warnings and operating on an
uninitialized wait_list.

> @@ -2584,6 +2608,11 @@ static void rt5668_i2c_shutdown(struct i2c_client *client)
>  {
>  	struct rt5668_priv *rt5668 = i2c_get_clientdata(client);
>  
> +	if (rt5668->irq_acquired)
> +		disable_irq(client->irq);
> +	cancel_delayed_work_sync(&rt5668->jack_detect_work);
> +	cancel_delayed_work_sync(&rt5668->jd_check_work);
> +
>  	rt5668_reset(rt5668->regmap);
>  }

[Severity: Low]
If the sound card was unbound via rt5668_remove() before system shutdown,
rt5668->irq_disabled is already true; doesn't rt5668_i2c_shutdown() then
call disable_irq() a second time on the already-disabled IRQ?

Setting rt5668->irq_disabled = true in
rt5668_i2c_disable_irq_and_cancel_work() and calling that helper here
(and in rt5668_remove()) would avoid the unbalanced disable_irq() and the
duplicated teardown sequence.

[1] https://sashiko.dev/#/bug/linux-ba1194b0-1aa7-482d-b655-2fd164cde5ff
[2] https://sashiko.dev/#/bug/linux-52105661-89bd-4327-8228-f16b8d913d85

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261107130651.2059891-1-tristan@talencesecurity.com?part=1

  reply	other threads:[~2026-11-07 13:28 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-07 13:06 [PATCH] ASoC: rt5668: fix teardown order and stale state across card rebind Tristan Madani
2026-11-07 13:28 ` sashiko-bot [this message]
2026-11-07 17:26 ` [PATCH v3] " Tristan Madani

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-202925@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tristmd@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox