On Thu, 27 Dec 2018 at 19:10, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:
>
> On Thu, 27 Dec 2018 at 12:08, Sumit Garg <sumit.garg@xxxxxxxxxx> 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@xxxxxxxxxx>
> > ---
> > 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.
>
This is something Daniel also suggested during our discussion. But we
agreed to discuss in upstream to get more feedback.
I think generic TEE should be modelled as a bus driver with devices
identified via UUIDs, probably queried from underline implementations
like OP-TEE regarding which resident devices (pseudo-TA UUIDs) it
supports. Then this list of device UUIDs can be compared against child
driver's UUID as part of match callback during driver registration.
Also the child driver could maintain list of device UUIDs which it
supports.
If we go via this approach we may not require device tree entry for
corresponding device UUIDs.
-Sumit
> > };
> > };
> > --
> > 2.7.4
> >
