[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250916203539.GA1815401@bhelgaas>
Date: Tue, 16 Sep 2025 15:35:39 -0500
From: Bjorn Helgaas <helgaas@...nel.org>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: "Chia-Lin Kao (AceLan)" <acelan.kao@...onical.com>,
nic_swsd@...ltek.com, Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
"Wang, Crag" <Crag.Wang@...l.com>,
"Chen, Alan" <Alan.Chen6@...l.com>,
"Alex Shen@...l" <Yijun.Shen@...l.com>, linux-pci@...r.kernel.org
Subject: Re: [PATCH] r8169: enable ASPM on Dell platforms
[+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
Powered by blists - more mailing lists