Re: [PATCH v3 2/3] hwrng: exynos - add Samsung Exynos True RNG driver

2017-12-22 Thread Marek Szyprowski
u2019 make[2]: *** [drivers/char/hw_random/exynos-trng.o] Error 1 make[1]: *** [_module_drivers/char/hw_random] Error 2 This looks like a missing dependency on "OF" when "COMPILE_TEST" is selected. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

Re: [PATCH 2/2] crypto: s5p-sss - Fix missed interrupts when working with 8 kB blocks

2016-04-25 Thread Marek Szyprowski
t;) Cc: Signed-off-by: Krzysztof Kozlowski Tested-by: Marek Szyprowski This patch solved similar hang issue on Exynos4210 based Universal_C210 board. Now AES crypto module works fine. --- Issue was easily reproduced on newer (faster?) SoCs, like Odroid XU3/XU4 (Exynos5422). Still it was kind o

[PATCH] crypto: s5p-sss: fix incorrect usage of scatterlists api

2016-04-26 Thread Marek Szyprowski
4a1100a445 ("crypto: s5p-sss - Handle unaligned buffers") Cc: Signed-off-by: Marek Szyprowski --- drivers/crypto/s5p-sss.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c index ac6d62b..2b3a0cf 100644 --- a/driv

Re: [PATCH] hw_random: move add_early_randomness() out of rng_mutex

2019-10-11 Thread Marek Szyprowski
err = enable_best_rng(); > @@ -529,6 +550,7 @@ void hwrng_unregister(struct hwrng *rng) > } > } > > + new_rng = get_current_rng_nolock(); > if (list_empty(&rng_list)) { > mutex_unlock(&rng_mutex); > if (hwrng_fill) > @@ -536,6 +558,12 @@ void hwrng_unregister(struct hwrng *rng) > } else > mutex_unlock(&rng_mutex); > > + if (new_rng) { > + if (old_rng != new_rng) > + add_early_randomness(new_rng); > + put_rng(new_rng); > + } > + > wait_for_completion(&rng->cleanup_done); > } > EXPORT_SYMBOL_GPL(hwrng_unregister); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland

Re: [PATCH v2] hwrng: core - move add_early_randomness() out of rng_mutex

2019-10-14 Thread Marek Szyprowski
17 deletions(-) > Please rebase your patch on top of the cryptodev tree, i.e., make > this an incremental patch with a Fixes header. This v2 applied on the linux-next with reverted v1 fixes my issue. When you prepare the incremental patch, feel free to add: Reported-by: Marek Szypr