| 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: <6b048028-b3f9-4d8d-aa20-89236c66b800@oss.qualcomm.com>
Date: Tue, 30 Dec 2025 13:32:25 +0530
From: Pankaj Patil <pankaj.patil@....qualcomm.com>
To: Stephan Gerhold <stephan.gerhold@...aro.org>
Cc: Bjorn Andersson <andersson@...nel.org>,
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,
rajendra.nayak@....qualcomm.com, sibi.sankar@....qualcomm.com,
Jyothi Kumar Seerapu <jyothi.seerapu@....qualcomm.com>,
Maulik Shah <maulik.shah@....qualcomm.com>,
Taniya Das <taniya.das@....qualcomm.com>,
Kamal Wadhwa <kamal.wadhwa@....qualcomm.com>,
Prudhvi Yarlagadda <quic_pyarlaga@...cinc.com>,
Qiang Yu <qiang.yu@....qualcomm.com>,
Manaf Meethalavalappu Pallikunhi <manaf.pallikunhi@....qualcomm.com>,
Jishnu Prakash <jishnu.prakash@....qualcomm.com>,
Abel Vesa <abelvesa@...nel.org>
Subject: Re: [PATCH v3 3/4] arm64: dts: qcom: Introduce Glymur base dtsi
On 12/22/2025 4:26 PM, Stephan Gerhold wrote:
> On Fri, Dec 19, 2025 at 08:16:56PM +0530, Pankaj Patil wrote:
>> Introduce the base device tree support for Glymur – Qualcomm's
>> next-generation compute SoC. The new glymur.dtsi describes the core SoC
>> components, including:
>>
>> - CPUs and CPU topology
>> - Interrupt controller and TLMM
>> - GCC,DISPCC and RPMHCC clock controllers
>> - Reserved memory and interconnects
>> - SMMU and firmware SCM
>> - Watchdog, RPMHPD, APPS RSC and SRAM
>> - PSCI and PMU nodes
>> - QUPv3 serial engines
>> - CPU power domains and idle states, plus SCMI/ SRAM pieces for CPU DVFS
>> - PDP0 mailbox, IPCC and AOSS
>> - Display clock controller
>> - SPMI PMIC arbiter with SPMI0/1/2 buses
>> - SMP2P nodes
>> - TSENS and thermal zones (8 instances, 92 sensors)
>>
>> Add dtsi files for PMH0101, PMK8850, PMCX0102, SMB2370, PMH0104,
>> PMH0110 along with temp-alarm and GPIO nodes needed on Glymur
>>
>> Add glmur-pmics.dtsi file for all the pmics enabled
>>
>> Enabled PCIe controllers and associated PHY to support boot to
>> shell with nvme storage,
>> List of PCIe instances enabled:
>>
>> - PCIe3b
>> - PCIe4
>> - PCIe5
>> - PCIe6
>>
>> [...]
>> diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> new file mode 100644
>> index 000000000000..eb042541cfe1
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
>> @@ -0,0 +1,5700 @@
>> [...]
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "qcom,oryon";
>> + reg = <0x0 0x0>;
>> + enable-method = "psci";
>> + power-domains = <&cpu_pd0>, <&scmi_perf 0>;
>> + power-domain-names = "psci", "perf";
>> + cpu-idle-states = <&cpu_c4>;
> You probably want to move this to domain-idle-states:
> https://lore.kernel.org/linux-arm-msm/20251010-topic-x1e_dt_idle-v1-1-b1c8d558e635@oss.qualcomm.com/
Will fix in next revision
>
>> + next-level-cache = <&l2_0>;
>> +
>> + l2_0: l2-cache {
>> + compatible = "cache";
>> + cache-level = <2>;
>> + cache-unified;
>> + };
>> + };
>> [...]
>> + qupv3_2: geniqup@...000 {
>> + compatible = "qcom,geni-se-qup";
>> + reg = <0x0 0x008c0000 0x0 0x3000>;
>> + clocks = <&gcc GCC_QUPV3_WRAP_2_M_AHB_CLK>,
>> + <&gcc GCC_QUPV3_WRAP_2_S_AHB_CLK>;
>> + clock-names = "m-ahb",
>> + "s-ahb";
>> + iommus = <&apps_smmu 0xd63 0x0>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> + status = "disabled";
>> +
>> + i2c16: i2c@...000 {
>> + compatible = "qcom,geni-i2c";
>> + reg = <0x0 0x00880000 0x0 0x4000>;
>> + interrupts = <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&gcc GCC_QUPV3_WRAP2_S0_CLK>;
>> + clock-names = "se";
>> + interconnects = <&clk_virt MASTER_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS
>> + &clk_virt SLAVE_QUP_CORE_2 QCOM_ICC_TAG_ALWAYS>,
>> + <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
>> + &config_noc SLAVE_QUP_2 QCOM_ICC_TAG_ALWAYS>,
> CPU->something paths should be QCOM_ICC_TAG_ACTIVE_ONLY (everywhere).
If we're removing and placing the vote during suspend/resume scenarios, then the tag mentioned in the device tree doesn't matter.The intention behind making it ACTIVE_ONLY for config path is that during APPS suspend,APPS->CONFIG wont be accessed as APPS itself is going to suspend.
>
>> + <&aggre3_noc MASTER_QUP_2 QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
>> + interconnect-names = "qup-core",
>> + "qup-config",
>> + "qup-memory";
>> + dmas = <&gpi_dma2 0 0 QCOM_GPI_I2C>,
>> + <&gpi_dma2 1 0 QCOM_GPI_I2C>;
>> + dma-names = "tx",
>> + "rx";
>> + pinctrl-0 = <&qup_i2c16_data_clk>;
>> + pinctrl-names = "default";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + status = "disabled";
>> + };
>> [...]
>> + pcie4: pci@...0000 {
>> + device_type = "pci";
>> + compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
>> + reg = <0x0 0x01bf0000 0x0 0x3000>,
>> + <0x0 0x78000000 0x0 0xf20>,
>> + <0x0 0x78000f40 0x0 0xa8>,
>> + <0x0 0x78001000 0x0 0x4000>,
>> + <0x0 0x78005000 0x0 0x100000>,
>> + <0x0 0x01bf3000 0x0 0x1000>;
>> + reg-names = "parf",
>> + "dbi",
>> + "elbi",
>> + "atu",
>> + "config",
>> + "mhi";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x01000000 0x0 0x00000000 0x0 0x78105000 0x0 0x100000>,
>> + <0x02000000 0x0 0x78205000 0x0 0x78205000 0x0 0x1dfb000>,
>> + <0x03000000 0x7 0x80000000 0x7 0x80000000 0x0 0x20000000>;
>> + bus-range = <0 0xff>;
>> +
>> + dma-coherent;
>> +
>> + linux,pci-domain = <4>;
>> + num-lanes = <2>;
>> +
>> + operating-points-v2 = <&pcie4_opp_table>;
>> +
>> + msi-map = <0x0 &gic_its 0xc0000 0x10000>;
>> +
>> + interrupts = <GIC_SPI 505 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 506 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 507 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 508 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 509 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 510 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 511 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 512 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 944 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "msi0",
>> + "msi1",
>> + "msi2",
>> + "msi3",
>> + "msi4",
>> + "msi5",
>> + "msi6",
>> + "msi7",
>> + "global";
>> +
>> + #interrupt-cells = <1>;
>> + interrupt-map-mask = <0 0 0 0x7>;
>> + interrupt-map = <0 0 0 1 &intc 0 0 0 513 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 2 &intc 0 0 0 514 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 3 &intc 0 0 0 515 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 4 &intc 0 0 0 516 IRQ_TYPE_LEVEL_HIGH>;
>> +
>> + clocks = <&gcc GCC_PCIE_4_AUX_CLK>,
>> + <&gcc GCC_PCIE_4_CFG_AHB_CLK>,
>> + <&gcc GCC_PCIE_4_MSTR_AXI_CLK>,
>> + <&gcc GCC_PCIE_4_SLV_AXI_CLK>,
>> + <&gcc GCC_PCIE_4_SLV_Q2A_AXI_CLK>,
>> + <&gcc GCC_AGGRE_NOC_PCIE_4_WEST_SF_AXI_CLK>;
>> + clock-names = "aux",
>> + "cfg",
>> + "bus_master",
>> + "bus_slave",
>> + "slave_q2a",
>> + "noc_aggr";
>> +
>> + assigned-clocks = <&gcc GCC_PCIE_4_AUX_CLK>;
>> + assigned-clock-rates = <19200000>;
>> +
>> + interconnects = <&pcie_west_anoc MASTER_PCIE_4 QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>> + <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
>> + &pcie_west_slv_noc SLAVE_PCIE_4 QCOM_ICC_TAG_ALWAYS>;
>> + interconnect-names = "pcie-mem",
>> + "cpu-pcie";
>> +
>> + resets = <&gcc GCC_PCIE_4_BCR>,
>> + <&gcc GCC_PCIE_4_LINK_DOWN_BCR>;
>> + reset-names = "pci",
>> + "link_down";
>> +
>> + power-domains = <&gcc GCC_PCIE_4_GDSC>;
>> +
>> + eq-presets-8gts = /bits/ 16 <0x5555 0x5555>;
>> + eq-presets-16gts = /bits/ 8 <0x55 0x55>;
> Shouldn't there be an IOMMU assigned here? (i.e. iommus = <...> or
> iommu-map = <...>). The reason we don't have these directly in
> hamoa.dtsi is that it runs in EL1 by default and the Gunyah hypervisor
> prevents direct access to the SMMUv3 that protects the PCIe endpoints.
>
> Your cover letter says Glymur is capable of booting at EL2, so this
> can't be the case here. Is there no SMMU for PCIe on Glymur?
>
> There are significant security and performance downsides without a IOMMU
> assigned here (especially with the upcoming USB4 enablement), so this is
> not something I would expect to be omitted without any TODO comment or
> similar mentioned anywhere.
Let me check on pcie smmu enablement.
>
>> [...]
>> + dispcc: clock-controller@...0000 {
>> + compatible = "qcom,glymur-dispcc";
>> + reg = <0x0 0x0af00000 0x0 0x20000>;
>> + clocks = <&rpmhcc RPMH_CXO_CLK>,
>> + <&sleep_clk>,
>> + <0>, /* dp0 */
>> + <0>,
>> + <0>, /* dp1 */
>> + <0>,
>> + <0>, /* dp2 */
>> + <0>,
>> + <0>, /* dp3 */
>> + <0>,
>> + <0>, /* dsi0 */
>> + <0>,
>> + <0>, /* dsi1 */
>> + <0>,
>> + <0>,
>> + <0>,
>> + <0>,
>> + <0>;
>> + power-domains = <&rpmhpd RPMHPD_MMCX>;
>> + required-opps = <&rpmhpd_opp_turbo>;
> Are you sure you want to force TURBO here?
Will decrease it in next revision.
>
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + #power-domain-cells = <1>;
>> + };
>> +
>> [...]
>> + watchdog@...00000 {
>> + compatible = "qcom,kpss-wdt";
> This compatible is deprecated.
Will update in next revision
>
>> + reg = <0x0 0x17600000 0x0 0x1000>;
>> + clocks = <&sleep_clk>;
>> + interrupts = <GIC_SPI 0 IRQ_TYPE_EDGE_RISING>;
>> + };
>> +
>> [...]
> Thanks,
> Stephan
Powered by blists - more mailing lists