Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200423064808.10468-1-etienne.carriere@linaro.org>
 <20200423064808.10468-2-etienne.carriere@linaro.org> <CAL_JsqKvQasaBCHC2s68WmtfwGN+t349tzmF=ySkuYz11HzksQ@mail.gmail.com>
In-Reply-To: <CAL_JsqKvQasaBCHC2s68WmtfwGN+t349tzmF=ySkuYz11HzksQ@mail.gmail.com>
From:   Etienne Carriere <etienne.carriere@linaro.org>
Date:   Sun, 26 Apr 2020 17:36:20 +0200
Message-ID: <CAN5uoS-zizF_by6WDtF7j9MrGsRt1fir5w+r1cN1QNzDUf8zgQ@mail.gmail.com>
Subject: Re: [RFC PATCH 1/2] dt-bindings: arm: Add secure-clocks binding description
To:     Rob Herring <robh+dt@kernel.org>
Cc:     "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE" 
        <linux-arm-kernel@lists.infradead.org>, devicetree@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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