| Message ID | 20200423064808.10468-2-etienne.carriere@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add examples of secure- prefixed property in documentation | expand |
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
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
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 ----------------------
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(+)