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

["Guido Günther" <agx@sigxcpu.org>]

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
>