[PATCH 0/2] arm64: qcom: sm8550: enable RNG

[PATCH 0/2] arm64: qcom: sm8550: enable RNG

[Neil Armstrong]

Enable RNG on SM8550.

Output of rngtest :

rngtest 6.15
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 188260032
rngtest: FIPS 140-2 successes: 9405
rngtest: FIPS 140-2 failures: 8
rngtest: FIPS 140-2(2001-10-10) Monobit: 1
rngtest: FIPS 140-2(2001-10-10) Poker: 1
rngtest: FIPS 140-2(2001-10-10) Runs: 2
rngtest: FIPS 140-2(2001-10-10) Long run: 4
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=7.518; avg=50.591; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=21.146; avg=27.867; max=160.281)Mibits/s
rngtest: Program run time: 10003649 microseconds
...

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Neil Armstrong (2):
      dt-bindings: crypto: qcom,prng: document SM8550
      arm64: dts: qcom: sm8550: Add PRNG

 Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 8 ++++++--
 arch/arm64/boot/dts/qcom/sm8550.dtsi                    | 5 +++++
 2 files changed, 11 insertions(+), 2 deletions(-)
---
base-commit: 28c736b0e92e11bfe2b9997688213dc43cb22182
change-id: 20230822-topic-sm8550-rng-c83142783e20

Best regards,
-- 
Neil Armstrong <neil.armstrong@linaro.org>

[PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Neil Armstrong]

Document SM8550 compatible for Pseudo Random Generator,
like SM8450 doesn't require clocks setup done by the secure
firmware.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
 Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
index 36b0ebd9a44b..60fc9f261b83 100644
--- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
+++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
@@ -16,7 +16,9 @@ properties:
           - qcom,prng  # 8916 etc.
           - qcom,prng-ee  # 8996 and later using EE
       - items:
-          - const: qcom,sm8450-prng-ee
+          - enum:
+              - qcom,sm8450-prng-ee
+              - qcom,sm8550-prng-ee
           - const: qcom,prng-ee
 
   reg:
@@ -39,7 +41,9 @@ allOf:
         properties:
           compatible:
             contains:
-              const: qcom,sm8450-prng-ee
+              enum:
+                - qcom,sm8450-prng-ee
+                - qcom,sm8550-prng-ee
     then:
       required:
         - clocks

-- 
2.34.1

[PATCH 2/2] arm64: dts: qcom: sm8550: Add PRNG

[Neil Armstrong]

Add the Qualcomm Pseudo-Random Number Generator.

Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
 arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
index d115960bdeec..643ec80feacc 100644
--- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
@@ -1661,6 +1661,11 @@ mmss_noc: interconnect@1780000 {
 			qcom,bcm-voters = <&apps_bcm_voter>;
 		};
 
+		rng: rng@10c3000 {
+			compatible = "qcom,sm8550-prng-ee", "qcom,prng-ee";
+			reg = <0 0x010c3000 0 0x1000>;
+		};
+
 		pcie0: pci@1c00000 {
 			device_type = "pci";
 			compatible = "qcom,pcie-sm8550";

-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Krzysztof Kozlowski]

On 22/08/2023 16:11, Neil Armstrong wrote:
> Document SM8550 compatible for Pseudo Random Generator,
> like SM8450 doesn't require clocks setup done by the secure
> firmware.
> 
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Konrad Dybcio]

On 22.08.2023 16:11, Neil Armstrong wrote:
> Document SM8550 compatible for Pseudo Random Generator,
> like SM8450 doesn't require clocks setup done by the secure
> firmware.
> 
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
+ CC Om

As mentioned in [1], perhaps we should rethink the compatible as
it may be a TRNG and not a PRNG?

Konrad

[1] https://lore.kernel.org/linux-arm-msm/d93902ee-c305-42cb-9d0d-1f0971ab3a70@quicinc.com/

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Om Prakash Singh]

PRNG Block on most of newer target from Qualcomm have some configuration 
where clock is configured by security firmware.

Adding separate compatible string for each platform is overhead.

