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

[Robin Murphy]

On 01/03/17 15:04, Jerome Forissier wrote:
> 
> 
> 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.

Once you start using DT in the secure OS, it doesn't seem too big a leap
for folks to want to start passing arguments, so I'd consider
secure-bootargs to be almost inevitable at *some* point down this road.

Perhaps we should consider a /secure-chosen node containing standard
properties instead...

>> 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).

...which different elements of firmware would in theory have a lot more
freedom to mangle between boot stages without the risk of disrupting the
regular /chosen properties.

Robin.

> 
> Thanks,
>