[PATCH] PCI: quirks: Prevent D3 for Acer Swift SF515-51T Root Port to fix audio

[PATCH] PCI: quirks: Prevent D3 for Acer Swift SF515-51T Root Port to fix audio

[Lowne Onema]

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

Re: [PATCH] PCI: quirks: Prevent D3 for Acer Swift SF515-51T Root Port to fix audio

[Lukas Wunner]

On Sat, Aug 01, 2026 at 08:10:25PM +0200, Lowne Onema wrote:
> 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.
[...]
> 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?

It is *one* option.  An alternative approach we've used in similar
cases is to create a device link.  It allows expressing a power
dependency of one device on another device.  E.g. GPUs frequently
expose an HDA controller as Function 1 of a PCI device which is
only accessible if Function 0 (the actual GPU) is powered on.
See quirk_gpu_hda() in drivers/pci/quirks.c.  For this approach
you need two struct device (the supplier and the consumer) and
I'm not sure if the speaker or speaker amplifier is represented
as a struct device.  If it's not, then this approach is not viable.
A workaround might be to use the HDA controller as supplier (to which
the speaker is attached), but that's not perfect.

Another option would be to patch the ACPI tables.  There are several
ways to do this via the initrd, via EFI etc.  See:

admin-guide/acpi/initrd_table_override.rst
https://github.com/xCuri0/ReBarUEFI/wiki/DSDT-Patching
https://wiki.archlinux.org/title/DSDT

Using a DSDT patch benefits other OSes you might have installed,
but doesn't benefit other Linux users who encounter the same problem.

In drivers/acpi/x86/ we carry a number of ACPI quirks for problematic
devices.  Amending that would be a third option to overcome the issue.
The kernel enumerates power resources and the dependencies of devices
on them, basically you'd have to add a quirk to amend those data
structures.  At the bottom of drivers/acpi/power.c, you'll find
existing quirks for products with broken power resource descriptions.
I don't know why these live in power.c, they're x86-specific and
everything in this file is also compiled into kernels for other
ACPI-supporting arches such as arm64.  Generally we try to move such
quirks to files that are only compiled on x86 (such as everything
under drivers/acpi/x86) or at least #ifdef them to CONFIG_X86.

The fourth and best option would be if the vendor would provide
a BIOS update to fix the ACPI table.  Often vendors are loathe
to do this for older products and then a workaround at the OS level
is the only solution, but please double-check that you've got the
latest BIOS version installed.

> 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>

A minor nit, you should use your real name in the Signed-off-by tag,
you may want to use "Closes:" instead of "Link:" and you may also
want to add a tag "Cc: stable@vger.kernel.org # v5.10+".

> Apologies in advance for any formatting/process mistakes,
> that's my first patch.

You're doing great!  I am sorry for the breakage caused by my commit!

Thanks,

Lukas

Re: [PATCH] PCI: quirks: Prevent D3 for Acer Swift SF515-51T Root Port to fix audio

[Lowne Onema]

Thanks for the details! It's very helpful.

1. Device link: agreed this does not seem viable here. The speaker/amp isn't
     enumerated as its own device (PCI, platform, or otherwise) on this
     hardware, it's just analog circuitry fed by a shared GPIO rail.
     there's no second struct device to link against.

  2. DSDT patch: I actually tried this route first, before settling on
     the quirk. Bumped SSDT5's OEM revision and added RP09.PXP as a
     second dependency in HDAS._PR0, but I struggled to recompile it
     with iasl (some header issues since several pins share an identical
     header). Also, as you note, it wouldn't help other Linux users of
     this model without each of them repeating the same disassembly by
     hand.

 3. Amending the power resource structures in drivers/acpi/: I looked
   at this a bit more and noticed RP09 and the SATA port
   (SAT0.PRT1) each have their own separate power resource in the
   ACPI tables, but both end up controlling the same physical GPIO
   pin. I'm not sure if that's something the kernel already knows
   how to handle safely, or if trying to sync RP09's power to audio
   activity could accidentally interfere with the SATA port through
   that shared pin. Still learning this part of the kernel, so
   wanted to ask before attempting it -- is that a real concern, or
   is it fine, and a better approach?

  4. BIOS update: checked, I'm unfortunately up to date with latest
     acer version (from 2019, no updates since).

  v2 below corrects the following: real name in Signed-off-by, Closes: instead
  of Link:, and Cc: stable added.

  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 the 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-good/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 OS 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")
  Closes: https://bugzilla.kernel.org/show_bug.cgi?id=212463
  Closes: https://bugzilla.kernel.org/show_bug.cgi?id=214125
  Cc: stable@vger.kernel.org # v5.10+
  Signed-off-by: Jacques Mironneau <lowneonema@gmail.com>
  ---
  v2: use real name in Signed-off-by, s/Link/Closes for the bugzilla
      references, add Cc: stable (per Lukas Wunner)


   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
