[RFC PATCH 0/2] Add examples of secure- prefixed property in documentation

[RFC PATCH 0/2] Add examples of secure- prefixed property in documentation

[Etienne Carriere]

Hello,

This is a proposal for adding a bit of description in the DT bindings
documentation of how secure- property prefix can be used for. The
changes in this patch series describe that for clocks and resets properties.

Documentation file arm/secure.txt already states that secure- prefix can be
used for any property hence the description proposed here are not mandated.
However it may be useful as explicit examples of such usage.

I will be very pleased to get your feedback in this changes.

Regards,

Etienne Carriere (2):
  dt-bindings: arm: Add secure-clocks binding description
  dt-bindings: arm: Add secure-resets binding description

 .../devicetree/bindings/arm/secure.txt        | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)

-- 
2.17.1

[RFC PATCH 1/2] dt-bindings: arm: Add secure-clocks binding description

[Etienne Carriere]

Describe how clocks property can leverage secure- property prefix
for clocks handled exclusively or shared by secure and non-secure
worlds.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
 .../devicetree/bindings/arm/secure.txt        | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
index f27bbff2c780..9bc94921f2a6 100644
--- a/Documentation/devicetree/bindings/arm/secure.txt
+++ b/Documentation/devicetree/bindings/arm/secure.txt
@@ -53,6 +53,25 @@ Valid Secure world properties
    status = "disabled";                             /* disabled in both */
    status = "disabled"; secure-status = "disabled"; /* disabled in both */
 
+- secure-clocks : specifies the Phandle list secure world shall use
+  for the related clocks whereas property "clocks" specifies the
+  clock Phandle list non-secure shall use for the that clocks.
+  This configuration can apply for example when a hardware clock is
+  shared by the 2 worlds and the hardware implements a specific interface
+  for each world, i.e.:
+
+  clocks = <&clk DMA_NS>;	/* NS relies on clock handle DMA_NS */
+  secure-clocks = <&clk DMA_S>;	/* S relies on clock handle DMA_S */
+
+  Another example where use of "clocks" and "secure-clocks" can apply
+  is when hardware implements a clock that secure and non-secure must
+  share, as a shared GPIO bank clock, and secure world relies on clock
+  device driver whereas non-secure world relies on a software service
+  exposed by secure world as SCMI clock device. I.e.:
+
+  clocks = <&scmi_clk 2>;	/* NS relies on SCMI resources */
+  secure-clocks= <&clk 5>;	/* S accesses the SoC reset interfaces */
+
 The secure-chosen node
 ----------------------
 
-- 
2.17.1

Re: [RFC PATCH 1/2] dt-bindings: arm: Add secure-clocks binding description

[Rob Herring]

On Thu, Apr 23, 2020 at 1:49 AM Etienne Carriere
<etienne.carriere@linaro.org> wrote:
>
> Describe how clocks property can leverage secure- property prefix
> for clocks handled exclusively or shared by secure and non-secure
> worlds.
>
> Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> ---
>  .../devicetree/bindings/arm/secure.txt        | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
> index f27bbff2c780..9bc94921f2a6 100644
> --- a/Documentation/devicetree/bindings/arm/secure.txt
> +++ b/Documentation/devicetree/bindings/arm/secure.txt
> @@ -53,6 +53,25 @@ Valid Secure world properties
>     status = "disabled";                             /* disabled in both */
>     status = "disabled"; secure-status = "disabled"; /* disabled in both */
>
> +- secure-clocks : specifies the Phandle list secure world shall use
> +  for the related clocks whereas property "clocks" specifies the
> +  clock Phandle list non-secure shall use for the that clocks.
> +  This configuration can apply for example when a hardware clock is
> +  shared by the 2 worlds and the hardware implements a specific interface
> +  for each world, i.e.:
> +
> +  clocks = <&clk DMA_NS>;      /* NS relies on clock handle DMA_NS */
> +  secure-clocks = <&clk DMA_S>;        /* S relies on clock handle DMA_S */

The device has to know what it's clocks are for and should know if
some clocks are secure only.

> +  Another example where use of "clocks" and "secure-clocks" can apply
> +  is when hardware implements a clock that secure and non-secure must
> +  share, as a shared GPIO bank clock, and secure world relies on clock
> +  device driver whereas non-secure world relies on a software service
> +  exposed by secure world as SCMI clock device. I.e.:
> +
> +  clocks = <&scmi_clk 2>;      /* NS relies on SCMI resources */
> +  secure-clocks= <&clk 5>;     /* S accesses the SoC reset interfaces */

If you have this case, I don't think this is the solution. I don't
think it scales well and you probably need separate DTs. It's
something to solve in the system DT project.

Rob

Re: [RFC PATCH 1/2] dt-bindings: arm: Add secure-clocks binding description

[Etienne Carriere]

