From: Bjorn Helgaas <helgaas@kernel.org>
To: Heiner Kallweit <hkallweit1@gmail.com>
Cc: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>,
nic_swsd@realtek.com, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org, "Wang,
Crag" <Crag.Wang@dell.com>, "Chen, Alan" <Alan.Chen6@dell.com>,
"Alex Shen@Dell" <Yijun.Shen@dell.com>,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] r8169: enable ASPM on Dell platforms
Date: Tue, 16 Sep 2025 15:35:39 -0500 [thread overview]
Message-ID: <20250916203539.GA1815401@bhelgaas> (raw)
In-Reply-To: <ec602131-ed22-44a8-a356-03729764a690@gmail.com>
[+cc linux-pci]
On Mon, Sep 15, 2025 at 09:25:39PM +0200, Heiner Kallweit wrote:
> On 9/15/2025 3:37 AM, Chia-Lin Kao (AceLan) wrote:
> > On Fri, Sep 12, 2025 at 05:30:52PM +0200, Heiner Kallweit wrote:
> >> On 9/12/2025 9:29 AM, Chia-Lin Kao (AceLan) wrote:
> >>> Enable PCIe ASPM for RTL8169 NICs on Dell platforms that have been
> >>> verified to work reliably with this power management feature. The
> >>> r8169 driver traditionally disables ASPM to prevent random link
> >>> failures and system hangs on problematic hardware.
> >>>
> >>> Dell has validated these product families to work correctly with
> >>> RTL NIC ASPM and commits to addressing any ASPM-related issues
> >>> with RTL hardware in collaboration with Realtek.
> >>>
> >>> This change enables ASPM for the following Dell product families:
> >>> - Alienware
> >>> - Dell Laptops/Pro Laptops/Pro Max Laptops
> >>> - Dell Desktops/Pro Desktops/Pro Max Desktops
> >>> - Dell Pro Rugged Laptops
> >>>
> >> I'd like to avoid DMI-based whitelists in kernel code. If more system
> >> vendors do it the same way, then this becomes hard to maintain.
> >
> > I totally understand your point; I also don’t like constantly adding DMI
> > info to the list. But this list isn’t for a single product name, it’s a
> > product family that covers a series of products, and it probably won’t
> > change anytime soon.
> >
> >> There is already a mechanism for vendors to flag that they successfully
> >> tested ASPM. See c217ab7a3961 ("r8169: enable ASPM L1.2 if system vendor
> >> flags it as safe").
> >
> > Right, but writing the flag is not applicable for Dell manufacturing
> > processes.
> >
> Can you elaborate on why this doesn't work for Dell?
>
> >> Last but not least ASPM can be (re-)enabled from userspace, using sysfs.
> >
> > That doesn't sound like a good solution to push the list to userspace.
> >
> > Dell has already been working with Canonical for more than a decade to
> > ship their products with r8169 ASPM enabled. Dell has also had lengthy
> > discussions with Realtek to have this feature enabled by default in the
> > r8169 driver. I think this is a good opportunity for Dell to work with
> > Realtek to spot bugs and refine the r8169 driver.
>
> One more option to avoid having to change kernel code with each new
> and successfully ASPM-tested system family from any system vendor:
>
> We could define a device property which states that ASPM has been
> successfully tested on a system. This device property could be set
> via device tree or via ACPI. Then a simple device_property_present()
> in the driver would be sufficient.
> A device property would also have the advantage that vendors can
> control behavior per device, not only per device family.
> An ACPI device property could be rolled out via normal BIOS update
> for existing systems.
>
> See also:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/Documentation/firmware-guide/acpi/DSD-properties-rules.rst?h=v6.16.7
Related conversation:
https://lore.kernel.org/r/5b00870c-be1a-42d6-8857-48b89716d5e2@gmail.com
next prev parent reply other threads:[~2025-09-16 20:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-12 7:29 [PATCH] r8169: enable ASPM on Dell platforms Chia-Lin Kao (AceLan)
2025-09-12 15:30 ` Heiner Kallweit
2025-09-15 1:37 ` Chia-Lin Kao (AceLan)
2025-09-15 19:25 ` Heiner Kallweit
2025-09-16 20:35 ` Bjorn Helgaas [this message]
2025-09-22 16:41 ` Bjorn Helgaas
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=20250916203539.GA1815401@bhelgaas \
--to=helgaas@kernel.org \
--cc=Alan.Chen6@dell.com \
--cc=Crag.Wang@dell.com \
--cc=Yijun.Shen@dell.com \
--cc=acelan.kao@canonical.com \
--cc=andrew+netdev@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nic_swsd@realtek.com \
--cc=pabeni@redhat.com \
/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