Re: [PATCH v6 11/16] ASoC: rsnd: Add ADG reset support for RZ/G3E

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The ADG reset line is deasserted during probe but never asserted on module removal or error paths, causing a state/resource leak.
- [High] The ADG module reset is deasserted before its clock is enabled, violating the hardware reset sequence.
--

commit 6c6d894ea65ae109e5fa8d85239c0bfcc07fc1aa
Author: John Madieu <john.madieu.xa@bp.renesas.com>

ASoC: rsnd: Add ADG reset support for RZ/G3E

This commit adds optional reset control support for the ADG module on
Renesas RZ/G3E SoCs. It retrieves the adg reset line and passes it to
rsnd_mod_init() during probe.

> diff --git a/sound/soc/renesas/rcar/adg.c b/sound/soc/renesas/rcar/adg.c
> --- a/sound/soc/renesas/rcar/adg.c
> +++ b/sound/soc/renesas/rcar/adg.c
> @@ -779,8 +780,11 @@ int rsnd_adg_probe(struct rsnd_priv *priv)
>  	if (!adg)
>  		return -ENOMEM;
>  
> -	ret = rsnd_mod_init(priv, &adg->mod, &adg_ops,
> -		      NULL, NULL, 0, 0);
> +	rstc = devm_reset_control_get_optional_exclusive(dev, "adg");
> +	if (IS_ERR(rstc))
> +		return dev_err_probe(dev, PTR_ERR(rstc), "failed to get adg reset\n");
> +
> +	ret = rsnd_mod_init(priv, &adg->mod, &adg_ops, NULL, rstc, 0, 0);

Does this sequence deassert the reset before the module clock is enabled?

Looking at rsnd_mod_init(), the reset is deasserted immediately:

sound/soc/renesas/rcar/core.c:rsnd_mod_init() {
        ...
        ret = clk_prepare_enable(clk);
        if (ret)
                return ret;

        ret = reset_control_deassert(rstc);
        ...
}

Since NULL is passed for the clk argument in rsnd_adg_probe(), the ADG
clock isn't enabled during this deassertion. The actual ADG clock is
fetched and enabled later in rsnd_adg_probe() via rsnd_adg_get_clkin()
and rsnd_adg_clk_enable().

On Renesas hardware, synchronous resets typically require the module
clock to be actively running when the reset is deasserted. Could this
cause the hardware to miss the reset release or lead to uninitialized
module state?

>  	if (ret)
>  		return ret;

Are there missing cleanup paths for the deasserted reset?

If rsnd_adg_probe() fails later (for example, in rsnd_adg_get_clkin()),
it returns the error directly without jumping to a cleanup path to
re-assert the reset.

Additionally, if rsnd_adg_remove() does not call rsnd_mod_quit() for
the ADG module, does this leave the hardware permanently out of reset
across unbind and rebind cycles?

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