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 for Android: free password hash cracker in your pocket

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

Message-ID: <f5c7eb1c-28b1-4cf1-afb0-b993384b7712@oss.qualcomm.com>
Date: Wed, 12 Nov 2025 14:52:45 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Srinivas Kandagatla <srinivas.kandagatla@....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/10/25 6:41 PM, Srinivas Kandagatla wrote:
> 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.

Does that mean that we can only load signed modules on the ADSP, but
the driver behavior was previously such that unsigned modules were
allowed (which was presumably fine on devboards, but not on fused
devices)?

Konrad