drivers/pci/quirks.c | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+)
commit c6e331312ebf ("PCI/ACPI: Whitelist hotplug ports for D3 if
power managed by ACPI") made Root Ports newly eligible for D3 when
ACPI reports the port as power-manageable. On my Acer Swift
SF515-51T, this Root Port (Intel Cannon Point-LP PCI Express Root
Port #9, 8086:9db0, always empty on this SKU) is put into D3 as a
result, and doing so permanently silences the internal speakers
until the machine is rebooted.
Disassembly of this board's ACPI tables shows the Root Port's power
resource (RP09.PXP) and the SATA port SAT0.PRT1 share GPIO pin
0x0402000D as their power enable line. That GPIO also gates a
rail the internal speaker amplifier depends on, but this dependency
is not expressed anywhere in ACPI -- HDAS._PR0 only references
PAUD, so the kernel has no way to know that putting the Root Port in D3
cuts power the audio codec/amp circuitry needs.
Prior to commit c6e331312ebf ("PCI/ACPI: Whitelist hotplug ports for
D3 if power managed by ACPI") this Root Port was never trusted for D3,
so the missing dependency had no observable effect. Confirmed on
hardware: forcing the port to stay in D0 (via
/sys/.../power/control) restores audio immediately, and letting it
re-enter D3 reliably kills it again.
Use PCI_DEV_FLAGS_NO_D3, matched to this exact model via DMI, to
keep the Root Port in D0, following the same pattern already used
for other model-specific D3 breakage in this file.
Fixes: c6e331312ebf ("PCI/ACPI: Whitelist hotplug ports for D3 if
power managed by ACPI")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=212463
Link: https://bugzilla.kernel.org/show_bug.cgi?id=214125
Signed-off-by: paasshme <lowneonema@gmail.com>
---
I went with a DMI-matched PCI_DEV_FLAGS_NO_D3 quirk since that seems to
be the go-to pattern in this file for "device breaks in D3" cases (I saw
quirk_no_ata_d3 above it). Is that the right mechanism here, or would
you prefer something scoped differently?
Apologies in advance for any formatting/process mistakes, that's my first patch.
Thanks for taking a look
drivers/pci/quirks.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index b09f27f78..feb83a84b 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -1471,6 +1471,41 @@ DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_AL,
PCI_ANY_ID,
DECLARE_PCI_FIXUP_CLASS_EARLY(PCI_VENDOR_ID_VIA, PCI_ANY_ID,
PCI_CLASS_STORAGE_IDE, 8, quirk_no_ata_d3);
+/*
+ * The Root Port that the Acer Swift SF515-51T's internal, always-empty PCIe
+ * slot is wired to (Intel Cannon Point-LP PCI Express Root Port #9) shares a
+ * GPIO power-good/enable line (0x0402000D) with SAT0.PRT1, a SATA port, per
+ * this board's own ACPI tables -- confirmed via DSDT/SSDT disassembly, not a
+ * naming coincidence. That GPIO gates a physical rail that isn't documented
+ * as a dependency anywhere else in ACPI, but real-world testing on this
+ * exact hardware shows it also feeds circuitry the internal speaker
+ * amplifier depends on: forcing this Root Port to stay out of D3 restores
+ * audio, and putting it back into D3 reliably kills it again.
+ *
+ * Before commit c6e331312ebf ("PCI/ACPI: Whitelist hotplug ports for D3 if
+ * power managed by ACPI"), this Root Port was never trusted for D3 at all,
+ * so the missing dependency was invisible -- the shared rail just stayed on
+ * incidentally. That commit's broadened trust condition lets this specific,
+ * always-empty port enter D3, silently cutting the rail and killing the
+ * internal speakers.
+ */
+static const struct dmi_system_id acer_sf515_rp_d3_dmi_table[] = {
+ {
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "Swift SF515-51T"),
+ },
+ },
+ {}
+};
+
+static void quirk_acer_sf515_rp09_no_d3(struct pci_dev *pdev)
+{
+ if (dmi_check_system(acer_sf515_rp_d3_dmi_table))
+ pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x9db0,
quirk_acer_sf515_rp09_no_d3);
+
/*
* This was originally an Alpha-specific thing, but it really fits here.
* The i82375 PCI/EISA bridge appears as non-classified. Fix that.
--
2.34.1
© 2016 - 2026 Red Hat, Inc.