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

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

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