On 13/12/2021 15:46, Bjorn Andersson wrote:
On Thu 09 Dec 04:06 PST 2021, Srinivas Kandagatla wrote:
From: Jeya R <jeyr@xxxxxxxxxxxxxx>
Add property to set DSP domain as non-secure.
ADSP/MDSP/SDSP are by default secured, where as CDSP can be either be
secured/unsecured.
non-secured Compute DSP would allow users to load unsigned process
and run hexagon instructions, but limiting access to secured hardware
within the DSP.
Based on this flag device nodes for secured and unsecured are created.
Signed-off-by: Jeya R <jeyr@xxxxxxxxxxxxxx>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
---
This patch has dependency this yaml conversion patch:
https://lore.kernel.org/lkml/20211208101508.24582-1-david@xxxxxxx/T/
Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
index f42ab208a7fc..f0df0a3bf69f 100644
--- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
+++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
@@ -29,6 +29,11 @@ properties:
- sdsp
- cdsp
+ qcom,non-secure-domain:
+ type: boolean
+ description: >
+ Property to specify that dsp domain is non-secure.
"non-secure" feels vague, how about expressing it as "Specifies that the
domains of this DSP instance may run unsigned programs."
TBH I dont mind either of this, but looking at some existing bindings I
see similar pattern of properties like.. "st,non-secure-otp"
Perhaps even go so far to name the property
qcom,allow-unsigned-programs? (Or some other word for "program"?)
Do you think adding more details in the description would help?
--srini
Regards,
Bjorn
+
'#address-cells':
const: 1
--
2.21.0
