1* ARM Secure world bindings
2
3ARM CPUs with TrustZone support have two distinct address spaces,
4"Normal" and "Secure". Most devicetree consumers (including the Linux
5kernel) are not TrustZone aware and run entirely in either the Normal
6world or the Secure world. However some devicetree consumers are
7TrustZone aware and need to be able to determine whether devices are
8visible only in the Secure address space, only in the Normal address
9space, or visible in both. (One example of that situation would be a
10virtual machine which boots Secure firmware and wants to tell the
11firmware about the layout of the machine via devicetree.)
12
13The general principle of the naming scheme for Secure world bindings
14is that any property that needs a different value in the Secure world
15can be supported by prefixing the property name with "secure-". So for
16instance "secure-foo" would override "foo". For property names with
17a vendor prefix, the Secure variant of "vendor,foo" would be
18"vendor,secure-foo". If there is no "secure-" property then the Secure
19world value is the same as specified for the Normal world by the
20non-prefixed property. However, only the properties listed below may
21validly have "secure-" versions; this list will be enlarged on a
22case-by-case basis.
23
24Defining the bindings in this way means that a device tree which has
25been annotated to indicate the presence of Secure-only devices can
26still be processed unmodified by existing Non-secure software (and in
27particular by the kernel).
28
29Note that it is still valid for bindings intended for purely Secure
30world consumers (like kernels that run entirely in Secure) to simply
31describe the view of Secure world using the standard bindings. These
32secure- bindings only need to be used where both the Secure and Normal
33world views need to be described in a single device tree.
34
35Valid Secure world properties:
36
37- secure-status : specifies whether the device is present and usable
38  in the secure world. The combination of this with "status" allows
39  the various possible combinations of device visibility to be
40  specified. If "secure-status" is not specified it defaults to the
41  same value as "status"; if "status" is not specified either then
42  both default to "okay". This means the following combinations are
43  possible:
44
45   /* Neither specified: default to visible in both S and NS */
46   secure-status = "okay";                          /* visible in both */
47   status = "okay";                                 /* visible in both */
48   status = "okay"; secure-status = "okay";         /* visible in both */
49   secure-status = "disabled";                      /* NS-only */
50   status = "okay"; secure-status = "disabled";     /* NS-only */
51   status = "disabled"; secure-status = "okay";     /* S-only */
52   status = "disabled";                             /* disabled in both */
53   status = "disabled"; secure-status = "disabled"; /* disabled in both */
54