We need to introduce common compatible string that can be used for all 
platforms with same configuration.

I would suggest to use "qcom,rng-ee" for newer platform, dropping "p" 
also signifies it is not a Pseudo Random Number Generator.

On 8/22/2023 7:58 PM, Konrad Dybcio wrote:
> On 22.08.2023 16:11, Neil Armstrong wrote:
>> Document SM8550 compatible for Pseudo Random Generator,
>> like SM8450 doesn't require clocks setup done by the secure
>> firmware.
>>
>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>> ---
> + CC Om
> 
> As mentioned in [1], perhaps we should rethink the compatible as
> it may be a TRNG and not a PRNG?
> 
> Konrad
> 
> [1] https://lore.kernel.org/linux-arm-msm/d93902ee-c305-42cb-9d0d-1f0971ab3a70@quicinc.com/

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Krzysztof Kozlowski]

On 22/08/2023 16:54, Om Prakash Singh wrote:
> PRNG Block on most of newer target from Qualcomm have some configuration 
> where clock is configured by security firmware.
> 
> Adding separate compatible string for each platform is overhead.

I don't think PRNG is here different than others and for all others we
expect it. I understand that this is an overhead, like every work is
overhead.

> 
> We need to introduce common compatible string that can be used for all 
> platforms with same configuration.

It is already introduced, isn't it?

> 
> I would suggest to use "qcom,rng-ee" for newer platform, dropping "p" 
> also signifies it is not a Pseudo Random Number Generator.
> 

Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Konrad Dybcio]

On 22.08.2023 16:54, Om Prakash Singh wrote:
> PRNG Block on most of newer target from Qualcomm have some configuration where clock is configured by security firmware.
> 
> Adding separate compatible string for each platform is overhead.
> 
> We need to introduce common compatible string that can be used for all platforms with same configuration.
> 
> I would suggest to use "qcom,rng-ee" for newer platform, dropping "p" also signifies it is not a Pseudo Random Number Generator.
Please reply inline and don't top-post.


Is this what you're trying to say?

1. sort out the clock requirements for designs where Linux manages it
   vs where the FW does so

2. introduce a new compatible for SoCs implementing a TRNG

3. for SoCs in 2., register the TRNG as a hwrng device


?

Konrad

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Om Prakash Singh]

On 8/22/2023 9:34 PM, Konrad Dybcio wrote:
> On 22.08.2023 16:54, Om Prakash Singh wrote:
>> PRNG Block on most of newer target from Qualcomm have some configuration where clock is configured by security firmware.
>>
>> Adding separate compatible string for each platform is overhead.
>>
>> We need to introduce common compatible string that can be used for all platforms with same configuration.
>>
>> I would suggest to use "qcom,rng-ee" for newer platform, dropping "p" also signifies it is not a Pseudo Random Number Generator.
> Please reply inline and don't top-post.
> 
> 
> Is this what you're trying to say?
> 
> 1. sort out the clock requirements for designs where Linux manages it
>     vs where the FW does so >
> 2. introduce a new compatible for SoCs implementing a TRNG
> 
> 3. for SoCs in 2., register the TRNG as a hwrng device

Yes to all

> 
> 
> ?
> 
> Konrad

Thanks,
Om

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Neil Armstrong]

Hi,

On 23/08/2023 02:10, Om Prakash Singh wrote:
> 
> 
> On 8/22/2023 9:34 PM, Konrad Dybcio wrote:
>> On 22.08.2023 16:54, Om Prakash Singh wrote:
>>> PRNG Block on most of newer target from Qualcomm have some configuration where clock is configured by security firmware.
>>>
>>> Adding separate compatible string for each platform is overhead.
>>>
>>> We need to introduce common compatible string that can be used for all platforms with same configuration.
>>>
>>> I would suggest to use "qcom,rng-ee" for newer platform, dropping "p" also signifies it is not a Pseudo Random Number Generator.
>> Please reply inline and don't top-post.
>>
>>
>> Is this what you're trying to say?
>>
>> 1. sort out the clock requirements for designs where Linux manages it
>>     vs where the FW does so >
>> 2. introduce a new compatible for SoCs implementing a TRNG
>>
>> 3. for SoCs in 2., register the TRNG as a hwrng device
> 
> Yes to all

