From: Heiner Kallweit <hkallweit1@gmail.com>
To: "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>
Subject: Re: [PATCH] r8169: enable ASPM on Dell platforms
Date: Mon, 15 Sep 2025 21:25:39 +0200 [thread overview]
Message-ID: <ec602131-ed22-44a8-a356-03729764a690@gmail.com> (raw)
In-Reply-To: <rqeme247cojqejerkedcj7m6t6zglks3pe2wcro3xvprit6npt@s4ymo5357hiv>
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
next prev parent reply other threads:[~2025-09-15 19:25 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 [this message]
2025-09-16 20:35 ` Bjorn Helgaas
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=ec602131-ed22-44a8-a356-03729764a690@gmail.com \
--to=hkallweit1@gmail.com \
--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=kuba@kernel.org \
--cc=linux-kernel@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;
as well as URLs for NNTP newsgroup(s).