Re: [PATCH v5 1/2] ASoC: codecs: nau8360: Block DSP path selection when firmware load fails
From: sashiko-bot@kernel.org
Date: 2026-09-14 02:11:38
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 [off-list ref] 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/ (local)
quoted hunk ↗ jump to hunk
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