[PATCH] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[PATCH] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Max Lee]

The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
excessive Correctable Error (Replay Timer Timeout) AER events during
PCIe link initialization. On systems where firmware enables AER
reporting (CERptEn+), this causes an AER storm of ~240K error events
within 11 seconds of boot, overwhelming the kernel's error handler and
blocking shutdown/reboot.

The root cause is a transient link training instability inherent to this
device -- even on BIOS versions that suppress reporting, the error
status register (CESta) shows Timeout+ set.

Unlike the GL9750/GL9755 fixup (which only masks the parent root port),
the RTS525A additionally requires masking the endpoint's own Correctable
Error Mask register bit 12 (PCI_ERR_COR_REP_TIMER) to prevent it from
sending ERR_COR messages upstream. Call pci_mask_replay_timer_timeout()
to mask the parent root port as well.

Signed-off-by: Max Lee <max.lee@canonical.com>
---
 drivers/pci/quirks.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc0..072d1456daad 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6380,4 +6380,23 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
+
+static void pci_mask_replay_timer_timeout_on_endpoint(struct pci_dev *pdev)
+{
+	u32 val;
+
+	if (!pdev->aer_cap)
+		return;
+
+	pci_info(pdev, "mask Replay Timer Timeout on endpoint due to hardware defect\n");
+
+	pci_read_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, &val);
+	val |= PCI_ERR_COR_REP_TIMER;
+	pci_write_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, val);
+
+	/* Also mask the parent root port */
+	pci_mask_replay_timer_timeout(pdev);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REALTEK, 0x525a,
+			 pci_mask_replay_timer_timeout_on_endpoint);
 #endif
-- 
2.43.0

Re: [PATCH] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The quirk returns early if the endpoint lacks the AER capability, unintentionally skipping the AER mask on the parent root port.
--

commit 33ed73136f45313933a545d6af06c38d893ebef2
Author: Max Lee <max.lee@canonical.com>

PCI: Mask Replay Timer Timeout for Realtek RTS525A

This commit adds a PCI fixup quirk for the Realtek RTS525A SD card reader.
It masks the Replay Timer Timeout on both the endpoint and its parent root
port to prevent an AER storm during PCIe link initialization.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index caaed1a01dc02..072d1456daad4 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -6380,4 +6380,23 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
>  }
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
>  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
> +
> +static void pci_mask_replay_timer_timeout_on_endpoint(struct pci_dev *pdev)
> +{
> +	u32 val;
> +
> +	if (!pdev->aer_cap)
> +		return;

[Severity: High]
If the endpoint lacks the AER capability, this early return will entirely
skip masking the parent root port later in the function. Does this leave the
system vulnerable to the AER storm from the parent port if the endpoint's
AER capability is disabled or hidden?

Could this be restructured so that the parent root port masking is still
applied even when the endpoint lacks the AER capability?

> +
> +	pci_info(pdev, "mask Replay Timer Timeout on endpoint due to hardware defect\n");
> +
> +	pci_read_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, &val);
> +	val |= PCI_ERR_COR_REP_TIMER;
> +	pci_write_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, val);
> +
> +	/* Also mask the parent root port */
> +	pci_mask_replay_timer_timeout(pdev);
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528032347.644365-1-max.lee@canonical.com?part=1

[PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Max Lee]

The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
excessive Correctable Error (Replay Timer Timeout) AER events during
PCIe link initialization. On systems where firmware enables AER
reporting (CERptEn+), this causes an AER storm of ~240K error events
within 11 seconds of boot, overwhelming the kernel error handler and
blocking shutdown/reboot.

The root cause is a transient link training instability inherent to this
device -- even on BIOS versions that suppress reporting, the error
status register (CESta) shows Timeout+ set.

Unlike the GL9750/GL9755 fixup, which only masks the parent root port,
the RTS525A also needs its endpoint Correctable Error Mask bit 12
(PCI_ERR_COR_REP_TIMER) masked when the endpoint exposes AER, so it does
not send ERR_COR messages upstream. Also mask the parent root port to
cover root-port reporting of link errors caused by the endpoint.

Signed-off-by: Max Lee <max.lee@canonical.com>
---
Changes in v2:
  - Mask the parent root port even when the endpoint lacks AER capability.
  - Remove the early return before parent root port masking.

 drivers/pci/quirks.c | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc0..6597536a4c70 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -6380,4 +6380,26 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
 }
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
 DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
+
+static void pci_mask_replay_timer_timeout_on_endpoint(struct pci_dev *pdev)
+{
+	u32 val;
+
+	if (pdev->aer_cap) {
+		pci_info(pdev, "mask Replay Timer Timeout on endpoint due to hardware defect\n");
+
+		pci_read_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, &val);
+		val |= PCI_ERR_COR_REP_TIMER;
+		pci_write_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, val);
+	}
+
+	/*
+	 * Also mask the parent root port. Do this even if the endpoint lacks
+	 * AER capability because the root port may still report link errors
+	 * caused by the endpoint.
+	 */
+	pci_mask_replay_timer_timeout(pdev);
+}
+DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REALTEK, 0x525a,
+			pci_mask_replay_timer_timeout_on_endpoint);
 #endif
-- 
2.43.0

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Manivannan Sadhasivam]

