From: Bjorn Helgaas <helgaas@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
devicetree@vger.kernel.org, linux-pci@vger.kernel.org,
Chia-Lin Kao <acelan.kao@canonical.com>
Subject: Re: Question on generic PCI ACPI/DT device property wrt ASPM
Date: Tue, 16 Sep 2025 17:22:51 -0500 [thread overview]
Message-ID: <20250916222251.GA1826923@bhelgaas> (raw)
In-Reply-To: <b54c5083-fd3a-40ad-98ee-f102fd28e230@gmail.com>
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.
prev parent reply other threads:[~2025-09-16 22:22 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-16 19:48 Question on generic PCI ACPI/DT device property wrt ASPM Heiner Kallweit
2025-09-16 20:25 ` Bjorn Helgaas
2025-09-16 20:56 ` Heiner Kallweit
2025-09-16 22:22 ` Bjorn Helgaas [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250916222251.GA1826923@bhelgaas \
--to=helgaas@kernel.org \
--cc=acelan.kao@canonical.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hkallweit1@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox