Re: [PATCH v5 1/2] ASoC: codecs: nau8360: Block DSP path selection when firmware load fails

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Missing `flush_work()` causes `alsactl` state restoration to sporadically fail on boot.
--

commit f48ac064e0d2cdb72be2043789666477aed5f727
Author: Neo Chang <YLCHANG2@nuvoton.com>

ASoC: codecs: nau8360: Block DSP path selection when firmware load fails

Block the DSP path selection if the firmware fails to load to prevent
invalid routing states.

If the firmware is not ready, nau8360_dac_mux_put_enum() will print
a rate-limited warning and return -EBUSY. This rejects the invalid
userspace request and maintains the original hardware state without
causing audio wrong status.

Closes: https://lore.kernel.org/linux-sound/aqK_oOpMAXVhxkHJ@stanley.mountain/

> diff --git a/sound/soc/codecs/nau8360.c b/sound/soc/codecs/nau8360.c
> index 89b8ee80d6c86..f5dee12127cd0 100644
> --- a/sound/soc/codecs/nau8360.c
> +++ b/sound/soc/codecs/nau8360.c
> @@ -715,8 +715,13 @@ static int nau8360_dac_mux_put_enum(struct snd_kcontrol *kcontrol,
>  	int ret = 0;
>  
>  	if (snd_soc_dapm_get_bias_level(dapm) > SND_SOC_BIAS_STANDBY) {
> -		dev_warn(nau8360->dev, "changing path is not allowed during playback");
> -		return ret;
> +		dev_warn_ratelimited(nau8360->dev, "changing path is not allowed during playback");
> +		return -EBUSY;
> +	}
> +
> +	if (item[0] == NAU8360_DAC_SRC_DSP && !nau8360->load_fw_done) {
> +		dev_warn_ratelimited(nau8360->dev, "Cannot enable DSP: Firmware not ready or disabled\n");
> +		return -EBUSY;

[Severity: Medium]
Will this cause boot-time ALSA state restoration to fail if the asynchronous
firmware loader is still running?

Userspace initialization tools like alsactl restore write to ALSA controls
immediately after card registration during boot. Because nau8360_load_fw_work
is scheduled asynchronously, nau8360->load_fw_done might still be false when
alsactl attempts to restore the DSP path.

Without a flush_work() call to synchronize with the firmware loader, does this
mean valid DSP routing configurations saved by the user will be sporadically
rejected during boot, causing the audio state to fall back to the default HW1
path?

>  	}
>  
>  	mutex_lock(&nau8360->lock);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914015648.311986-1-YLCHANG2@nuvoton.com?part=1