On Wed, Jun 10, 2026 at 10:47:23AM +0800, Max Lee wrote:
> The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
> excessive Correctable Error (Replay Timer Timeout) AER events during
> PCIe link initialization. On systems where firmware enables AER
> reporting (CERptEn+), this causes an AER storm of ~240K error events
> within 11 seconds of boot, overwhelming the kernel error handler and
> blocking shutdown/reboot.
> 
> The root cause is a transient link training instability inherent to this
> device -- even on BIOS versions that suppress reporting, the error
> status register (CESta) shows Timeout+ set.
> 
> Unlike the GL9750/GL9755 fixup, which only masks the parent root port,
> the RTS525A also needs its endpoint Correctable Error Mask bit 12
> (PCI_ERR_COR_REP_TIMER) masked when the endpoint exposes AER, so it does
> not send ERR_COR messages upstream. Also mask the parent root port to
> cover root-port reporting of link errors caused by the endpoint.
> 
> Signed-off-by: Max Lee <max.lee@canonical.com>
> ---
> Changes in v2:
>   - Mask the parent root port even when the endpoint lacks AER capability.

You've added this based on the comment by Sashiko I believe. But I think Sashiko
was wrong here. If the EP lacks AER capability, then there is no way it is going
to send AER errors to upstream RP. So it is OK to skip the quirk.

There is a slight chance that the RP itself generating AER events when it has
detected the Replay Timeout. But to verify, you need to share the AER log during
bootup.

Also, since you mentioned that the firmware is enabling the AER reporting for
the device, which means the device would've been enumerated by BIOS before the
kernel boots. In that case, RP would still continue to receive the COR_ERR and
by the time the AER driver binds to the RP (which happens before the quirk for
the RTS525A gets executed due to depth first enumeration), those AER errors will
still be logged until the quirk execution. So you'd still see AER errors in
dmesg, but not a flood before this patch.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Bjorn Helgaas]

[+cc Kai-Heng, Victor, Lukas, Jon]

On Wed, Jul 01, 2026 at 08:27:13AM +0200, Manivannan Sadhasivam wrote:
> On Wed, Jun 10, 2026 at 10:47:23AM +0800, Max Lee wrote:
> > The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
> > excessive Correctable Error (Replay Timer Timeout) AER events during
> > PCIe link initialization. On systems where firmware enables AER
> > reporting (CERptEn+), this causes an AER storm of ~240K error events
> > within 11 seconds of boot, overwhelming the kernel error handler and
> > blocking shutdown/reboot.

Specifically, I guess these error events are the AER interrupts.  We
rate-limit the actual *messages*, but not the interrupts, so we can be
overwhelmed by handling them.

> > The root cause is a transient link training instability inherent to this
> > device -- even on BIOS versions that suppress reporting, the error
> > status register (CESta) shows Timeout+ set.
> > 
> > Unlike the GL9750/GL9755 fixup, which only masks the parent root port,

I think PCI_ERR_COR_REP_TIMER is masked in both the GL975x Endpoint
and the Downstream Port leading to it:

  015c9cbcf0ad ("mmc: sdhci-pci-gli: GL9750: Mask the replay timer
  timeout of AER")

  eeee3b5e6d0b ("PCI: Mask Replay Timer Timeout errors for Genesys
  GL975x SD host controller")

Maybe those should be combined so the quirk masks
PCI_ERR_COR_REP_TIMER at both ends of the link in one place.  A quirk
like that could be used for both GL975x and RTS525A.

> > the RTS525A also needs its endpoint Correctable Error Mask bit 12
> > (PCI_ERR_COR_REP_TIMER) masked when the endpoint exposes AER, so it does
> > not send ERR_COR messages upstream. Also mask the parent root port to
> > cover root-port reporting of link errors caused by the endpoint.

I think this and the similar comment in the code are slightly
misleading.  pci_mask_replay_timer_timeout() masks
PCI_ERR_COR_REP_TIMER in the Downstream Port leading to pdev.  That
may be either a Root Port or a Switch Downstream Port.

> > Signed-off-by: Max Lee <max.lee@canonical.com>
> > ---
> > Changes in v2:
> >   - Mask the parent root port even when the endpoint lacks AER capability.
> 
> You've added this based on the comment by Sashiko I believe. But I
> think Sashiko was wrong here. If the EP lacks AER capability, then
> there is no way it is going to send AER errors to upstream RP. So it
> is OK to skip the quirk.

I'm not sure it's OK to skip the quirk.

Based on the flowchart in PCIe r7.0, sec 6.2.5, it looks like an
Endpoint that detects a Correctable Error but lacks an AER Capability
sets PCI_EXP_DEVSTA_CED and, if PCI_EXP_DEVCTL_CERE is set, sends
ERR_COR upstream.

I suspect that what we need here is:

  - Mask PCI_ERR_COR_REP_TIMER in Endpoint to prevent it from sending
    ERR_COR

  - Mask PCI_ERR_COR_REP_TIMER in upstream bridge to prevent it from
    sending ERR_COR

  - If the upstream bridge is not the Root Port, mask
    PCI_ERR_COR_REP_TIMER in Root Port to prevent AER interrupt if it
    receives ERR_COR, e.g., if the Endpoint or bridge lacks AER

I wonder if aer.c should disable the AER interrupt by temporarily
clearing PCI_ERR_ROOT_CMD_COR_EN if it detects a storm.  Maybe that
could avoid device quirks for transient issues like this.

> There is a slight chance that the RP itself generating AER events
> when it has detected the Replay Timeout. But to verify, you need to
> share the AER log during bootup.
> 
> Also, since you mentioned that the firmware is enabling the AER
> reporting for the device, which means the device would've been
> enumerated by BIOS before the kernel boots. In that case, RP would
> still continue to receive the COR_ERR and by the time the AER driver
> binds to the RP (which happens before the quirk for the RTS525A gets
> executed due to depth first enumeration), those AER errors will
> still be logged until the quirk execution. So you'd still see AER
> errors in dmesg, but not a flood before this patch.

> > +++ b/drivers/pci/quirks.c
> > @@ -6380,4 +6380,26 @@ static void pci_mask_replay_timer_timeout(struct pci_dev *pdev)
> >  }
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9750, pci_mask_replay_timer_timeout);
> >  DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_GLI, 0x9755, pci_mask_replay_timer_timeout);
> > +
> > +static void pci_mask_replay_timer_timeout_on_endpoint(struct pci_dev *pdev)
> > +{
> > +	u32 val;
> > +
> > +	if (pdev->aer_cap) {
> > +		pci_info(pdev, "mask Replay Timer Timeout on endpoint due to hardware defect\n");
> > +
> > +		pci_read_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, &val);
> > +		val |= PCI_ERR_COR_REP_TIMER;
> > +		pci_write_config_dword(pdev, pdev->aer_cap + PCI_ERR_COR_MASK, val);
> > +	}
> > +
> > +	/*
> > +	 * Also mask the parent root port. Do this even if the endpoint lacks
> > +	 * AER capability because the root port may still report link errors
> > +	 * caused by the endpoint.
> > +	 */
> > +	pci_mask_replay_timer_timeout(pdev);
> > +}
> > +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_REALTEK, 0x525a,
> > +			pci_mask_replay_timer_timeout_on_endpoint);
> >  #endif
> > -- 
> > 2.43.0
> > 

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Lukas Wunner]

On Wed, Jul 01, 2026 at 03:42:01PM -0500, Bjorn Helgaas wrote:
> On Wed, Jul 01, 2026 at 08:27:13AM +0200, Manivannan Sadhasivam wrote:
> > On Wed, Jun 10, 2026 at 10:47:23AM +0800, Max Lee wrote:
> > > The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
> > > excessive Correctable Error (Replay Timer Timeout) AER events during
> > > PCIe link initialization. On systems where firmware enables AER
> > > reporting (CERptEn+), this causes an AER storm of ~240K error events
> > > within 11 seconds of boot, overwhelming the kernel error handler and
> > > blocking shutdown/reboot.
> 
> Specifically, I guess these error events are the AER interrupts.  We
> rate-limit the actual *messages*, but not the interrupts, so we can be
> overwhelmed by handling them.

Ratelimiting went into v6.16.  It would be good to know whether
the behavior described in the commit message occurs only with
older kernels or persists with ratelimiting.

It would also be good to know whether the "overwhelming" occurs
with OS-native AER handling (aer_print_error()) or with Firmware
First AER handling (pci_print_aer()).

The PCIe port driver is registered in a device_initcall, which happens
much later than PCI device enumeration in a subsys_initcall.  Do these
errors occur before the port driver registers?  If they do, then the
"overwhelming" likely happens through the Firmware First code path.
Or perhaps "within 11 seconds of boot" is when portdrv probes and
registers the AER driver?

It would be good to have full dmesg output for analysis because this
is all a little murky.

> Based on the flowchart in PCIe r7.0, sec 6.2.5, it looks like an
> Endpoint that detects a Correctable Error but lacks an AER Capability
> sets PCI_EXP_DEVSTA_CED and, if PCI_EXP_DEVCTL_CERE is set, sends
> ERR_COR upstream.
> 
> I suspect that what we need here is:
> 
>   - Mask PCI_ERR_COR_REP_TIMER in Endpoint to prevent it from sending
>     ERR_COR
> 
>   - Mask PCI_ERR_COR_REP_TIMER in upstream bridge to prevent it from
>     sending ERR_COR
> 
>   - If the upstream bridge is not the Root Port, mask
>     PCI_ERR_COR_REP_TIMER in Root Port to prevent AER interrupt if it
>     receives ERR_COR, e.g., if the Endpoint or bridge lacks AER

The last bullet point doesn't sound quite right:  Per table 6-4 in
PCIe r7.0 sec 6.2.7, Replay Timer Timeout is detected by the Transmitter.
This can only be the Endpoint or its upstream bridge.  If the upstream
bridge is not the Root Port, masking PCI_ERR_COR_REP_TIMER in the
Root Port doesn't help.

If the Endpoint or its upstream bridge don't support AER, one has to
clear Correctable Error Reporting Enable in the Device Control Register
to suppress the Replay Timer Timeout errors.  Obviously this will
suppress reporting of any other Correctable Error as well.

> I wonder if aer.c should disable the AER interrupt by temporarily
> clearing PCI_ERR_ROOT_CMD_COR_EN if it detects a storm.  Maybe that
> could avoid device quirks for transient issues like this.

The hierarchy below the Root Port might be deeper and we'd risk
losing errors reported by other devices in that hierarchy while
interrupt generation is temporarily disabled.

Thanks,

Lukas

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Max Lee]

On Thu, Jul 02, 2026 at 07:10:46AM +0200, Lukas Wunner wrote:
> It would be good to have full dmesg output for analysis because this
> is all a little murky.

Thanks Mani, Bjorn and Lukas for the detailed analysis.

I collected full boot dmesg and lspci -vv from the affected system.

The system is:

  HP ZBook Power 16 inch G11 Mobile Workstation PC
  BIOS: W97 Ver. 01.09.01, 03/02/2026
  Kernel: 6.17.0-1012-oem

The topology is a direct Root Port -> Endpoint connection, with no switch
in between:

  0000:00:1c.6-[58]----00.0  Realtek RTS525A PCI Express Card Reader

The log shows that OS-native AER is in control:

  acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug SHPCHotplug PME
AER PCIeCapability LTR DPC]
  pcieport 0000:00:1c.6: AER: enabled with IRQ 127

I did not find GHES/HEST/Firmware First AER messages in dmesg/journal for
this boot.

The storm starts after the PCIe port driver enables AER on 0000:00:1c.6
and immediately after rtsx_pci enables the endpoint:

  [    0.798443] pcieport 0000:00:1c.6: AER: enabled with IRQ 127
  [    1.057380] rtsx_pci 0000:58:00.0: enabling device (0000 -> 0002)
  [    1.057399] pcieport 0000:00:1c.6: AER: Correctable error message
received from 0000:58:00.0
  [    1.057405] rtsx_pci 0000:58:00.0: PCIe Bus Error:
severity=Correctable, type=Data Link Layer, (Transmitter ID)
  [    1.057408] rtsx_pci 0000:58:00.0:   device [10ec:525a] error
status/mask=00001000/00006000
  [    1.057411] rtsx_pci 0000:58:00.0:    [12] Timeout

Ratelimiting is present, but the interrupt/callback volume is still very
large:

  [    6.058155] aer_ratelimit: 120541 callbacks suppressed
  [   11.059227] aer_ratelimit: 120906 callbacks suppressed

/proc/interrupts later showed IRQ 127 for 0000:00:1c.6
(PCIe PME, aerdrv, PCIe bwctrl) at 940777 interrupts, while the
endpoint's own rtsx_pci MSI had only 6 interrupts.

Both the endpoint and the immediate upstream port expose AER capability.
On this unpatched boot, Replay Timer Timeout is not masked on either side.

Endpoint 0000:58:00.0:

  Capabilities: [100 v2] Advanced Error Reporting
      CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
      CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+

Root Port 0000:00:1c.6:

  Capabilities: [100 v1] Advanced Error Reporting
      CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
      CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
      RootCmd: CERptEn+ NFERptEn+ FERptEn+
      ErrorSrc: ERR_COR: 5800 ERR_FATAL/NONFATAL: 0000

So for this system, the endpoint does expose AER, and the observed storm
does not require handling the no-endpoint-AER case.

I agree that the v2 wording is imprecise.  pci_mask_replay_timer_timeout()
does not necessarily mask a Root Port; it masks the immediate upstream
Downstream Port leading to pdev, which may be a Root Port or a Switch
Downstream Port.  If I send v3, I will fix the commit log and code comment
to use that wording instead of "parent root port".

I can also include the full dmesg and lspci output if useful.

Thanks,
Max

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Manivannan Sadhasivam]

