Re: [PATCH v6 06/16] ASoC: rsnd: Add audmacpp clock and reset support for RZ/G3E

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Resource leak (clock and reset) when falling back to PIO mode due to missing memory resource.
--

commit 9d3365c013fb5e0808a6b0ca2bbf14ed35e47250
Author: John Madieu <john.madieu.xa@bp.renesas.com>

ASoC: rsnd: Add audmacpp clock and reset support for RZ/G3E

This commit adds global audmacpp clock and reset management in
rsnd_dma_probe() for RZ/G3E using optional APIs.

> diff --git a/sound/soc/renesas/rcar/dma.c b/sound/soc/renesas/rcar/dma.c
> --- a/sound/soc/renesas/rcar/dma.c
> +++ b/sound/soc/renesas/rcar/dma.c
[ ... ]
> @@ -864,6 +867,25 @@ int rsnd_dma_probe(struct rsnd_priv *priv)
>  	if (rsnd_is_gen4(priv))
>  		goto audmapp_end;
>  
> +	/*
> +	 * Audio DMAC peri-peri clock and reset for RZ/G3E.
> +	 * These use optional APIs, so they gracefully return NULL
> +	 * (no error) on platforms whose DT does not provide them.
> +	 *
> +	 * Enable the clock first so the block sees a stable clock on
> +	 * the way out of reset, then deassert the reset line.
> +	 */
> +	dmac->audmapp_clk = devm_clk_get_optional_enabled(dev, "audmapp");
> +	if (IS_ERR(dmac->audmapp_clk))
> +		return dev_err_probe(dev, PTR_ERR(dmac->audmapp_clk),
> +				     "failed to get audmapp clock\n");
> +
> +	dmac->audmapp_rstc =
> +		devm_reset_control_get_optional_exclusive_deasserted(dev, "audmapp");
> +	if (IS_ERR(dmac->audmapp_rstc))
> +		return dev_err_probe(dev, PTR_ERR(dmac->audmapp_rstc),
> +				     "failed to get audmapp reset\n");
> +
>  	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "audmapp");
>  	if (!res) {
>  		dev_err(dev, "lack of audmapp in DT\n");
>  		return 0; /* it will be PIO mode */

Does this code leak the clock and reset if the device tree provides a clock
but lacks the memory resource?

Because rsnd_dma_probe() returns 0 on this fallback path, the overall
probe succeeds and devm will not clean up the acquired resources. This leaves
the clock permanently enabled and the reset deasserted.

Additionally, since priv->dma is not set before the early return, the clock
cannot be disabled during system suspend.

Could the memory resource check be performed before acquiring and enabling
the clock and reset?

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