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
