devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Rob Herring <robh+dt@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Sumit Garg <sumit.garg@linaro.org>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE"
	<linux-crypto@vger.kernel.org>,
	Devicetree List <devicetree@vger.kernel.org>,
	Matt Mackall <mpm@selenic.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Mark Rutland <mark.rutland@arm.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jens Wiklander <jens.wiklander@linaro.org>,
	Daniel Thompson <daniel.thompson@linaro.org>,
	Bhupesh Sharma <bhsharma@redhat.com>,
	tee-dev@lists.linaro.org
Subject: Re: [PATCH v1 1/2] dt/bindings: add bindings for optional optee rng-uuid property
Date: Thu, 3 Jan 2019 10:20:08 -0600	[thread overview]
Message-ID: <CAL_JsqKWLb1fYC6yT-w8eHFvsfYnVEK5EA85OhJ0dmGx5SaemA@mail.gmail.com> (raw)
In-Reply-To: <CAKv+Gu8o_6Mu8_2vNHXEy46mZ6xrSPekcwPH7BvxR8nec37Ktw@mail.gmail.com>

On Thu, Dec 27, 2018 at 7:40 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Thu, 27 Dec 2018 at 12:08, Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Add bindings for OP-TEE based optional hardware random number
> > generator identifier property. It could be used on ARM based devices
> > where entropy source is not accessible to normal world (linux in this
> > case).
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > index d38834c..e3a4c35 100644
> > --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
> > @@ -20,6 +20,9 @@ the reference implementation maintained by Linaro.
> >                     "hvc" : HVC #0, with the register assignments specified
> >                            in drivers/tee/optee/optee_smc.h
> >
> > +- rng-uuid       : Optional OP-TEE based RNG service identifier in case
> > +                   hardware entropy source is not accesible to normal world
> > +                   (Linux).
> >
> >
> >  Example:
> > @@ -27,5 +30,6 @@ Example:
> >                 optee {
> >                         compatible = "linaro,optee-tz";
> >                         method = "smc";
> > +                       rng-uuid = "ab7a617c-b8e7-4d8f-8301-d09b61036b64";
>
> If OP-TEE is going to expose devices in this way, it should be modeled
> more like a bus driver, i.e., sub-nodes that represent the devices,
> with compatible strings, and perhaps even 'reg' properties for the
> UUIDs.

Please, no. We have DT for things that are not discoverable. Make
OP-TEE services/devices discoverable. We only need the OP-TEE node in
the first place because sub-functions of the SMC-CC itself isn't
discoverable. I suppose there could be some need to expose providers
to consumer nodes in DT, but that's not the case here.

Rob

  parent reply	other threads:[~2019-01-03 16:20 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-27 11:07 [PATCH v1 0/2] Add OP-TEE based hwrng driver Sumit Garg
2018-12-27 11:07 ` [PATCH v1 1/2] dt/bindings: add bindings for optional optee rng-uuid property Sumit Garg
2018-12-27 13:39   ` Ard Biesheuvel
2018-12-28  9:11     ` Sumit Garg
2019-01-03 17:14       ` Daniel Thompson
2019-01-04  6:39         ` Sumit Garg
2019-01-04 11:01           ` Jens Wiklander
2019-01-04 12:01             ` Sumit Garg
2019-01-04 13:03               ` Jens Wiklander
2019-01-07  5:32                 ` Sumit Garg
2019-01-07  5:59                   ` Ard Biesheuvel
2019-01-07  6:46                     ` Sumit Garg
2019-01-03 16:20     ` Rob Herring [this message]
2018-12-27 11:07 ` [PATCH v1 2/2] hwrng: add OP-TEE based rng driver Sumit Garg
2018-12-27 18:28   ` Ard Biesheuvel
2018-12-28  9:58     ` Sumit Garg
2018-12-28 10:38       ` Ard Biesheuvel
2018-12-28 13:03         ` Sumit Garg
2018-12-28 14:46           ` Jens Wiklander
2018-12-30 14:59             ` Vesa Jääskeläinen
2018-12-31 10:35               ` Sumit Garg
2018-12-31 10:24             ` Sumit Garg
2019-01-02  8:04               ` Jens Wiklander
2019-01-02  8:26                 ` Bhupesh Sharma
2019-01-02 10:12                 ` Sumit Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAL_JsqKWLb1fYC6yT-w8eHFvsfYnVEK5EA85OhJ0dmGx5SaemA@mail.gmail.com \
    --to=robh+dt@kernel.org \
    --cc=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhsharma@redhat.com \
    --cc=daniel.thompson@linaro.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mpm@selenic.com \
    --cc=sumit.garg@linaro.org \
    --cc=tee-dev@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).