| 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
| ||
|
Message-ID: <v5yuwkfoegmtccn4qrbs2mj2uj2qxnwmix67whxmujtggdheo6@bk4vv54z6izj> Date: Wed, 4 Feb 2026 18:24:43 +0530 From: Manivannan Sadhasivam <mani@...nel.org> To: Konrad Dybcio <konrad.dybcio@....qualcomm.com> Cc: Qiang Yu <qiang.yu@....qualcomm.com>, Bjorn Andersson <andersson@...nel.org>, Pankaj Patil <pankaj.patil@....qualcomm.com>, Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, Krzysztof Kozlowski <krzysztof.kozlowski@....qualcomm.com>, Jyothi Kumar Seerapu <jyothi.seerapu@....qualcomm.com>, Maulik Shah <maulik.shah@....qualcomm.com>, Sibi Sankar <sibi.sankar@....qualcomm.com>, Taniya Das <taniya.das@....qualcomm.com>, Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>, Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@....qualcomm.com>, Jishnu Prakash <jishnu.prakash@....qualcomm.com>, Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>, Abel Vesa <abelvesa@...nel.org> Subject: Re: [PATCH v6 0/4] arm64: dts: qcom: Introduce Glymur SoC dtsi and Glymur CRD dts On Tue, Feb 03, 2026 at 10:50:26AM +0100, Konrad Dybcio wrote: > On 2/2/26 11:21 AM, Qiang Yu wrote: > > On Mon, Feb 02, 2026 at 10:49:10AM +0100, Konrad Dybcio wrote: > >> On 2/2/26 6:21 AM, Qiang Yu wrote: > >>> On Thu, Jan 29, 2026 at 01:07:08PM +0100, Konrad Dybcio wrote: > >>>> On 1/29/26 1:05 PM, Qiang Yu wrote: > >>>>> On Wed, Jan 28, 2026 at 07:21:04PM -0600, Bjorn Andersson wrote: > >>>>>> On Thu, Jan 22, 2026 at 08:53:57PM +0530, Pankaj Patil wrote: > >>>>>>> Introduce dt-bindings and initial device tree support for Glymur, > >>>>>>> Qualcomm's next-generation compute SoC and it's associated > >>>>>>> Compute Reference Device (CRD) platform. > >>>>>>> > >>>>>>> https://www.qualcomm.com/products/mobile/snapdragon/laptops-and-tablets/snapdragon-x2-elite > >>>>>>> https://www.qualcomm.com/news/releases/2025/09/new-snapdragon-x2-elite-extreme-and-snapdragon-x2-elite-are-the- > >>>>>>> > >>>>>>> The base support enables booting to shell with rootfs on NVMe, > >>>>>>> demonstrating functionality for PCIe and NVMe subsystems. > >>>>>>> DCVS is also enabled, allowing dynamic frequency scaling for the CPUs. > >>>>>>> TSENS (Thermal Sensors) enabled for monitoring SoC temperature and > >>>>>>> thermal management. The platform is capable of booting kernel at EL2 > >>>>>>> with kvm-unit tests performed on it for sanity. > >>>>>>> > >>>>>>> Added dtsi files for the PMIC's enabled PMH0101, PMK8850, PMCX0102, > >>>>>>> SMB2370, PMH0104, PMH0110 along with temp-alarm and GPIO nodeS. > >>>>>>> > >>>>>>> For CPU compatible naming, there is one discussion which is not specific > >>>>>>> to Glymur, Kaanapali and Glymur use the same Oryon cores. > >>>>>>> https://lore.kernel.org/all/20251119-oryon-binding-v1-1-f79a101b0391@oss.qualcomm.com/ > >>>>>>> We've kept the "qcom,oryon" compatible > >>>>>>> > >>>>>>> Features enabled in this patchset: > >>>>>>> 1. NVMe storage support > >>>>>>> 2. PCIe controller and PCIe PHY > >>>>>>> 3. RPMH Regulators > >>>>>>> 4. Clocks and reset controllers - GCC, TCSRCC, DISPCC, RPMHCC > >>>>>>> 5. Interrupt controller > >>>>>>> 6. TLMM (Top-Level Mode Multiplexer) > >>>>>>> 7. QUP Block > >>>>>>> 8. Reserved memory regions > >>>>>>> 9. PMIC support with regulators > >>>>>>> 10. CPU Power Domains > >>>>>>> 11. TSENS (Thermal Sensors) > >>>>>>> 12. DCVS: CPU DCVS with scmi perf protocol > >>>>>>> > >>>>>>> Dependencies: > >>>>>>> > >>>>>>> dt-bindings: > >>>>>>> 1. https://lore.kernel.org/all/20260121-glymur-pmic-mfd-v1-1-2aab4f21e79c@oss.qualcomm.com/ > >>>>>>> 2. https://lore.kernel.org/all/20251215-knp-pmic-leds-v3-2-5e583f68b0e5@oss.qualcomm.com/ > >>>>>>> 3. https://lore.kernel.org/all/20260121110828.2267061-1-pankaj.patil@oss.qualcomm.com/ > >>>>>>> 4. https://lore.kernel.org/all/20260111155234.5829-1-pankaj.patil@oss.qualcomm.com/ > >>>>>>> > >>>>>>> Linux-next based tree with Glymur patches is available at: > >>>>>>> https://git.codelinaro.org/clo/linux-kernel/kernel-qcom/-/tree/b4/v6_glymur_introduction > >>>>>>> > >>>>>> > >>>>>> FWIW, I applied these patches onto next-20260128 to see if things has > >>>>>> improved since Rob's report and I get: > >>>>>> > >>>>>> $ make qcom/glymur-crd.dtb CHECK_DTBS=1 > >>>>>> DTC [C] arch/arm64/boot/dts/qcom/glymur-crd.dtb > >>>>>> qcom/glymur-crd.dtb: dma-controller@...000 (qcom,glymur-gpi-dma): interrupts: [[0, 588, 4], [0, 589, 4], [0, 590, 4], [0, 591, 4], [0, 592, 4], [0, 593, 4], [0, 594, 4], [0, 595, 4], [0, 596, 4], [0, 597, 4], [0, 598, 4], [0, 599, 4], [2, 129, 4], [2, 130, 4], [2, 131, 4], [2, 132, 4]] is too long > >>>>>> from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml# > >>>>>> qcom/glymur-crd.dtb: dma-controller@...000 (qcom,glymur-gpi-dma): interrupts: [[0, 279, 4], [0, 280, 4], [0, 281, 4], [0, 282, 4], [0, 283, 4], [0, 284, 4], [0, 293, 4], [0, 294, 4], [0, 295, 4], [0, 296, 4], [0, 297, 4], [0, 298, 4], [2, 124, 4], [2, 125, 4], [2, 126, 4], [2, 127, 4]] is too long > >>>>>> from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml# > >>>>>> qcom/glymur-crd.dtb: dma-controller@...000 (qcom,glymur-gpi-dma): interrupts: [[2, 76, 4], [2, 77, 4], [2, 78, 4], [2, 79, 4], [2, 80, 4], [2, 81, 4], [2, 82, 4], [2, 83, 4], [2, 84, 4], [2, 85, 4], [2, 86, 4], [2, 87, 4], [2, 88, 4], [2, 89, 4], [2, 90, 4], [2, 91, 4]] is too long > >>>>>> from schema $id: http://devicetree.org/schemas/dma/qcom,gpi.yaml# > >>>>>> qcom/glymur-crd.dtb: pmic@1 (qcom,pmh0101): led-controller@...0:compatible:0: 'qcom,pmh0101-flash-led' is not one of ['qcom,pm6150l-flash-led', 'qcom,pm660l-flash-led', 'qcom,pm7550-flash-led', 'qcom,pm8150c-flash-led', 'qcom,pm8150l-flash-led', 'qcom,pm8350c-flash-led', 'qcom,pm8550-flash-led', 'qcom,pmi8998-flash-led'] > >>>>>> from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml# > >>>>>> qcom/glymur-crd.dtb: pmic@1 (qcom,pmh0101): pwm:compatible: 'oneOf' conditional failed, one must be fixed: > >>>>>> ['qcom,pmh0101-pwm', 'qcom,pm8350c-pwm'] is too long > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm660l-lpg', 'qcom,pm8150b-lpg', 'qcom,pm8150l-lpg', 'qcom,pm8350c-pwm', 'qcom,pm8916-pwm', 'qcom,pm8941-lpg', 'qcom,pm8994-lpg', 'qcom,pmc8180c-lpg', 'qcom,pmi632-lpg', 'qcom,pmi8950-pwm', 'qcom,pmi8994-lpg', 'qcom,pmi8998-lpg', 'qcom,pmk8550-pwm'] > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm6150l-lpg'] > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm8550-pwm'] > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm8937-pwm'] > >>>>>> 'qcom,pm8150l-lpg' was expected > >>>>>> 'qcom,pm8916-pwm' was expected > >>>>>> from schema $id: http://devicetree.org/schemas/mfd/qcom,spmi-pmic.yaml# > >>>>>> qcom/glymur-crd.dtb: led-controller@...0 (qcom,pmh0101-flash-led): compatible:0: 'qcom,pmh0101-flash-led' is not one of ['qcom,pm6150l-flash-led', 'qcom,pm660l-flash-led', 'qcom,pm7550-flash-led', 'qcom,pm8150c-flash-led', 'qcom,pm8150l-flash-led', 'qcom,pm8350c-flash-led', 'qcom,pm8550-flash-led', 'qcom,pmi8998-flash-led'] > >>>>>> from schema $id: http://devicetree.org/schemas/leds/qcom,spmi-flash-led.yaml# > >>>>>> qcom/glymur-crd.dtb: /soc@...rbiter@...0000/spmi@...6000/pmic@...ed-controller@...0: failed to match any schema with compatible: ['qcom,pmh0101-flash-led', 'qcom,spmi-flash-led'] > >>>>>> qcom/glymur-crd.dtb: pwm (qcom,pmh0101-pwm): compatible: 'oneOf' conditional failed, one must be fixed: > >>>>>> ['qcom,pmh0101-pwm', 'qcom,pm8350c-pwm'] is too long > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm660l-lpg', 'qcom,pm8150b-lpg', 'qcom,pm8150l-lpg', 'qcom,pm8350c-pwm', 'qcom,pm8916-pwm', 'qcom,pm8941-lpg', 'qcom,pm8994-lpg', 'qcom,pmc8180c-lpg', 'qcom,pmi632-lpg', 'qcom,pmi8950-pwm', 'qcom,pmi8994-lpg', 'qcom,pmi8998-lpg', 'qcom,pmk8550-pwm'] > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm6150l-lpg'] > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm8550-pwm'] > >>>>>> 'qcom,pmh0101-pwm' is not one of ['qcom,pm8937-pwm'] > >>>>>> 'qcom,pm8150l-lpg' was expected > >>>>>> 'qcom,pm8916-pwm' was expected > >>>>>> from schema $id: http://devicetree.org/schemas/leds/leds-qcom-lpg.yaml# > >>>>>> qcom/glymur-crd.dtb: /soc@...rbiter@...0000/spmi@...6000/pmic@...wm: failed to match any schema with compatible: ['qcom,pmh0101-pwm', 'qcom,pm8350c-pwm'] > >>>>>> > >>>>>> So, we're still missing a few dependencies. > >>>>>> > >>>>>> > >>>>>> Booting the system I get a ton of errors from PCIe in the kernel log: > >>>>>> > >>>>>> debugfs: 'opp:5000000' already exists in 'soc@...c00000.pci' > >>>>>> > >>>>>> # dmesg | grep -E 'debugfs: .+ already exists' |wc -l > >>>>>> 508 > >>>>>> > >>>>>> The system does eventually boot, and I was happy to see that we do end > >>>>>> up finding the PCIe devices after all. > >>>>>> > >>>>> I enabled dynamic debug logs and observed that each PCIe platform device > >>>>> probe was deferred approximately 10 times. The probe deferrals resulted in > >>>>> additional OPP debugfs warnings being printed. > >>>>> > >>>>> The PCIe platform device probe was deferred because the PHY driver was not > >>>>> ready - either because the PHY driver was not yet loaded, or because the > >>>>> PHY driver's own probe was also deferred due to its dependency (e.g., > >>>>> 1fd5000.clock-controller) not being ready. This is normal behavior, > >>>>> correct? I also observed that other driver probes were deferred. > >>>>> > >>>>> But I'm not sure why there are more than 300 times probe deferrals on > >>>>> your setup. > >>>> > >>>> I think Bjorn is trying to say that the driver is wrong, because it > >>>> effectively seems to call devm_pm_opp_of_add_table repeatedly > >>>> > >>> Okay, to avoid PCIe driver probe deferrals and the resulting increased OPP > >>> debugfs warnings caused by these deferrals, we plan to move the PHY > >>> properties back from the root port node to the controller device tree > >>> node. > >> > >> Would (roughly) this solve your problems without messing with the DT? > > > > This change cannot fix the OPP warning. The warning occurs because the OPP > > subsystem creates debugfs nodes using "op-hz" as the name, which is not > > unique for PCIe OPP tables. Mani posted a patch to fix this issue: > > https://lore.kernel.org/all/20260130071940.6949-1-manivannan.sadhasivam@oss.qualcomm.com/ > > > > Our goal is to prevent probe deferrals from occurring in our driver. > > Right, I would assume that was previously aided by devlink taking > into account 'phys', but since they're no longer part of the PCIe > device node directly, that logic fails. > > Still, modifying the DT to fit Linux behavior generally indicated that > Linux is not super good at doing that particular thing.. In this > instance I think we should extend drivers/of/property.c to maybe check > for supplier dependencies under subnodes of nodes that have > device_type="pci"? > Yes, that's exactly how I think it should be fixed. I'm wiring a patch now. - Mani -- மணிவண்ணன் சதாசிவம்
Powered by blists - more mailing lists