Re: [PATCH 3/4] PCI: qcom: Indicate broken L1ss exit during resume from system suspend

[Bjorn Helgaas <helgaas@kernel.org>]

On Tue, Apr 21, 2026 at 10:41:08PM +0530, Manivannan Sadhasivam wrote:
> On Mon, Apr 20, 2026 at 03:49:15PM -0500, Bjorn Helgaas wrote:
> > On Sat, Apr 18, 2026 at 11:09:11AM +0530, Manivannan Sadhasivam wrote:
> > > On Fri, Apr 17, 2026 at 05:26:15PM -0500, Bjorn Helgaas wrote:
> > > ...
> > 
> > > > Does L1.2 have to meet the advertised L1 Exit Latency?  I assume
> > > > maybe it does because I don't see an exception for L1.x or any
> > > > exit latencies advertised in the L1 PM Substates Capability.
> > > 
> > > As per my understanding, 'L1 Exit Latency' only covers ASPM L1
> > > state, not L1ss.  Because, 'L1 Exit Latency' field exists even
> > > before L1 PM Substates got introduced in r3.1. So it doesn't cover
> > > L1.2 exit latency.

FWIW, this FAQ from https://pcisig.com/faq?keys=3.0 confirms your
understanding:

  Section 7.8.6 - Is the L1 Exit Latency in the Link Capabilities
  register only the ASPM L1.0 exit latency or does it include the
  added ASPM L1.2 to ASPM L1.0 latency?

    The ASPM L1 Exit Latency in the Link Capabilities register
    indicates the L1/L1.0 to L0 latency, and does not include added
    latency due to Clock Power Management, L1.1 or L1.2.

> > > > Regardless, I'd be kind of surprised if *any* system could meet an
> > > > L1.2 exit latency from a system suspend situation where PHY power
> > > > is removed.  On ACPI systems, the OS doesn't know how to remove
> > > > PHY power, so I don't think that situation can happen unless
> > > > firmware is involved in the suspend.
> > > 
> > > Yes, you are right. Even for systems turning off the PHY completely,
> > > they should have some mechanism to detect the CLKREQ# assert and
> > > turn ON the PHY within the expected time.
> > 
> > What would the expected time be?
> 
> That's mostly L10_REFCLK_ON + T_COMMONMODE. But nevertheless, the
> system wakeup and controller driver resume() time would be far
> greater than it.

This patch sets "pp->bridge->broken_l1ss_resume = true".  I'm trying
to understand how we know to set this.  There might be other platforms
that need to do this but I don't know how to identify them.

This comment:

  + * Some host bridges power off the PHY to enter deep low-power modes
  + * during system suspend. Exiting L1 PM Substates from this condition
  + * violates strict timing requirements and results in Link Down (LDn).
  + * On such platforms, the endpoint must be prepared for context loss.

suggests that the L1.2 exit takes too long and results in the link
going down, which is essentially a reset for the downstream device,
which would destroy the context.

Is there some spec language that determines how long the Downstream
Port waits for the L1.2 exit before it gives up and decides the link
is down?