~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

TOMOYO Linux Cross Reference
Linux/Documentation/devicetree/bindings/arm/secure.txt

Version: ~ [ linux-6.12-rc7 ] ~ [ linux-6.11.7 ] ~ [ linux-6.10.14 ] ~ [ linux-6.9.12 ] ~ [ linux-6.8.12 ] ~ [ linux-6.7.12 ] ~ [ linux-6.6.60 ] ~ [ linux-6.5.13 ] ~ [ linux-6.4.16 ] ~ [ linux-6.3.13 ] ~ [ linux-6.2.16 ] ~ [ linux-6.1.116 ] ~ [ linux-6.0.19 ] ~ [ linux-5.19.17 ] ~ [ linux-5.18.19 ] ~ [ linux-5.17.15 ] ~ [ linux-5.16.20 ] ~ [ linux-5.15.171 ] ~ [ linux-5.14.21 ] ~ [ linux-5.13.19 ] ~ [ linux-5.12.19 ] ~ [ linux-5.11.22 ] ~ [ linux-5.10.229 ] ~ [ linux-5.9.16 ] ~ [ linux-5.8.18 ] ~ [ linux-5.7.19 ] ~ [ linux-5.6.19 ] ~ [ linux-5.5.19 ] ~ [ linux-5.4.285 ] ~ [ linux-5.3.18 ] ~ [ linux-5.2.21 ] ~ [ linux-5.1.21 ] ~ [ linux-5.0.21 ] ~ [ linux-4.20.17 ] ~ [ linux-4.19.323 ] ~ [ linux-4.18.20 ] ~ [ linux-4.17.19 ] ~ [ linux-4.16.18 ] ~ [ linux-4.15.18 ] ~ [ linux-4.14.336 ] ~ [ linux-4.13.16 ] ~ [ linux-4.12.14 ] ~ [ linux-4.11.12 ] ~ [ linux-4.10.17 ] ~ [ linux-4.9.337 ] ~ [ linux-4.4.302 ] ~ [ linux-3.10.108 ] ~ [ linux-2.6.32.71 ] ~ [ linux-2.6.0 ] ~ [ linux-2.4.37.11 ] ~ [ unix-v6-master ] ~ [ ccs-tools-1.8.12 ] ~ [ policy-sample ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

Diff markup

Differences between /Documentation/devicetree/bindings/arm/secure.txt (Architecture sparc) and /Documentation/devicetree/bindings/arm/secure.txt (Architecture alpha)


  1 * ARM Secure world bindings                         1 * ARM Secure world bindings
  2                                                     2 
  3 ARM CPUs with TrustZone support have two disti      3 ARM CPUs with TrustZone support have two distinct address spaces,
  4 "Normal" and "Secure". Most devicetree consume      4 "Normal" and "Secure". Most devicetree consumers (including the Linux
  5 kernel) are not TrustZone aware and run entire      5 kernel) are not TrustZone aware and run entirely in either the Normal
  6 world or the Secure world. However some device      6 world or the Secure world. However some devicetree consumers are
  7 TrustZone aware and need to be able to determi      7 TrustZone aware and need to be able to determine whether devices are
  8 visible only in the Secure address space, only      8 visible only in the Secure address space, only in the Normal address
  9 space, or visible in both. (One example of tha      9 space, or visible in both. (One example of that situation would be a
 10 virtual machine which boots Secure firmware an     10 virtual machine which boots Secure firmware and wants to tell the
 11 firmware about the layout of the machine via d     11 firmware about the layout of the machine via devicetree.)
 12                                                    12 
 13 The general principle of the naming scheme for     13 The general principle of the naming scheme for Secure world bindings
 14 is that any property that needs a different va     14 is that any property that needs a different value in the Secure world
 15 can be supported by prefixing the property nam     15 can be supported by prefixing the property name with "secure-". So for
 16 instance "secure-foo" would override "foo". Fo     16 instance "secure-foo" would override "foo". For property names with
 17 a vendor prefix, the Secure variant of "vendor     17 a vendor prefix, the Secure variant of "vendor,foo" would be
 18 "vendor,secure-foo". If there is no "secure-"      18 "vendor,secure-foo". If there is no "secure-" property then the Secure
 19 world value is the same as specified for the N     19 world value is the same as specified for the Normal world by the
 20 non-prefixed property. However, only the prope     20 non-prefixed property. However, only the properties listed below may
 21 validly have "secure-" versions; this list wil     21 validly have "secure-" versions; this list will be enlarged on a
 22 case-by-case basis.                                22 case-by-case basis.
 23                                                    23 
 24 Defining the bindings in this way means that a     24 Defining the bindings in this way means that a device tree which has
 25 been annotated to indicate the presence of Sec     25 been annotated to indicate the presence of Secure-only devices can
 26 still be processed unmodified by existing Non-     26 still be processed unmodified by existing Non-secure software (and in
 27 particular by the kernel).                         27 particular by the kernel).
 28                                                    28 
 29 Note that it is still valid for bindings inten     29 Note that it is still valid for bindings intended for purely Secure
 30 world consumers (like kernels that run entirel     30 world consumers (like kernels that run entirely in Secure) to simply
 31 describe the view of Secure world using the st     31 describe the view of Secure world using the standard bindings. These
 32 secure- bindings only need to be used where bo     32 secure- bindings only need to be used where both the Secure and Normal
 33 world views need to be described in a single d     33 world views need to be described in a single device tree.
 34                                                    34 
 35 Valid Secure world properties                      35 Valid Secure world properties
 36 -----------------------------                      36 -----------------------------
 37                                                    37 
 38 - secure-status : specifies whether the device     38 - secure-status : specifies whether the device is present and usable
 39   in the secure world. The combination of this     39   in the secure world. The combination of this with "status" allows
 40   the various possible combinations of device      40   the various possible combinations of device visibility to be
 41   specified. If "secure-status" is not specifi     41   specified. If "secure-status" is not specified it defaults to the
 42   same value as "status"; if "status" is not s     42   same value as "status"; if "status" is not specified either then
 43   both default to "okay". This means the follo     43   both default to "okay". This means the following combinations are
 44   possible:                                        44   possible:
 45                                                    45 
 46    /* Neither specified: default to visible in     46    /* Neither specified: default to visible in both S and NS */
 47    secure-status = "okay";                         47    secure-status = "okay";                          /* visible in both */
 48    status = "okay";                                48    status = "okay";                                 /* visible in both */
 49    status = "okay"; secure-status = "okay";        49    status = "okay"; secure-status = "okay";         /* visible in both */
 50    secure-status = "disabled";                     50    secure-status = "disabled";                      /* NS-only */
 51    status = "okay"; secure-status = "disabled"     51    status = "okay"; secure-status = "disabled";     /* NS-only */
 52    status = "disabled"; secure-status = "okay"     52    status = "disabled"; secure-status = "okay";     /* S-only */
 53    status = "disabled";                            53    status = "disabled";                             /* disabled in both */
 54    status = "disabled"; secure-status = "disab     54    status = "disabled"; secure-status = "disabled"; /* disabled in both */
 55                                                    55 
 56 The secure-chosen node                             56 The secure-chosen node
 57 ----------------------                             57 ----------------------
 58                                                    58 
 59 Similar to the /chosen node which serves as a      59 Similar to the /chosen node which serves as a place for passing data
 60 between firmware and the operating system, the     60 between firmware and the operating system, the /secure-chosen node may
 61 be used to pass data to the Secure OS. Only th     61 be used to pass data to the Secure OS. Only the properties defined
 62 below may appear in the /secure-chosen node.       62 below may appear in the /secure-chosen node.
 63                                                    63 
 64 - stdout-path : specifies the device to be use     64 - stdout-path : specifies the device to be used by the Secure OS for
 65   its console output. The syntax is the same a     65   its console output. The syntax is the same as for /chosen/stdout-path.
 66   If the /secure-chosen node exists but the st     66   If the /secure-chosen node exists but the stdout-path property is not
 67   present, the Secure OS should not perform an     67   present, the Secure OS should not perform any console output. If
 68   /secure-chosen does not exist, the Secure OS     68   /secure-chosen does not exist, the Secure OS should use the value of
 69   /chosen/stdout-path instead (that is, use th     69   /chosen/stdout-path instead (that is, use the same device as the
 70   Normal world OS).                                70   Normal world OS).
                                                      

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~

kernel.org | git.kernel.org | LWN.net | Project Home | SVN repository | Mail admin

Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.

sflogo.php