On 03/01/2017 04:20 PM, Robin Murphy wrote:
> 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@xxxxxxxxxx> 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@xxxxxxxxxx>
>>>> ---
>>>> 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...
Fine with me. I'll send a new patch.
>>> 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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