On Wed, Jul 01, 2026 at 03:42:01PM -0500, Bjorn Helgaas wrote:
> [+cc Kai-Heng, Victor, Lukas, Jon]
> 
> On Wed, Jul 01, 2026 at 08:27:13AM +0200, Manivannan Sadhasivam wrote:
> > On Wed, Jun 10, 2026 at 10:47:23AM +0800, Max Lee wrote:
> > > The Realtek RTS525A PCI-Express SD card reader (10ec:525a) generates
> > > excessive Correctable Error (Replay Timer Timeout) AER events during
> > > PCIe link initialization. On systems where firmware enables AER
> > > reporting (CERptEn+), this causes an AER storm of ~240K error events
> > > within 11 seconds of boot, overwhelming the kernel error handler and
> > > blocking shutdown/reboot.
> 
> Specifically, I guess these error events are the AER interrupts.  We
> rate-limit the actual *messages*, but not the interrupts, so we can be
> overwhelmed by handling them.
> 
> > > The root cause is a transient link training instability inherent to this
> > > device -- even on BIOS versions that suppress reporting, the error
> > > status register (CESta) shows Timeout+ set.
> > > 
> > > Unlike the GL9750/GL9755 fixup, which only masks the parent root port,
> 
> I think PCI_ERR_COR_REP_TIMER is masked in both the GL975x Endpoint
> and the Downstream Port leading to it:
> 
>   015c9cbcf0ad ("mmc: sdhci-pci-gli: GL9750: Mask the replay timer
>   timeout of AER")
> 
>   eeee3b5e6d0b ("PCI: Mask Replay Timer Timeout errors for Genesys
>   GL975x SD host controller")
> 
> Maybe those should be combined so the quirk masks
> PCI_ERR_COR_REP_TIMER at both ends of the link in one place.  A quirk
> like that could be used for both GL975x and RTS525A.
> 
> > > the RTS525A also needs its endpoint Correctable Error Mask bit 12
> > > (PCI_ERR_COR_REP_TIMER) masked when the endpoint exposes AER, so it does
> > > not send ERR_COR messages upstream. Also mask the parent root port to
> > > cover root-port reporting of link errors caused by the endpoint.
> 
> I think this and the similar comment in the code are slightly
> misleading.  pci_mask_replay_timer_timeout() masks
> PCI_ERR_COR_REP_TIMER in the Downstream Port leading to pdev.  That
> may be either a Root Port or a Switch Downstream Port.
> 
> > > Signed-off-by: Max Lee <max.lee@canonical.com>
> > > ---
> > > Changes in v2:
> > >   - Mask the parent root port even when the endpoint lacks AER capability.
> > 
> > You've added this based on the comment by Sashiko I believe. But I
> > think Sashiko was wrong here. If the EP lacks AER capability, then
> > there is no way it is going to send AER errors to upstream RP. So it
> > is OK to skip the quirk.
> 
> I'm not sure it's OK to skip the quirk.
> 
> Based on the flowchart in PCIe r7.0, sec 6.2.5, it looks like an
> Endpoint that detects a Correctable Error but lacks an AER Capability
> sets PCI_EXP_DEVSTA_CED and, if PCI_EXP_DEVCTL_CERE is set, sends
> ERR_COR upstream.
> 

Ah, you're right. I missed CERE.

> I suspect that what we need here is:
> 
>   - Mask PCI_ERR_COR_REP_TIMER in Endpoint to prevent it from sending
>     ERR_COR
> 
>   - Mask PCI_ERR_COR_REP_TIMER in upstream bridge to prevent it from
>     sending ERR_COR
> 
>   - If the upstream bridge is not the Root Port, mask
>     PCI_ERR_COR_REP_TIMER in Root Port to prevent AER interrupt if it
>     receives ERR_COR, e.g., if the Endpoint or bridge lacks AER
> 

If the endpoint lacks AER capability, it will simply send an ERR_COR message to
the upstream bridge without any advanced logging info. Because the message
reaches the Root Port as a generic ERR_COR, RP will log the error in its Root
Error Status register and raise the AER interrupt without checking its own
PCI_ERR_COR_REP_TIMER mask status. Also, any upstream bridge lacking AER
capability will simply forward the ERR_COR message upstream irrespective of its
own PCI_ERR_COR_REP_TIMER status.

So if the endpoint lacks AER capability, we cannot prevent it from reporting the
error, unless we disable CERE, which will affect other errors also. However, we
can still mask PCI_ERR_COR_REP_TIMER in the upstream bridge's AER to prevent
the bridge itself from generating its own Replay Link Timeout errors due to the
endpoint's behavior, but this acts only as a safeguard and will not prevent the
messages originating from the endpoint.

Correct me if my understanding is wrong.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Lukas Wunner]

On Thu, Jul 02, 2026 at 03:06:29PM +0800, Max Lee wrote:
> Both the endpoint and the immediate upstream port expose AER capability.
> On this unpatched boot, Replay Timer Timeout is not masked on either side.
> 
> Endpoint 0000:58:00.0:
> 
>   Capabilities: [100 v2] Advanced Error Reporting
>       CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
>       CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
> 
> Root Port 0000:00:1c.6:
> 
>   Capabilities: [100 v1] Advanced Error Reporting
>       CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr-
>       CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- AdvNonFatalErr+
>       RootCmd: CERptEn+ NFERptEn+ FERptEn+
>       ErrorSrc: ERR_COR: 5800 ERR_FATAL/NONFATAL: 0000

There were Advisory Non-Fatal Errors on both ends of the links.
The upstream kernel does not support ANFE so far, but this
development branch contains three tentative patches to add it:

https://github.com/l1k/linux/commits/anfe_v1/

So far this is compile-tested only.  You may want to give these
patches a spin to see which Non-Fatal Errors are signaled.  The
kernel should also dump the TLP Prefix Log for those errors and
you can use this tool to decode it:

https://github.com/mmpg-x86/tlp-tool

See the example usage in:  Documentation/PCI/pcieaer-howto.rst

The TLP Prefix Log might give a hint as to the root cause.

Your commit message mentions a "transient link training instability",
but I think if that were the case, you'd see Surprise Link Down Errors
(which are Fatal Errors).  Except if the Root Port was hotplug-capable,
in which case Surprise Link Down Error generation is blocked per
PCIe r7.0 sec 3.2.1.  Another exception would be if the Root Port is
not Surprise Down Error Reporting Capable (bit 19 in the Link
Capabilities Register).

Bjorn mentioned commit eeee3b5e6d0b, which states that the Replay Timer
Timeout errors (only) occur when ASPM is enabled.  That may be the
actual root cause, so you may want to play with ASPM settings (disable
L1 substates etc) to see if it makes the issue go away.  Disabling
non-working ASPM settings in a quirk would be better than silencing
the ensuing errors.

Thanks,

Lukas

Re: [PATCH v2] PCI: Mask Replay Timer Timeout for Realtek RTS525A

[Max Lee]

On Thu, Jul 02, 2026 at 04:42:43PM +0200, Lukas Wunner wrote:
> There were Advisory Non-Fatal Errors on both ends of the links.
> The upstream kernel does not support ANFE so far, but this
> development branch contains three tentative patches to add it:
>
> https://github.com/l1k/linux/commits/anfe_v1/
>
> So far this is compile-tested only. You may want to give these
> patches a spin to see which Non-Fatal Errors are signaled. The
> kernel should also dump the TLP Prefix Log for those errors and
> you can use this tool to decode it:
>
> https://github.com/mmpg-x86/tlp-tool
>
> See the example usage in: Documentation/PCI/pcieaer-howto.rst
>
> The TLP Prefix Log might give a hint as to the root cause.
>
> [...]
>
> Bjorn mentioned commit eeee3b5e6d0b, which states that the Replay Timer
> Timeout errors (only) occur when ASPM is enabled. That may be the
> actual root cause, so you may want to play with ASPM settings (disable
> L1 substates etc) to see if it makes the issue go away. Disabling
> non-working ASPM settings in a quirk would be better than silencing
> the ensuing errors.

Thanks Lukas for the suggestions

I tested Lukas' anfe_v1 branch on the affected system:

https://github.com/l1k/linux.git anfe_v1
ca3701e1b037 ("PCI/AER: Support Advisory Non-Fatal Errors")

The tested kernel was:

Linux localhost 7.2.0-rc1+ #2 SMP PREEMPT_DYNAMIC Fri Jul 3 08:00:24 UTC 2026

With that kernel, the storm still reproduced, but the reported error
remained a Correctable Replay Timer Timeout. I did not see Advisory
Non-Fatal Error or TLP Prefix/Header Log output for this storm.

The relevant dmesg lines were still:

pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0
pci 0000:58:00.0: PCIe Bus Error: severity=Correctable
pci 0000:58:00.0: device [10ec:525a] error status/mask=00001000/00004000
pci 0000:58:00.0: [12] Timeout | Transmitter | Data Link Layer

In that boot, dmesg contained 767 printed Correctable/Timeout messages
and 76 aer_ratelimit lines. The actual interrupt/counter volume was much
higher. Before stopping the storm, /proc/interrupts showed:

IR-PCI-MSI-0000:00:1c.6 ... 37981589 ... PCIe PME, aerdrv, PCIe bwctrl

The AER sysfs counters showed:

Endpoint 0000:58:00.0:
Timeout 12018352
TOTAL_ERR_COR 12018352
TOTAL_ERR_FATAL 0
TOTAL_ERR_NONFATAL 0

Root Port 0000:00:1c.6:
aer_rootport_total_err_cor 12062319
aer_rootport_total_err_fatal 0
aer_rootport_total_err_nonfatal 0

I then tested the ASPM settings directly. With OS-native AER active,
disabling only L0s on the RTS525A link stopped new AER interrupt and
counter growth while leaving L1 enabled:

echo 0 > /sys/bus/pci/devices/0000:58:00.0/link/l0s_aspm

After that, over a 10 second interval:

irq_delta=0
endpoint_cor_delta=0
rootport_cor_delta=0
link_l0s=0
link_l1=1

Disabling L1, L1 substates, or Clock PM alone did not stop the storm.
The storm also did not require the rtsx_pci driver to bind: it was
reproducible while rtsx_pci/rtsx_pci_sdmmc were blacklisted and the
endpoint was not enabled by a driver.

Based on this, I agree that disabling the non-working ASPM state is a
better direction than masking the resulting AER reports.

I tested a v3 patch that disables L0s for the RTS525A by removing L0s
from the device's ASPM link capability:

DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_REALTEK, 0x525a,
quirk_disable_aspm_l0s);

