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] [thread-next>] [day] [month] [year] [list]
Message-ID: <0b06f744-b695-43d9-8da3-4424e2b53a5e@oss.qualcomm.com>
Date: Thu, 20 Nov 2025 16:24:54 +0530
From: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
To: Nickolay Goppen <setotau@...nlining.org>,
        Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>,
        Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        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, Chenna Kesava Raju <chennak@....qualcomm.com>,
        Bharath Kumar <bkumar@....qualcomm.com>
Subject: Re: [PATCH v2 1/3] arm64: dts: qcom: sdm630/660: Add CDSP-related
 nodes



On 11/20/2025 1:27 PM, Nickolay Goppen wrote:
>
> 20.11.2025 07:55, Ekansh Gupta пишет:
>>
>> On 11/20/2025 1:58 AM, Srinivas Kandagatla wrote:
>>> On 11/12/25 1:52 PM, Konrad Dybcio wrote:
>>>> 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)?
>>> Yes, its true that we allowed full access to adsp device nodes when we
>>> first started upstreaming fastrpc driver.
>>>
>>> irrespective of the board only signed modules are supported on the ADSP.
>>> I think there was one version of SoC i think 8016 or some older one
>>> which had adsp with hvx which can load unsigned modules for compute
>>> usecase only.
>>>
>>> I have added @Ekansh for more clarity.
>>>
>>> --srini
>> For all the available platforms, ADSP supports only signed modules. Unsigned
>> modules(as well as signed) are supported by CDSP and GDSP subsystems.
>>
>> qcom,non-secure-domain property marks the corresponding DSP as non-secure DSP.
>> The implications of adding this property would be the following:
>> on ADSP, SDSP, MDSP:
>> - Only non-secure device node(/dev/fastrpc-Xdsp) is created.
>> - Non-secure device node can be used for signed DSP PD offload.
>>
>> on CDSP, GDSP:
>> - Both secure(/dev/fastrpc-Xdsp-secure) and non-secure(/dev/fastrpc-Xdsp) devices
>>    are created, regardless of this property.
>> - Both the nodes can be used for signed and unsigned DSP PD offload.
>>
>> Note: If the property is not added for CDSP/GDSP, only secure device node can
>> be used for signed PD offload, if non-secure device is used, the request gets
>> rejected[1].
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1245
>>
>> //Ekansh
> Does this mean that the qcom,non-secure-domain property should be dropped from both nodes? 
I checked again and found that unsigned module support for CDSP is
not available on this platform. Given this, the safest approach would
be to add the property for both ADSP and CDSP, ensuring that all
created device nodes can be used for signed PD offload. I can provide
a more definitive recommendation once I know the specific use cases
you plan to run.

//Ekansh
>>>
>>>> Konrad
>