ASoC: partial match the sdca codec name by bardliao · Pull Request #5664 · thesofproject/linux

bardliao · 2026-02-06T03:13:01Z

Currently, we set a predefined codec component name in a DAI link. But the codec name may contain an index which is not fixed. This series suggest using partial match the codec name to fix the issue.

charleskeepax · 2026-02-06T11:23:43Z

sound/soc/sdw_utils/soc_sdw_utils.c

+	if (dai_info->codec_name) {
+		struct snd_soc_component *component;
+
+		component = snd_soc_lookup_component_by_name(dai_info->codec_name);


Can we be sure the component exists by this point?

Can we be sure the component exists by this point?

No, but in theory, the function will be called again when the component probed and be registered.

charleskeepax · 2026-02-06T11:57:36Z

Ok well it mostly works for me, will investigate the probe concerns a little more. One thing that is missing though is the handling of aux devices on the link, we added very basic support for this for the HID device and it would also need renaming.

bardliao · 2026-02-06T12:48:44Z

Ok well it mostly works for me, will investigate the probe concerns a little more. One thing that is missing though is the handling of aux devices on the link, we added very basic support for this for the HID device and it would also need renaming.

Oh, yes, I missed soc_aux->dlc.name.

charleskeepax

Ok I think this looks good to me and it tests out fine on my setup here even with the function disabled as it is on the customer system.
EDIT: Also thank you very much for having a look at this, been quite slammed at the moment and it's a big help.

ujfalusi

@bardliao and how we are going to find the other codec?
snd_soc_sdca.UAJ.1, snd_soc_sdca.UAJ.2 and we are looking for snd_soc_sdca.UAJ if I got the idea right.

ujfalusi · 2026-02-10T07:49:15Z

sound/soc/soc-core.c

+	struct snd_soc_component *component;
+
+	mutex_lock(&client_mutex);
+	component = snd_soc_lookup_component_by_name_nolocked(component_name);


I don't think this helps much in readability, just move the for_each... here
and use guard(mutex)(&client_mutex); instead of the manual lock/unlock, it takes care of unlock at returns

bardliao · 2026-02-10T09:01:48Z

@bardliao and how we are going to find the other codec? snd_soc_sdca.UAJ.1, snd_soc_sdca.UAJ.2 and we are looking for snd_soc_sdca.UAJ if I got the idea right.

For now, we will have only one device for each SDCA function. We will figure out how to handle the case when it really happens.

Add a helper to help user to get the component by name. Signed-off-by: Bard Liao <[email protected]>

Currently, we can set codec name in the dai info which will be set as the codec component name in a DAI link. However, the codec name may not be fixed. For example, there is an index in a SDCA codec name and that is not fixed. Lookup the fixed codec name string from the component list to get the right component name to ensure the DAI link will bind to the right codec component. Signed-off-by: Bard Liao <[email protected]>

The index is not fixed and it will lead to the DAI link can't bind the codec component with the name when the index is different from the predefined one. Signed-off-by: Bard Liao <[email protected]>

ujfalusi · 2026-02-10T10:58:29Z

@bardliao and how we are going to find the other codec? snd_soc_sdca.UAJ.1, snd_soc_sdca.UAJ.2 and we are looking for snd_soc_sdca.UAJ if I got the idea right.

For now, we will have only one device for each SDCA function. We will figure out how to handle the case when it really happens.

Hrm, so is it like that there is only a single codec with a unique name with a random number tossed to it's name for whatever reason?

bardliao · 2026-02-10T11:07:35Z

Hrm, so is it like that there is only a single codec with a unique name with a random number tossed to it's name for whatever reason?

Yes, but the number is not random. I think it is the order of the function being listed in the DisCo table. @charleskeepax Please correct me if I am wrong.

charleskeepax · 2026-02-11T10:04:33Z

Yeah its an IDA in the SDCA auxiliary, typically it will be the order things are registered although I don't think that is guaranteed if drivers are removed and added.

ujfalusi · 2026-02-11T12:14:01Z

Yeah its an IDA in the SDCA auxiliary, typically it will be the order things are registered although I don't think that is guaranteed if drivers are removed and added.

Right, but can we have snd_soc_sdca.UAJ.1, snd_soc_sdca.UAJ.2 in the system, so same name with different number tossed in?
How would that work?

charleskeepax · 2026-02-11T15:04:45Z

As Bard notes it won't with the current code, but we don't currently have any devices doing that. We likely will in the future but we are hoping to save that problem for another day.

ujfalusi · 2026-02-11T15:14:28Z

As Bard notes it won't with the current code, but we don't currently have any devices doing that. We likely will in the future but we are hoping to save that problem for another day.

I'm perfectly aware that we won't with the current code, I'm asking if is this a valid concern or just a perfectionists problem.
No idea what UAJ stands for, so no idea what this function is for, but if it is a function then it can be a jack and we can have several jacks.

charleskeepax · 2026-02-11T15:27:55Z

No, it's a real problem. UAJ stands for Universal Audio Jack, it is one of several functions that can exist on an SDCA audio part. Parts can have multiple functions and there are no rules against a part having multiple instances of the same function, say in the UAJ case this might be a part that supported dual jack sockets. There are currently no parts supported by the SDCA driver that have duplicate functions, but it is likely there will be in the future.

ranj063 · 2026-02-11T18:36:11Z

sound/soc/sdw_utils/soc_sdw_utils.c

 {
-	if (dai_info->codec_name)
-		return devm_kstrdup(dev, dai_info->codec_name, GFP_KERNEL);
+	if (dai_info->codec_name) {


what is the "partial match" you mention in your commit in the code?

I removed the index from the codec_name, and use the partial codec name to match the component name.

bardliao · 2026-02-12T02:21:59Z

@ujfalusi I understand that we will need to handle the duplicate function case sometime in the future. But this PR can buy us some time to solve the current issue. Unless we can find a way to handle the duplicate function case shortly, otherwise I would suggest that we go with the solution to unblock the OEM release.

plbossart · 2026-02-13T17:40:11Z

sound/soc/sdw_utils/soc_sdw_utils.c

+			       __func__, component->name, dai_info->codec_name);
+			return devm_kstrdup(dev, component->name, GFP_KERNEL);
+		} else {
+			return devm_kstrdup(dev, dai_info->codec_name, GFP_KERNEL);


it'd be worth having a real example to show the old behavior and the new behavior...

In the next path you use "snd_soc_sdca.UAJ.1" and remove the trailing index, but that doesn't tell us how the component->name is brought in the picture on line 1225

bardliao requested review from charleskeepax, ranj063 and ujfalusi February 6, 2026 03:13

bardliao requested review from dbaluta, kv2019i, lgirdwood and plbossart as code owners February 6, 2026 03:13

charleskeepax reviewed Feb 6, 2026

View reviewed changes

bardliao force-pushed the sdca_codec_name_index branch from 3495316 to e4b195e Compare February 6, 2026 13:16

bardliao requested a review from charleskeepax February 6, 2026 13:17

charleskeepax previously approved these changes Feb 6, 2026

View reviewed changes

ujfalusi reviewed Feb 10, 2026

View reviewed changes

bardliao added 3 commits February 10, 2026 17:37

ASoC: add snd_soc_lookup_component_by_name helper

22b8a7e

Add a helper to help user to get the component by name. Signed-off-by: Bard Liao <[email protected]>

ASoC: soc_sdw_utils: remove index from sdca codec name

0f09026

The index is not fixed and it will lead to the DAI link can't bind the codec component with the name when the index is different from the predefined one. Signed-off-by: Bard Liao <[email protected]>

bardliao dismissed charleskeepax’s stale review via 0f09026 February 10, 2026 09:38

bardliao force-pushed the sdca_codec_name_index branch from e4b195e to 0f09026 Compare February 10, 2026 09:38

charleskeepax approved these changes Feb 11, 2026

View reviewed changes

bardliao requested a review from ujfalusi February 11, 2026 11:03

ranj063 reviewed Feb 11, 2026

View reviewed changes

plbossart reviewed Feb 13, 2026

View reviewed changes

Conversation

bardliao commented Feb 6, 2026

Uh oh!

charleskeepax Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

bardliao Feb 6, 2026

Choose a reason for hiding this comment

Uh oh!

charleskeepax commented Feb 6, 2026

Uh oh!

bardliao commented Feb 6, 2026

Uh oh!

charleskeepax left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ujfalusi left a comment

Choose a reason for hiding this comment

Uh oh!

ujfalusi Feb 10, 2026

Choose a reason for hiding this comment

Uh oh!

bardliao commented Feb 10, 2026

Uh oh!

ujfalusi commented Feb 10, 2026

Uh oh!

bardliao commented Feb 10, 2026

Uh oh!

charleskeepax commented Feb 11, 2026

Uh oh!

ujfalusi commented Feb 11, 2026

Uh oh!

charleskeepax commented Feb 11, 2026

Uh oh!

ujfalusi commented Feb 11, 2026

Uh oh!

charleskeepax commented Feb 11, 2026

Uh oh!

ranj063 Feb 11, 2026

Choose a reason for hiding this comment

Uh oh!

bardliao Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

bardliao commented Feb 12, 2026

Uh oh!

plbossart Feb 13, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

charleskeepax left a comment •

edited

Loading