I tested that patch on top of Lukas' anfe_v1 branch. The patched kernel
booted as:

Linux localhost 7.2.0-rc1-rts525a-l0s+ #4 SMP PREEMPT_DYNAMIC Mon Jul
6 02:08:30 UTC 2026

The quirk ran during enumeration:

pci 0000:58:00.0: ASPM: Link Capabilities L0s treated as unsupported
to avoid device defect

With the temporary rtsx_pci blacklist removed and the initramfs rebuilt,
the card reader driver bound normally:

  rtsx_pci 0000:58:00.0: enabling device (0000 -> 0002)

  rtsx_pci_sdmmc         36864  0
  rtsx_pci              143360  1 rtsx_pci_sdmmc

The endpoint was enabled and bound to rtsx_pci:

  0000:58:00.0 enable=1
  0000:58:00.0 power_state=D3hot
  driver=/sys/bus/pci/drivers/rtsx_pci

L0s was no longer enabled, while L1 remained enabled on both ends of the
link:

  0000:00:1c.6:
    LnkCtl: ASPM L1 Enabled

  0000:58:00.0:
    LnkCtl: ASPM L1 Enabled

The endpoint link sysfs state also showed L1 and L1 substates still
enabled:

  clkpm=1
  l1_1_aspm=1
  l1_1_pcipm=1
  l1_2_aspm=1
  l1_2_pcipm=1
  l1_aspm=1

The l0s_aspm sysfs file was no longer present for the endpoint link,
consistent with L0s being removed from the ASPM capability.

After booting the patched kernel with rtsx_pci bound, there were no AER
Correctable Replay Timer Timeout messages and no aer_ratelimit lines in
dmesg:

  aer_correctable=0
  timeout_lines=0
  ratelimit_lines=0

Over a 10 second interval after boot, IRQ and AER counters did not
increase:

  irq_delta=0
  endpoint_cor_delta=0
  rootport_cor_delta=0

The counters stayed at zero:

  Endpoint 0000:58:00.0:
    Timeout 0
    TOTAL_ERR_COR 0

  Root Port 0000:00:1c.6:
    aer_rootport_total_err_cor 0

