Re: [PATCH v1 5/7] ASoC: codecs: ES8389: Modify the initial configuration

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The return values of multiple `regmap_read()` calls are ignored, leading to the use of uninitialized stack variables.
--

commit eeca5823fe9bef5ffe179596ec0a3aab2d9ba07a
Author: Zhang Yi <zhangyi@everest-semi.com>

ASoC: codecs: ES8389: Modify the initial configuration

Modify the initial configuration.

> diff --git a/sound/soc/codecs/es8389.c b/sound/soc/codecs/es8389.c
> index 647d9d62820e6..284eb707f9f7f 100644
> --- a/sound/soc/codecs/es8389.c
> +++ b/sound/soc/codecs/es8389.c
> @@ -793,7 +793,7 @@ static void es8389_init(struct snd_soc_component *component)
>  
>  	regmap_read(es8389->regmap, ES8389_MAX_REGISTER, &reg);
>  	es8389->version = reg;

[Severity: High]
This isn't a bug introduced by this patch, but I noticed the return value of
regmap_read() is ignored here. If the read fails, 'reg' will remain
uninitialized, and es8389->version will be corrupted with stack garbage.

Could this also cause unpredictable behavior in other parts of the driver?
Similar unchecked regmap_read() calls seem to exist in:
- es8389_pcm_hw_params() (corrupting dmic_enable)
- es8389_mute() (triggering spurious state changes)
- es8389_resume() (potentially triggering es8389_init() erroneously)

> -	regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x00);
> +	regmap_write(es8389->regmap, ES8389_ISO_CTL, 0x56);
>  	regmap_write(es8389->regmap, ES8389_RESET, 0x7E);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611031824.4628-1-zhangyi@everest-semi.com?part=5