summaryrefslogtreecommitdiff
path: root/drivers/mcb/Makefile
diff options
context:
space:
mode:
authorJason A. Donenfeld <Jason@zx2c4.com>2022-07-17 13:35:24 +0300
committerJason A. Donenfeld <Jason@zx2c4.com>2022-07-25 14:26:14 +0300
commitd349ab99eec7ab0f977fc4aac27aa476907acf90 (patch)
treeb98736b45c4f0c00ea2e00e5cefe543bd2ce0759 /drivers/mcb/Makefile
parent0b9ba6135d7f18b82f3d8bebb55ded725ba88e0e (diff)
downloadlinux-d349ab99eec7ab0f977fc4aac27aa476907acf90.tar.xz
random: handle archrandom with multiple longs
The archrandom interface was originally designed for x86, which supplies RDRAND/RDSEED for receiving random words into registers, resulting in one function to generate an int and another to generate a long. However, other architectures don't follow this. On arm64, the SMCCC TRNG interface can return between one and three longs. On s390, the CPACF TRNG interface can return arbitrary amounts, with four longs having the same cost as one. On UML, the os_getrandom() interface can return arbitrary amounts. So change the api signature to take a "max_longs" parameter designating the maximum number of longs requested, and then return the number of longs generated. Since callers need to check this return value and loop anyway, each arch implementation does not bother implementing its own loop to try again to fill the maximum number of longs. Additionally, all existing callers pass in a constant max_longs parameter. Taken together, these two things mean that the codegen doesn't really change much for one-word-at-a-time platforms, while performance is greatly improved on platforms such as s390. Acked-by: Heiko Carstens <hca@linux.ibm.com> Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> Acked-by: Borislav Petkov <bp@suse.de> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'drivers/mcb/Makefile')
0 files changed, 0 insertions, 0 deletions