summaryrefslogtreecommitdiff
path: root/include/linux
diff options
context:
space:
mode:
authorNicolas Frattaroli <nicolas.frattaroli@collabora.com>2025-02-04 18:35:50 +0300
committerHerbert Xu <herbert@gondor.apana.org.au>2025-02-22 10:56:02 +0300
commit8eff8eb83fc0ae8b5f76220e2bb8644d836e99ff (patch)
treefd7a4049ec74ae6b250e9cd972471a31f72d640f /include/linux
parent24aaa42ed65c0811b598674a593fc653d643a7e6 (diff)
downloadlinux-8eff8eb83fc0ae8b5f76220e2bb8644d836e99ff.tar.xz
hwrng: rockchip - add support for rk3588's standalone TRNG
The RK3588 SoC includes several TRNGs, one part of the Crypto IP block, and the other one (referred to as "trngv1") as a standalone new IP. Add support for this new standalone TRNG to the driver by both generalising it to support multiple different rockchip RNGs and then implementing the required functionality for the new hardware. This work was partly based on the downstream vendor driver by Rockchip's Lin Jinhan, which is why they are listed as a Co-author. While the hardware does support notifying the CPU with an IRQ when the random data is ready, I've discovered while implementing the code to use this interrupt that this results in significantly slower throughput of the TRNG even when under heavy CPU load. I assume this is because with only 32 bytes of data per invocation, the overhead of reinitialising a completion, enabling the interrupt, sleeping and then triggering the completion in the IRQ handler is way more expensive than busylooping. Speaking of busylooping, the poll interval for reading the ISTAT is an atomic read with a delay of 0. In my testing, I've found that this gives us the largest throughput, and it appears the random data is ready pretty much the moment we begin polling, as increasing the poll delay leads to a drop in throughput significant enough to not just be due to the poll interval missing the ideal timing by a microsecond or two. According to downstream, the IP should take 1024 clock cycles to generate 56 bits of random data, which at 150MHz should work out to 6.8us. I did not test whether the data really does take 256/56*6.8us to arrive, though changing the readl to a __raw_readl makes no difference in throughput, and this data does pass the rngtest FIPS checks, so I'm not entirely sure what's going on but I presume it's got something to do with the AHB bus speed and the memory barriers that mainline's readl/writel functions insert. The only other current SoC that uses this new IP is the Rockchip RV1106, but that SoC does not have mainline support as of the time of writing, so we make no effort to declare it as supported for now. Co-developed-by: Lin Jinhan <troy.lin@rock-chips.com> Signed-off-by: Lin Jinhan <troy.lin@rock-chips.com> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'include/linux')
0 files changed, 0 insertions, 0 deletions