[PATCH] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[PATCH] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Zimeng Li]

The DAI ID is a hardware port ID and is not necessarily the index of
the corresponding entry in variant->dai_driver.

When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code
currently uses dai_id to index variant->dai_driver. This is incorrect
for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S
DAI has ID 4 while it is the only entry in the DAI driver table, so
the current code accesses dai_driver[4] instead of the DAI being
processed.

Use the loop index i when updating the current DAI's playback channel
constraints, while retaining dai_id for indexing the hardware-port
specific playback SD-line mode array.

This fixes the incorrect DAI table access for platforms where the DAI
ID does not match its position in the driver table.

Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary")
Signed-off-by: Zimeng Li <me@lizi.moe>
Assisted-by: LLM
---
Compile-tested with LLVM for ARM using multi_v7_defconfig with
CONFIG_SND_SOC_STORM=m. The lpass-cpu.o, lpass-ipq806x.o and
lpass-platform.o targets built successfully. Not hardware-tested;
the IPQ806x example is based on static analysis, not a reproduced crash.

 sound/soc/qcom/lpass-cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 242bc16da..079177a6d 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -1234,8 +1234,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
 		}
 		if (drvdata->mi2s_playback_sd_mode[dai_id] ==
 			LPAIF_I2SCTL_MODE_QUAD01) {
-			variant->dai_driver[dai_id].playback.channels_min = 4;
-			variant->dai_driver[dai_id].playback.channels_max = 4;
+			variant->dai_driver[i].playback.channels_min = 4;
+			variant->dai_driver[i].playback.channels_max = 4;
 		}
 	}
 

base-commit: 0ed6f7f62318a581fe9698f8a4e98c7ca01160e4
-- 
2.55.0

Re: [PATCH] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Srinivas Kandagatla]

On 9/20/26 3:58 PM, Zimeng Li wrote:
> The DAI ID is a hardware port ID and is not necessarily the index of
> the corresponding entry in variant->dai_driver.
> 
> When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code
> currently uses dai_id to index variant->dai_driver. This is incorrect
> for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S
> DAI has ID 4 while it is the only entry in the DAI driver table, so
> the current code accesses dai_driver[4] instead of the DAI being
> processed.

This looks like a bug, however the code has been written in assumption
that the dai_drive.

That also raises the question that was this patch actually tested on any
hardware?

> 
> Use the loop index i when updating the current DAI's playback channel
> constraints, while retaining dai_id for indexing the hardware-port
> specific playback SD-line mode array.
> 
> This fixes the incorrect DAI table access for platforms where the DAI
> ID does not match its position in the driver table.
> 
> Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary")

Cc Stable ?

> Signed-off-by: Zimeng Li <me@lizi.moe>
> Assisted-by: LLM
Can you please add the actual model name as others do.

> ---
> Compile-tested with LLVM for ARM using multi_v7_defconfig with
> CONFIG_SND_SOC_STORM=m. The lpass-cpu.o, lpass-ipq806x.o and
> lpass-platform.o targets built successfully. Not hardware-tested;
> the IPQ806x example is based on static analysis, not a reproduced crash.
> 
>  sound/soc/qcom/lpass-cpu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
> index 242bc16da..079177a6d 100644
> --- a/sound/soc/qcom/lpass-cpu.c
> +++ b/sound/soc/qcom/lpass-cpu.c
> @@ -1234,8 +1234,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
>  		}
>  		if (drvdata->mi2s_playback_sd_mode[dai_id] ==
>  			LPAIF_I2SCTL_MODE_QUAD01) {
> -			variant->dai_driver[dai_id].playback.channels_min = 4;
> -			variant->dai_driver[dai_id].playback.channels_max = 4;
> +			variant->dai_driver[i].playback.channels_min = 4;
> +			variant->dai_driver[i].playback.channels_max = 4;
>  		}
>  	}
>  
> 
> base-commit: 0ed6f7f62318a581fe9698f8a4e98c7ca01160e4

Re: [PATCH] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Zimeng Li]

Hi Srinivas,

No, I have not tested this patch on hardware. So far I have only
compile-tested the ARM objects listed below the commit message.

The IPQ806x example is based on static analysis. Its DAI table contains
one entry with hardware ID 4. If that DAI is configured for QUAD01 and
probe reaches this branch, dai_driver[dai_id] accesses beyond that
single entry. I have not reproduced this on an IPQ806x board, and I
have not found an in-tree IPQ806x DTS explicitly selecting this mode.

I do have access to a SC7180 device, but its relevant DAI table index
and hardware ID are both 1. Testing there could provide regression
coverage for the changed code, but would not exercise the sparse-ID
case.

I will add Cc stable and identify the model as
GPT-6 Astra in the Assisted-by trailer in v2.

Would regression testing on SC7180 be useful here, given that it does
not exercise the sparse-ID case? If testing on IPQ806x is required,
I currently do not have access to suitable hardware.

