Re: [PATCH v5 06/15] ASoC: qdsp6: q6dsp-lpass-ports: add support for lpi mi2s ports 5-6

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Global singleton DAI array `q6dsp_audio_fe_dais` is unsafely modified, leading to cross-driver type confusion if multiple front-ends probe.
--

commit 4aa03981f3bbeea9a8f5b00fc98ab94eec2d0492
Author: Richard Acayan <mailingradian@gmail.com>

ASoC: qdsp6: q6dsp-lpass-ports: add support for lpi mi2s ports 5-6

Add the extra LPI MI2S ports used for internal MI2S on SDM660.

Link: https://android.googlesource.com/kernel/msm-extra/+/530cffa4cc977a348753831b163eb9d3302b954a/asoc/msm-dai-q6-v2.c#4597

> diff --git a/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c b/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c
> index e5cd82f77b552..c3d8116ad5035 100644
> --- a/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c
> +++ b/sound/soc/qcom/qdsp6/q6dsp-lpass-ports.c

[ ... ]

> @@ -712,6 +716,7 @@ struct snd_soc_dai_driver *q6dsp_audio_ports_set_config(struct device *dev,
>  		case QUINARY_MI2S_RX ... QUINARY_MI2S_TX:
>  		case PRIMARY_MI2S_RX ... QUATERNARY_MI2S_TX:
>  		case LPI_MI2S_RX_0 ... LPI_MI2S_TX_4:
> +		case LPI_MI2S_RX_5 ... LPI_MI2S_TX_6:
>  			q6dsp_audio_fe_dais[i].ops = cfg->q6i2s_ops;

[Severity: High]
This is a pre-existing issue, but adding new ports to this switch block
highlights a potential problem with how q6dsp_audio_fe_dais is handled.

Since q6dsp_audio_ports_set_config() modifies the ops pointers of the
global static q6dsp_audio_fe_dais array in-place, does this create a risk
if multiple audio components that use this shared library probe on the
same system?

If a second component probes, wouldn't it overwrite the ops pointers for
all DAIs globally? Because ALSA stores a direct pointer to elements of
this array during component registration via devm_snd_soc_register_component(),
it seems the DAI callbacks for the first component could end up being
executed by the second component's driver.

Could this cause cross-driver type confusion where a callback casts
dev_get_drvdata(dai->dev) to its own driver data struct, but actually
operates on the other component's data (like expecting q6apm_lpass_dai_data
but getting q6afe_dai_data), potentially leading to memory corruption?

>  			break;
>  		case PRIMARY_TDM_RX_0 ... QUINARY_TDM_TX_7:

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260609162255.31074-1-mailingradian@gmail.com?part=6