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

[Manivannan Sadhasivam]

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

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

I partly agree with you. But it should be noted that this API doesn't just apply
to PCI alone, but for the overall system. So even if the native host controller
drivers are present, the firmware might do something more at the end of suspend.
This is exactly what happens on ARM64 systems where PSCI firmware carries out
some activities at the end of suspend and we still have host controller drivers
doing some power management. Consequently, even if the host controller driver
wants to keep the bus active, the firmware might power down the whole PCI bus
for system power savings.

So you are right that host controller drivers do what the firmware might do on
ACPI based systems, but there could be some firmware involvement also.

For this series, I'm trying to keep the existing behavior intact and just
introduce one more check. But if we want to move away from
pm_suspend_via_firmware(), that could be done as a follow up series. Wdyt?

- Mani

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