Re: [PATCH v7 09/18] ASoC: rsnd: ssiu: Add shared SSI reset controller support

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Missing rollback on probe error paths leaks the shared reset control's deassert count.
--

commit 75b9405455f9c9d54972ded411c26d45e6a17c73
Author: John Madieu <john.madieu.xa@bp.renesas.com>

ASoC: rsnd: ssiu: Add shared SSI reset controller support

The RZ/G3E SoC exposes a single shared "ssi-all" reset that gates all
SSI/SSIU modules. Acquire it at SSIU probe and pass it through
rsnd_mod_init() so it is wired into the rsnd_mod->rstc plumbing.

> diff --git a/sound/soc/renesas/rcar/ssiu.c b/sound/soc/renesas/rcar/ssiu.c
> --- a/sound/soc/renesas/rcar/ssiu.c
> +++ b/sound/soc/renesas/rcar/ssiu.c
[ ... ]
> @@ -586,7 +593,7 @@ int rsnd_ssiu_probe(struct rsnd_priv *priv)
>  		}
>  
>  		ret = rsnd_mod_init(priv, rsnd_mod_get(ssiu),
> -				    ops, NULL, NULL, RSND_MOD_SSIU, i);
> +				    ops, NULL, rstc, RSND_MOD_SSIU, i);
>  		if (ret)
>  			return ret;

[Severity: High]
This is a pre-existing issue, but does this error path leak the shared reset
control's deassert count?

If probe fails on a subsequent module (for example, returning -EPROBE_DEFER
from rsnd_mod_init), the function returns directly without calling
rsnd_mod_quit() for the modules initialized in previous iterations of the loop.

Since rsnd_mod_init() calls reset_control_deassert(), the reset remains
deasserted for those modules.

While devres cleanup will call reset_control_put() on the shared reset acquired
via devm_reset_control_get_optional_shared(), this only drops the kref. It does
not balance the atomic deassert_count or assert the hardware line.

Across common initialization events like -EPROBE_DEFER retries, will the
deassert count grow unbounded and leave the hardware permanently deasserted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260525110230.4014435-1-john.madieu.xa@bp.renesas.com?part=9