On 24.08.2023 08:37, Krzysztof Kozlowski wrote:
On 24/08/2023 01:32, Om Prakash Singh wrote:Herbert already picked up the 8450 compatible last week or so.
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 somePlease reply inline and don't top-post.
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.
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.
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