On Sat, 25 Apr 2020 at 00:06, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Thu, Apr 23, 2020 at 1:49 AM Etienne Carriere
> <etienne.carriere@linaro.org> wrote:
> >
> > Describe how clocks property can leverage secure- property prefix
> > for clocks handled exclusively or shared by secure and non-secure
> > worlds.
> >
> > Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
> > ---
> >  .../devicetree/bindings/arm/secure.txt        | 19 +++++++++++++++++++
> >  1 file changed, 19 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
> > index f27bbff2c780..9bc94921f2a6 100644
> > --- a/Documentation/devicetree/bindings/arm/secure.txt
> > +++ b/Documentation/devicetree/bindings/arm/secure.txt
> > @@ -53,6 +53,25 @@ Valid Secure world properties
> >     status = "disabled";                             /* disabled in both */
> >     status = "disabled"; secure-status = "disabled"; /* disabled in both */
> >
> > +- secure-clocks : specifies the Phandle list secure world shall use
> > +  for the related clocks whereas property "clocks" specifies the
> > +  clock Phandle list non-secure shall use for the that clocks.
> > +  This configuration can apply for example when a hardware clock is
> > +  shared by the 2 worlds and the hardware implements a specific interface
> > +  for each world, i.e.:
> > +
> > +  clocks = <&clk DMA_NS>;      /* NS relies on clock handle DMA_NS */
> > +  secure-clocks = <&clk DMA_S>;        /* S relies on clock handle DMA_S */
>
> The device has to know what it's clocks are for and should know if
> some clocks are secure only.
>
> > +  Another example where use of "clocks" and "secure-clocks" can apply
> > +  is when hardware implements a clock that secure and non-secure must
> > +  share, as a shared GPIO bank clock, and secure world relies on clock
> > +  device driver whereas non-secure world relies on a software service
> > +  exposed by secure world as SCMI clock device. I.e.:
> > +
> > +  clocks = <&scmi_clk 2>;      /* NS relies on SCMI resources */
> > +  secure-clocks= <&clk 5>;     /* S accesses the SoC reset interfaces */
>
> If you have this case, I don't think this is the solution. I don't
> think it scales well and you probably need separate DTs. It's
> something to solve in the system DT project.

Acked,

Thanks,
Etienne

>
> Rob

[RFC PATCH 2/2] dt-bindings: arm: Add secure-resets binding description

[Etienne Carriere]

Describe how resets property can leverage secure- property prefix
for reset controller assigned to secure or non-secure world.

Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
---
 .../devicetree/bindings/arm/secure.txt         | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/secure.txt b/Documentation/devicetree/bindings/arm/secure.txt
index 9bc94921f2a6..f0aa6a5fb436 100644
--- a/Documentation/devicetree/bindings/arm/secure.txt
+++ b/Documentation/devicetree/bindings/arm/secure.txt
@@ -72,6 +72,24 @@ Valid Secure world properties
   clocks = <&scmi_clk 2>;	/* NS relies on SCMI resources */
   secure-clocks= <&clk 5>;	/* S accesses the SoC reset interfaces */
 
+- secure-resets : specifies the Phandle list secure world shall use
+  for the related reset controller(s) whereas property "resets" specifies
+  the reset controller Phandle list non-secure shall use. This
+  configuration can apply for example when a hardware reset controller can
+  only be accessed by secure world and this one opens a software service,
+  as a SCMI reset domain, for non-secure world to access the resource when
+  platform assigns the reset control to non-secure world, i.e.:
+
+  resets = <&scmi_rst 0>, <&scmi_rst 1>;
+  secure-resets = <&rst 5>, <&rst 7>;
+  reset-names = "int", "ext";
+
+  Such device description relaxes constraints on device tree modifications
+  when one, a user or a bootloader, needs to assign a resource to secure
+  or non-secure worlds. Indeed, this allows only "status" and "secure-status"
+  to be set while the rest of the device description in the node remains
+  unchanged.
+
 The secure-chosen node
 ----------------------
 
-- 
2.17.1

Re: [RFC PATCH 0/2] Add examples of secure- prefixed property in documentation

[Rob Herring]

On Thu, Apr 23, 2020 at 1:49 AM Etienne Carriere
<etienne.carriere@linaro.org> wrote:
>
> Hello,
>
> This is a proposal for adding a bit of description in the DT bindings
> documentation of how secure- property prefix can be used for. The
> changes in this patch series describe that for clocks and resets properties.
>
> Documentation file arm/secure.txt already states that secure- prefix can be
> used for any property hence the description proposed here are not mandated.
> However it may be useful as explicit examples of such usage.

It may say that, but any new property has to be documented and
reviewed still. I'm not sure that anything in secure.txt has actually
gotten used.

You should participate in the System DT discussions in Linaro where
how to represent different CPUs and CPU execution environments (like
secure world) is being worked on.

Rob

Re: [RFC PATCH 0/2] Add examples of secure- prefixed property in documentation

[Etienne Carriere]

On Fri, 24 Apr 2020 at 23:59, Rob Herring <robh+dt@kernel.org> wrote:
>
> On Thu, Apr 23, 2020 at 1:49 AM Etienne Carriere
> <etienne.carriere@linaro.org> wrote:
> >
> > Hello,
> >
> > This is a proposal for adding a bit of description in the DT bindings
> > documentation of how secure- property prefix can be used for. The
> > changes in this patch series describe that for clocks and resets properties.
> >
> > Documentation file arm/secure.txt already states that secure- prefix can be
> > used for any property hence the description proposed here are not mandated.
> > However it may be useful as explicit examples of such usage.
>
> It may say that, but any new property has to be documented and
> reviewed still. I'm not sure that anything in secure.txt has actually
> gotten used.

Looking at Linux kernel, U-Boot, Qemu, EDK II, that's right :)
I guess that applies to the so-called non-secure world.

>
> You should participate in the System DT discussions in Linaro where
> how to represent different CPUs and CPU execution environments (like
> secure world) is being worked on.

Fair, I'll get information there.
Thank you for your prompt feedback.

In the same scope, I am to post a change in the Linux DTS files.
A change to define a new attribute mostly of interest for the secure
world description.
I will still post it to the LKML to get feedback about it.
Such new bindings should still be discussed in the Linux DT ML, right?

Regards,
Etienne

>
> Rob