From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

Though I couldn't confirm the ASPM L0s support with the Qcom hardware team,
bug report from Dmitry suggests that L0s is broken on this legacy SoC.
Hence, clear the L0s CAP for the Root Ports in this SoC.

Since qcom_pcie_clear_aspm_l0s() is now used by more than one SoC config,
call it from qcom_pcie_host_init() instead.

Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Closes: https://lore.kernel.org/linux-pci/4cp5pzmlkkht2ni7us6p3edidnk25l45xrp6w3fxguqcvhq2id@wjqqrdpkypkf
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
---
 drivers/pci/controller/dwc/pcie-qcom.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/controller/dwc/pcie-qcom.c b/drivers/pci/controller/dwc/pcie-qcom.c
index 805edbbfe7eb..25399d47fc40 100644
--- a/drivers/pci/controller/dwc/pcie-qcom.c
+++ b/drivers/pci/controller/dwc/pcie-qcom.c
@@ -1088,7 +1088,6 @@ static int qcom_pcie_post_init_2_7_0(struct qcom_pcie *pcie)
 		writel(WR_NO_SNOOP_OVERRIDE_EN | RD_NO_SNOOP_OVERRIDE_EN,
 				pcie->parf + PARF_NO_SNOOP_OVERRIDE);
 
-	qcom_pcie_clear_aspm_l0s(pcie->pci);
 	qcom_pcie_clear_hpc(pcie->pci);
 
 	return 0;
@@ -1350,6 +1349,8 @@ static int qcom_pcie_host_init(struct dw_pcie_rp *pp)
 			goto err_disable_phy;
 	}
 
+	qcom_pcie_clear_aspm_l0s(pcie->pci);
+
 	qcom_ep_reset_deassert(pcie);
 
 	if (pcie->cfg->ops->config_sid) {
@@ -1486,6 +1487,7 @@ static const struct qcom_pcie_cfg cfg_2_1_0 = {
 
 static const struct qcom_pcie_cfg cfg_2_3_2 = {
 	.ops = &ops_2_3_2,
+	.no_l0s = true,
 };
 
 static const struct qcom_pcie_cfg cfg_2_3_3 = {
-- 
2.48.1

On 11/26/25 9:17 AM, Manivannan Sadhasivam wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> Though I couldn't confirm the ASPM L0s support with the Qcom hardware team,
> bug report from Dmitry suggests that L0s is broken on this legacy SoC.
> Hence, clear the L0s CAP for the Root Ports in this SoC.

FWIW if we trust the downstream DT, we have this hunk:

arch/arm64/boot/dts/qcom/msm8996.dtsi
1431:           qcom,l1-supported;
1432:           qcom,l1ss-supported;
1586:           qcom,l1-supported;
1587:           qcom,l1ss-supported;
1739:           qcom,l1-supported;
1740:           qcom,l1ss-supported;

But also funnily enough, msm8996auto boards specifically manually
do a /delete-property/ on those..

(there exists one 'qcom,l0s-supported', but it's NOT set for 8996, 98,
or 845)

On msm-4.14, this became "qcom,no-l0s/l1/l1ss-supported". This forbids L0s
on at least 8150 and 8250.

Later, both hosts on SM8350 and SM8450-PCIe0 (not 1) forbid L0s.

SM8350-PCIe0 sets 'qcom,l1ss-sleep-disable' which influences some RPMh
things, but also prevents some clock ops wrt the CLKREF source

There's probably more platforms affected, this was a quick grep.

Konrad

On Thu, Nov 27, 2025 at 11:55:15AM +0100, Konrad Dybcio wrote:
> On 11/26/25 9:17 AM, Manivannan Sadhasivam wrote:
> > From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> > 
> > Though I couldn't confirm the ASPM L0s support with the Qcom hardware team,
> > bug report from Dmitry suggests that L0s is broken on this legacy SoC.
> > Hence, clear the L0s CAP for the Root Ports in this SoC.
> 
> FWIW if we trust the downstream DT, we have this hunk:
> 
> arch/arm64/boot/dts/qcom/msm8996.dtsi
> 1431:           qcom,l1-supported;
> 1432:           qcom,l1ss-supported;
> 1586:           qcom,l1-supported;
> 1587:           qcom,l1ss-supported;
> 1739:           qcom,l1-supported;
> 1740:           qcom,l1ss-supported;
> 
> But also funnily enough, msm8996auto boards specifically manually
> do a /delete-property/ on those..
> 
> (there exists one 'qcom,l0s-supported', but it's NOT set for 8996, 98,
> or 845)
> 
> On msm-4.14, this became "qcom,no-l0s/l1/l1ss-supported". This forbids L0s
> on at least 8150 and 8250.
> 
> Later, both hosts on SM8350 and SM8450-PCIe0 (not 1) forbid L0s.
> 

Thanks for digging in. Unfortunately, I have to rely on word of mouth to get the
ASPM capability as there is no proper doc that says which SoC supports which
state. And, I'm quite nervous to trust downstream DTS as they were not very
accurate in describing the hardware capabilities. But I think we should atleast
consider the 'no-l0s' properties seriously.

Let me go through all DTS and build try to build a sane ASPM compatibility
table. But just be clear, the above exercise should not block this patch as it
fixes a real issue that has been reported.

> SM8350-PCIe0 sets 'qcom,l1ss-sleep-disable' which influences some RPMh
> things, but also prevents some clock ops wrt the CLKREF source
> 

We can ignore 'qcom,l1ss-sleep-disable' as it is a Qcom low power feature built
around PCIe L1ss, which is not yet supported in upstream.

- Mani

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

On 11/27/25 2:55 PM, Manivannan Sadhasivam wrote:
> On Thu, Nov 27, 2025 at 11:55:15AM +0100, Konrad Dybcio wrote:
>> On 11/26/25 9:17 AM, Manivannan Sadhasivam wrote:
>>> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>>>
>>> Though I couldn't confirm the ASPM L0s support with the Qcom hardware team,
>>> bug report from Dmitry suggests that L0s is broken on this legacy SoC.
>>> Hence, clear the L0s CAP for the Root Ports in this SoC.
>>
>> FWIW if we trust the downstream DT, we have this hunk:
>>
>> arch/arm64/boot/dts/qcom/msm8996.dtsi
>> 1431:           qcom,l1-supported;
>> 1432:           qcom,l1ss-supported;
>> 1586:           qcom,l1-supported;
>> 1587:           qcom,l1ss-supported;
>> 1739:           qcom,l1-supported;
>> 1740:           qcom,l1ss-supported;
>>
>> But also funnily enough, msm8996auto boards specifically manually
>> do a /delete-property/ on those..
>>
>> (there exists one 'qcom,l0s-supported', but it's NOT set for 8996, 98,
>> or 845)
>>
>> On msm-4.14, this became "qcom,no-l0s/l1/l1ss-supported". This forbids L0s
>> on at least 8150 and 8250.
>>
>> Later, both hosts on SM8350 and SM8450-PCIe0 (not 1) forbid L0s.
>>
> 
> Thanks for digging in. Unfortunately, I have to rely on word of mouth to get the
> ASPM capability as there is no proper doc that says which SoC supports which
> state. And, I'm quite nervous to trust downstream DTS as they were not very
> accurate in describing the hardware capabilities. But I think we should atleast
> consider the 'no-l0s' properties seriously.
> 
> Let me go through all DTS and build try to build a sane ASPM compatibility
> table. But just be clear, the above exercise should not block this patch as it
> fixes a real issue that has been reported.

Yeah definitely

fwiw

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>


>> SM8350-PCIe0 sets 'qcom,l1ss-sleep-disable' which influences some RPMh
>> things, but also prevents some clock ops wrt the CLKREF source
>>
> 
> We can ignore 'qcom,l1ss-sleep-disable' as it is a Qcom low power feature built
> around PCIe L1ss, which is not yet supported in upstream.

OK thanks

Konrad

On Wed, Nov 26, 2025 at 01:47:18PM +0530, Manivannan Sadhasivam wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> 
> Though I couldn't confirm the ASPM L0s support with the Qcom hardware team,
> bug report from Dmitry suggests that L0s is broken on this legacy SoC.
> Hence, clear the L0s CAP for the Root Ports in this SoC.
> 
> Since qcom_pcie_clear_aspm_l0s() is now used by more than one SoC config,
> call it from qcom_pcie_host_init() instead.
> 
> Reported-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Closes: https://lore.kernel.org/linux-pci/4cp5pzmlkkht2ni7us6p3edidnk25l45xrp6w3fxguqcvhq2id@wjqqrdpkypkf
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
>  drivers/pci/controller/dwc/pcie-qcom.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Tested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>

Thanks!

-- 
With best wishes
Dmitry