--- 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

Jacques Mironneau

Le dim. 2 août 2026 à 10:42, Lukas Wunner <lukas@wunner.de> a écrit :
>
> On Sat, Aug 01, 2026 at 08:10:25PM +0200, Lowne Onema wrote:
> > 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.
> [...]
> > 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?
>
> It is *one* option.  An alternative approach we've used in similar
> cases is to create a device link.  It allows expressing a power
> dependency of one device on another device.  E.g. GPUs frequently
> expose an HDA controller as Function 1 of a PCI device which is
> only accessible if Function 0 (the actual GPU) is powered on.
> See quirk_gpu_hda() in drivers/pci/quirks.c.  For this approach
> you need two struct device (the supplier and the consumer) and
> I'm not sure if the speaker or speaker amplifier is represented
> as a struct device.  If it's not, then this approach is not viable.
> A workaround might be to use the HDA controller as supplier (to which
> the speaker is attached), but that's not perfect.
>
> Another option would be to patch the ACPI tables.  There are several
> ways to do this via the initrd, via EFI etc.  See:
>
> admin-guide/acpi/initrd_table_override.rst
> https://github.com/xCuri0/ReBarUEFI/wiki/DSDT-Patching
> https://wiki.archlinux.org/title/DSDT
>
> Using a DSDT patch benefits other OSes you might have installed,
> but doesn't benefit other Linux users who encounter the same problem.
>
> In drivers/acpi/x86/ we carry a number of ACPI quirks for problematic
> devices.  Amending that would be a third option to overcome the issue.
> The kernel enumerates power resources and the dependencies of devices
> on them, basically you'd have to add a quirk to amend those data
> structures.  At the bottom of drivers/acpi/power.c, you'll find
> existing quirks for products with broken power resource descriptions.
> I don't know why these live in power.c, they're x86-specific and
> everything in this file is also compiled into kernels for other
> ACPI-supporting arches such as arm64.  Generally we try to move such
> quirks to files that are only compiled on x86 (such as everything
> under drivers/acpi/x86) or at least #ifdef them to CONFIG_X86.
>
> The fourth and best option would be if the vendor would provide
> a BIOS update to fix the ACPI table.  Often vendors are loathe
> to do this for older products and then a workaround at the OS level
> is the only solution, but please double-check that you've got the
> latest BIOS version installed.
>
> > 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>
>
> A minor nit, you should use your real name in the Signed-off-by tag,
> you may want to use "Closes:" instead of "Link:" and you may also
> want to add a tag "Cc: stable@vger.kernel.org # v5.10+".
>
> > Apologies in advance for any formatting/process mistakes,
> > that's my first patch.
>
> You're doing great!  I am sorry for the breakage caused by my commit!
>
> Thanks,
>
> Lukas

Re: [PATCH] PCI: quirks: Prevent D3 for Acer Swift SF515-51T Root Port to fix audio

[Lukas Wunner]

On Tue, Aug 04, 2026 at 09:40:03PM +0200, Lowne Onema wrote:
>  3. Amending the power resource structures in drivers/acpi/: I looked
>    at this a bit more and noticed RP09 and the SATA port
>    (SAT0.PRT1) each have their own separate power resource in the
>    ACPI tables, but both end up controlling the same physical GPIO
>    pin. I'm not sure if that's something the kernel already knows
>    how to handle safely, or if trying to sync RP09's power to audio
>    activity could accidentally interfere with the SATA port through
>    that shared pin. Still learning this part of the kernel, so
>    wanted to ask before attempting it -- is that a real concern, or
>    is it fine, and a better approach?

If two devices reference the same PowerResource in the ACPI tables,
then the kernel is aware of the dependency.  E.g., when the
PowerResource is turned on, the kernel runtime resumes all "dependents"
of that PowerResource.

However if these are separate PowerResources whose _ON method happens
to toggle the same GPIO, that's opaque to the kernel.  I think it is
then the job of the _ON and _OFF methods to track whether another
device still needs the GPIO to be kept on.

But perhaps the ACPI tables are just completely broken and the right
thing to do is modify the PowerResource assignment such that all
3 devices depend on the same PowerResource?

> +++ b/drivers/pci/quirks.c
> +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);

On x86 SoCs introduced in the last about 10 years, keeping a Root Port
in D0 prevents the SoC from entering lower power states.  So the
workaround of keeping RP09 in D0 may reduce battery life.

Usually Root Ports can only be put into D3hot, not D3cold.  If there's
a PowerResource for the Root Port, that's usually for powering off
a device *below* that Root Port.  E.g. if RP09 is an internal,
unoccupied M.2 slot, then the PowerResource allows cutting power
to an NVMe drive or WiFi card in that M.2 slot.

If RP09 isn't exposed physically at all, then it's unclear why the OEM
chose to enable it in the first place, let alone describe a PowerResource
for it in the ACPI tables.

Thanks,

Lukas