On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
[off-list ref] wrote:
quoted hunk
Some platforms may use a single device tree to describe two address
spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
for Secure-only devices"). We extend the use of the secure- prefix to
the stdout-path property, so that the Secure firmware may use a
different console device than the one used by the kernel.
Signed-off-by: Jerome Forissier <redacted>
---
Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
index e31303f..558c9a1 100644
--- a/Documentation/devicetree/bindings/arm/secure.txt
+++ b/Documentation/devicetree/bindings/arm/secure.txt
@@ -51,3 +51,8 @@ Valid Secure world properties:
status = "disabled"; secure-status = "okay"; /* S-only */
status = "disabled"; /* disabled in both */
status = "disabled"; secure-status = "disabled"; /* disabled in both */
+
+- secure-stdout-path (/chosen node): specifies the device to be used
+for console output by Secure firmware. The syntax is the same as for
+"stdout-path". If "secure-stdout-path" is not specified it defaults to
+the same value as "stdout-path".
I'm not all that enthusiastic about this. This alone is okay, but
continued additions of secure-* properties doesn't seem very scalable.
Is this it or do you have other needs? What happens when we have 3
modes/address spaces?
Maybe we should allow stdout-path to have multiple strings and secure
fw grabs the first one and updates the DT removing it (perhaps only if
the device is secure only). Might be nice to have multiple ones
supported anyway (like we can do on the kernel command line:
"console=ttyS0 console=ttyS1").
Rob
On 03/01/2017 03:50 PM, Rob Herring wrote:
On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
[off-list ref] wrote:
quoted
Some platforms may use a single device tree to describe two address
spaces, as described in d9f43babb998 ("Documentation: dt: Add bindings
for Secure-only devices"). We extend the use of the secure- prefix to
the stdout-path property, so that the Secure firmware may use a
different console device than the one used by the kernel.
Signed-off-by: Jerome Forissier <redacted>
---
Documentation/devicetree/bindings/arm/secure.txt | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
index e31303f..558c9a1 100644
--- a/Documentation/devicetree/bindings/arm/secure.txt
+++ b/Documentation/devicetree/bindings/arm/secure.txt
@@ -51,3 +51,8 @@ Valid Secure world properties:
status = "disabled"; secure-status = "okay"; /* S-only */
status = "disabled"; /* disabled in both */
status = "disabled"; secure-status = "disabled"; /* disabled in both */
+
+- secure-stdout-path (/chosen node): specifies the device to be used
+for console output by Secure firmware. The syntax is the same as for
+"stdout-path". If "secure-stdout-path" is not specified it defaults to
+the same value as "stdout-path".
I'm not all that enthusiastic about this. This alone is okay, but
continued additions of secure-* properties doesn't seem very scalable.
Is this it or do you have other needs? What happens when we have 3
modes/address spaces?
How is this different from status/secure-status?
I have no other needs for the moment. I'm experimenting with the
introduction of DT in OP-TEE. The secure-status property (or lack
thereof) already allows me to know if a device can be used by the secure
OS and how it should be mapped (secure vs. non-secure). This extension
allows me to reuse the same TEE binary and change the console, which is
a simple use case to demonstrate the advantage of using the DT in the
secure FW.
Maybe we should allow stdout-path to have multiple strings and secure
fw grabs the first one and updates the DT removing it (perhaps only if
the device is secure only). Might be nice to have multiple ones
supported anyway (like we can do on the kernel command line:
"console=ttyS0 console=ttyS1").
The problem I see with removing entries is that the secure firmware may
have multiple stages (say, ARM Trusted Firmware plus a secure OS such as
OP-TEE).
Thanks,
--
Jerome