[PATCH] hw_random: rockchip: import driver from vendor tree

Janpieter Sollie janpieter.sollie at kabelmail.de
Mon Sep 23 00:48:54 PDT 2024


Hi everybody,

Is there any chance this random driver will be upstreamed?
I'm using it instead of the built-in crypto driver (rk3328-crypto), as this crypto driver showed 
the following:

> [     9.270549] rk3288-crypto ff060000.crypto: will run requests pump with realtime priority
> [     9.270687] rk3288-crypto ff060000.crypto: Register ecb(aes) as ecb-aes-rk
> [     9.270808] rk3288-crypto ff060000.crypto: Register cbc(aes) as cbc-aes-rk
> [     9.270831] rk3288-crypto ff060000.crypto: Register ecb(des) as ecb-des-rk
> [     9.270848] rk3288-crypto ff060000.crypto: Register cbc(des) as cbc-des-rk
> [     9.270864] rk3288-crypto ff060000.crypto: Register ecb(des3_ede) as ecb-des3-ede-rk
> [     9.270880] rk3288-crypto ff060000.crypto: Register cbc(des3_ede) as cbc-des3-ede-rk
> [     9.270896] rk3288-crypto ff060000.crypto: Register sha1 as rk-sha1
> [     9.270915] rk3288-crypto ff060000.crypto: Register sha256 as rk-sha256
> [     9.270932] rk3288-crypto ff060000.crypto: Register md5 as rk-md5

so the options here are pretty useless:
standard tls / ssh (ktls anyone?) almost never uses ecb or cbc ciphers, and about des ... yeah, 
won't dig into that one.
I think a rk3328 device will actually benefit more from a entropy source (even if it's not 
high-quality) than from sha1/256 which are almost always covered by armv8 crypto extensions.
I tried this patch (and disabled the crypto device in dts), it works.
Off course there are FIPS failures, but the user employing a rk3328 board probably knows this is 
not a high-security device.

Any chances here? applying the patch on 6.6.48 (even with clang thinLTO) works flawlessly.

kind regards,

Janpieter Sollie



More information about the Linux-rockchip mailing list