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

[Bjorn Andersson]

On Tue, Jul 14, 2026 at 08:15:24PM +0800, Shawn Guo wrote:
> 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@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxxxxxxxx>
> > > Signed-off-by: Shawn Guo <shengchao.guo@xxxxxxxxxxxxxxxx>
> > > ---
> > >  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.
> 

Now I see the answer is was actually looking for: the SCMI-based variant
doesn't list the mcq region. Why is that?

If they have to be different, then I think your proposed way makes sense
(i.e. don't muck around with delete-property etc) - but you didn't
answer my question, you jump directly to "solution"...

Regards,
Bjorn

> Shawn