On 11/13/2024 11:13 AM, Dmitry Baryshkov wrote:
> On Wed, Nov 13, 2024 at 10:30:42AM +0530, Ekansh Gupta wrote:
>> FastRPC framework treats ADSP as a secure domain on sc7280 SoC
>> which means that only secure fastrpc device node should be
>> created for ADSP remoteproc. Remove the non-secure-domain
>> property from ADSP fastrpc node.
> If this prevents the non-secure devices from being created, isn't that a
> regression from the userspace point of view?
The actual intention of having secure and non-secure domains is to utilize signed(high privilege)
and unsigned(low privilege) DSP processes properly.
Non-secure device node is intended to be used by untrusted/generic applications which needs to
offload tasks to DSP as unsignedPD. Only unsigned PD is expected to be allowed if the process is
using non-secure node.
Secure device is intended to be used by trusted processes like daemons or any application
which needs to offload as signed PD to DSP.
The ideal expectation from userspace is to first try to open secure device node and fall back to
non-secure node if the secure node is not accessible or absent.
I understand your concerns, can you please suggest how this can be improved/corrected?
--ekansh
>> Signed-off-by: Ekansh Gupta <quic_ekangupt@xxxxxxxxxxx>
>> ---
>> arch/arm64/boot/dts/qcom/sc7280.dtsi | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> index 3d8410683402..c633926c0f33 100644
>> --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
>> @@ -3852,7 +3852,6 @@ fastrpc {
>> compatible = "qcom,fastrpc";
>> qcom,glink-channels = "fastrpcglink-apps-dsp";
>> label = "adsp";
>> - qcom,non-secure-domain;
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> --
>> 2.34.1
>>
