public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
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.

      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