AWS Graviton based systems provide an Arm SMC call in the vendor defined
hypervisor region to read random numbers from a HW TRNG and return them to the
guest.
We've observed slower guest boot and especially reboot times due to lack of
entropy and providing access to a TRNG is meant to address thi
AWS Graviton based systems provide an Arm SMC call in the vendor defined
hypervisor region to read random numbers from a TRNG and return them
to the guest.
Co-developed-by: Ron Rindjunsky
Signed-off-by: Ali Saidi
Signed-off-by: Ron Rindjunsky
---
MAINTAINERS | 6 ++
Allow a module that wants to make SMC calls to detect if it should be
using smc or hvc.
Signed-off-by: Ali Saidi
---
arch/arm64/kernel/acpi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 803f0494dd3e..ea41c6541d3c 100644
--- a/arch
The SMC calling convention defines service identifiers for generic and
vendor specific hypervisor services. This patch adds those services to
the list of existing service identifiers.
Signed-off-by: Ali Saidi
---
include/linux/arm-smccc.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/inc
Fix sparse warnings:
drivers/crypto/bcm/cipher.c:99:6: warning: symbol 'BCMHEADER' was not declared.
Should it be static?
drivers/crypto/bcm/cipher.c:2096:6: warning: symbol 'spu_no_incr_hash' was not
declared. Should it be static?
drivers/crypto/bcm/cipher.c:4823:5: warning: symbol 'bcm_spu_pro
Hi Andrew,
>But struct ZSTD_CCtx_s.params is still a copied structure. Could we
>make it `const ZSTD_parameters *params'? Probably not, due to lifetime
>issues?
ZSTD maintains its own ctxt. Yes we can avoid storing pointers of other modules
because of lifetime issues. We should keep ZSTD_CCtx_
Hi Andrew,
>> This patch set reduces stack usage for zstd code, because target like ARM has
>> limited 8KB kernel stack, which is getting overflowed due to hight stack
>> usage
>> of zstd code with call flow like:
>That's rather bad behaviour. I assume the patchset actually fixes this?
Yes, p
