Re: [PATCH v4 5/5] ASoC: fsl_easrc: expose individual DAIs per conversion path

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Read-Modify-Write (RMW) on a Write-1-to-Clear (W1C) interrupt status register causes unintentional clearing of concurrent interrupt flags.
- [High] Calling hw_params multiple times for the same stream leaks EASRC hardware contexts and available channels, leading to Use-After-Free (UAF).
--

--- Patch [5]: [PATCH v4 5/5] ASoC: fsl_easrc: expose individual DAIs per conversion path ---
commit 6668df3f25b7ce9103114dd835e72d2e72b096cc
Author: Shengjiu Wang <shengjiu.wang@nxp.com>

ASoC: fsl_easrc: expose individual DAIs per conversion path

The i.MX EASRC hardware supports four independent conversion contexts.
This commit replaces the single fsl_easrc_dai instance with an array of
four DAI drivers to allow up to four independent conversion paths to be
active at the same time.

> diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
> index 2b8319b8a609a..c2f0524e949e9 100644
> --- a/sound/soc/fsl/fsl_easrc.c
> +++ b/sound/soc/fsl/fsl_easrc.c
> @@ -1589,27 +1589,99 @@ static const struct snd_soc_dai_ops fsl_easrc_dai_ops = {
>  	.hw_free	= fsl_easrc_hw_free,
>  };
>  
> -static struct snd_soc_dai_driver fsl_easrc_dai = {
[ ... ]
> +static struct snd_soc_dai_driver fsl_easrc_dai[] = {
> +	{
> +		.name = "easrc-0",
[ ... ]
> +	{
> +		.name = "easrc-3",
> +		.playback = {
> +			.stream_name = "ASRC3-Playback",
> +			.channels_min = 1,
> +			.channels_max = 32,
> +			.rate_min = 8000,
> +			.rate_max = 768000,
> +			.rates = SNDRV_PCM_RATE_KNOT,
> +			.formats = FSL_EASRC_FORMATS,
> +		},
> +		.capture = {
> +			.stream_name = "ASRC3-Capture",
> +			.channels_min = 1,
> +			.channels_max = 32,
> +			.rate_min = 8000,
> +			.rate_max = 768000,
> +			.rates = SNDRV_PCM_RATE_KNOT,
> +			.formats = FSL_EASRC_FORMATS |
> +				   SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE,
> +		},
> +		.ops = &fsl_easrc_dai_ops,
>  	},
> -	.ops = &fsl_easrc_dai_ops,
>  };

[Severity: High]
This isn't a bug introduced by this patch, but since multiple DAIs now
allow concurrent streams, could this read-modify-write operation in
fsl_easrc_stop_context() cause issues with interrupt handling?

sound/soc/fsl/fsl_easrc.c:fsl_easrc_stop_context() {
	...
	regmap_write_bits(easrc->regmap,
			  REG_EASRC_IRQF,
			  EASRC_IRQF_RSD(1 << ctx->index),
			  EASRC_IRQF_RSD(1 << ctx->index));
	...
}

Because REG_EASRC_IRQF is a write-1-to-clear register, will this write
1s back to all currently pending interrupt flags?

If two streams stop simultaneously, could one CPU unintentionally clear
the run-stop-done bit of the other context, causing the other CPU's
polling loop to time out?

[Severity: High]
This is a pre-existing issue, but with up to four independent conversion
paths active, is it possible to leak hardware contexts if the ALSA core
calls hw_params multiple times for the same stream?

In sound/soc/fsl/fsl_easrc.c:fsl_easrc_hw_params():

	ret = fsl_easrc_request_context(channels, ctx);

This unconditionally assigns a new context. Then in
fsl_easrc_request_context():

	ctx->index = index;
	ctx->channels = channels;
	easrc->pair[index] = ctx;
	easrc->channel_avail -= channels;

If hw_params is called multiple times without an intermediate hw_free,
won't this leak channels and leave a dangling pointer in the old slot
when ctx is eventually freed?

>  
>  static const struct snd_soc_component_driver fsl_easrc_component = {
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260813070020.719810-1-shengjiu.wang@oss.nxp.com?part=5