I can send a proposal, but that means writing a new driver for this compatible in drivers/char/hw_random/ right ?

Neil

> 
>>
>>
>> ?
>>
>> Konrad
> 
> Thanks,
> Om

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Om Prakash Singh]

On 8/23/2023 1:25 PM, Neil Armstrong wrote:
> Hi,
> 
> On 23/08/2023 02:10, Om Prakash Singh wrote:
>>
>>
>> On 8/22/2023 9:34 PM, Konrad Dybcio wrote:
>>> On 22.08.2023 16:54, Om Prakash Singh wrote:
>>>> PRNG Block on most of newer target from Qualcomm have some 
>>>> configuration where clock is configured by security firmware.
>>>>
>>>> Adding separate compatible string for each platform is overhead.
>>>>
>>>> We need to introduce common compatible string that can be used for 
>>>> all platforms with same configuration.
>>>>
>>>> I would suggest to use "qcom,rng-ee" for newer platform, dropping 
>>>> "p" also signifies it is not a Pseudo Random Number Generator.
>>> Please reply inline and don't top-post.
>>>
>>>
>>> Is this what you're trying to say?
>>>
>>> 1. sort out the clock requirements for designs where Linux manages it
>>>     vs where the FW does so >
>>> 2. introduce a new compatible for SoCs implementing a TRNG
>>>
>>> 3. for SoCs in 2., register the TRNG as a hwrng device
>>
>> Yes to all
> 
> I can send a proposal, but that means writing a new driver for this 
> compatible in drivers/char/hw_random/ right ?

We can add hwrng support in same driver like 
drivers/crypto/hisilicon/trng/trng.c

As Krzysztof is suggesting we need to have platform specific compatible 
string, we can go with your change. for hwrng support I will send 
separate patches.

> 
> Neil
> 
>>
>>>
>>>
>>> ?
>>>
>>> Konrad
>>
>> Thanks,
>> Om
> 

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Om Prakash Singh]

On 8/22/2023 7:41 PM, Neil Armstrong wrote:
> Document SM8550 compatible for Pseudo Random Generator,
> like SM8450 doesn't require clocks setup done by the secure
> firmware.
> 
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
Acked-by: Om Prakash Singh <quic_omprsing@quicinc.com>
>   Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
> index 36b0ebd9a44b..60fc9f261b83 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,prng.yaml
> @@ -16,7 +16,9 @@ properties:
>             - qcom,prng  # 8916 etc.
>             - qcom,prng-ee  # 8996 and later using EE
>         - items:
> -          - const: qcom,sm8450-prng-ee
> +          - enum:
> +              - qcom,sm8450-prng-ee
> +              - qcom,sm8550-prng-ee
>             - const: qcom,prng-ee
>   
>     reg:
> @@ -39,7 +41,9 @@ allOf:
>           properties:
>             compatible:
>               contains:
> -              const: qcom,sm8450-prng-ee
> +              enum:
> +                - qcom,sm8450-prng-ee
> +                - qcom,sm8550-prng-ee
>       then:
>         required:
>           - clocks
> 

Re: [PATCH 2/2] arm64: dts: qcom: sm8550: Add PRNG

[Om Prakash Singh]

On 8/22/2023 7:41 PM, Neil Armstrong wrote:
> Add the Qualcomm Pseudo-Random Number Generator.
> 
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
Reviewed-by: Om Prakash Singh <quic_omprsing@quicinc.com>

