[PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Mario Limonciello]

When comparing lspci output between Windows and Linux for hotplugged
Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:

  Windows: LnkCtl: ASPM L1 Enabled
  Linux:   LnkCtl: ASPM Disabled

This difference in ASPM configuration can cause behavioral differences
between the two operating systems for the same hardware.

The root cause is that Linux's default ASPM policy (POLICY_DEFAULT) relies
on firmware/BIOS configuration. For hotplugged devices like Thunderbolt/USB4
eGPUs, the BIOS may not have configured ASPM since the device wasn't present
at boot time. As a result, link->aspm_enabled is 0, link->aspm_default is
set to 0, and Linux never enables ASPM for these devices.

Devicetree platforms already have special handling to enable L0s/L1 by
default regardless of firmware configuration. Extend this same logic to
removable devices when firmware hasn't configured any ASPM states.

This makes Linux behavior more consistent with Windows for hotplugged
Thunderbolt/USB4 devices.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221319
Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
---
 drivers/pci/pcie/aspm.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
index 925373b98dff0..77497d90be0b7 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)) {
 		if (link->aspm_support & PCIE_LINK_STATE_L0S)
 			link->aspm_default |= PCIE_LINK_STATE_L0S;
 		if (link->aspm_support & PCIE_LINK_STATE_L1)
-- 
2.43.0

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[sashiko-bot]

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

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Bjorn Helgaas]

On Mon, May 04, 2026 at 05:52:46PM -0500, Mario Limonciello wrote:
> When comparing lspci output between Windows and Linux for hotplugged
> Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
> 
>   Windows: LnkCtl: ASPM L1 Enabled
>   Linux:   LnkCtl: ASPM Disabled
> 
> This difference in ASPM configuration can cause behavioral differences
> between the two operating systems for the same hardware.

A tangent, not a comment on the patch itself, but what sort of
behavioral differences are these?  If ASPM is working correctly, the
only differences *should* be in power consumption and performance.

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Mario Limonciello]

On 5/5/26 11:05, Bjorn Helgaas wrote:
> On Mon, May 04, 2026 at 05:52:46PM -0500, Mario Limonciello wrote:
>> When comparing lspci output between Windows and Linux for hotplugged
>> Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
>>
>>    Windows: LnkCtl: ASPM L1 Enabled
>>    Linux:   LnkCtl: ASPM Disabled
>>
>> This difference in ASPM configuration can cause behavioral differences
>> between the two operating systems for the same hardware.
> 
> A tangent, not a comment on the patch itself, but what sort of
> behavioral differences are these?  If ASPM is working correctly, the
> only differences *should* be in power consumption and performance.

This originally stemmed from a significant performance difference that 
was observed between Windows and Linux with eGPUs.  The link in the 
patch points at that bug if you want to look more closely at it.

I was hopeful that aligning ASPM would align the behavior, but alas this 
didn't.

It was still a difference that I figured we should discuss whether it 
should be changed to be consistent.

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Rafael J. Wysocki]

+Mika Westerberg

On Tue, May 5, 2026 at 12:53 AM Mario Limonciello
<mario.limonciello@amd.com> wrote:
>
> When comparing lspci output between Windows and Linux for hotplugged
> Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
>
>   Windows: LnkCtl: ASPM L1 Enabled
>   Linux:   LnkCtl: ASPM Disabled
>
> This difference in ASPM configuration can cause behavioral differences
> between the two operating systems for the same hardware.
>
> The root cause is that Linux's default ASPM policy (POLICY_DEFAULT) relies
> on firmware/BIOS configuration. For hotplugged devices like Thunderbolt/USB4
> eGPUs, the BIOS may not have configured ASPM since the device wasn't present
> at boot time. As a result, link->aspm_enabled is 0, link->aspm_default is
> set to 0, and Linux never enables ASPM for these devices.
>
> Devicetree platforms already have special handling to enable L0s/L1 by
> default regardless of firmware configuration. Extend this same logic to
> removable devices when firmware hasn't configured any ASPM states.
>
> This makes Linux behavior more consistent with Windows for hotplugged
> Thunderbolt/USB4 devices.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221319
> Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>
> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> ---
>  drivers/pci/pcie/aspm.c | 11 +++++++++--
>  1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index 925373b98dff0..77497d90be0b7 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)) {
>                 if (link->aspm_support & PCIE_LINK_STATE_L0S)
>                         link->aspm_default |= PCIE_LINK_STATE_L0S;
>                 if (link->aspm_support & PCIE_LINK_STATE_L1)
> --
> 2.43.0
>

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Bjorn Helgaas]

[+cc Mika]

On Tue, May 05, 2026 at 11:08:14AM -0500, Mario Limonciello wrote:
> On 5/5/26 11:05, Bjorn Helgaas wrote:
> > On Mon, May 04, 2026 at 05:52:46PM -0500, Mario Limonciello wrote:
> > > When comparing lspci output between Windows and Linux for hotplugged
> > > Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
> > > 
> > >    Windows: LnkCtl: ASPM L1 Enabled
> > >    Linux:   LnkCtl: ASPM Disabled
> > > 
> > > This difference in ASPM configuration can cause behavioral differences
> > > between the two operating systems for the same hardware.
> > 
> > A tangent, not a comment on the patch itself, but what sort of
> > behavioral differences are these?  If ASPM is working correctly, the
> > only differences *should* be in power consumption and performance.
> 
> This originally stemmed from a significant performance difference that was
> observed between Windows and Linux with eGPUs.  The link in the patch points
> at that bug if you want to look more closely at it.

Hmm.  The bug (https://bugzilla.kernel.org/show_bug.cgi?id=221319)
reports "instant reboot", which is definitely a behavioral difference.
But AFAICS this patch would just fix something noticed along the way
but not the reboot itself.

To avoid confusion, I would use "performance difference" or "power
difference" when describing this patch.

> I was hopeful that aligning ASPM would align the behavior, but alas this
> didn't.
> 
> It was still a difference that I figured we should discuss whether it should
> be changed to be consistent.

Definitely.  I hope we can at least enable L1.1.  L1.2 is a whole
'nother issue.

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Mario Limonciello]

On 5/5/26 16:42, Bjorn Helgaas wrote:
> [+cc Mika]
> 
> On Tue, May 05, 2026 at 11:08:14AM -0500, Mario Limonciello wrote:
>> On 5/5/26 11:05, Bjorn Helgaas wrote:
>>> On Mon, May 04, 2026 at 05:52:46PM -0500, Mario Limonciello wrote:
>>>> When comparing lspci output between Windows and Linux for hotplugged
>>>> Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
>>>>
>>>>     Windows: LnkCtl: ASPM L1 Enabled
>>>>     Linux:   LnkCtl: ASPM Disabled
>>>>
>>>> This difference in ASPM configuration can cause behavioral differences
>>>> between the two operating systems for the same hardware.
>>>
>>> A tangent, not a comment on the patch itself, but what sort of
>>> behavioral differences are these?  If ASPM is working correctly, the
>>> only differences *should* be in power consumption and performance.
>>
>> This originally stemmed from a significant performance difference that was
>> observed between Windows and Linux with eGPUs.  The link in the patch points
>> at that bug if you want to look more closely at it.
> 
> Hmm.  The bug (https://bugzilla.kernel.org/show_bug.cgi?id=221319)
> reports "instant reboot", which is definitely a behavioral difference.
> But AFAICS this patch would just fix something noticed along the way
> but not the reboot itself.
> 
> To avoid confusion, I would use "performance difference" or "power
> difference" when describing this patch.

There is a lot of traffic in that bug and similar eGPU bugs; but some 
people have narrowed down that using NVIDIA's GSP "causes the instant 
reboot" but the performance difference is tangential to the reboot (or 
maybe it's part of the cause - I don't actually know).

The reboots /seem/ to be caused by sync floods which I originally 
hypothesized to be caused by Linux using AER and Windows not using it 
(potentially leading to a flood of errors in Linux), but turning off AER 
from kernel command line didn't change that.

> 
>> I was hopeful that aligning ASPM would align the behavior, but alas this
>> didn't.
>>
>> It was still a difference that I figured we should discuss whether it should
>> be changed to be consistent.
> 
> Definitely.  I hope we can at least enable L1.1.  L1.2 is a whole
> 'nother issue.

Yup.

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Mika Westerberg]

Hi,

On Tue, May 05, 2026 at 08:09:22PM +0200, Rafael J. Wysocki wrote:
> +Mika Westerberg
> 
> On Tue, May 5, 2026 at 12:53 AM Mario Limonciello
> <mario.limonciello@amd.com> wrote:
> >
> > When comparing lspci output between Windows and Linux for hotplugged
> > Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
> >
> >   Windows: LnkCtl: ASPM L1 Enabled
> >   Linux:   LnkCtl: ASPM Disabled
> >
> > This difference in ASPM configuration can cause behavioral differences
> > between the two operating systems for the same hardware.
> >
> > The root cause is that Linux's default ASPM policy (POLICY_DEFAULT) relies
> > on firmware/BIOS configuration. For hotplugged devices like Thunderbolt/USB4
> > eGPUs, the BIOS may not have configured ASPM since the device wasn't present
> > at boot time. As a result, link->aspm_enabled is 0, link->aspm_default is
> > set to 0, and Linux never enables ASPM for these devices.
> >
> > Devicetree platforms already have special handling to enable L0s/L1 by
> > default regardless of firmware configuration. Extend this same logic to
> > removable devices when firmware hasn't configured any ASPM states.
> >
> > This makes Linux behavior more consistent with Windows for hotplugged
> > Thunderbolt/USB4 devices.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221319
> > Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>
> > Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
> > ---
> >  drivers/pci/pcie/aspm.c | 11 +++++++++--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> > index 925373b98dff0..77497d90be0b7 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.
> > +        */

