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: <20201023075530.19295-1-prabhakar.mahadev-lad.rj@bp.renesas.com>
 <20201023075530.19295-2-prabhakar.mahadev-lad.rj@bp.renesas.com>
 <CAMuHMdW0d3WRwupF-ZEnMdkumwLtRAw9yCLnb4AJ3RGZGP7Hwg@mail.gmail.com> <CA+V-a8sEmC7oDdtc7tgK8D47P=V-tW8PExqpJkwU6=tZ6tb_dg@mail.gmail.com>
In-Reply-To: <CA+V-a8sEmC7oDdtc7tgK8D47P=V-tW8PExqpJkwU6=tZ6tb_dg@mail.gmail.com>
From:   Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Fri, 23 Oct 2020 14:27:32 +0200
Message-ID: <CAMuHMdUqXD6XunzgKNXBarJXAdpmAz4wbiiyyc0w_v1rihqfUA@mail.gmail.com>
Subject: Re: [PATCH 1/2] arm64: dts: renesas: hihope-common: Add optee node
To:     "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Cc:     Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>,
        Magnus Damm <magnus.damm@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Biju Das <biju.das.jz@bp.renesas.com>,
        Marek Vasut <marek.vasut+renesas@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Prabhakar,

CC Marek

On Fri, Oct 23, 2020 at 12:03 PM Lad, Prabhakar
<prabhakar.csengg@gmail.com> wrote:
> On Fri, Oct 23, 2020 at 10:50 AM Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > On Fri, Oct 23, 2020 at 9:56 AM Lad Prabhakar
> > <prabhakar.mahadev-lad.rj@bp.renesas.com> wrote:
> > > Add optee device tree node to HiHope RZ/G2{HMN} boards.
> > >
> > > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > > Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Thanks for your patch!
> >
> > > --- a/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/hihope-common.dtsi
> > > @@ -110,6 +110,13 @@
> > >                 #clock-cells = <0>;
> > >                 clock-frequency = <25000000>;
> > >         };
> > > +
> > > +       firmware {
> > > +               optee {
> > > +                       compatible = "linaro,optee-tz";
> > > +                       method = "smc";
> > > +               };
> > > +       };
> > >  };
> >
> > Should this be added to the SoC-specific .dtsi instead?
> It's a bit tricky, the reason I put in board files is due to current
> boards having optee do the same. Let me know if you want me to move
> the nodes to SoC dtsi

At least the Layerscape and K3 SoCs do have the optee node in the
SoC-specific .dtsi...

Given it needs a special TFA, it's probably safest to pass this through
the firmware stack, cfr. the memory nodes?

> > How can we test this?
> This needs a special TFA (by special I mean optee enabled
> (SPD="opteed")) and In Linux we need the below configs enabled:
>
> CONFIG_TEE=y
> CONFIG_OPTEE=y
> CONFIG_OPTEE_SHM_NUM_PRIV_PAGES=1
>
> Once Linux is booted up this exposes a optee device which can be used
> for communication. I have used optee_test [1] test-suite (xtest) to
> make sure all the tests pass (I have attached results for RZ/G2H for
> reference).
>
> [1] https://optee.readthedocs.io/en/latest/building/gits/optee_test.html

Thanks, that is very valuable information!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds