[RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[Val Packett]

When setting the model property for the sound card on an OF/DT system,
the expectation is that that model name would be used in the UCM config
path lookup. However, the DT model name was only used as the "short"
name, which gets overriden by the "long" name during loading, and
the "long" name is automatically set based on DMI data if available.
As a result, adding an intermediate bootloader such as U-Boot which
provides DMI data on a device that didn't have it before would break
the UCM config loading by suddenly looking at the "wrong" path.

Fix by assigning the DT model name to the long_name field as well.

Signed-off-by: Val Packett <val@packett.cool>
---

For more context/examples, see:
https://gitlab.postmarketos.org/postmarketOS/pmaports/-/work_items/4386

err, for some reason that link requires an account to view right now,
hopefully that's fixed by the time you're reading this. if not, quoting:

> ALSA looks for wrong device name when using U-Boot
> 
> What's the expected behaviour?
>   ALSA finds Fairphone 5.conf
> What's the current behaviour?
>   ALSA looks for fairphone-Fairphone5-.conf, doesn't find it, and results in no audio.

("Fairphone 5.conf" coming from `model = "Fairphone 5";` in .dts)

So it's totally unexpected in the DT world that adding DMI info would
change which UCM path is used.

Now the question is, could this possibly break anything for anyone???..

Qcom laptops do not rely on these model-based paths at all, instead
having custom DMI match `If` conditions inside of "fallback" SoC-wide
UCM .conf files such as:
https://github.com/alsa-project/alsa-ucm-conf/blob/980fb83651e82c3e53d3a0ab7fa9b7d6fc2d809b/ucm2/Qualcomm/x1e80100/x1e80100.conf

So there it shouldn't make a difference. But does *anyone* use DMI-based
soundcard names intentionally on *any* DT platform?


Thanks,
~val

P.S. I don't understand the lifecycle of these strings but it seeeems that
the expectation is that they point to static data so they're never freed?

---
 sound/soc/soc-core.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 3fecf9fc903c..8456595bb41d 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2995,6 +2995,14 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
 		return ret;
 	}
 
+	/*
+	 * When setting the OF property in a device tree, the expectation is
+	 * that the UCM config matching the value would be loaded. However if
+	 * a long_name is set, it would be used in the config path instead, and
+	 * snd_soc_set_dmi_name sets long_name to the DMI name if it's unset.
+	 */
+	card->long_name = card->name;
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name);
-- 
2.53.0

