[PATCH v2] ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays

[PATCH v2] ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays

[Sen Wang]

graph_util_is_ports0() identifies DPCM front-end (ports@0) vs back-end
(ports@1) by calling of_get_child_by_name() to find the first "ports"
child and comparing pointers. This relies on child iteration order
matching DTS source order.

When the DPCM topology comes from a DT overlay, __of_attach_node()
inserts new children at the head of the sibling list, reversing the
order. of_get_child_by_name() then returns ports@1 instead of ports@0,
causing all front-end links to be classified as back-ends. The card
registers with no PCM devices.

Fix this by matching the unit address directly from the node name
instead of relying on sibling order.

Fixes: 92939252458f ("ASoC: simple-card-utils: add asoc_graph_is_ports0()")
Signed-off-by: Sen Wang <sen@ti.com>
---
Changes in v2:
 - Updated code comment with rationale for string matching approach

 sound/soc/generic/simple-card-utils.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/sound/soc/generic/simple-card-utils.c b/sound/soc/generic/simple-card-utils.c
index bdc02e85b089..9e5be0eaa77f 100644
--- a/sound/soc/generic/simple-card-utils.c
+++ b/sound/soc/generic/simple-card-utils.c
@@ -1038,11 +1038,15 @@ int graph_util_is_ports0(struct device_node *np)
 	else
 		port = np;
 
-	struct device_node *ports  __free(device_node) = of_get_parent(port);
-	struct device_node *top    __free(device_node) = of_get_parent(ports);
-	struct device_node *ports0 __free(device_node) = of_get_child_by_name(top, "ports");
+	struct device_node *ports __free(device_node) = of_get_parent(port);
+	const char *at = strchr(kbasename(ports->full_name), '@');
 
-	return ports0 == ports;
+	/*
+	 * Since child iteration order may differ
+	 * between a base DT and DT overlays,
+	 * string match "ports" or "ports@0" in the node name instead.
+	 */
+	return !at || !strcmp(at, "@0");
 }
 EXPORT_SYMBOL_GPL(graph_util_is_ports0);
 
-- 
2.43.0

Re: [PATCH v2] ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays

[Kuninori Morimoto]

Hi Sen

> graph_util_is_ports0() identifies DPCM front-end (ports@0) vs back-end
> (ports@1) by calling of_get_child_by_name() to find the first "ports"
> child and comparing pointers. This relies on child iteration order
> matching DTS source order.
> 
> When the DPCM topology comes from a DT overlay, __of_attach_node()
> inserts new children at the head of the sibling list, reversing the
> order. of_get_child_by_name() then returns ports@1 instead of ports@0,
> causing all front-end links to be classified as back-ends. The card
> registers with no PCM devices.
> 
> Fix this by matching the unit address directly from the node name
> instead of relying on sibling order.
> 
> Fixes: 92939252458f ("ASoC: simple-card-utils: add asoc_graph_is_ports0()")
> Signed-off-by: Sen Wang <sen@ti.com>
> ---

Acked-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>


Thank you for your help !!

Best regards
---
Kuninori Morimoto

Re: [PATCH v2] ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays

[Mark Brown]

On Sun, 08 Mar 2026 23:21:09 -0500, Sen Wang wrote:
> graph_util_is_ports0() identifies DPCM front-end (ports@0) vs back-end
> (ports@1) by calling of_get_child_by_name() to find the first "ports"
> child and comparing pointers. This relies on child iteration order
> matching DTS source order.
> 
> When the DPCM topology comes from a DT overlay, __of_attach_node()
> inserts new children at the head of the sibling list, reversing the
> order. of_get_child_by_name() then returns ports@1 instead of ports@0,
> causing all front-end links to be classified as back-ends. The card
> registers with no PCM devices.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: simple-card-utils: fix graph_util_is_ports0() for DT overlays
      commit: 4185b95f8a42d92d68c49289b4644546b51e252b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark