Re: [PATCH v2 07/11] arm64: dts: qcom: sdm670: add adsp

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dts: qcom: missing qcom,non-secure-domain in ADSP fastrpc node
--

commit 0239f40f83c2c0077ff48ea5393d0b2751dd608a
Author: Richard Acayan <mailingradian@gmail.com>

arm64: dts: qcom: sdm670: add adsp
    
This commit adds the Audio DSP (ADSP) node along with the SMP2P nodes
used to communicate with it on the SDM670. The sleep state is also
included to prevent crashes related to sensor processing.

> diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
> index 5c60ea36f04a1..038ef0f73ea94 100644
> --- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi

[ ... ]

> @@ -2301,6 +2349,126 @@ cpufreq_hw: cpufreq@17d43000 {
>  			#freq-domain-cells = <1>;
>  		};
>  
> +		adsp_pas: remoteproc@62400000 {

[ ... ]

> +				fastrpc {
> +					compatible = "qcom,fastrpc";
> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
> +					label = "adsp";
> +					#address-cells = <1>;
> +					#size-cells = <0>;

[Severity: Medium]
Is the `qcom,non-secure-domain` property missing here?

During probe, the driver checks for `qcom,non-secure-domain`. When it is
missing, the driver defaults `secure_dsp` to true, creating a 
`/dev/fastrpc-adsp-secure` device node instead of the standard 
`/dev/fastrpc-adsp`.

Does this break standard userspace audio and sensor applications that expect
the non-secure device node for standard ADSP compute tasks?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261003175659.23536-1-mailingradian@gmail.com?part=7