linux-toradex.git/drivers/crypto/exynos-rng.c, branch v5.9

crypto: exynos - use devm_platform_ioremap_resource() to simplify code

2019-08-09T05:11:59+00:00

Use devm_platform_ioremap_resource() to simplify the code a bit.
This is detected by coccinelle.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: drivers - simplify getting .drvdata

2018-04-28T08:09:35+00:00

We should get drvdata from struct device directly. Going via
platform_device is an unneeded step back and forth.

Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos-rng - Add SPDX license identifier and correct module license

2018-01-18T11:52:23+00:00

Replace GPL license statement with SPDX GPL-2.0 license identifier and
correct the module license to GPLv2.

The license itself was a generic GPL because of copy-and-paste from old
drivers/char/hw_random/exynos-rng.c driver (on which this was based on).
However the module license indicated GPL-2.0 or later.  GPL-2.0 was
intended by author so fix up this mess.

Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos - Introduce mutex to prevent concurrent access to hardware

2017-12-22T08:52:44+00:00

Hardware operations like reading random numbers and setting a seed need
to be conducted in a single thread. Therefore a mutex is required to
prevent multiple threads (processes) from accessing the hardware at the
same time.

The sequence of mutex_lock() and mutex_unlock() in the exynos_rng_reseed()
function enables switching between different threads waiting for the
driver to generate random numbers for them.

Signed-off-by: Łukasz Stelmach 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos - Reseed PRNG after generating 2^16 random bytes

2017-12-22T08:52:43+00:00

Reseed PRNG after reading 65 kB of randomness. Although this may reduce
performance, in most cases the loss is not noticeable. Also the time
based threshold for reseeding is changed to one second. Reseeding is
performed whenever either limit is exceeded.

Reseeding of a PRNG does not increase entropy, but it helps preventing
backtracking the internal state of the device from its output sequence,
and hence, prevents potential attacker from predicting numbers to be
generated.

Signed-off-by: Łukasz Stelmach 
Reviewed-by: Stephan Mueller 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos - Improve performance of PRNG

2017-12-22T08:52:43+00:00

Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
to retrieve generated numbers from the registers of PRNG.

Signed-off-by: Łukasz Stelmach 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos - Support Exynos5250+ SoCs

2017-12-22T08:52:42+00:00

Add support for PRNG in Exynos5250+ SoCs.

Signed-off-by: Łukasz Stelmach 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos - Icrease the priority of the driver

2017-12-22T08:29:03+00:00

exynos-rng is one of many implementations of stdrng. With priority as
low as 100 it isn't selected, if software implementations (DRBG) are
available. The value 300 was selected to give the PRNG priority before
software implementations, but allow them to be selected in FIPS-mode
(fips=1 in the kernel command line).

Signed-off-by: Łukasz Stelmach 
Reviewed-by: Stephan Mueller 
Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Herbert Xu

crypto: exynos - Add new Exynos RNG driver

2017-04-21T12:30:46+00:00

Replace existing hw_ranndom/exynos-rng driver with a new, reworked one.
This is a driver for pseudo random number generator block which on
Exynos4 chipsets must be seeded with some value.  On newer Exynos5420
chipsets it might seed itself from true random number generator block
but this is not implemented yet.

New driver is a complete rework to use the crypto ALGAPI instead of
hw_random API.  Rationale for the change:
1. hw_random interface is for true RNG devices.
2. The old driver was seeding itself with jiffies which is not a
   reliable source for randomness.
3. Device generates five random 32-bit numbers in each pass but old
   driver was returning only one 32-bit number thus its performance was
   reduced.

Compatibility with DeviceTree bindings is preserved.

New driver does not use runtime power management but manually enables
and disables the clock when needed.  This is preferred approach because
using runtime PM just to toggle clock is huge overhead.

Another difference is reseeding itself with generated random data
periodically and during resuming from system suspend (previously driver
was re-seeding itself again with jiffies).

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Stephan Müller 
Reviewed-by: PrasannaKumar Muralidharan 
Reviewed-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Herbert Xu