In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to
determine
whether the RNG is running. This is suspicious firstly due to the use of
RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to
RNG_CONTROL_REG after configuration of the FROs. Similar
Hi ,
I am trying to understand Hashing Algorithms implementation in linux kernel .
I am really not sure on how to deal with following scenario.
assume when App1 is in middle of
execution(crypto_ahash_init/update/update...) ,App2 sends a request
may be from another cpu in multi-core system to
This patch increases the interleave factor for parallel AES modes
to 4x. This improves performance on Cortex-A57 by ~35%. This is
due to the 3-cycle latency of AES instructions on the A57's
relatively deep pipeline (compared to Cortex-A53 where the AES
instruction latency is only 2 cycles).
At
Signed-off-by: Andre Wolokita andre.wolok...@analog.com
---
drivers/char/hw_random/omap-rng.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index d14dcf7..ff74e5d 100644
---
omap4_rng_init() checks bit 10 of the RNG_CONFIG_REG to determine whether
the RNG is already running before performing any initiliasation. This is not
the correct register to check, as the enable bit is in RNG_CONFIG_CONTROL.
Read from RNG_CONTROL_REG instead.
Signed-off-by: Andre Wolokita
