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