[PATCH] Documentation: dt: Add binding for /chosen/secure-stdout-path

[Jerome Forissier]

On 03/01/2017 03:50 PM, Rob Herring wrote:
> On Wed, Mar 1, 2017 at 7:29 AM, Jerome Forissier
> <jerome.forissier at linaro.org> wrote:
>> 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 <jerome.forissier at linaro.org>
>> ---
>>  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