diff mbox

[v6,3/6] dt/bindings: add bindings for optee

Message ID 1446106888-8983-4-git-send-email-jens.wiklander@linaro.org (mailing list archive)
State New, archived
Headers show

Commit Message

Jens Wiklander Oct. 29, 2015, 8:21 a.m. UTC
Introduces optee prefix and adds bindings for ARM TrustZone based OP-TEE
implementation.

Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
 .../bindings/arm/firmware/optee,optee-tz.txt       | 29 ++++++++++++++++++++++
 .../devicetree/bindings/vendor-prefixes.txt        |  1 +
 2 files changed, 30 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt

Comments

Rob Herring (Arm) Nov. 16, 2015, 5:01 p.m. UTC | #1
On Thu, Oct 29, 2015 at 09:21:25AM +0100, Jens Wiklander wrote:
> Introduces optee prefix and adds bindings for ARM TrustZone based OP-TEE
> implementation.
> 
> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> ---
>  .../bindings/arm/firmware/optee,optee-tz.txt       | 29 ++++++++++++++++++++++
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  2 files changed, 30 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
> 
> diff --git a/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
> new file mode 100644
> index 0000000..0a8ed0d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
> @@ -0,0 +1,29 @@
> +OP-TEE Device Tree Bindings
> +
> +OP-TEE is a piece of software using hardware features to provide a Trusted
> +Execution Environment. The security can be provided with ARM TrustZone, but
> +also by virtualization or a separate chip. As there's no single OP-TEE
> +vendor we're using "optee" as the first part of compatible property,
> +indicating the OP-TEE protocol is used when communicating with the secure
> +world.
> +
> +* OP-TEE based on ARM TrustZone required properties:
> +
> +- compatible     : should contain "optee,optee-tz"

I would leave off optee as a vendor. Different implementations by 
vendors should then add their vendor prefix as they all have the chance 
to screw-up something. I suppose we could do "linaro" as the reference 
implementation.

> +
> +- method         : The method of calling the OP-TEE Trusted OS. Permitted
> +                   values are:
> +
> +                   "smc" : SMC #0, with the register assignments specified
> +		           in drivers/tee/optee/optee_smc.h
> +
> +                   "hvc" : HVC #0, with the register assignments specified
> +		           in drivers/tee/optee/optee_smc.h

The use here would be a guest VM calling thru to hypervisor and then 
hypervisor calling optee?

