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
