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: <125b4e86-8a72-4338-91cf-08f7e988b167@oss.qualcomm.com>
Date: Fri, 9 May 2025 23:32:42 +0530
From: Ekansh Gupta <ekansh.gupta@....qualcomm.com>
To: Srinivas Kandagatla <srinivas.kandagatla@....qualcomm.com>,
        Alexey Klimov <alexey.klimov@...aro.org>,
        linux-arm-msm@...r.kernel.org
Cc: andersson@...nel.org, konradybcio@...nel.org, robh@...nel.org,
        krzk+dt@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, srini@...nel.org,
        quic_ekangupt@...cinc.com, krzysztof.kozlowski@...aro.org
Subject: Re: [PATCH] arm64: dts: qcom: sm8750: Add adsp fastrpc support



On 5/9/2025 7:01 PM, Srinivas Kandagatla wrote:
> On 5/9/25 14:16, Alexey Klimov wrote:
>> On Fri May 2, 2025 at 11:51 AM BST, Srinivas Kandagatla wrote:
>>> On 5/2/25 02:15, Alexey Klimov wrote:
>>>> While at this, also add required memory region for fastrpc.
>>>>
>>>> Tested on sm8750-mtp device with adsprpdcd.
>>>>
>>>> Cc: Ekansh Gupta <quic_ekangupt@...cinc.com>
>>>> Cc: Srinivas Kandagatla <srini@...nel.org>
>>>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>>> Signed-off-by: Alexey Klimov <alexey.klimov@...aro.org>
>>>> ---
>>>>  arch/arm64/boot/dts/qcom/sm8750.dtsi | 70 ++++++++++++++++++++++++++++
>>>>  1 file changed, 70 insertions(+)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
>>>> index 149d2ed17641..48ee66125a89 100644
>>>> --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
>>>> +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
>>>> @@ -7,6 +7,7 @@
>>>>  #include <dt-bindings/clock/qcom,sm8750-gcc.h>
>>>>  #include <dt-bindings/clock/qcom,sm8750-tcsr.h>
>>>>  #include <dt-bindings/dma/qcom-gpi.h>
>>>> +#include <dt-bindings/firmware/qcom,scm.h>
>>>>  #include <dt-bindings/interconnect/qcom,icc.h>
>>>>  #include <dt-bindings/interconnect/qcom,sm8750-rpmh.h>
>>>>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> @@ -523,6 +524,14 @@ llcc_lpi_mem: llcc-lpi@...00000 {
>>>>  			reg = <0x0 0xff800000 0x0 0x800000>;
>>>>  			no-map;
>>>>  		};
>>>> +
>>>> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>>>> +			compatible = "shared-dma-pool";
>>>> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
>>>> +			alignment = <0x0 0x400000>;
>>>> +			size = <0x0 0xc00000>;
>>>> +			reusable;
>>>> +		};
>>>>  	};
>>>>  
>>>>  	smp2p-adsp {
>>>> @@ -2237,6 +2246,67 @@ q6prmcc: clock-controller {
>>>>  						};
>>>>  					};
>>>>  				};
>>>> +
>>>> +				fastrpc {
>>>> +					compatible = "qcom,fastrpc";
>>>> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>> +					label = "adsp";
>>>> +					memory-region = <&adsp_rpc_remote_heap_mem>;
>>>> +					qcom,vmids = <QCOM_SCM_VMID_LPASS
>>>> +						      QCOM_SCM_VMID_ADSP_HEAP>;
>>>> +					qcom,non-secure-domain;
>>> Any reason why we what to mark adsp as non-secure domain by default?
>> No particular reason. That's what we went with on other platforms, so this just follows
>> the same. If we need to update this flag to secure then most likely that should be done
>> for some other platforms as well.
>> The only thing I know that adsprpcd + audio pd works with non-secure flag.
>> I can try to re-test with secure flag.
>>
> I know that this is loosely enforced in the current state.
> We want adsp to be always in secure mode as it will have access to some
> of the IP blocks inside the DSP other than just hexagon compute.
>
>
>> Ekansh, do we have any preference here regarding this?
> @Ekansh, we should provide that clarity in dt bindings.

qcom,non-secure-domain should actually represent the DSPs supporting
unsigned PD(low privileged) and secure only supports Signed PD(privileged).
I had added some details here[1] also.

I agree with Srini's point about providing clarity in dt bindings for this
property. I'll send some changes for this.

[1] https://lore.kernel.org/all/412fe24e-ce70-4733-ace5-d3fbe43476c4@oss.qualcomm.com/

//Ekansh

>
> --srini
>> Best regards,
>> Alexey


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