Re: [PATCH v1 3/4] ASoC: codecs: pm4125: Keep the micbias reference count balanced

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] ASoC: pm4125: data races in micbias control from MBHC workqueues
--

commit 8af5811d67f1f26cf2cd472e51e4bbe2a10e4f6f
Author: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>

ASoC: codecs: pm4125: Keep the micbias reference count balanced

This patch updates the pm4125 microphone bias handling to prevent
unbalanced reference drops from the MBHC framework. It changes the global
bias disable to use atomic_dec_if_positive() and ignores micbias releases
that do not have matching requests.

> diff --git a/sound/soc/codecs/pm4125.c b/sound/soc/codecs/pm4125.c
> --- a/sound/soc/codecs/pm4125.c
> +++ b/sound/soc/codecs/pm4125.c
> @@ -229,7 +229,7 @@ static int pm4125_global_mbias_disable(struct snd_soc_component *component)
>  {
>  	struct pm4125_priv *pm4125 = snd_soc_component_get_drvdata(component);
>  
> -	if (atomic_dec_and_test(&pm4125->gloal_mbias_cnt)) {
> +	if (atomic_dec_if_positive(&pm4125->gloal_mbias_cnt) == 0) {
>  
>  		snd_soc_component_write_field(component, PM4125_ANA_MBIAS_EN,
>  					      PM4125_ANA_MBIAS_EN_V2I_MASK,

[Severity: Medium]
Is there a race condition here in pm4125_global_mbias_disable() between the
atomic decrement and the hardware register updates?

If a racing enable thread increments gloal_mbias_cnt to 1 and enables the
hardware between this thread's atomic_dec_if_positive() and the subsequent
snd_soc_component_write_field() calls, could the hardware bias be left
disabled while the count is 1? 

This sequence might silently break the active audio path by tearing down
the mic bias underneath it.

[ ... ]

> @@ -772,8 +772,18 @@ static int pm4125_micbias_control(struct snd_soc_component *component, int micb_
>  		}
>  		break;
>  	case MICB_DISABLE:
> -		if (pm4125->micb_ref[micb_index] > 0)
> -			pm4125->micb_ref[micb_index]--;
> +		/*
> +		 * Ignore a release that has no matching request. The MBHC
> +		 * framework releases MIC_BIAS_2 once when the plug type
> +		 * correction work ends and again when it turns the bias off,
> +		 * and honouring the second one would drop a reference on the
> +		 * shared global mbias that was never taken, switching the
> +		 * analog master bias off under an active stream.
> +		 */
> +		if (!pm4125->micb_ref[micb_index])
> +			break;
> +
> +		pm4125->micb_ref[micb_index]--;

[Severity: Medium]
Could this lead to data corruption of the reference tracking arrays?

The micb_ref array is evaluated and decremented non-atomically without a
local lock in pm4125_micbias_control(). Because the MBHC framework executes
from asynchronous workqueues (like mbhc_plug_detect_fn), and DAPM widget
events can run concurrently, inserting a jack during stream playback might
cause these threads to race on the micb_ref array updates.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015-pm4125_mbhc_support-v1-0-8bc1212db6f7@oss.qualcomm.com?part=3