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

[Bjorn Helgaas <helgaas@kernel.org>]

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.
> 
> > 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?

> On our Qcom platforms, we do have some co-processors handling this
> even before the OS wakesup.  But support for that co-processor is
> currently not available in upstream and we don't know when it is
> going to be added. Until then, we only have one option to not put
> the link to L1ss during suspend and keep the devices into D3Cold to
> achieve the SoC low power state.
> 
> > Maybe that's part of why pm_suspend_via_firmware() exists.  What
> > if native host drivers just called pm_set_suspend_via_firmware()?
> > After all, if they support suspend, they're doing things that are
> > done by firmware on other systems.
> 
> No, that would be inappropriate. pm_set_suspend_via_firmware() is
> supposed to be called only when the firmware is invoked at the end
> of suspend. If OS handles everything and not the firmware, there is
> no need to invoke this API.

This is part of my issue with the "pm_suspend_via_firmware()" name --
it doesn't really matter whether the code is in the OS or in the
firmware.  What matters is what the code *does* or is *allowed* to do.
The native host bridge drivers do things that are done by firmware on
ACPI systems, so the "via_firmware" part is not as clear as it once
was.