sound/hda/controllers/intel.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)
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>
---
sound/hda/controllers/intel.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/sound/hda/controllers/intel.c b/sound/hda/controllers/intel.c
index 2edbcab597c8..8a7bd49e411f 100644
--- a/sound/hda/controllers/intel.c
+++ b/sound/hda/controllers/intel.c
@@ -2085,6 +2085,11 @@ static struct pci_device_id driver_denylist_ideapad_z570[] = {
{}
};
+static struct pci_device_id driver_denylist_msi_x870e[] = {
+ { PCI_DEVICE_SUB(0x1022, 0x15e3, 0x1462, 0xee59) }, /* MSI X870E Tomahawk WiFi */
+ {}
+};
+
/* DMI-based denylist, to be used when:
* - PCI subsystem IDs are zero, impossible to distinguish from valid sound cards.
* - Different modifications of the same laptop use different GPU models.
@@ -2098,6 +2103,14 @@ static const struct dmi_system_id driver_denylist_dmi[] = {
},
.driver_data = &driver_denylist_ideapad_z570,
},
+ {
+ /* PCI device matching alone incorrectly matches some laptops */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
+ DMI_MATCH(DMI_BOARD_NAME, "MAG X870E TOMAHAWK WIFI (MS-7E59)"),
+ },
+ .driver_data = &driver_denylist_msi_x870e,
+ },
{}
};
--
2.53.0
On Fri, 27 Mar 2026 16:57:36 +0100, 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> Although this could be addressed in BIOS, it won't hurt much to take a workaround for now. So I applied this one. thanks, Takashi
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?
> ---
> sound/hda/controllers/intel.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/sound/hda/controllers/intel.c b/sound/hda/controllers/intel.c
> index 2edbcab597c8..8a7bd49e411f 100644
> --- a/sound/hda/controllers/intel.c
> +++ b/sound/hda/controllers/intel.c
> @@ -2085,6 +2085,11 @@ static struct pci_device_id driver_denylist_ideapad_z570[] = {
> {}
> };
>
> +static struct pci_device_id driver_denylist_msi_x870e[] = {
> + { PCI_DEVICE_SUB(0x1022, 0x15e3, 0x1462, 0xee59) }, /* MSI X870E Tomahawk WiFi */
> + {}
> +};
> +
> /* DMI-based denylist, to be used when:
> * - PCI subsystem IDs are zero, impossible to distinguish from valid sound cards.
> * - Different modifications of the same laptop use different GPU models.
> @@ -2098,6 +2103,14 @@ static const struct dmi_system_id driver_denylist_dmi[] = {
> },
> .driver_data = &driver_denylist_ideapad_z570,
> },
> + {
> + /* PCI device matching alone incorrectly matches some laptops */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Micro-Star International Co., Ltd."),
> + DMI_MATCH(DMI_BOARD_NAME, "MAG X870E TOMAHAWK WIFI (MS-7E59)"),
> + },
> + .driver_data = &driver_denylist_msi_x870e,
> + },
> {}
> };
>
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
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.
> If you end up having a good experience that could be the way we approach > this problem in the future. I can certainly try, but I've already got a pile of issues stacking up that they don't seem to be interested in fixing. Hopefully this will be a simpler fix for them than the other issues...
© 2016 - 2026 Red Hat, Inc.