public inbox for linux-sound@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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