Thanks,
Li

Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
于2026年9月21日周一 00:05写道：
>
>
>
> On 9/20/26 3:58 PM, Zimeng Li wrote:
> > The DAI ID is a hardware port ID and is not necessarily the index of
> > the corresponding entry in variant->dai_driver.
> >
> > When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code
> > currently uses dai_id to index variant->dai_driver. This is incorrect
> > for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S
> > DAI has ID 4 while it is the only entry in the DAI driver table, so
> > the current code accesses dai_driver[4] instead of the DAI being
> > processed.
>
> This looks like a bug, however the code has been written in assumption
> that the dai_drive.
>
> That also raises the question that was this patch actually tested on any
> hardware?
>
> >
> > Use the loop index i when updating the current DAI's playback channel
> > constraints, while retaining dai_id for indexing the hardware-port
> > specific playback SD-line mode array.
> >
> > This fixes the incorrect DAI table access for platforms where the DAI
> > ID does not match its position in the driver table.
> >
> > Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary")
>
> Cc Stable ?
>
> > Signed-off-by: Zimeng Li <me@lizi.moe>
> > Assisted-by: LLM
> Can you please add the actual model name as others do.
>
> > ---
> > Compile-tested with LLVM for ARM using multi_v7_defconfig with
> > CONFIG_SND_SOC_STORM=m. The lpass-cpu.o, lpass-ipq806x.o and
> > lpass-platform.o targets built successfully. Not hardware-tested;
> > the IPQ806x example is based on static analysis, not a reproduced crash.
> >
> >  sound/soc/qcom/lpass-cpu.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
> > index 242bc16da..079177a6d 100644
> > --- a/sound/soc/qcom/lpass-cpu.c
> > +++ b/sound/soc/qcom/lpass-cpu.c
> > @@ -1234,8 +1234,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
> >               }
> >               if (drvdata->mi2s_playback_sd_mode[dai_id] ==
> >                       LPAIF_I2SCTL_MODE_QUAD01) {
> > -                     variant->dai_driver[dai_id].playback.channels_min = 4;
> > -                     variant->dai_driver[dai_id].playback.channels_max = 4;
> > +                     variant->dai_driver[i].playback.channels_min = 4;
> > +                     variant->dai_driver[i].playback.channels_max = 4;
> >               }
> >       }
> >
> >
> > base-commit: 0ed6f7f62318a581fe9698f8a4e98c7ca01160e4
>
>

Re: [PATCH] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

On Sun, Sep 20, 2026 at 05:05:48PM +0100, Srinivas Kandagatla wrote:
> On 9/20/26 3:58 PM, Zimeng Li wrote:

> > Assisted-by: LLM

> Can you please add the actual model name as others do.

The latest standard for the tag is to list what was done, not the model.
Which model isn't really the point, and people felt it was more being
used for advertising than anything else.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[PATCH v2] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Zimeng Li]

The DAI ID is a hardware port ID and is not necessarily the index of
the corresponding entry in variant->dai_driver.

When configuring a DAI with LPAIF_I2SCTL_MODE_QUAD01, the probe code
currently uses dai_id to index variant->dai_driver. This is incorrect
for platforms where DAI IDs are sparse. For example, the IPQ806x MI2S
DAI has ID 4 while it is the only entry in the DAI driver table. If
that DAI is configured for QUAD01 and probe reaches this branch, the
code writes beyond that single entry via dai_driver[4] instead of
updating the DAI being processed.

Use the loop index i when updating the current DAI's playback channel
constraints, while retaining dai_id for indexing the hardware-port
specific playback SD-line mode array.

This fixes the incorrect DAI table access for platforms where the DAI
ID does not match its position in the driver table.

Fixes: c223f41c1a52 ("ASoC: qcom: Add four speaker support on MI2S secondary")
Cc: stable@vger.kernel.org
Signed-off-by: Zimeng Li <me@lizi.moe>
Assisted-by: GPT-6 Astra
---
Changes in v2:
- Add stable to Cc.
- Identify the model in the Assisted-by trailer.
- Clarify that the IPQ806x out-of-bounds access requires QUAD01 mode
  and probe to reach the affected branch.

Compile-tested with LLVM for ARM using multi_v7_defconfig with
CONFIG_SND_SOC_STORM=m. The lpass-cpu.o, lpass-ipq806x.o and
lpass-platform.o targets built successfully. Not hardware-tested;
the IPQ806x example is based on static analysis, not a reproduced crash.
The code change is unchanged from v1.

 sound/soc/qcom/lpass-cpu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 242bc16da..079177a6d 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -1234,8 +1234,8 @@ int asoc_qcom_lpass_cpu_platform_probe(struct platform_device *pdev)
 		}
 		if (drvdata->mi2s_playback_sd_mode[dai_id] ==
 			LPAIF_I2SCTL_MODE_QUAD01) {
-			variant->dai_driver[dai_id].playback.channels_min = 4;
-			variant->dai_driver[dai_id].playback.channels_max = 4;
+			variant->dai_driver[i].playback.channels_min = 4;
+			variant->dai_driver[i].playback.channels_max = 4;
 		}
 	}
 

base-commit: 0ed6f7f62318a581fe9698f8a4e98c7ca01160e4
-- 
2.55.0

Re: [PATCH v2] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

On Mon, Sep 21, 2026 at 03:38:30AM +0800, Zimeng Li wrote:
> The DAI ID is a hardware port ID and is not necessarily the index of
> the corresponding entry in variant->dai_driver.

Please don't send new patches in reply to old patches or serieses, this
makes it harder for both people and tools to understand what is going
on - it can bury things in mailboxes and make it difficult to keep track
of what current patches are, both for the new patches and the old ones.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH v2] ASoC: qcom: lpass-cpu: use DAI table index for playback constraints

[Li Tadokoro]

Sorry about that. I'll send future revisions as new threads.

Li

Mark Brown <broonie@kernel.org> 于2026年9月21日周一 16:27写道：
>
> On Mon, Sep 21, 2026 at 03:38:30AM +0800, Zimeng Li wrote:
> > The DAI ID is a hardware port ID and is not necessarily the index of
> > the corresponding entry in variant->dai_driver.
>
> Please don't send new patches in reply to old patches or serieses, this
> makes it harder for both people and tools to understand what is going
> on - it can bury things in mailboxes and make it difficult to keep track
> of what current patches are, both for the new patches and the old ones.