From: sashiko-bot@kernel.org
To: "Mario Limonciello" <mario.limonciello@amd.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM
Date: Mon, 04 May 2026 23:17:03 +0000 [thread overview]
Message-ID: <20260504231704.3B6D9C2BCB8@smtp.kernel.org> (raw)
In-Reply-To: <20260504225246.480921-1-mario.limonciello@amd.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The patch bypasses ACPI BIOS mechanisms that disable ASPM, forcibly enabling ASPM on hardware even when the BIOS explicitly denied OS control.
- [High] The logic forcefully enables ASPM on boot-connected removable devices where the BIOS may have intentionally disabled it for stability.
- [Medium] The `!link->aspm_enabled` condition is brittle and will silently fail to enable L1 for hotplugged devices if the parent port defaults to L0s.
- [Medium] The check creates a paradoxical state handling where partially enabled ASPM escapes the override, but fully disabled ASPM is overridden to full ASPM.
--
commit 6d92b2eb999d5bb255b9529c7fd1ff1a3798ce5b
Author: Mario Limonciello <mario.limonciello@amd.com>
PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM
This commit enables ASPM L0s and L1 by default for removable devices like
Thunderbolt/USB4 eGPUs when the BIOS hasn't configured any ASPM states.
This aligns Linux behavior with Windows for hotplugged devices.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=221319
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 925373b98dff..77497d90be0b 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -804,8 +804,15 @@ static void pcie_aspm_override_default_link_state(struct pcie_link_state *link)
> struct pci_dev *pdev = link->downstream;
> u32 override;
>
> - /* For devicetree platforms, enable L0s and L1 by default */
> - if (of_have_populated_dt()) {
> + /*
> + * For devicetree platforms, enable L0s and L1 by default.
> + *
> + * For removable devices (e.g., Thunderbolt/USB4), enable L0s and L1
> + * by default if BIOS didn't configure any ASPM states. This handles
> + * hotplugged devices where firmware may not have configured ASPM.
> + */
> + if (of_have_populated_dt() ||
> + (dev_is_removable(&pdev->dev) && !link->aspm_enabled)) {
Does this bypass the ACPI BIOS mechanisms that disable ASPM? When the BIOS
denies ASPM control via ACPI FADT NO_ASPM or _OSC, the kernel sets
aspm_disabled = true and aspm_policy = POLICY_DEFAULT. In
pcie_aspm_sanity_check(), devices are skipped if aspm_disabled is true.
But since this modifies link->aspm_default to L0s|L1, and
pcie_aspm_init_link_state() calls pcie_config_aspm_path() for
POLICY_DEFAULT, pcie_config_aspm_link() will compute the target state as
L0s|L1. Because this differs from link->aspm_enabled == 0, the kernel will
actively write to the PCI registers to enable ASPM, violating the
OS-firmware ACPI contract.
Will this condition silently fail to enable L1 for hotplugged devices if the
parent port defaults to L0s? link->aspm_enabled is an aggregate bitmask
populated in pcie_aspm_cap_init() by reading both the upstream and
downstream link control registers.
If the parent port has PCI_EXP_LNKCTL_ASPM_L0S set, the bitmask will include
PCIE_LINK_STATE_L0S_DW and be non-zero. The strict boolean negation
!link->aspm_enabled would then evaluate to false, skipping the override
entirely.
Does this forcefully enable ASPM on boot-connected removable devices where
the BIOS intentionally disabled it for stability? dev_is_removable()
evaluates to true for Thunderbolt/USB4 devices whether they were hotplugged
or present at boot.
If the BIOS intentionally disabled ASPM for a boot-connected device due to
hardware errata, link->aspm_enabled would be 0. This check evaluates to
true, overriding the BIOS's intentional disablement.
Does this create a paradoxical policy where hardware deemed partially stable
escapes the override, but hardware deemed completely unstable receives the
most aggressive ASPM configuration?
If the BIOS evaluated a device and enabled only L0s, link->aspm_enabled is
non-zero, the check is false, and L1 remains disabled. However, if the BIOS
disabled both L0s and L1, the bitmask is 0, the check evaluates to true,
and both L0s and L1 are forcefully enabled.
> if (link->aspm_support & PCIE_LINK_STATE_L0S)
> link->aspm_default |= PCIE_LINK_STATE_L0S;
> if (link->aspm_support & PCIE_LINK_STATE_L1)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260504225246.480921-1-mario.limonciello@amd.com?part=1
next prev parent reply other threads:[~2026-05-04 23:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-04 22:52 [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM Mario Limonciello
2026-05-04 23:17 ` sashiko-bot [this message]
2026-05-05 16:05 ` Bjorn Helgaas
2026-05-05 16:08 ` Mario Limonciello
2026-05-05 21:42 ` Bjorn Helgaas
2026-05-06 3:36 ` Mario Limonciello
2026-05-05 18:09 ` Rafael J. Wysocki
2026-05-06 4:53 ` Mika Westerberg
2026-05-06 15:10 ` Mario Limonciello
2026-05-06 15:27 ` 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=20260504231704.3B6D9C2BCB8@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=sashiko@lists.linux.dev \
/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