Question on generic PCI ACPI/DT device property wrt ASPM

Question on generic PCI ACPI/DT device property wrt ASPM

[Heiner Kallweit]

There are drivers (in my case r8169) disabling ASPM for a device per default
because there are known issues on a number of systems. However on other
systems ASPM works flawlessly, and vendors (especially of notebooks) would
like to (re-)enable ASPM for this device on such systems.

Reference:
https://lore.kernel.org/netdev/20250912072939.2553835-1-acelan.kao@canonical.com/

Realtek NICs are used on more or less every consumer device, and maintaining
long DMI-based whitelists wouldn't be too nice.

Therefore idea is to use a device property (working title: aspm-is-safe), that
can be set via ACPI or DT. In my case it's a PCIe NIC, but in general the
property could be applicable on every PCIe device.
So question is to which schema such a property would belong. Here?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pci/pci-ep.yaml?h=next-20250916

Re: Question on generic PCI ACPI/DT device property wrt ASPM

[Bjorn Helgaas]

[+cc AceLan]

On Tue, Sep 16, 2025 at 09:48:06PM +0200, Heiner Kallweit wrote:
> There are drivers (in my case r8169) disabling ASPM for a device per default
> because there are known issues on a number of systems. However on other
> systems ASPM works flawlessly, and vendors (especially of notebooks) would
> like to (re-)enable ASPM for this device on such systems.

I would definitely love to be able to fully enable ASPM on these
devices everywhere and rip the ASPM code out of r8169.

> Reference:
> https://lore.kernel.org/netdev/20250912072939.2553835-1-acelan.kao@canonical.com/
> 
> Realtek NICs are used on more or less every consumer device, and maintaining
> long DMI-based whitelists wouldn't be too nice.
> 
> Therefore idea is to use a device property (working title: aspm-is-safe), that
> can be set via ACPI or DT. In my case it's a PCIe NIC, but in general the
> property could be applicable on every PCIe device.
> So question is to which schema such a property would belong. Here?
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pci/pci-ep.yaml?h=next-20250916

I'm not super enthused about yet more knobs to control ASPM based on
issues we don't completely understand.

Quirks that say "X is broken on this device" are to be expected, but I
have a hard time understanding a quirk that says "this feature works
as it's supposed to."

If ASPM works on some systems but not others, it's either because some
Downstream Ports leading to the NIC have defects or Linux (or BIOS) is
configuring ASPM incorrectly sometimes.

I think we just need to figure this out.

Re: Question on generic PCI ACPI/DT device property wrt ASPM

[Heiner Kallweit]

On 9/16/2025 10:25 PM, Bjorn Helgaas wrote:
> [+cc AceLan]
> 
> On Tue, Sep 16, 2025 at 09:48:06PM +0200, Heiner Kallweit wrote:
>> There are drivers (in my case r8169) disabling ASPM for a device per default
>> because there are known issues on a number of systems. However on other
>> systems ASPM works flawlessly, and vendors (especially of notebooks) would
>> like to (re-)enable ASPM for this device on such systems.
> 
> I would definitely love to be able to fully enable ASPM on these
> devices everywhere and rip the ASPM code out of r8169.
> 
>> Reference:
>> https://lore.kernel.org/netdev/20250912072939.2553835-1-acelan.kao@canonical.com/
>>
>> Realtek NICs are used on more or less every consumer device, and maintaining
>> long DMI-based whitelists wouldn't be too nice.
>>
>> Therefore idea is to use a device property (working title: aspm-is-safe), that
>> can be set via ACPI or DT. In my case it's a PCIe NIC, but in general the
>> property could be applicable on every PCIe device.
>> So question is to which schema such a property would belong. Here?
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pci/pci-ep.yaml?h=next-20250916
> 
> I'm not super enthused about yet more knobs to control ASPM based on
> issues we don't completely understand.
> 
> Quirks that say "X is broken on this device" are to be expected, but I
> have a hard time understanding a quirk that says "this feature works
> as it's supposed to."
> 
> If ASPM works on some systems but not others, it's either because some
> Downstream Ports leading to the NIC have defects or Linux (or BIOS) is
> configuring ASPM incorrectly sometimes.
> 
> I think we just need to figure this out.

I'm tempted to say we've been having the ASPM issues with Realtek NICs
for decades now, and so far there was no good way to "just figure this out".
Some issues:
- We only see the tip of the iceberg (the users reporting ASPM issues to
  linux kernel bugzilla)
- These Realtek NICs are on hundreds of consumer mainboard/system types,
  with endless chances of problematic NIC chip version / PCIe chipset / BIOS
  issues combinations.

Therefore a whitelist property might be the least bad option.

Re: Question on generic PCI ACPI/DT device property wrt ASPM

[Bjorn Helgaas]

On Tue, Sep 16, 2025 at 10:56:26PM +0200, Heiner Kallweit wrote:
> On 9/16/2025 10:25 PM, Bjorn Helgaas wrote:
> > On Tue, Sep 16, 2025 at 09:48:06PM +0200, Heiner Kallweit wrote:
> >> There are drivers (in my case r8169) disabling ASPM for a device per default
> >> because there are known issues on a number of systems. However on other
> >> systems ASPM works flawlessly, and vendors (especially of notebooks) would
> >> like to (re-)enable ASPM for this device on such systems.
> > 
> > I would definitely love to be able to fully enable ASPM on these
> > devices everywhere and rip the ASPM code out of r8169.
> > 
> >> Reference:
> >> https://lore.kernel.org/netdev/20250912072939.2553835-1-acelan.kao@canonical.com/
> >>
> >> Realtek NICs are used on more or less every consumer device, and maintaining
> >> long DMI-based whitelists wouldn't be too nice.
> >>
> >> Therefore idea is to use a device property (working title: aspm-is-safe), that
> >> can be set via ACPI or DT. In my case it's a PCIe NIC, but in general the
> >> property could be applicable on every PCIe device.
> >> So question is to which schema such a property would belong. Here?
> >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Documentation/devicetree/bindings/pci/pci-ep.yaml?h=next-20250916
> > 
> > I'm not super enthused about yet more knobs to control ASPM based on
> > issues we don't completely understand.
> > 
> > Quirks that say "X is broken on this device" are to be expected, but I
> > have a hard time understanding a quirk that says "this feature works
> > as it's supposed to."
> > 
> > If ASPM works on some systems but not others, it's either because some
> > Downstream Ports leading to the NIC have defects or Linux (or BIOS) is
> > configuring ASPM incorrectly sometimes.
> > 
> > I think we just need to figure this out.
> 
> I'm tempted to say we've been having the ASPM issues with Realtek NICs
> for decades now, and so far there was no good way to "just figure this out".

Yeah, that was a little flip, sorry.

My impression (perhaps unfounded) is that we don't have much solid
data about any situation where ASPM doesn't work reliably.  I don't
remember seeing actual ASPM configurations or details from a PCIe
analyzer.  Maybe Realtek has looked at this internally; I just don't
think I've seen it.

My suspicion is that it's mostly likely a misconfiguration because the
Root Ports are almost certainly used in many other machines.  And if
the NIC works well in other machines, the NIC is most likely not
broken.

> Some issues:
> - We only see the tip of the iceberg (the users reporting ASPM issues to
>   linux kernel bugzilla)
> - These Realtek NICs are on hundreds of consumer mainboard/system types,
>   with endless chances of problematic NIC chip version / PCIe chipset / BIOS
>   issues combinations.
> 
> Therefore a whitelist property might be the least bad option.