Re: [PATCH v7 05/18] ASoC: rsnd: Add RZ/G3E SoC probing and register map

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The driver computes an incorrect physical address for DMA transfers on RZ/G3E by mistakenly falling back to R-Car Gen2/Gen3 hardcoded offsets.
- [Medium] The driver unconditionally attempts to write to `SSI_MODE0` during stream initialization for RZ/G3E, but this register is omitted from the RZ/G3E register map, causing continuous error logs.
--

commit 15c83e0793c513d3877a09357bf6e83e9029bbdb
Author: John Madieu <john.madieu.xa@bp.renesas.com>
Date:   Mon May 25 11:02:17 2026 +0000

ASoC: rsnd: Add RZ/G3E SoC probing and register map

This commit adds probe support and register layouts for the RZ/G3E audio
subsystem. It introduces specific register maps to accommodate the different
base address organization and register offsets compared to R-Car Gen2/3/4.

> diff --git a/sound/soc/renesas/rcar/gen.c b/sound/soc/renesas/rcar/gen.c
> index d1f20cde66be1..05d5f656fb01c 100644
> --- a/sound/soc/renesas/rcar/gen.c
> +++ b/sound/soc/renesas/rcar/gen.c
> @@ -464,6 +464,184 @@ static int rsnd_gen1_probe(struct rsnd_priv *priv)
>  	return ret_adg | ret_ssi;
>  }
>  
> +/*
> + *		RZ/G3E Generation
> + */
> +static int rsnd_rzg3e_probe(struct rsnd_priv *priv)
> +{
> +	static const struct rsnd_regmap_field_conf conf_ssiu[] = {
> +		RSND_GEN_S_REG(SSI_MODE1,		0x804),

[Severity: Medium]
Will this cause unsupported register access errors during stream initialization?

The conf_ssiu register map omits SSI_MODE0, but rsnd_ssiu_init() will
unconditionally attempt to write to it using rsnd_mod_bset(). Without this
register in the map, rsnd_is_accessible_reg() might fail, potentially
leading to error logs every time a stream starts.

I note this regression is addressed in the subsequent commit
"ASoC: rsnd: ssiu: Add RZ/G3E BUSIF support". Could this cause issues for
users who bisect to this specific commit?

> +		RSND_GEN_S_REG(SSI_MODE2,		0x808),
> +		RSND_GEN_S_REG(SSI_MODE3,		0x80c),

[ ... ]

> @@ -487,6 +665,8 @@ int rsnd_gen_probe(struct rsnd_priv *priv)
>  		ret = rsnd_gen2_probe(priv);
>  	else if (rsnd_is_gen4(priv))
>  		ret = rsnd_gen4_probe(priv);
> +	else if (rsnd_is_rzg3e(priv))
> +		ret = rsnd_rzg3e_probe(priv);

[Severity: Critical]
Does this new RZ/G3E generation cause a regression in rsnd_dma_addr()?

When setting up a DMA transfer, there doesn't seem to be a specific branch
for RZ/G3E address calculations. Because rsnd_is_gen1() and rsnd_is_gen4()
evaluate to false, execution appears to default to rsnd_gen2_dma_addr().

This fallback subtracts hardcoded offsets valid only for R-Car Gen2/Gen3,
which could yield an incorrect physical address for RZ/G3E and potentially
cause incorrect memory access during DMA transfers.

I note this regression is fixed later in the series by the commit
"ASoC: rsnd: Add RZ/G3E DMA address calculation support". Should the DMA
calculation support be included in this patch to maintain bisectability?

>  
>  	if (ret < 0)
>  		dev_err(dev, "unknown generation R-Car sound device\n");

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