Re: [PATCH] acpi: pci_root: Add quirks table for _OSC support

On Tue, Aug 4, 2026 at 6:08 AM Rafael J. Wysocki (Intel)
<[email protected]> wrote:
>
> On Tue, Aug 4, 2026 at 2:46 PM Rafael J. Wysocki (Intel)
> <[email protected]> wrote:
> >
> > On Mon, Aug 3, 2026 at 10:35 PM Derek J. Clark
> > <[email protected]> wrote:
> > >
> > > The MSI Claw A8 hard-locks on resume from s2idle whenever an SD/MMC
> > > card is present in the RTS525A card reader (10ec:525a, PCI ID). This
> > > issue is not present on the Lenovo Legion Go with the same card reader.
> > > The primary difference is that the Claw A8 withholds LTR and DPC while
> > > granting ASPM control to the OS, leading to a split ownership. The issue
> > > can be mitigated by passing pcie_asmp=off, but quirking on the pci_dev
> >
> > You mean pcie_aspm=off I suppose.
> >

Hi Rafael,

Indeed, that was a typo.

> > > in pci/quirks has no effect.
> > >
> > > Attempted quirks included use of pci_disable_link_state(),
> > > dev->link_state = NULL, manually zeroing aspm_l0s_support/aspm_l1_support
> > > via DECLARE_PCI_FIXUP_FINAL, and pcie_aspm_remove_cap() on
> > > DECLARE_PCI_FIXUP_HEADER. Only by disabling ASPM on the root hub is the
> > > system able to resume successfully.
> >
> > So if there is a clash between the firmware and the OS, the question
> > is why it only happens during system resume and only for this specific
> > device in this specific configuration.
> >
> > If disabling ASPM globally makes the symptom go away, it certainly is
> > related to ASPM, but it is kind of hard to say what exactly the
> > relationship is at this point.
>
> Besides, does disabling ASPM globally affect what happens to LTR and
> DPC?  I think so.
>
> If that is the case, maybe the suspend-resume code paths skip LTR and
> DPC if ASPM is disabled and they do something to those capabilities
> otherwise?  LTR and DPC generally should not be touched by the system
> suspend-resume paths if native_ltr and native_dpc are zero,
> respectively.

I'll be up-front that _OSC handling isn't in my wheelhouse of things I
have troubleshot before. After reviewing your feedback I
re-investigated my assumptions to get a better handle on exactly what
the mechanism was that was resolved by the quirk and found some
interesting results. The LTR/DPC asymmetry and ASPM disablement were
masking the real root cause of the failure. Upon looking at my dmesg
again I noted that the quirk caused _OSC negotiation to alter the
PCIeHotPlug control state.

Normal boot:
Aug 04 14:33:12 clawa8 kernel: acpi PNP0A08:00: _OSC: OS supports
[ExtendedConfig ASPM ClockPM Segments MSI EDR HPX-Type3]
Aug 04 14:33:12 clawa8 kernel: acpi PNP0A08:00: _OSC: platform does
not support [SHPCHotplug AER LTR DPC]
Aug 04 14:33:12 clawa8 kernel: acpi PNP0A08:00: _OSC: OS now controls
[PCIeHotplug PME PCIeCapability]

Quirked boot:
Aug 04 14:37:48 clawa8 kernel: acpi PNP0A08:00: PCI Root Bridge
[0000:00] _OSC quirk: stripping support 0x00000006 (MSI Claw A8 BZ2EM)
Aug 04 14:37:48 clawa8 kernel: acpi PNP0A08:00: _OSC: OS supports
[ExtendedConfig Segments MSI EDR HPX-Type3]
Aug 04 14:37:48 clawa8 kernel: acpi PNP0A08:00: _OSC: not requesting
OS control; OS requires [ExtendedConfig ASPM ClockPM MSI]

I then tested pcie_ports=compat and also was able to resume. After a
bit of back and forth I found that using pci/quirks.c and setting
native_pcie_hotplug = false on the root bridge in a HEADER quirk, I
was able to resolve this issue more cleanlyl. Given that, I'll be
sending a different patch to resolve this once I've more thoroughly
tested it to see if I can isolate it to the device itself and/or root
hub. Considering the possible performance hit you described, I think
that is a better path.

Thanks,
Derek