Re: [RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[Clayton Craft]

On Tue May 5, 2026 at 8:58 PM PDT, Val Packett wrote:
> When setting the model property for the sound card on an OF/DT system,
> the expectation is that that model name would be used in the UCM config
> path lookup. However, the DT model name was only used as the "short"
> name, which gets overriden by the "long" name during loading, and
> the "long" name is automatically set based on DMI data if available.
> As a result, adding an intermediate bootloader such as U-Boot which
> provides DMI data on a device that didn't have it before would break
> the UCM config loading by suddenly looking at the "wrong" path.
>
> Fix by assigning the DT model name to the long_name field as well.
>
> Signed-off-by: Val Packett <val@packett.cool>
> ---

Thanks for the patch! This fixed audio on my Google Pixel 3a, which booted the
7.1.3 kernel (on postmarketOS) via u-boot.

-Clayton

Tested-by: Clayton Craft <craftyguy@postmarketos.org>

Re: [RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[David Heidelberg]

On 06/05/2026 05:58, Val Packett wrote:
> When setting the model property for the sound card on an OF/DT system,
> the expectation is that that model name would be used in the UCM config
> path lookup. However, the DT model name was only used as the "short"
> name, which gets overriden by the "long" name during loading, and
> the "long" name is automatically set based on DMI data if available.
> As a result, adding an intermediate bootloader such as U-Boot which
> provides DMI data on a device that didn't have it before would break
> the UCM config loading by suddenly looking at the "wrong" path.
> 
> Fix by assigning the DT model name to the long_name field as well.
> 
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> 
> For more context/examples, see:
> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/work_items/4386
> 
> err, for some reason that link requires an account to view right now,
> hopefully that's fixed by the time you're reading this. if not, quoting:
> 
>> ALSA looks for wrong device name when using U-Boot
>>
>> What's the expected behaviour?
>>    ALSA finds Fairphone 5.conf
>> What's the current behaviour?
>>    ALSA looks for fairphone-Fairphone5-.conf, doesn't find it, and results in no audio.
> 
> ("Fairphone 5.conf" coming from `model = "Fairphone 5";` in .dts)
> 
> So it's totally unexpected in the DT world that adding DMI info would
> change which UCM path is used.
> 
> Now the question is, could this possibly break anything for anyone???..
> 
> Qcom laptops do not rely on these model-based paths at all, instead
> having custom DMI match `If` conditions inside of "fallback" SoC-wide
> UCM .conf files such as:
> https://github.com/alsa-project/alsa-ucm-conf/blob/980fb83651e82c3e53d3a0ab7fa9b7d6fc2d809b/ucm2/Qualcomm/x1e80100/x1e80100.conf
> 
> So there it shouldn't make a difference. But does *anyone* use DMI-based
> soundcard names intentionally on *any* DT platform?
> 
> 
> Thanks,
> ~val
> 
> P.S. I don't understand the lifecycle of these strings but it seeeems that
> the expectation is that they point to static data so they're never freed?
> 
> ---
>   sound/soc/soc-core.c | 8 ++++++++
>   1 file changed, 8 insertions(+)
> 
Would be great to hear what what maintainers think about this, this causing some 
level of unpleasantness.

Also there is my slightly related question about the DT `model` property naming [1].

Thanks
David

[1] https://lore.kernel.org/all/c5773a71-e7f0-44ae-8418-1e00de16d08f@ixit.cz/

Re: [RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[Guido Günther]

Hi,
On Wed, May 06, 2026 at 12:58:55AM -0300, Val Packett wrote:
> When setting the model property for the sound card on an OF/DT system,
> the expectation is that that model name would be used in the UCM config
> path lookup. However, the DT model name was only used as the "short"
> name, which gets overriden by the "long" name during loading, and
> the "long" name is automatically set based on DMI data if available.
> As a result, adding an intermediate bootloader such as U-Boot which
> provides DMI data on a device that didn't have it before would break
> the UCM config loading by suddenly looking at the "wrong" path.
> 
> Fix by assigning the DT model name to the long_name field as well.
> 
> Signed-off-by: Val Packett <val@packett.cool>
> ---
> 
> For more context/examples, see:
> https://gitlab.postmarketos.org/postmarketOS/pmaports/-/work_items/4386
> 
> err, for some reason that link requires an account to view right now,
> hopefully that's fixed by the time you're reading this. if not, quoting:
> 
> > ALSA looks for wrong device name when using U-Boot
> > 
> > What's the expected behaviour?
> >   ALSA finds Fairphone 5.conf
> > What's the current behaviour?
> >   ALSA looks for fairphone-Fairphone5-.conf, doesn't find it, and results in no audio.
> 
> ("Fairphone 5.conf" coming from `model = "Fairphone 5";` in .dts)
> 
> So it's totally unexpected in the DT world that adding DMI info would
> change which UCM path is used.
> 
> Now the question is, could this possibly break anything for anyone???..
> 
> Qcom laptops do not rely on these model-based paths at all, instead
> having custom DMI match `If` conditions inside of "fallback" SoC-wide
> UCM .conf files such as:
> https://github.com/alsa-project/alsa-ucm-conf/blob/980fb83651e82c3e53d3a0ab7fa9b7d6fc2d809b/ucm2/Qualcomm/x1e80100/x1e80100.conf
> 
> So there it shouldn't make a difference. But does *anyone* use DMI-based
> soundcard names intentionally on *any* DT platform?

Would be great to have some guidance from the subsystem / alsa ucm
maintainers as multiple distros are patching around it atm (either with
this patch or symlinks in the ucm profiles).

Cheers,
 -- Guido

> 
> 
> Thanks,
> ~val
> 
> P.S. I don't understand the lifecycle of these strings but it seeeems that
> the expectation is that they point to static data so they're never freed?
> 
> ---
>  sound/soc/soc-core.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 3fecf9fc903c..8456595bb41d 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -2995,6 +2995,14 @@ int snd_soc_of_parse_card_name(struct snd_soc_card *card,
>  		return ret;
>  	}
>  
> +	/*
> +	 * When setting the OF property in a device tree, the expectation is
> +	 * that the UCM config matching the value would be loaded. However if
> +	 * a long_name is set, it would be used in the config path instead, and
> +	 * snd_soc_set_dmi_name sets long_name to the DMI name if it's unset.
> +	 */
> +	card->long_name = card->name;
> +
>  	return 0;
>  }
>  EXPORT_SYMBOL_GPL(snd_soc_of_parse_card_name);
> -- 
> 2.53.0
> 

Re: [RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[Mark Brown]

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

On Mon, Sep 14, 2026 at 01:00:49PM +0200, Guido Günther wrote:
> On Wed, May 06, 2026 at 12:58:55AM -0300, Val Packett wrote:
> > When setting the model property for the sound card on an OF/DT system,
> > the expectation is that that model name would be used in the UCM config
> > path lookup. However, the DT model name was only used as the "short"
> > name, which gets overriden by the "long" name during loading, and
> > the "long" name is automatically set based on DMI data if available.
> > As a result, adding an intermediate bootloader such as U-Boot which
> > provides DMI data on a device that didn't have it before would break
> > the UCM config loading by suddenly looking at the "wrong" path.

> > Fix by assigning the DT model name to the long_name field as well.

I'm not convinced that there is a clear expectation here, any change
will doubtless upset some other user (for example someone using a system
derived from a reference board that happens to work with it's device
tree, or something where the firmware puts discovered information into
DMI).  Really you're just not supposed to combine DMI and DT based
discovery methods, having a system shipping both is just going to lead
to confusion and there's no way we can possibly get it right.  You have
decided that for your systems the DMI information is bad and you want to
override it but that doesn't mean that the next person won't make the
opposite choice.  Any decision here should be policy based in userspace
based on the full system information.

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.

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

Re: [RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[Guido Günther]

Hi Mark,
On Mon, Sep 14, 2026 at 12:19:15PM +0100, Mark Brown wrote:
> On Mon, Sep 14, 2026 at 01:00:49PM +0200, Guido Günther wrote:
> > On Wed, May 06, 2026 at 12:58:55AM -0300, Val Packett wrote:
> > > When setting the model property for the sound card on an OF/DT system,
> > > the expectation is that that model name would be used in the UCM config
> > > path lookup. However, the DT model name was only used as the "short"
> > > name, which gets overriden by the "long" name during loading, and
> > > the "long" name is automatically set based on DMI data if available.
> > > As a result, adding an intermediate bootloader such as U-Boot which
> > > provides DMI data on a device that didn't have it before would break
> > > the UCM config loading by suddenly looking at the "wrong" path.
> 
> > > Fix by assigning the DT model name to the long_name field as well.
> 
> I'm not convinced that there is a clear expectation here, any change
> will doubtless upset some other user (for example someone using a system
> derived from a reference board that happens to work with it's device
> tree, or something where the firmware puts discovered information into
> DMI).  Really you're just not supposed to combine DMI and DT based
> discovery methods, having a system shipping both is just going to lead
> to confusion and there's no way we can possibly get it right.  You have
> decided that for your systems the DMI information is bad and you want to
> override it but that doesn't mean that the next person won't make the
> opposite choice.  Any decision here should be policy based in userspace
> based on the full system information.

Thanks for the hint. So that would mean we should do something similar
to what Lenovo does in UCM (that Val pointed to)?

https://github.com/alsa-project/alsa-ucm-conf/blob/980fb83651e82c3e53d3a0ab7fa9b7d6fc2d809b/ucm2/Qualcomm/x1e80100/x1e80100.conf

> 
> Please don't send content free pings and please allow a reasonable time
> for review.  People get busy, go on holiday, attend conferences and so 
> on so unless there is some reason for urgency (like critical bug fixes)
> please allow at least a couple of weeks for review.  If there have been
> review comments then people may be waiting for those to be addressed.

The original mail was from May so I figured ~ half a year would be o.k.?
Sorry I got that wrong.

Cheers,
 -- Guido

Re: [RFC PATCH] ASoC: soc-core: use the device tree card name as long_name

[Mark Brown]

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

On Mon, Sep 14, 2026 at 01:34:24PM +0200, Guido Günther wrote:
> On Mon, Sep 14, 2026 at 12:19:15PM +0100, Mark Brown wrote:

> > opposite choice.  Any decision here should be policy based in userspace
> > based on the full system information.

> Thanks for the hint. So that would mean we should do something similar
> to what Lenovo does in UCM (that Val pointed to)?

> https://github.com/alsa-project/alsa-ucm-conf/blob/980fb83651e82c3e53d3a0ab7fa9b7d6fc2d809b/ucm2/Qualcomm/x1e80100/x1e80100.conf

That looks plausibe, or possibly some more generic thing that teaches
UCM about when to use DMI.

> > Please don't send content free pings and please allow a reasonable time
> > for review.  People get busy, go on holiday, attend conferences and so 
> > on so unless there is some reason for urgency (like critical bug fixes)
> > please allow at least a couple of weeks for review.  If there have been
> > review comments then people may be waiting for those to be addressed.

> The original mail was from May so I figured ~ half a year would be o.k.?
> Sorry I got that wrong.

Note the bit in the mail about resending if you think things have been
dropped.

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