Only L1 is supported over TB/USB4 tunnel (no L0s, no L1 substates). The
PCIe endpoint and the downstream port it connects to of course can support
the full range as that's a real PCIe link.

> > +       if (of_have_populated_dt() ||
> > +           (dev_is_removable(&pdev->dev) && !link->aspm_enabled)) {
> >                 if (link->aspm_support & PCIE_LINK_STATE_L0S)
> >                         link->aspm_default |= PCIE_LINK_STATE_L0S;
> >                 if (link->aspm_support & PCIE_LINK_STATE_L1)
> > --
> > 2.43.0
> >

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Mario Limonciello]

On 5/5/26 23:53, Mika Westerberg wrote:
> Hi,
> 
> On Tue, May 05, 2026 at 08:09:22PM +0200, Rafael J. Wysocki wrote:
>> +Mika Westerberg
>>
>> On Tue, May 5, 2026 at 12:53 AM Mario Limonciello
>> <mario.limonciello@amd.com> wrote:
>>>
>>> When comparing lspci output between Windows and Linux for hotplugged
>>> Thunderbolt 5 eGPU devices, Windows enables ASPM L1 but Linux doesn't:
>>>
>>>    Windows: LnkCtl: ASPM L1 Enabled
>>>    Linux:   LnkCtl: ASPM Disabled
>>>
>>> This difference in ASPM configuration can cause behavioral differences
>>> between the two operating systems for the same hardware.
>>>
>>> The root cause is that Linux's default ASPM policy (POLICY_DEFAULT) relies
>>> on firmware/BIOS configuration. For hotplugged devices like Thunderbolt/USB4
>>> eGPUs, the BIOS may not have configured ASPM since the device wasn't present
>>> at boot time. As a result, link->aspm_enabled is 0, link->aspm_default is
>>> set to 0, and Linux never enables ASPM for these devices.
>>>
>>> Devicetree platforms already have special handling to enable L0s/L1 by
>>> default regardless of firmware configuration. Extend this same logic to
>>> removable devices when firmware hasn't configured any ASPM states.
>>>
>>> This makes Linux behavior more consistent with Windows for hotplugged
>>> Thunderbolt/USB4 devices.
>>>
>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221319
>>> Assisted-by: Claude Opus 4.6 <noreply@anthropic.com>
>>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>>> ---
>>>   drivers/pci/pcie/aspm.c | 11 +++++++++--
>>>   1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
>>> index 925373b98dff0..77497d90be0b7 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.
>>> +        */
> 
> Only L1 is supported over TB/USB4 tunnel (no L0s, no L1 substates). The
> PCIe endpoint and the downstream port it connects to of course can support
> the full range as that's a real PCIe link.
> 

OK - the comment should be updated but I do expect that below code 
(link->aspm_support) should remain OK.

>>> +       if (of_have_populated_dt() ||
>>> +           (dev_is_removable(&pdev->dev) && !link->aspm_enabled)) {
>>>                  if (link->aspm_support & PCIE_LINK_STATE_L0S)
>>>                          link->aspm_default |= PCIE_LINK_STATE_L0S;
>>>                  if (link->aspm_support & PCIE_LINK_STATE_L1)
>>> --
>>> 2.43.0
>>>

Re: [PATCH] PCI/ASPM: Enable L0s/L1 for removable devices when BIOS didn't configure ASPM

[Bjorn Helgaas]

On Wed, May 06, 2026 at 10:10:47AM -0500, Mario Limonciello wrote:
> On 5/5/26 23:53, Mika Westerberg wrote:
> > On Tue, May 05, 2026 at 08:09:22PM +0200, Rafael J. Wysocki wrote:
> > > On Tue, May 5, 2026 at 12:53 AM Mario Limonciello
> > > <mario.limonciello@amd.com> wrote:
> ...

> > > > +        * 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.
> > > > +        */
> > 
> > Only L1 is supported over TB/USB4 tunnel (no L0s, no L1 substates). The
> > PCIe endpoint and the downstream port it connects to of course can support
> > the full range as that's a real PCIe link.
> 
> OK - the comment should be updated but I do expect that below code
> (link->aspm_support) should remain OK.

TB/USB4 are examples of removable devices but they're not the only
ones, so I think it's OK for the comment to mention L0s.  In fact, it
*should* mention L0s since the code below includes L0s, and mentioning
only L1 would just be confusing.

> > > > +       if (of_have_populated_dt() ||
> > > > +           (dev_is_removable(&pdev->dev) && !link->aspm_enabled)) {
> > > >                  if (link->aspm_support & PCIE_LINK_STATE_L0S)
> > > >                          link->aspm_default |= PCIE_LINK_STATE_L0S;
> > > >                  if (link->aspm_support & PCIE_LINK_STATE_L1)
> > > > --
> > > > 2.43.0
> > > > 
>