linux-kernel - Re: [PATCH 1/2] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4q7rtc7kdfpy7pyqa4eztjcgpraonxlx2hxcrez46msqthjtmt@f43oyk2imi5c>
Date: Thu, 23 Oct 2025 17:23:26 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Nickolay Goppen <setotau@...nlining.org>,
        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,
        ~postmarketos/upstreaming@...ts.sr.ht, linux@...nlining.org
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sdm630/660: Add CDSP-related nodes

On Wed, Oct 22, 2025 at 07:17:51PM +0200, Konrad Dybcio wrote:
> On 10/20/25 5:42 PM, Nickolay Goppen wrote:
> > 
> > 20.10.2025 18:27, Nickolay Goppen пишет:
> >>
> >> 20.10.2025 16:14, Dmitry Baryshkov пишет:
> >>> On Sun, Oct 19, 2025 at 07:27:06PM +0300, Nickolay Goppen wrote:
> >>>> In order to enable CDSP support for SDM660 SoC:
> >>>>   * add shared memory p2p nodes for CDSP
> >>>>   * add CDSP-specific smmu node
> >>>>   * add CDSP peripheral image loader node
> >>>>
> >>>> Memory region for CDSP in SDM660 occupies the same spot as
> >>>> TZ buffer mem defined in sdm630.dtsi (which does not have CDSP).
> >>>> In sdm660.dtsi replace buffer_mem inherited from SDM630 with
> >>>> cdsp_region, which is also larger in size.
> >>>>
> >>>> SDM636 also doesn't have CDSP, so remove inherited from sdm660.dtsi
> >>>> related nodes and add buffer_mem back.
> >>>>
> >>>> Signed-off-by: Nickolay Goppen <setotau@...nlining.org>
> >>>> ---
> >>>>   arch/arm64/boot/dts/qcom/sdm630.dtsi |   2 +-
> >>>>   arch/arm64/boot/dts/qcom/sdm636.dtsi |  14 ++++
> >>>>   arch/arm64/boot/dts/qcom/sdm660.dtsi | 152 +++++++++++++++++++++++++++++++++++
> >>>>   3 files changed, 167 insertions(+), 1 deletion(-)
> >>>>
> >>>> diff --git a/arch/arm64/boot/dts/qcom/sdm630.dtsi b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> >>>> index 8b1a45a4e56e..a6a1933229b9 100644
> >>>> --- a/arch/arm64/boot/dts/qcom/sdm630.dtsi
> >>>> +++ b/arch/arm64/boot/dts/qcom/sdm630.dtsi
> >>>> @@ -563,7 +563,7 @@ modem_smp2p_in: slave-kernel {
> >>>>           };
> >>>>       };
> >>>>   -    soc@0 {
> >>>> +    soc: soc@0 {
> >>>>           #address-cells = <1>;
> >>>>           #size-cells = <1>;
> >>>>           ranges = <0 0 0 0xffffffff>;
> >>>> diff --git a/arch/arm64/boot/dts/qcom/sdm636.dtsi b/arch/arm64/boot/dts/qcom/sdm636.dtsi
> >>>> index ae15d81fa3f9..41e4e97f7747 100644
> >>>> --- a/arch/arm64/boot/dts/qcom/sdm636.dtsi
> >>>> +++ b/arch/arm64/boot/dts/qcom/sdm636.dtsi
> >>>> @@ -16,6 +16,20 @@
> >>>>    * be addressed when the aforementioned
> >>>>    * peripherals will be enabled upstream.
> >>>>    */
> >>>> +/delete-node/ &cdsp_pil;
> >>>> +/delete-node/ &cdsp_smmu;
> >>>> +/delete-node/ &cdsp_region;
> >>>> +
> >>>> +/ {
> >>>> +    /delete-node/ smp2p-cdsp;
> >>>> +
> >>>> +    reserved-memory {
> >>>> +        buffer_mem: tzbuffer@...00000 {
> >>>> +            reg = <0x00 0x94a00000 0x00 0x100000>;
> >>>> +            no-map;
> >>>> +        };
> >>>> +    };
> >>>> +};
> >>> This probably means that we need to invert things and make SDM636
> >>> inherit SDM630 and SDM660 inherit SDM636. Would you mind doing that as a
> >>> part of this patchset?
> >> I'd mind
> > Konrad decided to do the split this way for some reason initially
> 
> This isn't a very good argument, but I think keeping it as-is is a
> good idea in this case, as opening sdm660.dtsi I see a need for some
> more cleanup work on this platform.. which I don't think anyone
> is willing to do short term, this is less invasive

Okay. It just felt weird to readd the node that we remove in the
previous #include.

-- 
With best wishes
Dmitry