From: Hasun Park <hasunpark@gmail.com>
Some ASUS ProArt PX13 systems expose ACP ACPI config flags that can
select a non-working fallback path.
Add a DMI override in snd_amd_acp_find_config() for ACP70+ boards and
return 0 so ACP ACPI flag-based selection is skipped on this platform.
This keeps machine driver selection on the intended SoundWire path.
Signed-off-by: Hasun Park <hasunpark@gmail.com>
---
sound/soc/amd/acp-config.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/sound/soc/amd/acp-config.c b/sound/soc/amd/acp-config.c
index 365209ea53f3..1604ed679224 100644
--- a/sound/soc/amd/acp-config.c
+++ b/sound/soc/amd/acp-config.c
@@ -23,6 +23,16 @@
static int acp_quirk_data;
+static const struct dmi_system_id acp70_acpi_flag_override_table[] = {
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HN7306EA"),
+ },
+ },
+ {}
+};
+
static const struct config_entry config_table[] = {
{
.flags = FLAG_AMD_SOF,
@@ -186,8 +196,11 @@ int snd_amd_acp_find_config(struct pci_dev *pci)
*/
if (!pci->revision)
return 0;
- else if (pci->revision >= ACP_7_0_REV)
+ else if (pci->revision >= ACP_7_0_REV) {
+ if (dmi_check_system(acp70_acpi_flag_override_table))
+ return 0;
return snd_amd_acp_acpi_find_config(pci);
+ }
for (i = 0; i < ARRAY_SIZE(config_table); i++, table++) {
if (table->device != device)
--
2.53.0
On 08/03/26 20:46, hasunpark@gmail.com wrote:
> [You don't often get email from hasunpark@gmail.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> From: Hasun Park <hasunpark@gmail.com>
>
> Some ASUS ProArt PX13 systems expose ACP ACPI config flags that can
> select a non-working fallback path.
>
> Add a DMI override in snd_amd_acp_find_config() for ACP70+ boards and
> return 0 so ACP ACPI flag-based selection is skipped on this platform.
>
> This keeps machine driver selection on the intended SoundWire path.
This patch should be dropped.
To avoid overgrowing DMI quirks table, we have introduced "acp-audio-config-flag"
which should be updated based on platform hw configuration and required driver
solution to be loaded.
ASUS has to update the BIOS by changing "acp-audio-config-flag" to zero.
>
> Signed-off-by: Hasun Park <hasunpark@gmail.com>
> ---
> sound/soc/amd/acp-config.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/amd/acp-config.c b/sound/soc/amd/acp-config.c
> index 365209ea53f3..1604ed679224 100644
> --- a/sound/soc/amd/acp-config.c
> +++ b/sound/soc/amd/acp-config.c
> @@ -23,6 +23,16 @@
>
> static int acp_quirk_data;
>
> +static const struct dmi_system_id acp70_acpi_flag_override_table[] = {
> + {
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK COMPUTER INC."),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HN7306EA"),
> + },
> + },
> + {}
> +};
> +
> static const struct config_entry config_table[] = {
> {
> .flags = FLAG_AMD_SOF,
> @@ -186,8 +196,11 @@ int snd_amd_acp_find_config(struct pci_dev *pci)
> */
> if (!pci->revision)
> return 0;
> - else if (pci->revision >= ACP_7_0_REV)
> + else if (pci->revision >= ACP_7_0_REV) {
> + if (dmi_check_system(acp70_acpi_flag_override_table))
> + return 0;
> return snd_amd_acp_acpi_find_config(pci);
> + }
>
> for (i = 0; i < ARRAY_SIZE(config_table); i++, table++) {
> if (table->device != device)
> --
> 2.53.0
>
On Mon, Mar 09, 2026 at 11:03:21AM +0530, Mukunda,Vijendar wrote: > On 08/03/26 20:46, hasunpark@gmail.com wrote: > > Add a DMI override in snd_amd_acp_find_config() for ACP70+ boards and > > return 0 so ACP ACPI flag-based selection is skipped on this platform. > This patch should be dropped. > To avoid overgrowing DMI quirks table, we have introduced "acp-audio-config-flag" > which should be updated based on platform hw configuration and required driver > solution to be loaded. > ASUS has to update the BIOS by changing "acp-audio-config-flag" to zero. This is a good thing to have going forward but I don't think we can require that people get or apply firmware updates for existing systems, there's no guarantee that vendors will make them and the process of getting and applying the update may not be trivial, particularly for people running Linux on a system the vendor shipped with Windows.
On 3/9/2026 6:34 AM, Mark Brown wrote: > On Mon, Mar 09, 2026 at 11:03:21AM +0530, Mukunda,Vijendar wrote: >> On 08/03/26 20:46, hasunpark@gmail.com wrote: > >>> Add a DMI override in snd_amd_acp_find_config() for ACP70+ boards and >>> return 0 so ACP ACPI flag-based selection is skipped on this platform. > >> This patch should be dropped. >> To avoid overgrowing DMI quirks table, we have introduced "acp-audio-config-flag" >> which should be updated based on platform hw configuration and required driver >> solution to be loaded. > >> ASUS has to update the BIOS by changing "acp-audio-config-flag" to zero. > > This is a good thing to have going forward but I don't think we can > require that people get or apply firmware updates for existing systems, > there's no guarantee that vendors will make them and the process of > getting and applying the update may not be trivial, particularly for > people running Linux on a system the vendor shipped with Windows. At least for pre-production hardware we should not accept quirks like this. Vendors should populate their BIOS properly. But I gather this is a production hardware and the vendor made a mistake. In this case I guess the vendor doesn't make Linux BIOS update easy either, and thus the reporter suffers. So maybe we should let this one go, but let's look through these closely if more come. We really don't want to end up with a giant quirk table of BIOS mistakes.
On Mon, Mar 09, 2026 at 10:31:00AM -0500, Mario Limonciello wrote: > On 3/9/2026 6:34 AM, Mark Brown wrote: > > On Mon, Mar 09, 2026 at 11:03:21AM +0530, Mukunda,Vijendar wrote: > > > ASUS has to update the BIOS by changing "acp-audio-config-flag" to zero. > > This is a good thing to have going forward but I don't think we can > > require that people get or apply firmware updates for existing systems, > > there's no guarantee that vendors will make them and the process of > > getting and applying the update may not be trivial, particularly for > > people running Linux on a system the vendor shipped with Windows. > At least for pre-production hardware we should not accept quirks like this. > Vendors should populate their BIOS properly. Yeah, for preproduction that's definitely reasonable in the normal course of affairs. > But I gather this is a production hardware and the vendor made a mistake. > In this case I guess the vendor doesn't make Linux BIOS update easy either, > and thus the reporter suffers. > So maybe we should let this one go, but let's look through these closely if > more come. > We really don't want to end up with a giant quirk table of BIOS mistakes. I mean, that's idiomatic for ACPI :(
© 2016 - 2026 Red Hat, Inc.