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 <[email protected]> > --- > > 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 >