> +
> +
> +
> +Example:
> +	optee {

This should go under a /firmware node similar to 
Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt.

Rob
Jens Wiklander Nov. 19, 2015, 9:18 a.m. UTC | #2
On Mon, Nov 16, 2015 at 11:01:10AM -0600, Rob Herring wrote:
> On Thu, Oct 29, 2015 at 09:21:25AM +0100, Jens Wiklander wrote:
> > Introduces optee prefix and adds bindings for ARM TrustZone based OP-TEE
> > implementation.
> > 
> > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> > ---
> >  .../bindings/arm/firmware/optee,optee-tz.txt       | 29 ++++++++++++++++++++++
> >  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
> >  2 files changed, 30 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
> > 
> > diff --git a/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
> > new file mode 100644
> > index 0000000..0a8ed0d
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
> > @@ -0,0 +1,29 @@
> > +OP-TEE Device Tree Bindings
> > +
> > +OP-TEE is a piece of software using hardware features to provide a Trusted
> > +Execution Environment. The security can be provided with ARM TrustZone, but
> > +also by virtualization or a separate chip. As there's no single OP-TEE
> > +vendor we're using "optee" as the first part of compatible property,
> > +indicating the OP-TEE protocol is used when communicating with the secure
> > +world.
> > +
> > +* OP-TEE based on ARM TrustZone required properties:
> > +
> > +- compatible     : should contain "optee,optee-tz"
> 
> I would leave off optee as a vendor. Different implementations by 
> vendors should then add their vendor prefix as they all have the chance 
> to screw-up something. I suppose we could do "linaro" as the reference 
> implementation.

OK, I'll use "linaro" then.

> 
> > +
> > +- method         : The method of calling the OP-TEE Trusted OS. Permitted
> > +                   values are:
> > +
> > +                   "smc" : SMC #0, with the register assignments specified
> > +		           in drivers/tee/optee/optee_smc.h
> > +
> > +                   "hvc" : HVC #0, with the register assignments specified
> > +		           in drivers/tee/optee/optee_smc.h
> 
> The use here would be a guest VM calling thru to hypervisor and then 
> hypervisor calling optee?

Yes, the hypervisor needs to be involved (translating IPA to PA etc)
when invoking secure world.

> 
> > +
> > +
> > +
> > +Example:
> > +	optee {
> 
> This should go under a /firmware node similar to 
> Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt.

I tried that and discovered that a
compatible = "simple-bus";
is needed for the firmware node for optee to get probed. Is it OK to write
the example as:

firmware {
        compatible = "simple-bus";

        optee {
...

Thanks,
Jens
Rob Herring (Arm) Nov. 19, 2015, 2:30 p.m. UTC | #3
On Thu, Nov 19, 2015 at 3:18 AM, Jens Wiklander
<jens.wiklander@linaro.org> wrote:
> On Mon, Nov 16, 2015 at 11:01:10AM -0600, Rob Herring wrote:
>> On Thu, Oct 29, 2015 at 09:21:25AM +0100, Jens Wiklander wrote:
>> > Introduces optee prefix and adds bindings for ARM TrustZone based OP-TEE
>> > implementation.
>> >
>> > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
>> > ---
>> >  .../bindings/arm/firmware/optee,optee-tz.txt       | 29 ++++++++++++++++++++++
>> >  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>> >  2 files changed, 30 insertions(+)
>> >  create mode 100644 Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
>> >
>> > diff --git a/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
>> > new file mode 100644
>> > index 0000000..0a8ed0d
>> > --- /dev/null
>> > +++ b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
>> > @@ -0,0 +1,29 @@
>> > +OP-TEE Device Tree Bindings
>> > +
>> > +OP-TEE is a piece of software using hardware features to provide a Trusted
>> > +Execution Environment. The security can be provided with ARM TrustZone, but
>> > +also by virtualization or a separate chip. As there's no single OP-TEE
>> > +vendor we're using "optee" as the first part of compatible property,
>> > +indicating the OP-TEE protocol is used when communicating with the secure
>> > +world.

[...]

>> > +Example:
>> > +   optee {
>>
>> This should go under a /firmware node similar to
>> Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt.
>
> I tried that and discovered that a
> compatible = "simple-bus";
> is needed for the firmware node for optee to get probed. Is it OK to write
> the example as:
>
> firmware {
>         compatible = "simple-bus";
>
>         optee {

That would needlessly create devices for any other child nodes and it
is not a bus. Just find the node and call of_platform_device_create
for that node in an initcall.

Rob
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
new file mode 100644
index 0000000..0a8ed0d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/optee,optee-tz.txt
@@ -0,0 +1,29 @@ 
+OP-TEE Device Tree Bindings
+
+OP-TEE is a piece of software using hardware features to provide a Trusted
+Execution Environment. The security can be provided with ARM TrustZone, but
+also by virtualization or a separate chip. As there's no single OP-TEE
+vendor we're using "optee" as the first part of compatible property,
+indicating the OP-TEE protocol is used when communicating with the secure
+world.
+
+* OP-TEE based on ARM TrustZone required properties:
+
+- compatible     : should contain "optee,optee-tz"
+
+- method         : The method of calling the OP-TEE Trusted OS. Permitted
+                   values are:
+
+                   "smc" : SMC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+                   "hvc" : HVC #0, with the register assignments specified
+		           in drivers/tee/optee/optee_smc.h
+
+
+
+Example:
+	optee {
+		compatible = "optee,optee-tz";
+		method = "smc";
+	};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 82d2ac9..38e632f 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -159,6 +159,7 @@  nxp	NXP Semiconductors
 okaya	Okaya Electric America, Inc.
 onnn	ON Semiconductor Corp.
 opencores	OpenCores.org
+optee	OP-TEE, Open Portable Trusted Execution Environment
 option	Option NV
 ortustech	Ortus Technology Co., Ltd.
 ovti	OmniVision Technologies