linux-kernel - Re: [PATCH v2 1/3] 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: <d17548bb-ddce-4d60-8dc4-2c0633989299@oss.qualcomm.com>
Date: Mon, 10 Nov 2025 17:41:22 +0000
From: Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        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>
Cc: 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 v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related
 nodes

On 11/3/25 12:52 PM, Konrad Dybcio wrote:
> On 10/31/25 12:30 PM, Nickolay Goppen wrote:
>>
>> 24.10.2025 16:58, Nickolay Goppen пишет:
>>>
>>> 24.10.2025 11:28, Konrad Dybcio пишет:
>>>> On 10/23/25 9:51 PM, 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>
>>>>> ---
>>>> [...]
>>>>
>>>>> +            label = "turing";
>>>> "cdsp"
>>> Ok, I'll change this in the next revision.
>>>>> +            mboxes = <&apcs_glb 29>;
>>>>> +            qcom,remote-pid = <5>;
>>>>> +
>>>>> +            fastrpc {
>>>>> +                compatible = "qcom,fastrpc";
>>>>> +                qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>> +                label = "cdsp";
>>>>> +                qcom,non-secure-domain;
>>>> This shouldn't matter, both a secure and a non-secure device is
>>>> created for CDSP
>>> I've added this property, because it is used in other SoC's, such as SDM845 and SM6115 for both ADSP and CDSP
>> Is this property not neccessary anymore?
> 
> +Srini?

That is true, we do not require this for CDSP, as CDSP allows both
unsigned and signed loading, we create both secured and non-secure node
by default. May be we can provide that clarity in yaml bindings so that
it gets caught during dtb checks.


However in ADSP case, we only support singed modules, due to historical
reasons how this driver evolved over years, we have this flag to allow
compatiblity for such users.


--srini>
> Konrad