From: Mario Limonciello <mario.limonciello@amd.com>
To: Takashi Iwai <tiwai@suse.de>
Cc: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>,
linux-sound@vger.kernel.org, Takashi Iwai <tiwai@suse.com>,
linux-kernel@vger.kernel.org, Jaroslav Kysela <perex@perex.cz>
Subject: Re: [PATCH] ALSA: hda/intel: Add MSI X870E Tomahawk to denylist by DMI ID
Date: Fri, 27 Mar 2026 11:52:33 -0500 [thread overview]
Message-ID: <8cd14428-24a9-45fd-9286-9d9f142b32b1@amd.com> (raw)
In-Reply-To: <87zf3tp6p4.wl-tiwai@suse.de>
On 3/27/26 11:39, Takashi Iwai wrote:
> On Fri, 27 Mar 2026 17:15:38 +0100,
> Mario Limonciello wrote:
>>
>>
>>
>> On 3/27/26 10:57, Stuart Hayhurst wrote:
>>> This motherboard uses USB audio instead, causing this driver to complain
>>> about "no codecs found!".
>>> Add it to the denylist to silence the warning.
>>>
>>> The first attempt only matched on the PCI device, but this caused issues
>>> for some laptops, so DMI match against the board as well.
>>>
>>> Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
>>
>> Thanks!
>>
>> Takashi,
>>
>> Probably worth asking - why is the "no codecs found" ERR in the first
>> place? There are obviously designs out there like this, should the
>> ERR message be simmered down?
>
> Although HD-audio is a bus that can be dynamically enabled / disabled
> codecs, it's been supposed to be rather static and exposed only if
> there is really a need for it -- that is, only if there is a codec on
> it. So "no codec" is seen as an error for now if you try to
> initialize the HD-audio controller.
>
> We may downgrade it, but the situation is still not ideal either; the
> driver is still bound without serving anything useful, and it needs to
> react for the PM and other things. Since the probe of codecs happens
> after the driver probe stage, the driver can't go away by itself,
> unfortunately.
>
>
> thanks,
>
> Takashi
I guess in an ideal world systems like this (where physically there is
USB audio and HD audio, but HD audio has no codecs connected to it)
the BIOS should avoid exposing the HD audio device on the PCI bus.
Stuart,
In parallel could you try spinning up a thread with your MB vendor? If
they're willing, maybe a future BIOS can also stop exposing the HD audio
PCI device.
If you end up having a good experience that could be the way we approach
this problem in the future.
next prev parent reply other threads:[~2026-03-27 16:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-27 15:57 [PATCH] ALSA: hda/intel: Add MSI X870E Tomahawk to denylist by DMI ID Stuart Hayhurst
2026-03-27 16:15 ` Mario Limonciello
2026-03-27 16:39 ` Takashi Iwai
2026-03-27 16:52 ` Mario Limonciello [this message]
2026-03-27 17:35 ` Stuart
2026-04-14 13:06 ` Stuart
2026-03-28 9:36 ` Takashi Iwai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8cd14428-24a9-45fd-9286-9d9f142b32b1@amd.com \
--to=mario.limonciello@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=perex@perex.cz \
--cc=stuart.a.hayhurst@gmail.com \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox