linux-kernel - Re: [PATCH] PCI: qcom: Clear ASPM L0s CAP for MSM8996 SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cdebc4f2-202b-46b2-9cdf-0ebce1ffd98e@oss.qualcomm.com>
Date: Thu, 27 Nov 2025 15:12:08 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: Manivannan Sadhasivam <manivannan.sadhasivam@....qualcomm.com>,
        lpieralisi@...nel.org, kwilczynski@...nel.org, bhelgaas@...gle.com,
        robh@...nel.org, linux-pci@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH] PCI: qcom: Clear ASPM L0s CAP for MSM8996 SoC

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