Date:	Thu, 12 Nov 2015 21:22:27 -0600
From:	Rob Herring <robh@...nel.org>
To:	Peter Maydell <peter.maydell@...aro.org>
Cc:	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	lkml - Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roy Franz <roy.franz@...aro.org>,
	arm-mail-list <linux-arm-kernel@...ts.infradead.org>,
	Kumar Gala <galak@...eaurora.org>,
	Jens Wiklander <jens.wiklander@...aro.org>,
	Christoffer Dall <christoffer.dall@...aro.org>,
	Grant Likely <grant.likely@...aro.org>
Subject: Re: [PATCH v2] Documentation: dt: Add bindings for Secure-only devices

On Thu, Nov 12, 2015 at 3:42 PM, Peter Maydell <peter.maydell@...aro.org> wrote:
> On 12 November 2015 at 21:33, Rob Herring <robh@...nel.org> wrote:
>> On Thu, Nov 12, 2015 at 04:24:50PM +0000, Peter Maydell wrote:
>>> The existing device tree bindings assume that we are only trying to
>>> describe a single address space with a device tree (for ARM, either
>>> the Normal or the Secure world). Some uses for device tree need to
>>> describe both Normal and Secure worlds in a single device tree. Add
>>> documentation of how to do this, by adding extra properties which
>>> describe when a device appears differently in the two worlds or when
>>> it only appears in one of them.
>>>
>>> The binding describes the general principles for adding new
>>> properties describing the secure world, but for now we only need a
>>> single new property, "secure-status", which can be used to annotate
>>> devices to indicate that they are only visible in one of the two
>>> worlds.
>>>
>>> The primary expected use of this binding is for a virtual machine
>>> like QEMU to describe the VM layout to a TrustZone aware firmware
>>> (which would then use the secure-only devices itself, and pass the DT
>>> on to a kernel running in the non-secure world, which ignores the
>>> secure-only devices and uses the rest).
>>>
>>> Signed-off-by: Peter Maydell <peter.maydell@...aro.org>
>>
>> I'd specifically like Mark's ack on this one.


>>> +The general principle of the naming scheme for Secure world bindings
>>> +is that any property that needs a different value in the Secure world
>>> +can be supported by prefixing the property name with "secure-". So for
>>> +instance "secure-reg" would override "reg". If there is no "secure-"
>>
>> I'd prefer this be "secure-foo" and "foo", rather than reg given I
>> specifically have a differing opinion on how to support reg.
>>
>> Also, would it be secure-vendor,foo or vendor,secure-foo for properties
>> with vendor prefix? The latter looks more correct to me, but the former
>> would be easier to search for both variants of the property. I'd lean
>> towards the latter.
>
> OK, so how about making that para read:
>
> + The general principle of the naming scheme for Secure world bindings
> + is that any property that needs a different value in the Secure world
> + can be supported by prefixing the property name with "secure-". So for
> + instance "secure-foo" would override "foo". For property names with
> + a vendor prefix, the Secure variant of "vendor,foo" would be
> + "vendor,secure-foo". If there is no "secure-" property then the Secure
> + world value is the same as specified for the Normal world by the
> + non-prefixed property. However, only the properties listed below may
> + validly have "secure-" versions; this list will be enlarged on a
> + case-by-case basis.

Looks good.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists