Re: [PATCH v5 5/7] arm64: dts: qcom: Add device tree for Nord Embedded variant

[Shawn Guo <shengchao.guo@oss.qualcomm.com>]

On Sun, Jul 12, 2026 at 10:39:44AM -0500, Bjorn Andersson wrote:
> On Thu, Jul 09, 2026 at 09:20:11PM +0800, Shawn Guo wrote:
> > Unlike the GearVM variant, Nord Embedded variant has platform resources
> > (clocks, regulators, powerdomains, pins, etc.) directly controlled by
> > Linux.
> 
> We're writing DeviceTree here, our job is solely to express the hardware
> and firmware interfaces using the agreed upon bindings.
> As such resources are "directly controlled by the operating system" -
> not "Linux".

Indeed! Thanks for the suggestion!

> 
> That said, this is a good structured commit message, starting with
> problem description, nicely done.
> 
> > Add a separate dtsi file extending the existing top-level
> > nord.dtsi with nodes representing these peripherals as well as describing
> > how they are wired up with the already defined components.
> > 
> > Co-developed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> > Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> > ---
> >  arch/arm64/boot/dts/qcom/nord-embedded.dtsi | 1731 +++++++++++++++++++
> >  1 file changed, 1731 insertions(+)
> >  create mode 100644 arch/arm64/boot/dts/qcom/nord-embedded.dtsi
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/nord-embedded.dtsi b/arch/arm64/boot/dts/qcom/nord-embedded.dtsi
> [..]
> > +/ {
> > +	clk_virt: interconnect-clk-virt {
> > +		compatible = "qcom,nord-clk-virt";
> > +		#interconnect-cells = <2>;
> > +		qcom,bcm-voters = <&apps_bcm_voter>;
> > +	};
> > +
> > +	mc_virt: interconnect-mc-virt {
> > +		compatible = "qcom,nord-mc-virt";
> > +		#interconnect-cells = <2>;
> > +		qcom,bcm-voters = <&apps_bcm_voter>;
> > +	};
> > +};
> > +
> > +&crypto {
> 
> Just to document my concern here as well, splitting the definition of
> IP-blocks like this across two separate files makes it very hard for a
> human to reason about what the actual platform dtsi looks like.
> 
> If the benefit of this reuse is worth the added complexity, I'm
> accepting it, but it does means that I expect that any changes to
> nord.dtsi will be tested across both models!

That's a reasonable ask!

> 
> > +	interconnects = <&aggre1_noc_tile MASTER_CRYPTO_CORE0 QCOM_ICC_TAG_ALWAYS
> > +			 &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> > +	interconnect-names = "memory";
> > +};
> [..]
> > +&ufs_mem_hc {
> > +	reg = <0x0 0x01d44000 0x0 0x3000>,
> > +	      <0x0 0x01d60000 0x0 0x15000>;
> > +	reg-names = "std",
> > +		    "mcq";
> 
> All other changes in this patch directly relates to resource providers,
> why does the UFS controller's mmio ranges change?

We can have them in nord.dtsi just like all other device nodes, but we
will need to delete reg-names from nord-gearvm.dtsi, since
qcom,sa8255p-ufshc binding doesn't require reg-names.

@@ -2907,5 +2907,6 @@ &ufs_mem_hc {
        compatible = "qcom,sa8797p-ufshc",
                     "qcom,sa8255p-ufshc";
        reg = <0x0 0x01d44000 0x0 0x3000>;
+       /delete-property/ reg-names;
        power-domains = <&scmi3_pd 0>;
 };

I will do this with v6, unless you hate delete-property.

Shawn