From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9E1ED15687D; Sun, 12 Jul 2026 15:39:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783870789; cv=none; b=kuaddYzEj3be4xlQvZ0qnnJiu2J3atihgIFilO/MkjCpz23SOFCQrFolSPcloYXvTD5CjHw6Av6LDGZ1vpmE9dDntwpdxtZLwCObvHVXKh5FBoYVXAt+jb1JUDcSkubYVMVtL1otWV+8lUIRyiYtOlnuO1aKzRfihzF2EfmLCA4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783870789; c=relaxed/simple; bh=EfLXGTSwDhtzB33bOgajTZ0EBGXLh4JJX1G64RQUIaQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=l44kkPRmaomiVp2/E76RGarcg6vkWarUy3AfQoTS+7ztjwH8ec7KKg0Rk6jID5ctkcYgr0B3aVWiUqJDI+ff3WD/0HyoPejG2l5F5O7fug2nv+aU74/v8mY3QHj9kXInRFReWnMlhmTiVqMTwm8eRsiTgKvBH2B0FnDnqHRTOyA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=T1kR5k5H; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="T1kR5k5H" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1F2471F000E9; Sun, 12 Jul 2026 15:39:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783870787; bh=d9w2qfNIP9ZxYDaUYu2yhjqGU+oG0vDxaqK374aXjAM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=T1kR5k5HkIJjeoGkOP0PZv8hC07QX3+5EAXQH8dNasY9vDKh4Mukn68X5zX7CnYZy jlhUZKP/uh8TIJefgxW2UXVtLBFbgYBJTCDe/UDIc9WAhB+0QYUKhIPFgmGaoinQ0B 33an3asTqxHnyX/5J/bdoVtOwvXuefe9Zj56cFl4b1y65CzS7OdVtHp6ZwpiUm2wht Et0CmGj/0jaPKhfbKY9Oazb66LdGhLJQl/YvCKJqpuB3VL9+iTaREnsdBKXsjt2joZ 6KlDjAXhHRNZbwG5Zs+GmRfzUZK3pOkhikz8fkiTiJs/pXQ+2lb4TgWnR8AgVjLkM5 wAwF9/x71/YUQ== Date: Sun, 12 Jul 2026 10:39:44 -0500 From: Bjorn Andersson To: Shawn Guo Cc: Konrad Dybcio , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bartosz Golaszewski , Deepti Jaggi , devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, Bartosz Golaszewski Subject: Re: [PATCH v5 5/7] arm64: dts: qcom: Add device tree for Nord Embedded variant Message-ID: References: <20260709132013.4096850-1-shengchao.guo@oss.qualcomm.com> <20260709132013.4096850-6-shengchao.guo@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260709132013.4096850-6-shengchao.guo@oss.qualcomm.com> 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". 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 > Signed-off-by: Bartosz Golaszewski > Signed-off-by: Shawn Guo > --- > 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! > + 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? > + > + clocks = <&negcc NE_GCC_UFS_PHY_AXI_CLK>, > + <&negcc NE_GCC_AGGRE_NOC_UFS_PHY_AXI_CLK>, > + <&negcc NE_GCC_UFS_PHY_AHB_CLK>, > + <&negcc NE_GCC_UFS_PHY_UNIPRO_CORE_CLK>, > + <&tcsrcc TCSR_UFS_CLKREF_EN>, > + <&negcc NE_GCC_UFS_PHY_TX_SYMBOL_0_CLK>, > + <&negcc NE_GCC_UFS_PHY_RX_SYMBOL_0_CLK>, > + <&negcc NE_GCC_UFS_PHY_RX_SYMBOL_1_CLK>; > + clock-names = "core_clk", > + "bus_aggr_clk", > + "iface_clk", > + "core_clk_unipro", > + "ref_clk", > + "tx_lane0_sync_clk", > + "rx_lane0_sync_clk", > + "rx_lane1_sync_clk"; > + > + resets = <&negcc NE_GCC_UFS_PHY_BCR>; > + reset-names = "rst"; > + > + interconnects = <&aggre1_noc_tile MASTER_UFS_MEM QCOM_ICC_TAG_ALWAYS > + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>, > + <&hscnoc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY > + &config_noc SLAVE_UFS_MEM_CFG QCOM_ICC_TAG_ACTIVE_ONLY>; > + interconnect-names = "ufs-ddr", > + "cpu-ufs"; > + > + phys = <&ufs_mem_phy>; > + phy-names = "ufsphy"; > + > + power-domains = <&negcc NE_GCC_UFS_PHY_GDSC>; > + operating-points-v2 = <&ufs_opp_table>; > + required-opps = <&rpmhpd_opp_nom>; > + qcom,ice = <&ice>; > + #reset-cells = <1>; > + > + status = "disabled"; > + > + ufs_opp_table: opp-table { > + compatible = "operating-points-v2"; > + > + opp-100000000 { > + opp-hz = /bits/ 64 <100000000>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <100000000>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <0>; > + required-opps = <&rpmhpd_opp_low_svs>; > + }; > + > + opp-201500000 { > + opp-hz = /bits/ 64 <201500000>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <201500000>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <0>; > + required-opps = <&rpmhpd_opp_svs>; > + }; > + > + opp-403000000 { > + opp-hz = /bits/ 64 <403000000>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <403000000>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <0>, > + /bits/ 64 <0>; > + required-opps = <&rpmhpd_opp_nom>; > + }; > + }; > +}; > -- > 2.43.0 >