Le Wed, Nov 16, 2022 at 09:04:07PM +0300, Mikhail Rudenko a écrit :

On 2022-09-29 at 09:45 +02, LABBE Corentin [off-list ref] wrote:

quoted

Le Tue, Sep 27, 2022 at 11:39:17PM +0200, Aurelien Jarno a écrit :

quoted

On 2022-09-27 21:46, LABBE Corentin wrote:

quoted

Le Tue, Sep 27, 2022 at 06:37:53PM +0200, Aurelien Jarno a écrit :

quoted

On 2022-09-20 10:35, Robin Murphy wrote:

quoted

On 2022-09-19 22:00, Jason A. Donenfeld wrote:

quoted

The Rockchip driver has long existed out of tree, but not upstream.
There is support for it upstream in u-boot, but not in Linux proper.
This commit imports the GPLv2 driver written by Lin Jinhan, together
with the DTS and config blobs from Wevsty.

Note that Corentin has a series enabling the full crypto driver for
RK3328 and RK3399[1], so it would seem more sensible to add TRNG support
to that. Having confliciting compatibles for the same hardware that
force the user to change their DT to choose one functionality or the
other isn't good (plus there's also no binding for this one).

It might make sense for the cryptov1-rng driver (I haven't checked). For
the cryptov2-rng driver, I looked at the RK3568 TRM (I can't find the
RK3588 one), and from what I understand crypto and TRNG are two
different devices, using different address spaces, clock, reset and
interrupts. The vendor kernel uses two different drivers.

I confirm that TRNG is not on the same IP on rk3568, something I didnt remark when doing my V2 driver. (I need to remove rng clock from rk3568 dt).
But the rk3588 crypto IP and the TRNG are in the same device.

Ok, thanks for confirming about the rk3568. It seems the only one in the
family with separate devices for TRNG and crypto. Does it means we need
a separate TRNG driver only for it? Or could we handle it the same way
than for instance rk3588 anyway?

I just got now the part 1 of rk3588 TRM which I has missing and it show some conflicting information.
rk3588 seems to have both a dedicated TRNG (TRNG_NS/TRNG_S) with dedicated address space and a TRNG inside the crypto IP.
But for the moment, the TRNG inside crypto IP seems defective.

So what's the ultimate decision? Does anyone work on merging this into
the existing crypto driver? I have a use case with an rk3399-based board,
where having hardware rng enhances boot times dramatically (at least for
some userspaces; see also [1]).

[1] https://bugzilla.kernel.org/show_bug.cgi?id=216502

Hello

I started to work on adding RNG to rk3288_crypto.
I need to publish the work on my github and take time to send it for review.

Regards