diff mbox series

[1/3] dt-bindings: crypto: qcom,prng: Add SM8450

Message ID 20230811-topic-8450_prng-v1-1-01becceeb1ee@linaro.org
State Accepted
Commit b9296bb41275ef2173d2c8b144b808f5e6d18bbe
Headers show
Series [1/3] dt-bindings: crypto: qcom,prng: Add SM8450 | expand

Commit Message

Konrad Dybcio Aug. 11, 2023, 8:50 p.m. UTC
SM8450's PRNG does not require a core clock reference. Add a new
compatible with a qcom,prng-ee fallback and handle that.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
 .../devicetree/bindings/crypto/qcom,prng.yaml      | 24 +++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

Comments

Om Prakash Singh Aug. 18, 2023, 4:17 p.m. UTC | #1
Instead of having SoC name "qcom,sm8450-prng-ee" we could use "qcom,rng-ee" as
new IP core is not longer pseudo random number generator. so "prng" can be
changed to "rng". Clock configuration is not needed on sm8550 as well. So it is
better to use generic compatible string.
Krzysztof Kozlowski Aug. 21, 2023, 6:07 a.m. UTC | #2
On 21/08/2023 02:52, Om Prakash Singh wrote:
> I meant first one. using "qcom,rng-ee".

Then please provide some reasons.

> 
> I am looking for generic compatible string for all SoCs for which core 
> clock can be optional, same as we have "qcom,prng-ee".

There is a generic compatible already... but anyway, is the clock really
optional? Or just configured by firmware?

> 
> If we are using SoC name in compatible string, for each SoC support we 
> need to update qcom,prng.yaml file.

So you were talking about second case from my email? Still not sure what
you want to propose, but just in case - please always follow DT bindings
guidelines:

https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42

Best regards,
Krzysztof
Om Prakash Singh Aug. 22, 2023, 4:27 a.m. UTC | #3
On 8/21/2023 11:37 AM, Krzysztof Kozlowski wrote:
> On 21/08/2023 02:52, Om Prakash Singh wrote:
>> I meant first one. using "qcom,rng-ee".
> 
> Then please provide some reasons.
> 
New IP block available on SM8450 and newer platform is true random 
number generator with it's entropy source. Also it is NIST SP800 90B 
compliant.
By introducing "qcom,rng-ee" I am also planning to add hwrng support in 
driver.

>>
>> I am looking for generic compatible string for all SoCs for which core
>> clock can be optional, same as we have "qcom,prng-ee".
> 
> There is a generic compatible already... but anyway, is the clock really
> optional? Or just configured by firmware?
>
Clock is configured using security firmware.

>>
>> If we are using SoC name in compatible string, for each SoC support we
>> need to update qcom,prng.yaml file.
> 
> So you were talking about second case from my email? Still not sure what
> you want to propose, but just in case - please always follow DT bindings
> guidelines:
> 
> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
> 
> Best regards,
> Krzysztof
>
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index bb42f4588b40..36b0ebd9a44b 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -11,9 +11,13 @@  maintainers:
 
 properties:
   compatible:
-    enum:
-      - qcom,prng  # 8916 etc.
-      - qcom,prng-ee  # 8996 and later using EE
+    oneOf:
+      - enum:
+          - qcom,prng  # 8916 etc.
+          - qcom,prng-ee  # 8996 and later using EE
+      - items:
+          - const: qcom,sm8450-prng-ee
+          - const: qcom,prng-ee
 
   reg:
     maxItems: 1
@@ -28,8 +32,18 @@  properties:
 required:
   - compatible
   - reg
-  - clocks
-  - clock-names
+
+allOf:
+  - if:
+      not:
+        properties:
+          compatible:
+            contains:
+              const: qcom,sm8450-prng-ee
+    then:
+      required:
+        - clocks
+        - clock-names
 
 additionalProperties: false