So for this system, the evidence points specifically at L0s on the
RTS525A link: enabling L0s triggers the Correctable Replay Timer Timeout
storm, and disabling L0s stops it while leaving L1 enabled.

I will send v3 changing the quirk from masking AER Replay Timer Timeout
to disabling ASPM L0s for the RTS525A.

Thanks,
Max

[PATCH v3] PCI: Disable ASPM L0s for Realtek RTS525A

[Max Lee]

The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
Timer Timeout storm when ASPM L0s is enabled on its link.  On an affected
HP ZBook Power 16 inch G11, the Root Port received tens of millions of
AER interrupts from the RTS525A even when the rtsx_pci driver was
blacklisted and the endpoint was not enabled by a driver.

Testing with OS-native AER control showed that disabling only L0s on the
RTS525A link stops new AER interrupt and counter growth while leaving L1
enabled.  Disabling L1, L1 substates, or Clock PM alone did not stop the
storm.

Prevent the broken L0s configuration by removing L0s from the RTS525A
advertised ASPM capability.  This avoids enabling the non-working ASPM
state instead of masking the resulting AER Replay Timer Timeout reports.

Signed-off-by: Max Lee <max.lee@canonical.com>
---
Changes in v3:
  - Disable ASPM L0s for RTS525A instead of masking AER Replay Timer
    Timeout reports.
  - Keep ASPM L1 enabled based on testing that only L0s is required to
    reproduce the storm.
  - Drop the endpoint/root-port AER mask quirk from v2.

 drivers/pci/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc0..e63ed055f466 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2520,6 +2520,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10f1, quirk_disable_aspm_l0s);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
 
+/* Realtek RTS525A generates Replay Timer Timeouts when L0s is enabled. */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_REALTEK, 0x525a, quirk_disable_aspm_l0s);
+
 static void quirk_disable_aspm_l0s_l1(struct pci_dev *dev)
 {
 	pcie_aspm_remove_cap(dev,
-- 
2.43.0

Re: [PATCH v3] PCI: Disable ASPM L0s for Realtek RTS525A

[sashiko-bot]

> The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
> Timer Timeout storm when ASPM L0s is enabled on its link.  On an affected
> HP ZBook Power 16 inch G11, the Root Port received tens of millions of
> AER interrupts from the RTS525A even when the rtsx_pci driver was
> blacklisted and the endpoint was not enabled by a driver.
> 
> Testing with OS-native AER control showed that disabling only L0s on the
> RTS525A link stops new AER interrupt and counter growth while leaving L1
> enabled.  Disabling L1, L1 substates, or Clock PM alone did not stop the
> storm.
> 
> Prevent the broken L0s configuration by removing L0s from the RTS525A
> advertised ASPM capability.  This avoids enabling the non-working ASPM
> state instead of masking the resulting AER Replay Timer Timeout reports.
> 
> Signed-off-by: Max Lee <max.lee@canonical.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260706025358.516607-1-max.lee@canonical.com?part=1

Re: [PATCH v3] PCI: Disable ASPM L0s for Realtek RTS525A

[Lukas Wunner]

On Mon, Jul 06, 2026 at 10:53:58AM +0800, Max Lee wrote:
> The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
> Timer Timeout storm when ASPM L0s is enabled on its link.  On an affected
> HP ZBook Power 16 inch G11, the Root Port received tens of millions of
> AER interrupts from the RTS525A even when the rtsx_pci driver was
> blacklisted and the endpoint was not enabled by a driver.
> 
> Testing with OS-native AER control showed that disabling only L0s on the
> RTS525A link stops new AER interrupt and counter growth while leaving L1
> enabled.  Disabling L1, L1 substates, or Clock PM alone did not stop the
> storm.
> 
> Prevent the broken L0s configuration by removing L0s from the RTS525A
> advertised ASPM capability.  This avoids enabling the non-working ASPM
> state instead of masking the resulting AER Replay Timer Timeout reports.
> 
> Signed-off-by: Max Lee <max.lee@canonical.com>

Reviewed-by: Lukas Wunner <lukas@wunner.de>
Cc: stable@vger.kernel.org

Thanks for your great analysis in:

https://lore.kernel.org/r/CA+YcyLw0HpR1Dnz-mOL1Ryym89ytc=1a_Ri9buMt3at-9mib+g@mail.gmail.com/

In fact a quick Google search finds other reports of ASPM issues with
this card reader.  This one is for Linux and talks about Receiver Errors
with RTS525A which are fixed by pcie_aspm=off, a more targeted fix was
apparently not developed:

https://github.com/pop-os/pop/issues/3775

And another one for macOS specifically mentioning non-working L0s on
RTS525A:

https://github.com/5T33Z0/OC-Little-Translated/blob/main/Content/04_Fixing_Sleep_and_Wake_Issues/Setting_ASPM_Operating_Mode/README.md

It looks like this product just doesn't support L0s and the vendor
neglected to set the ASPM Support bits in the Link Capabilities Register
correctly.

Thanks,

Lukas

Re: [PATCH v3] PCI: Disable ASPM L0s for Realtek RTS525A

[Manivannan Sadhasivam]

On Mon, Jul 06, 2026 at 10:53:58AM +0800, Max Lee wrote:
> The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
> Timer Timeout storm when ASPM L0s is enabled on its link.  On an affected
> HP ZBook Power 16 inch G11, the Root Port received tens of millions of
> AER interrupts from the RTS525A even when the rtsx_pci driver was
> blacklisted and the endpoint was not enabled by a driver.
> 
> Testing with OS-native AER control showed that disabling only L0s on the
> RTS525A link stops new AER interrupt and counter growth while leaving L1
> enabled.  Disabling L1, L1 substates, or Clock PM alone did not stop the
> storm.
> 
> Prevent the broken L0s configuration by removing L0s from the RTS525A
> advertised ASPM capability.  This avoids enabling the non-working ASPM
> state instead of masking the resulting AER Replay Timer Timeout reports.
> 

If you can add the AER log snippet here, it will help others to find this quirk
in the future.

> Signed-off-by: Max Lee <max.lee@canonical.com>

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

One minor nit below...

> ---
> Changes in v3:
>   - Disable ASPM L0s for RTS525A instead of masking AER Replay Timer
>     Timeout reports.
>   - Keep ASPM L1 enabled based on testing that only L0s is required to
>     reproduce the storm.
>   - Drop the endpoint/root-port AER mask quirk from v2.
> 
>  drivers/pci/quirks.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index caaed1a01dc0..e63ed055f466 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2520,6 +2520,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10f1, quirk_disable_aspm_l0s);
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
>  
> +/* Realtek RTS525A generates Replay Timer Timeouts when L0s is enabled. */

s/Replay Timer Timeouts/Replay Timer Timeout Storm

to stress the severity.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

[PATCH v4] PCI: Disable ASPM L0s for Realtek RTS525A

[Max Lee]

The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
Timer Timeout storm when ASPM L0s is enabled on its link.  On an affected
HP ZBook Power 16 inch G11, the Root Port received tens of millions of
AER interrupts from the RTS525A even when the rtsx_pci driver was
blacklisted and the endpoint was not enabled by a driver.

For example:

  pcieport 0000:00:1c.6: AER: Multiple Correctable error message received from 0000:58:00.0
  rtsx_pci 0000:58:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID)
  rtsx_pci 0000:58:00.0:   device [10ec:525a] error status/mask=00001000/00006000
  rtsx_pci 0000:58:00.0:    [12] Timeout
  pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0

Testing with OS-native AER control showed that disabling only L0s on the
RTS525A link stops new AER interrupt and counter growth while leaving L1
enabled.  Disabling L1, L1 substates, or Clock PM alone did not stop the
storm.

Prevent the broken L0s configuration by removing L0s from the RTS525A
advertised ASPM capability.  This avoids enabling the non-working ASPM
state instead of masking the resulting AER Replay Timer Timeout reports.

Reviewed-by: Lukas Wunner <lukas@wunner.de>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Max Lee <max.lee@canonical.com>
---
Changes in v4:
  - Add an AER log snippet to make the quirk easier to find.
  - Reword the RTS525A comment to describe this as a Replay Timer Timeout storm.
  - Add Reviewed-by tags from Lukas Wunner and Manivannan Sadhasivam.
  - Add Cc stable tag as suggested by Lukas Wunner.

 drivers/pci/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index caaed1a01dc0..ab94bd7f3a34 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -2520,6 +2520,9 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10f1, quirk_disable_aspm_l0s);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x10f4, quirk_disable_aspm_l0s);
 DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x1508, quirk_disable_aspm_l0s);
 
+/* Realtek RTS525A generates a Replay Timer Timeout storm when L0s is enabled. */
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_REALTEK, 0x525a, quirk_disable_aspm_l0s);
+
 static void quirk_disable_aspm_l0s_l1(struct pci_dev *dev)
 {
 	pcie_aspm_remove_cap(dev,
-- 
2.43.0

Re: [PATCH v4] PCI: Disable ASPM L0s for Realtek RTS525A

[sashiko-bot]

> The Realtek RTS525A PCIe card reader reports an AER Correctable Replay
> Timer Timeout storm when ASPM L0s is enabled on its link.  On an affected
> HP ZBook Power 16 inch G11, the Root Port received tens of millions of
> AER interrupts from the RTS525A even when the rtsx_pci driver was
> blacklisted and the endpoint was not enabled by a driver.
> 
> For example:
> 
>   pcieport 0000:00:1c.6: AER: Multiple Correctable error message received from 0000:58:00.0
>   rtsx_pci 0000:58:00.0: PCIe Bus Error: severity=Correctable, type=Data Link Layer, (Transmitter ID)
>   rtsx_pci 0000:58:00.0:   device [10ec:525a] error status/mask=00001000/00006000
>   rtsx_pci 0000:58:00.0:    [12] Timeout
>   pcieport 0000:00:1c.6: AER: Correctable error message received from 0000:58:00.0
> 
> Testing with OS-native AER control showed that disabling only L0s on the
> RTS525A link stops new AER interrupt and counter growth while leaving L1
> enabled.  Disabling L1, L1 substates, or Clock PM alone did not stop the
> storm.
> 
> Prevent the broken L0s configuration by removing L0s from the RTS525A
> advertised ASPM capability.  This avoids enabling the non-working ASPM
> state instead of masking the resulting AER Replay Timer Timeout reports.
> 
> Reviewed-by: Lukas Wunner <lukas@wunner.de>
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
> Cc: stable@vger.kernel.org
> Signed-off-by: Max Lee <max.lee@canonical.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260707021527.639611-1-max.lee@canonical.com?part=1