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

[Mark Brown <broonie@kernel.org>]

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