All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: shengjiu.wang@oss.nxp.com
Cc: imx@lists.linux.dev, devicetree@vger.kernel.org,
	Frank.Li@kernel.org, robh@kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH 4/4] ASoC: fsl_easrc: expose individual DAIs per conversion context
Date: Mon, 20 Jul 2026 10:43:58 +0000	[thread overview]
Message-ID: <20260720104358.77CB81F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720095450.1618747-5-shengjiu.wang@oss.nxp.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Concurrent streams will cause a data race on the shared `dma_params_tx` and `dma_params_rx` structures, leading to incorrect DMA FIFO address configuration and state corruption.
--

--- Patch [4]: [PATCH 4/4] ASoC: fsl_easrc: expose individual DAIs per conversion context ---
commit 8f522766ccdfc101a1c60ab6f34e2623d03f39d0
Author: Shengjiu Wang <shengjiu.wang@nxp.com>

ASoC: fsl_easrc: expose individual DAIs per conversion context

The i.MX EASRC hardware supports four independent conversion contexts
(A, B, C, D). The driver previously registered a single DAI with generic
stream names "ASRC-Playback" and "ASRC-Capture", which prevents
individual contexts from being routed to separate audio paths
simultaneously. This commit replaces the single fsl_easrc_dai instance 
with an array of four DAI drivers.

> diff --git a/sound/soc/fsl/fsl_easrc.c b/sound/soc/fsl/fsl_easrc.c
> index 15a3424967601..dd0c3046a0075 100644
> --- a/sound/soc/fsl/fsl_easrc.c
> +++ b/sound/soc/fsl/fsl_easrc.c

[ ... ]

> @@ -2245,7 +2317,7 @@ static int fsl_easrc_probe(struct platform_device *pdev)
>  	regcache_cache_only(easrc->regmap, true);
>  
>  	ret = devm_snd_soc_register_component(dev, &fsl_easrc_component,
> -					      &fsl_easrc_dai, 1);
> +					      fsl_easrc_dai, ARRAY_SIZE(fsl_easrc_dai));

[Severity: High]
When multiple DAIs are registered and active concurrently, can this cause a
data race on the shared DMA parameters?

Since all four DAIs share the same operations, fsl_easrc_dai_probe()
initializes them all with the exact same pointers:

fsl_easrc_dai_probe() {
    ...
    snd_soc_dai_init_dma_data(cpu_dai,
                              &easrc->dma_params_tx,
                              &easrc->dma_params_rx);
    ...
}

If an application opens multiple PCM devices simultaneously, won't their
concurrent hardware parameters operations modify the shared parameters
without locking?

fsl_asrc_dma_hw_params() {
    ...
    dma_params_fe = snd_soc_dai_get_dma_data(snd_soc_rtd_to_cpu(rtd, 0), substream);
    dma_params_fe->addr = asrc->paddr + asrc->get_fifo_addr(!dir, index);
    dma_params_fe->maxburst = dma_params_be->maxburst;
    ...
}

Could this lead to incorrect DMA FIFO address configuration and state corruption
across the different DAI contexts?

>  	if (ret) {
>  		dev_err(dev, "failed to register ASoC DAI\n");
>  		goto err_pm_disable;

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

      reply	other threads:[~2026-07-20 10:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20  9:54 [PATCH 0/4] ASoC: fsl: expose individual DAIs per ASRC/EASRC conversion pair/context shengjiu.wang
2026-07-20  9:54 ` [PATCH 1/4] dt-bindings: sound: fsl,imx-asrc: update port binding to support multiple pairs shengjiu.wang
2026-07-20 10:03   ` sashiko-bot
2026-07-20 14:28   ` Mark Brown
2026-07-21  8:58     ` Shengjiu Wang
2026-07-20  9:54 ` [PATCH 2/4] dt-bindings: sound: fsl,easrc: add ports binding for multiple contexts shengjiu.wang
2026-07-20 10:16   ` sashiko-bot
2026-07-20  9:54 ` [PATCH 3/4] ASoC: fsl_asrc: expose individual DAIs per conversion pair shengjiu.wang
2026-07-20 10:33   ` sashiko-bot
2026-07-20  9:54 ` [PATCH 4/4] ASoC: fsl_easrc: expose individual DAIs per conversion context shengjiu.wang
2026-07-20 10:43   ` sashiko-bot [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260720104358.77CB81F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=Frank.Li@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=imx@lists.linux.dev \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shengjiu.wang@oss.nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.