>   arch/arm64/boot/dts/qcom/sm8550.dtsi | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/qcom/sm8550.dtsi b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> index d115960bdeec..643ec80feacc 100644
> --- a/arch/arm64/boot/dts/qcom/sm8550.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sm8550.dtsi
> @@ -1661,6 +1661,11 @@ mmss_noc: interconnect@1780000 {
>   			qcom,bcm-voters = <&apps_bcm_voter>;
>   		};
>   
> +		rng: rng@10c3000 {
> +			compatible = "qcom,sm8550-prng-ee", "qcom,prng-ee";
> +			reg = <0 0x010c3000 0 0x1000>;
> +		};
> +
>   		pcie0: pci@1c00000 {
>   			device_type = "pci";
>   			compatible = "qcom,pcie-sm8550";
> 

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Krzysztof Kozlowski]

On 24/08/2023 01:32, Om Prakash Singh wrote:
> 
> 
> On 8/23/2023 1:25 PM, Neil Armstrong wrote:
>> Hi,
>>
>> On 23/08/2023 02:10, Om Prakash Singh wrote:
>>>
>>>
>>> On 8/22/2023 9:34 PM, Konrad Dybcio wrote:
>>>> On 22.08.2023 16:54, Om Prakash Singh wrote:
>>>>> PRNG Block on most of newer target from Qualcomm have some 
>>>>> configuration where clock is configured by security firmware.
>>>>>
>>>>> Adding separate compatible string for each platform is overhead.
>>>>>
>>>>> We need to introduce common compatible string that can be used for 
>>>>> all platforms with same configuration.
>>>>>
>>>>> I would suggest to use "qcom,rng-ee" for newer platform, dropping 
>>>>> "p" also signifies it is not a Pseudo Random Number Generator.
>>>> Please reply inline and don't top-post.
>>>>
>>>>
>>>> Is this what you're trying to say?
>>>>
>>>> 1. sort out the clock requirements for designs where Linux manages it
>>>>     vs where the FW does so >
>>>> 2. introduce a new compatible for SoCs implementing a TRNG
>>>>
>>>> 3. for SoCs in 2., register the TRNG as a hwrng device
>>>
>>> Yes to all
>>
>> I can send a proposal, but that means writing a new driver for this 
>> compatible in drivers/char/hw_random/ right ?
> 
> We can add hwrng support in same driver like 
> drivers/crypto/hisilicon/trng/trng.c
> 
> As Krzysztof is suggesting we need to have platform specific compatible 

That's independent question

> string, we can go with your change. for hwrng support I will send 
> separate patches.

Any bindings decision should be made now. We don't produce knowingly
incomplete bindings just to change them later. Therefore now you need to
decide whether you call it prng-ee or something else.


Best regards,
Krzysztof

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[Konrad Dybcio]

On 24.08.2023 08:37, Krzysztof Kozlowski wrote:
> On 24/08/2023 01:32, Om Prakash Singh wrote:
>>
>>
>> On 8/23/2023 1:25 PM, Neil Armstrong wrote:
>>> Hi,
>>>
>>> On 23/08/2023 02:10, Om Prakash Singh wrote:
>>>>
>>>>
>>>> On 8/22/2023 9:34 PM, Konrad Dybcio wrote:
>>>>> On 22.08.2023 16:54, Om Prakash Singh wrote:
>>>>>> PRNG Block on most of newer target from Qualcomm have some 
>>>>>> configuration where clock is configured by security firmware.
>>>>>>
>>>>>> Adding separate compatible string for each platform is overhead.
>>>>>>
>>>>>> We need to introduce common compatible string that can be used for 
>>>>>> all platforms with same configuration.
>>>>>>
>>>>>> I would suggest to use "qcom,rng-ee" for newer platform, dropping 
>>>>>> "p" also signifies it is not a Pseudo Random Number Generator.
>>>>> Please reply inline and don't top-post.
>>>>>
>>>>>
>>>>> Is this what you're trying to say?
>>>>>
>>>>> 1. sort out the clock requirements for designs where Linux manages it
>>>>>     vs where the FW does so >
>>>>> 2. introduce a new compatible for SoCs implementing a TRNG
>>>>>
>>>>> 3. for SoCs in 2., register the TRNG as a hwrng device
>>>>
>>>> Yes to all
>>>
>>> I can send a proposal, but that means writing a new driver for this 
>>> compatible in drivers/char/hw_random/ right ?
>>
>> We can add hwrng support in same driver like 
>> drivers/crypto/hisilicon/trng/trng.c
>>
>> As Krzysztof is suggesting we need to have platform specific compatible 
> 
> That's independent question
> 
>> string, we can go with your change. for hwrng support I will send 
>> separate patches.
> 
> Any bindings decision should be made now. We don't produce knowingly
> incomplete bindings just to change them later. Therefore now you need to
> decide whether you call it prng-ee or something else.
Herbert already picked up the 8450 compatible last week or so.
If we decide quickly, perhaps it can be reverted and substituted
with the non-*P*RNG one. It would theoretically be an ABI break,
but:

a) it would be very very prompt
b) the dts patch hasn't been merged so there are no users

I'd be fine with that, not sure about the rest of you guys.

Konrad

Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: document SM8550

[neil.armstrong]

On 24/08/2023 10:40, Konrad Dybcio wrote:
> On 24.08.2023 08:37, Krzysztof Kozlowski wrote:
>> On 24/08/2023 01:32, Om Prakash Singh wrote:
>>>
>>>
>>> On 8/23/2023 1:25 PM, Neil Armstrong wrote:
>>>> Hi,
>>>>
>>>> On 23/08/2023 02:10, Om Prakash Singh wrote:
>>>>>
>>>>>
>>>>> On 8/22/2023 9:34 PM, Konrad Dybcio wrote:
>>>>>> On 22.08.2023 16:54, Om Prakash Singh wrote:
>>>>>>> PRNG Block on most of newer target from Qualcomm have some
>>>>>>> configuration where clock is configured by security firmware.
>>>>>>>
>>>>>>> Adding separate compatible string for each platform is overhead.
>>>>>>>
>>>>>>> We need to introduce common compatible string that can be used for
>>>>>>> all platforms with same configuration.
>>>>>>>
>>>>>>> I would suggest to use "qcom,rng-ee" for newer platform, dropping
>>>>>>> "p" also signifies it is not a Pseudo Random Number Generator.
>>>>>> Please reply inline and don't top-post.
>>>>>>
>>>>>>
>>>>>> Is this what you're trying to say?
>>>>>>
>>>>>> 1. sort out the clock requirements for designs where Linux manages it
>>>>>>      vs where the FW does so >
>>>>>> 2. introduce a new compatible for SoCs implementing a TRNG
>>>>>>
>>>>>> 3. for SoCs in 2., register the TRNG as a hwrng device
>>>>>
>>>>> Yes to all
>>>>
>>>> I can send a proposal, but that means writing a new driver for this
>>>> compatible in drivers/char/hw_random/ right ?
>>>
>>> We can add hwrng support in same driver like
>>> drivers/crypto/hisilicon/trng/trng.c
>>>
>>> As Krzysztof is suggesting we need to have platform specific compatible
>>
>> That's independent question
>>
>>> string, we can go with your change. for hwrng support I will send
>>> separate patches.
>>
>> Any bindings decision should be made now. We don't produce knowingly
>> incomplete bindings just to change them later. Therefore now you need to
>> decide whether you call it prng-ee or something else.
> Herbert already picked up the 8450 compatible last week or so.
> If we decide quickly, perhaps it can be reverted and substituted
> with the non-*P*RNG one. It would theoretically be an ABI break,
> but:
> 
> a) it would be very very prompt
> b) the dts patch hasn't been merged so there are no users
> 
> I'd be fine with that, not sure about the rest of you guys.

I'm fine for that aswell, this can be done quickly without the
hwrng part

I can quickly refresh this serie with :
1) introduce a new "qcom,trng" and move "qcom,sm8450-prng-ee" to "qcom,sm8450-trng"
2) add qcom,sm8550-prng-ee
3) add "qcom,trng"  to the driver compatible list

then afterwards, the hwrng part can be added in a separate serie.

Neil

> 
> Konrad