linux 3.10 crash with crypto hardware assist,

[Hsieh, Che-Min]

Has anyone seen the following problem on Linux 3.10, or later Linux?
If it is fixed, can anyone point out where the fix is?
Thanks.
Chemin

We are running Android, based on Linux3.10.
With our crypto hardware accelerator, and driver, algorithm of 
"authenc(hmac(sha1),cbc(aes))" is running well.
With our hardware accelerator and algorithm of "rfc4309(ccm(aes))", it is 
running fine  too.

We start testing extended sequence number recently. 
 ip xfrm state is set with flag esn and replay-window 256.  

System crashes shortly, after the first couple of packet transmits.
We try to run the same test with flag esn and replay-window 256 with algorithm 
of "rfc4309(ccm(aes))", it still runs fine with hardware accelerator.

We go back to the same algorithm of "authenc(hmac(sha1),cbc(aes))" but without 
hardware accelerator. This time, it runs fine.

The crypto hardware driver is agnostic to esn. Without esn, it is running fine. 
So it is less likely driver is at fault. 
When it crashes, the stack dump looks like the following

# ping 10.2.242.93 -I 192.168.2.10
PING 10.2.242.93 (10.2.242.93) from 192.168.2.10: 56 data byt  329.068077] 
Unable to handle kernel NULL pointer dereference at virtual address 0008

[  329.079579] pgd = c0004000
[  329.082277] [0008] *pgd=
[  329.085844] Internal error: Oops: 5 [#1] PREEMPT SMP THUMB2
[  329.091390] Modules linked in: ota_crypto ath_pktlog(PO) umac(O) ath_dev(PO) 
ath_dfs(PO) ath_rate_atheros(PO) ath_hal(PO) adf(PO) asf(PO) evbug
[  329.104228] CPU: 3 PID: 247 Comm: kworker/3:1H Tainted: P   O 
3.10.84-perf-gbc40dee-35160-g0d54083 #1
[  329.114126] Workqueue: qcrypto_seq_response_wq seq_response
[  329.119678] task: c94fd080 ti: c97be000 task.ti: c97be000
[  329.125062] PC is at scatterwalk_map_and_copy+0x1e/0x98
[  329.130272] LR is at authenc_esn_geniv_ahash_done+0x29/0x3c
[  329.135824] pc : []lr : []psr: 2033
[  329.135824] sp : c97bfe98  ip :   fp : c0c189e4
[  329.147282] r10: c91585ac  r9 : c9158564  r8 : c0b163c8
[  329.152490] r7 :   r6 : 0001  r5 :   r4 : 271ae748
[  329.158999] r3 : c0b6155c  r2 :   r1 :   r0 : 
[  329.165510] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb  Segment 
kernel
[  329.172977] Control: 50c5787d  Table: 1267c06a  DAC: 0015
[  329.178706]
[  329.178706] PC: 0xc02cd3b2:
[  329.182958] d3b0  f3c243e2 3201020b 1b2c441d bf284294 42b44614 4634bf28 
ff5ef7ff 46394605
[  329.191117] d3d0  0f00f1b8 4629d101 46224638 f02a4427 4628fadf fb62f645 
5004f8d9 464842a6
[  329.199277] d3f0  f04f4641 eba60201 44250604 5004f8c9 e9ddd1cd e9dd3400 
e9dd5602 b0067804
[  329.207436] d410  8200e8bd 4506e96d 8e04e9cd 38c8f246 08b1f2cc 6702e9cd 
f8d8b084 94034000
[  329.215596] d430  688cb33b 91012600 b17446b6 1935684f 970242aa 680cd310 
d40807a4 b32c698c
[  329.223756] d450  462e3110 2c009101 f7ffd1f0 f8deff27 21004008 e7f5462e 
a9014417 461a1bbe
[  329.231915] d470  96029b0a ff86f7ff 990aa801 f7ff2200 9a03ff5d 3000f8d8 
d10d429a e9ddb004
[  329.240075] d490  e9dd4500 b0046702 8100e8bd 462e6909 0103f021 e7d5688c 
ffacf661 f2474608
[  329.248236] d4b0  f2cc21d8 f72b0172 bf00b85b 4504e96d f24f460c f1040120 
f2cc0228 e9cd0189
[  329.256397]
[  329.256397] LR: 0xc02df07d:
[  329.260650] f07c  e7cf0149 ebc96cb2 46500308 e9d46961 6ae56702 65a36992 
6aa36561 64e76a21
[  329.268809] f09c  652264a6 e9c46665 68d31317 46014798 bf00e7b5 4e02e96d 
f5004604 f7ed708c
[  329.276968] f0bc  f504fa6b f7ed7080 4620fa67 4e00e9dd f6fdb002 bf00bea1 
4504e96d e9cd460d
[  329.285127] f0dc  68c46e02 6923b082 b9496c1a 44222601 f8d26a1b 6ce100cc 
96006c22 f98cf7ee
[  329.293287] f0fc  462968a3 b0024620 4500e9dd 6e02e9dd 4718b004 3406e96d 
5602e9cd 4606460d
[  329.301448] f11c  7e04e9cd e9d26902 6eda4310 f1034404 34ac0140 69d74620 
681b6121 b1284798
[  329.309608] f13c  3400e9dd 5602e9dd bd80b004 01acf106 f1066c72 eb010350 
46200147 692361e3
[  329.317768] f15c  0707ea21 622761a2 f8d66972 60e610a4 60a1402a f8536162 
47983c3c d1df2800
[  329.325927] f17c  46206cf1 62276c33 e9c46922 69733106 10a8f8d6 402b60e6 
616360a1 3c3cf852
[  329.334086]
[  329.334086] SP: 0xc97bfe18:
[  329.338340] fe18  0001 c0b2cf80 c1b9f4c0 c0b2cf80 6013 271ae748 
c02cd432 2033
[  329.346500] fe38   c97bfe84 c0b163c8 c9158564 c91585ac c06172f5 
 
[  329.354658] fe58   c0b6155c 271ae748  0001  
c0b163c8 c9158564
[  329.362819] fe78  c91585ac c0c189e4  c97bfe98 c02df0fd c02cd432 
2033 
[  329.370978] fe98  c9158564 8b43 0001 271ae748 cab26540  
0001 
[  329.379139] feb8  c0c18950 c02df0fd 0001 c02d087f c0c189fc 0001 
 c03bc4c7
[  329.387299] fed8  c0c189ec c0c189e0 c1ba1540 c0c189ec c97b4e80 c0b6ada0 
c1ba1540 c1ba6800
[  329.395458] fef8  0001 c1ba1540 c97be008 c01458ab c97bff20  
 
[  329.403619]
[  329.403619] FP: 0xc0c18964:
[  329.407871] 8964  0100 01010001 

[PATCH 13/21] padata: Convert to hotplug state machine

[Sebastian Andrzej Siewior]

Install the callbacks via the state machine. CPU-hotplug multinstance support
is used with the nocalls() version. Maybe parts of padata_alloc() could be
moved into the online callback so that we could invoke ->startup callback for
instance and drop get_online_cpus().

Cc: Steffen Klassert 
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
---
 include/linux/padata.h |  2 +-
 kernel/padata.c| 92 --
 2 files changed, 53 insertions(+), 41 deletions(-)

diff --git a/include/linux/padata.h b/include/linux/padata.h
index 113ee626a4dc..0f9e567d5e15 100644
--- a/include/linux/padata.h
+++ b/include/linux/padata.h
@@ -151,7 +151,7 @@ struct parallel_data {
  * @flags: padata flags.
  */
 struct padata_instance {
-   struct notifier_blockcpu_notifier;
+   struct hlist_nodenode;
struct workqueue_struct *wq;
struct parallel_data*pd;
struct padata_cpumask   cpumask;
diff --git a/kernel/padata.c b/kernel/padata.c
index 993278895ccc..7848f0566403 100644
--- a/kernel/padata.c
+++ b/kernel/padata.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_OBJ_NUM 1000
 
@@ -769,52 +770,43 @@ static inline int pinst_has_cpu(struct padata_instance 
*pinst, int cpu)
cpumask_test_cpu(cpu, pinst->cpumask.cbcpu);
 }
 
-
-static int padata_cpu_callback(struct notifier_block *nfb,
-  unsigned long action, void *hcpu)
+static int padata_cpu_online(unsigned int cpu, struct hlist_node *node)
 {
-   int err;
struct padata_instance *pinst;
-   int cpu = (unsigned long)hcpu;
+   int ret;
 
-   pinst = container_of(nfb, struct padata_instance, cpu_notifier);
+   pinst = hlist_entry_safe(node, struct padata_instance, node);
+   if (!pinst_has_cpu(pinst, cpu))
+   return 0;
 
-   switch (action) {
-   case CPU_ONLINE:
-   case CPU_ONLINE_FROZEN:
-   case CPU_DOWN_FAILED:
-   case CPU_DOWN_FAILED_FROZEN:
-   if (!pinst_has_cpu(pinst, cpu))
-   break;
-   mutex_lock(>lock);
-   err = __padata_add_cpu(pinst, cpu);
-   mutex_unlock(>lock);
-   if (err)
-   return notifier_from_errno(err);
-   break;
-
-   case CPU_DOWN_PREPARE:
-   case CPU_DOWN_PREPARE_FROZEN:
-   case CPU_UP_CANCELED:
-   case CPU_UP_CANCELED_FROZEN:
-   if (!pinst_has_cpu(pinst, cpu))
-   break;
-   mutex_lock(>lock);
-   err = __padata_remove_cpu(pinst, cpu);
-   mutex_unlock(>lock);
-   if (err)
-   return notifier_from_errno(err);
-   break;
-   }
-
-   return NOTIFY_OK;
+   mutex_lock(>lock);
+   ret = __padata_add_cpu(pinst, cpu);
+   mutex_unlock(>lock);
+   return ret;
 }
+
+static int padata_cpu_prep_down(unsigned int cpu, struct hlist_node *node)
+{
+   struct padata_instance *pinst;
+   int ret;
+
+   pinst = hlist_entry_safe(node, struct padata_instance, node);
+   if (!pinst_has_cpu(pinst, cpu))
+   return 0;
+
+   mutex_lock(>lock);
+   ret = __padata_remove_cpu(pinst, cpu);
+   mutex_unlock(>lock);
+   return ret;
+}
+
+static enum cpuhp_state hp_online;
 #endif
 
 static void __padata_free(struct padata_instance *pinst)
 {
 #ifdef CONFIG_HOTPLUG_CPU
-   unregister_hotcpu_notifier(>cpu_notifier);
+   cpuhp_state_remove_instance_nocalls(hp_online, >node);
 #endif
 
padata_stop(pinst);
@@ -1012,11 +1004,8 @@ struct padata_instance *padata_alloc(struct 
workqueue_struct *wq,
mutex_init(>lock);
 
 #ifdef CONFIG_HOTPLUG_CPU
-   pinst->cpu_notifier.notifier_call = padata_cpu_callback;
-   pinst->cpu_notifier.priority = 0;
-   register_hotcpu_notifier(>cpu_notifier);
+   cpuhp_state_add_instance_nocalls(hp_online, >node);
 #endif
-
return pinst;
 
 err_free_masks:
@@ -1039,3 +1028,26 @@ void padata_free(struct padata_instance *pinst)
kobject_put(>kobj);
 }
 EXPORT_SYMBOL(padata_free);
+
+#ifdef CONFIG_HOTPLUG_CPU
+
+static __init int padata_driver_init(void)
+{
+   int ret;
+
+   ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "padata:online",
+ padata_cpu_online,
+ padata_cpu_prep_down);
+   if (ret < 0)
+   return ret;
+   hp_online = ret;
+   return 0;
+}
+module_init(padata_driver_init);
+
+static __exit void padata_driver_exit(void)
+{
+   cpuhp_remove_multi_state(hp_online);
+}
+module_exit(padata_driver_exit);
+#endif
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to 

Re: [PATCH 4/9] hwrng: omap - Use the managed device resource API for registration

[PrasannaKumar Muralidharan]

> Use devm_hwrng_register instead of hwrng_register. It avoids the need
> to handle unregistration explicitly from the remove function.
>
> Signed-off-by: Romain Perier 
> ---
>  drivers/char/hw_random/omap-rng.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/char/hw_random/omap-rng.c 
> b/drivers/char/hw_random/omap-rng.c
> index d47b24d..171c3e8 100644
> --- a/drivers/char/hw_random/omap-rng.c
> +++ b/drivers/char/hw_random/omap-rng.c
> @@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device *pdev)
> if (ret)
> goto err_ioremap;
>
> -   ret = hwrng_register(_rng_ops);
> +   ret = devm_hwrng_register(dev, _rng_ops);
> if (ret)
> goto err_register;
>
> @@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device *pdev)
>  {
> struct omap_rng_dev *priv = platform_get_drvdata(pdev);
>
> -   hwrng_unregister(_rng_ops);
> -
> priv->pdata->cleanup(priv);
>
> pm_runtime_put_sync(>dev);
> --

If devm_hwrng_register is used hwrng_unregister will be called after
pm_runtime_disable is called. If RNG device is in use calling
omap_rng_remove may not work properly.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: echainiv not working as supposed to be?

[Herbert Xu]

On Tue, Sep 06, 2016 at 02:24:59PM +0200, Mathias Krause wrote:
> 
> For each request it XORs the salt into the provided IV (req->iv). For
> ESP the provided IV is the sequence number or, at least, parts of it.
> The thus modified IV gets written into the *destination* buffer
> (req->dst) which might be a different buffer than the source buffer
> (not in the ESP case, though, as it passes the same sg for src and
> dst). Afterwards, the per-cpu IV gets copied over into req->iv,
> effectively overwriting the generated XORed value. Then the inner
> crypto request gets initiated which may finish synchronously or
> asynchronously. Either way, the per-cpu IV gets updated with the new
> value from subreq->iv, which should be equal to req->iv in the normal
> case.

I think your description is basically correct.  However, you seem
to be missing the fact that the real IV (i.e., the IV transmitted
over the wire) is the first block of the encrypted ciphertext.

IOW the per-cpu IV is never sent over the wire.  It's only used
to encrypt the first block of the ciphertext, which becomes the
actual IV.

> So, should echainiv use a per-context per-cpu array instead that --
> for simplicity -- gets initialised with random bytes and will be
> updated as it's now, just not with a single global per-cpu array, but
> a per-context one?

As I said, the per-cpu IV is never seen by anyone so there is no
need to make it per-tfm.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/9] hwrng: omap - Don't prefix the probe message with OMAP

[Romain Perier]

So far, this driver was only used for OMAP SoCs. However, if a device
variant is added for an IP block that has nothing to do with the OMAP
platform, the message "OMAP Random Number Generator Ver" is displayed
anyway. Instead of hardcoding "OMAP" into this message, we decide to
only display "Random Number Generator". As dev_info is already
pre-pending the message with the name of the device, we have enough
informations.

Signed-off-by: Romain Perier 
---
 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 6a3aaad..f1dcdb3 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -392,7 +392,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_register;
 
-   dev_info(>dev, "OMAP Random Number Generator ver. %02x\n",
+   dev_info(>dev, "Random Number Generator ver. %02x\n",
 omap_rng_read(priv, RNG_REV_REG));
 
return 0;
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/9] hwrng: omap - Add support for 128-bit output of data

[Romain Perier]

So far, this driver only supports up to 64 bits of output data generated
by an RNG. Some IP blocks, like the SafeXcel IP-76 supports up to 128
bits of output data. This commits renames registers descriptions
OUTPUT_L_REG and OUTPUT_H_REG to OUTPUT_0_REG and OUPUT_1_REG,
respectively. It also adds two new values to the enumeration of existing
registers: OUTPUT_2_REG and OUTPUT_3_REG.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/omap-rng.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index f9a99b2..6a3aaad 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -65,8 +65,10 @@
 #define OMAP4_RNG_OUTPUT_SIZE  0x8
 
 enum {
-   RNG_OUTPUT_L_REG = 0,
-   RNG_OUTPUT_H_REG,
+   RNG_OUTPUT_0_REG = 0,
+   RNG_OUTPUT_1_REG,
+   RNG_OUTPUT_2_REG,
+   RNG_OUTPUT_3_REG,
RNG_STATUS_REG,
RNG_INTMASK_REG,
RNG_INTACK_REG,
@@ -82,7 +84,7 @@ enum {
 };
 
 static const u16 reg_map_omap2[] = {
-   [RNG_OUTPUT_L_REG]  = 0x0,
+   [RNG_OUTPUT_0_REG]  = 0x0,
[RNG_STATUS_REG]= 0x4,
[RNG_CONFIG_REG]= 0x28,
[RNG_REV_REG]   = 0x3c,
@@ -90,8 +92,8 @@ static const u16 reg_map_omap2[] = {
 };
 
 static const u16 reg_map_omap4[] = {
-   [RNG_OUTPUT_L_REG]  = 0x0,
-   [RNG_OUTPUT_H_REG]  = 0x4,
+   [RNG_OUTPUT_0_REG]  = 0x0,
+   [RNG_OUTPUT_1_REG]  = 0x4,
[RNG_STATUS_REG]= 0x8,
[RNG_INTMASK_REG]   = 0xc,
[RNG_INTACK_REG]= 0x10,
@@ -155,7 +157,7 @@ static int omap_rng_do_read(struct hwrng *rng, void *data, 
size_t max,
if (!priv->pdata->data_present(priv))
return 0;
 
-   memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG],
+   memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_0_REG],
  priv->pdata->data_size);
 
if (priv->pdata->regs[RNG_INTACK_REG])
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 8/9] hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K

[Romain Perier]

This commits adds a device variant for Safexcel,EIP76 found in Marvell
Armada 8k. It defines registers mapping with the good offset and add a
specific initialization function.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/Kconfig|  2 +-
 drivers/char/hw_random/omap-rng.c | 85 ++-
 2 files changed, 84 insertions(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 56ad5a5..aea3613 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -168,7 +168,7 @@ config HW_RANDOM_IXP4XX
 
 config HW_RANDOM_OMAP
tristate "OMAP Random Number Generator support"
-   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS
+   depends on ARCH_OMAP16XX || ARCH_OMAP2PLUS || ARCH_MVEBU
default HW_RANDOM
---help---
  This driver provides kernel-side support for the Random Number
diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index f1dcdb3..7c86c0d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -63,6 +64,7 @@
 
 #define OMAP2_RNG_OUTPUT_SIZE  0x4
 #define OMAP4_RNG_OUTPUT_SIZE  0x8
+#define EIP76_RNG_OUTPUT_SIZE  0x10
 
 enum {
RNG_OUTPUT_0_REG = 0,
@@ -108,6 +110,23 @@ static const u16 reg_map_omap4[] = {
[RNG_SYSCONFIG_REG] = 0x1FE4,
 };
 
+static const u16 reg_map_eip76[] = {
+   [RNG_OUTPUT_0_REG]  = 0x0,
+   [RNG_OUTPUT_1_REG]  = 0x4,
+   [RNG_OUTPUT_2_REG]  = 0x8,
+   [RNG_OUTPUT_3_REG]  = 0xc,
+   [RNG_STATUS_REG]= 0x10,
+   [RNG_INTACK_REG]= 0x10,
+   [RNG_CONTROL_REG]   = 0x14,
+   [RNG_CONFIG_REG]= 0x18,
+   [RNG_ALARMCNT_REG]  = 0x1c,
+   [RNG_FROENABLE_REG] = 0x20,
+   [RNG_FRODETUNE_REG] = 0x24,
+   [RNG_ALARMMASK_REG] = 0x28,
+   [RNG_ALARMSTOP_REG] = 0x2c,
+   [RNG_REV_REG]   = 0x7c,
+};
+
 struct omap_rng_dev;
 /**
  * struct omap_rng_pdata - RNG IP block-specific data
@@ -130,6 +149,7 @@ struct omap_rng_dev {
struct device   *dev;
const struct omap_rng_pdata *pdata;
struct hwrng rng;
+   struct clk  *clk;
 };
 
 static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
@@ -213,6 +233,38 @@ static inline u32 omap4_rng_data_present(struct 
omap_rng_dev *priv)
return omap_rng_read(priv, RNG_STATUS_REG) & RNG_REG_STATUS_RDY;
 }
 
+static int eip76_rng_init(struct omap_rng_dev *priv)
+{
+   u32 val;
+
+   /* Return if RNG is already running. */
+   if (omap_rng_read(priv, RNG_CONTROL_REG) & RNG_CONTROL_ENABLE_TRNG_MASK)
+   return 0;
+
+   /*  Number of 512 bit blocks of raw Noise Source output data that must
+*  be processed by either the Conditioning Function or the
+*  SP 800-90 DRBG ???BC_DF??? functionality to yield a ???full 
entropy???
+*  output value.
+*/
+   val = 0x5 << RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT;
+
+   /* Number of FRO samples that are XOR-ed together into one bit to be
+* shifted into the main shift register
+*/
+   val |= RNG_CONFIG_MAX_REFIL_CYCLES << RNG_CONFIG_MAX_REFIL_CYCLES_SHIFT;
+   omap_rng_write(priv, RNG_CONFIG_REG, val);
+
+   /* Enable all available FROs */
+   omap_rng_write(priv, RNG_FRODETUNE_REG, 0x0);
+   omap_rng_write(priv, RNG_FROENABLE_REG, RNG_REG_FROENABLE_MASK);
+
+   /* Enable TRNG */
+   val = RNG_CONTROL_ENABLE_TRNG_MASK;
+   omap_rng_write(priv, RNG_CONTROL_REG, val);
+
+   return 0;
+}
+
 static int omap4_rng_init(struct omap_rng_dev *priv)
 {
u32 val;
@@ -282,6 +334,14 @@ static struct omap_rng_pdata omap4_rng_pdata = {
.cleanup= omap4_rng_cleanup,
 };
 
+static struct omap_rng_pdata eip76_rng_pdata = {
+   .regs   = (u16 *)reg_map_eip76,
+   .data_size  = EIP76_RNG_OUTPUT_SIZE,
+   .data_present   = omap4_rng_data_present,
+   .init   = eip76_rng_init,
+   .cleanup= omap4_rng_cleanup,
+};
+
 static const struct of_device_id omap_rng_of_match[] = {
{
.compatible = "ti,omap2-rng",
@@ -291,6 +351,10 @@ static const struct of_device_id omap_rng_of_match[] = {
.compatible = "ti,omap4-rng",
.data   = _rng_pdata,
},
+   {
+   .compatible = "inside-secure,safexcel-eip76",
+   .data   = _rng_pdata,
+   },
{},
 };
 MODULE_DEVICE_TABLE(of, omap_rng_of_match);
@@ -309,7 +373,8 @@ static int of_get_omap_rng_device_details(struct 
omap_rng_dev *priv,
}
   

[PATCH 9/9] arm64: dts: marvell: add TRNG description for Armada 8K CP

[Romain Perier]

This commits adds the devicetree description of the SafeXcel IP-76 TRNG
found in the two Armada CP110.

Signed-off-by: Romain Perier 
---
 arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 8 
 arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi  | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi 
b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
index da31bbb..aaffa24 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi
@@ -164,6 +164,14 @@
clocks = <_syscon0 1 21>;
status = "disabled";
};
+
+   cpm_trng: trng@76 {
+   compatible = "marvell,armada-8k-rng", 
"inside-secure,safexcel-eip76";
+   reg = <0x76 0x7d>;
+   interrupts = ;
+   clocks = <_syscon0 1 25>;
+   status = "okay";
+   };
};
 
cpm_pcie0: pcie@f260 {
diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi 
b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
index 6ff1201..216de12 100644
--- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi
@@ -164,6 +164,14 @@
clocks = <_syscon0 1 21>;
status = "disabled";
};
+
+   cps_trng: trng@76 {
+   compatible = "marvell,armada-8k-rng", 
"inside-secure,safexcel-eip76";
+   reg = <0x76 0x7d>;
+   interrupts = ;
+   clocks = <_syscon0 1 25>;
+   status = "okay";
+   };
};
 
cps_pcie0: pcie@f460 {
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/9] hwrng: omap - Switch to non-obsolete read API implementation

[Romain Perier]

The ".data_present" and ".data_read" operations are marked as
OBSOLETE in the hwrng API. We have to use the ".read" operation instead.
It makes the driver simpler and removes the need to do a busy loop to
wait until enough data is generated by the IP. We simplify this step by
only checking the status of the engine, if there is data, we copy the
data to the output buffer and the amout of copied data is returned to the
caller, otherwise zero is returned. The hwrng core will re-call the read
operation as many times as required until enough data has been copied.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/omap-rng.c | 39 ---
 1 file changed, 12 insertions(+), 27 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 01d4be2..d47b24d 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -140,41 +140,27 @@ static inline void omap_rng_write(struct omap_rng_dev 
*priv, u16 reg,
__raw_writel(val, priv->base + priv->pdata->regs[reg]);
 }
 
-static int omap_rng_data_present(struct hwrng *rng, int wait)
+
+static int omap_rng_do_read(struct hwrng *rng, void *data, size_t max,
+   bool wait)
 {
struct omap_rng_dev *priv;
-   int data, i;
 
priv = (struct omap_rng_dev *)rng->priv;
 
-   for (i = 0; i < 20; i++) {
-   data = priv->pdata->data_present(priv);
-   if (data || !wait)
-   break;
-   /* RNG produces data fast enough (2+ MBit/sec, even
-* during "rngtest" loads, that these delays don't
-* seem to trigger.  We *could* use the RNG IRQ, but
-* that'd be higher overhead ... so why bother?
-*/
-   udelay(10);
-   }
-   return data;
-}
-
-static int omap_rng_data_read(struct hwrng *rng, u32 *data)
-{
-   struct omap_rng_dev *priv;
-   u32 data_size, i;
+   if (max < priv->pdata->data_size)
+   return 0;
 
-   priv = (struct omap_rng_dev *)rng->priv;
-   data_size = priv->pdata->data_size;
+   if (!priv->pdata->data_present(priv))
+   return 0;
 
-   for (i = 0; i < data_size / sizeof(u32); i++)
-   data[i] = omap_rng_read(priv, RNG_OUTPUT_L_REG + i);
+   memcpy_fromio(data, priv->base + priv->pdata->regs[RNG_OUTPUT_L_REG],
+ priv->pdata->data_size);
 
if (priv->pdata->regs[RNG_INTACK_REG])
omap_rng_write(priv, RNG_INTACK_REG, RNG_REG_INTACK_RDY_MASK);
-   return data_size;
+
+   return priv->pdata->data_size;
 }
 
 static int omap_rng_init(struct hwrng *rng)
@@ -195,8 +181,7 @@ static void omap_rng_cleanup(struct hwrng *rng)
 
 static struct hwrng omap_rng_ops = {
.name   = "omap",
-   .data_present   = omap_rng_data_present,
-   .data_read  = omap_rng_data_read,
+   .read   = omap_rng_do_read,
.init   = omap_rng_init,
.cleanup= omap_rng_cleanup,
 };
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/9] dt-bindings: omap-rng: Document SafeXcel IP-76 device variant

[Romain Perier]

This commits add missing fields in the documentation that are used
by the new device variant. It also includes DT example to show how
the variant should be used.

Signed-off-by: Romain Perier 
---
 Documentation/devicetree/bindings/rng/omap_rng.txt | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/rng/omap_rng.txt 
b/Documentation/devicetree/bindings/rng/omap_rng.txt
index 6a62acd..4714772 100644
--- a/Documentation/devicetree/bindings/rng/omap_rng.txt
+++ b/Documentation/devicetree/bindings/rng/omap_rng.txt
@@ -1,4 +1,4 @@
-OMAP SoC HWRNG Module
+OMAP SoC and Inside-Secure HWRNG Module
 
 Required properties:
 
@@ -6,11 +6,13 @@ Required properties:
   RNG versions:
   - "ti,omap2-rng" for OMAP2.
   - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+  - "inside-secure,safexcel-eip76" for SoCs with EIP76 IP block
   Note that these two versions are incompatible.
 - ti,hwmods: Name of the hwmod associated with the RNG module
 - reg : Offset and length of the register set for the module
 - interrupts : the interrupt number for the RNG module.
-   Only used for "ti,omap4-rng".
+   Used for "ti,omap4-rng" and "inside-secure,safexcel-eip76"
+- clocks: the trng clock source
 
 Example:
 /* AM335x */
@@ -20,3 +22,11 @@ rng: rng@4831 {
reg = <0x4831 0x2000>;
interrupts = <111>;
 };
+
+/* SafeXcel IP-76 */
+trng: rng@f276 {
+   compatible = "inside-secure,safexcel-eip76";
+   reg = <0xf276 0x7d>;
+   interrupts = ;
+   clocks = <_syscon0 1 25>;
+};
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/9] Add support for SafeXcel IP-76 to OMAP RNG

[Romain Perier]

The driver omap-rng has a lot of similarity with the IP block SafeXcel
IP-76. A lot of registers are the same and the way that the driver works
is very closed the description of the TRNG EIP76 in its datasheet.

This series refactorize the driver, add support for generating bigger
output random data and add a device variant for SafeXcel IP-76, found
in Armada 8K.

Romain Perier (9):
  dt-bindings: Add vendor prefix for INSIDE Secure
  dt-bindings: omap-rng: Document SafeXcel IP-76 device variant
  hwrng: omap - Switch to non-obsolete read API implementation
  hwrng: omap - Use the managed device resource API for registration
  hwrng: omap - Remove global definition of hwrng
  hwrng: omap - Add support for 128-bit output of data
  hwrng: omap - Don't prefix the probe message with OMAP
  hwrng: omap - Add device variant for SafeXcel IP-76 found in Armada 8K
  arm64: dts: marvell: add TRNG description for Armada 8K CP

 Documentation/devicetree/bindings/rng/omap_rng.txt |  14 +-
 .../devicetree/bindings/vendor-prefixes.txt|   1 +
 .../boot/dts/marvell/armada-cp110-master.dtsi  |   8 ++
 .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |   8 ++
 drivers/char/hw_random/Kconfig |   2 +-
 drivers/char/hw_random/omap-rng.c  | 159 +++--
 6 files changed, 145 insertions(+), 47 deletions(-)

-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/9] hwrng: omap - Use the managed device resource API for registration

[Romain Perier]

Use devm_hwrng_register instead of hwrng_register. It avoids the need
to handle unregistration explicitly from the remove function.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/omap-rng.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index d47b24d..171c3e8 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -381,7 +381,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_ioremap;
 
-   ret = hwrng_register(_rng_ops);
+   ret = devm_hwrng_register(dev, _rng_ops);
if (ret)
goto err_register;
 
@@ -402,8 +402,6 @@ static int omap_rng_remove(struct platform_device *pdev)
 {
struct omap_rng_dev *priv = platform_get_drvdata(pdev);
 
-   hwrng_unregister(_rng_ops);
-
priv->pdata->cleanup(priv);
 
pm_runtime_put_sync(>dev);
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/9] hwrng: omap - Remove global definition of hwrng

[Romain Perier]

The omap-rng driver currently assumes that there will only ever be a
single instance of an RNG device. For this reason, there is a statically
allocated struct hwrng, with a fixed name. However, registering two
struct hwrng with the same isn't accepted by the RNG framework, so we
need to switch to a dynamically allocated struct hwrng, each using a
different name. Then, we define the name of this hwrng to "dev_name(dev)",
so the name of the data structure is unique per device.

Signed-off-by: Romain Perier 
---
 drivers/char/hw_random/omap-rng.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/char/hw_random/omap-rng.c 
b/drivers/char/hw_random/omap-rng.c
index 171c3e8..f9a99b2 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -127,6 +127,7 @@ struct omap_rng_dev {
void __iomem*base;
struct device   *dev;
const struct omap_rng_pdata *pdata;
+   struct hwrng rng;
 };
 
 static inline u32 omap_rng_read(struct omap_rng_dev *priv, u16 reg)
@@ -179,12 +180,6 @@ static void omap_rng_cleanup(struct hwrng *rng)
priv->pdata->cleanup(priv);
 }
 
-static struct hwrng omap_rng_ops = {
-   .name   = "omap",
-   .read   = omap_rng_do_read,
-   .init   = omap_rng_init,
-   .cleanup= omap_rng_cleanup,
-};
 
 static inline u32 omap2_rng_data_present(struct omap_rng_dev *priv)
 {
@@ -357,7 +352,11 @@ static int omap_rng_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
 
-   omap_rng_ops.priv = (unsigned long)priv;
+   priv->rng.read = omap_rng_do_read;
+   priv->rng.init = omap_rng_init;
+   priv->rng.cleanup = omap_rng_cleanup;
+
+   priv->rng.priv = (unsigned long)priv;
platform_set_drvdata(pdev, priv);
priv->dev = dev;
 
@@ -368,6 +367,12 @@ static int omap_rng_probe(struct platform_device *pdev)
goto err_ioremap;
}
 
+   priv->rng.name = devm_kstrdup(dev, dev_name(dev), GFP_KERNEL);
+   if (!priv->rng.name) {
+   ret = -ENOMEM;
+   goto err_register;
+   }
+
pm_runtime_enable(>dev);
ret = pm_runtime_get_sync(>dev);
if (ret) {
@@ -381,7 +386,7 @@ static int omap_rng_probe(struct platform_device *pdev)
if (ret)
goto err_ioremap;
 
-   ret = devm_hwrng_register(dev, _rng_ops);
+   ret = devm_hwrng_register(dev, >rng);
if (ret)
goto err_register;
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/9] dt-bindings: Add vendor prefix for INSIDE Secure

[Romain Perier]

This commits adds a vendor for the company INSIDE Secure.
See https://www.insidesecure.com, for more details.

Signed-off-by: Romain Perier 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 1992aa9..6a5e872 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -132,6 +132,7 @@ infineon Infineon Technologies
 inforceInforce Computing
 ingenicIngenic Semiconductor
 innoluxInnolux Corporation
+inside-secure  INSIDE Secure
 intel  Intel Corporation
 intercontrol   Inter Control Group
 invensense InvenSense Inc.
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

echainiv not working as supposed to be?

[Mathias Krause]

Hi Herbert,

I'm a little bit confused on how echainiv is supposed to work. I think
it's doing a few things wrongly, I just can't decide what's actually
wrong as the intended mode of operation is unclear to me. At least,
as-is, the code isn't quite operating as advertised in the comment at
the top of the file.

So, in hope you could enlighten me, here's my understanding of the
current _implementation_ of echainiv (assuming aligned req->iv, for
simplicity):

For each request it XORs the salt into the provided IV (req->iv). For
ESP the provided IV is the sequence number or, at least, parts of it.
The thus modified IV gets written into the *destination* buffer
(req->dst) which might be a different buffer than the source buffer
(not in the ESP case, though, as it passes the same sg for src and
dst). Afterwards, the per-cpu IV gets copied over into req->iv,
effectively overwriting the generated XORed value. Then the inner
crypto request gets initiated which may finish synchronously or
asynchronously. Either way, the per-cpu IV gets updated with the new
value from subreq->iv, which should be equal to req->iv in the normal
case.

Things that are unclear to me:

1/ Why is the XORed IV written to the destination buffer and not the
source buffer? Isn't the sub-request supposed to use the IV from
either req->src or req->iv -- and especially *not* from req->dst?

2/ Why does the XORed IV gets overwritten with the per-cpu IV prior
passing it on to the sub-request, making all possible IV locations in
req->src, req->dst and req->iv *all* be different?

Moreover, the behaviour of 2/ actually leads to the fact, that the
very first IV on each CPU will be a null IV -- not a salted sequence
number. All following IVs will be the result of the (or better "some")
sub-request's IV update, stored into the per-cpu variable -- still no
salted sequence numbers, though.

That behaviour is a bug, IMHO, as this clearly differs from what is
described in the comment. However, I'm uncertain on how to fix it, as
the intended mode of operation is unclear to me... Should only the
first IV of each crypto transform be the salted sequence number and
all following the result of the sub-request's IV update, therefore not
stored in a single per-cpu variable but some echainiv context specific
one?

3/ Why is echainiv using per-cpu IVs in the first place? Shouldn't
those be crypto context specific? Currently we're happily mixing IVs
from different transforms (with possibly different IV sizes!) with
each other via the per-cpu variables. That might be an "issue" if one
echainiv user can maliciously mess with the IVs of another user, e.g.
via AF_ALG.

So, should echainiv use a per-context per-cpu array instead that --
for simplicity -- gets initialised with random bytes and will be
updated as it's now, just not with a single global per-cpu array, but
a per-context one?

That would allow us to still have a lock-less IV generator but one
that cannot be accidentally / maliciously be tampered with by other
echainiv users.


Thanks,
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/2] crypto: qat - fix resource release omissions

[Giovanni Cabiddu]

Hi Lambert,

On Fri, Sep 02, 2016 at 04:47:53PM +0200, Quentin Lambert wrote:
> In certain cases qat_uclo_parse_uof_obj used to return with an error code
> before releasing all resources. This patch add a jump to the appropriate label
> ensuring that the resources are properly released before returning.
> 
> This issue was found with Hector.
Thanks for the patches. This can be easily fixed by moving the kcalloc after 
the compatibility check function. What do you think?

---8<---
Subject: [PATCH] crypto: qat - fix leak on error path

Fix a memory leak in an error path in uc loader.

Signed-off-by: Giovanni Cabiddu 
---
 drivers/crypto/qat/qat_common/qat_uclo.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/crypto/qat/qat_common/qat_uclo.c 
b/drivers/crypto/qat/qat_common/qat_uclo.c
index 9b961b3..e2454d9 100644
--- a/drivers/crypto/qat/qat_common/qat_uclo.c
+++ b/drivers/crypto/qat/qat_common/qat_uclo.c
@@ -967,10 +967,6 @@ static int qat_uclo_parse_uof_obj(struct 
icp_qat_fw_loader_handle *handle)
struct icp_qat_uclo_objhandle *obj_handle = handle->obj_handle;
unsigned int ae;
 
-   obj_handle->uword_buf = kcalloc(UWORD_CPYBUF_SIZE, sizeof(uint64_t),
-   GFP_KERNEL);
-   if (!obj_handle->uword_buf)
-   return -ENOMEM;
obj_handle->encap_uof_obj.beg_uof = obj_handle->obj_hdr->file_buff;
obj_handle->encap_uof_obj.obj_hdr = (struct icp_qat_uof_objhdr *)
 obj_handle->obj_hdr->file_buff;
@@ -982,6 +978,10 @@ static int qat_uclo_parse_uof_obj(struct 
icp_qat_fw_loader_handle *handle)
pr_err("QAT: UOF incompatible\n");
return -EINVAL;
}
+   obj_handle->uword_buf = kcalloc(UWORD_CPYBUF_SIZE, sizeof(uint64_t),
+   GFP_KERNEL);
+   if (!obj_handle->uword_buf)
+   return -ENOMEM;
obj_handle->ustore_phy_size = ICP_QAT_UCLO_MAX_USTORE;
if (!obj_handle->obj_hdr->file_buff ||
!qat_uclo_map_str_table(obj_handle->obj_hdr, ICP_QAT_UOF_STRT,
-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] hwrng: pasemi-rng - Use linux/io.h instead of asm/io.h

[PrasannaKumar Muralidharan]

Checkpatch.pl warns about usage of asm/io.h. Use linux/io.h instead.

Signed-off-by: PrasannaKumar Muralidharan 
---
 drivers/char/hw_random/pasemi-rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/hw_random/pasemi-rng.c 
b/drivers/char/hw_random/pasemi-rng.c
index b4e32f7..545df48 100644
--- a/drivers/char/hw_random/pasemi-rng.c
+++ b/drivers/char/hw_random/pasemi-rng.c
@@ -26,7 +26,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define SDCRNG_CTL_REG 0x00
 #define   SDCRNG_CTL_FVLD_M0xf000
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] s390/crypto: initialize ret to zero to avoid returning garbage value

[Martin Schwidefsky]

On Mon,  5 Sep 2016 17:21:18 +0100
Colin King  wrote:

> From: Colin Ian King 
> 
> static analysis with cppcheck detected that ret is not initialized
> and hence garbage is potentially being returned in the case where
> prng_data->ppnows.reseed_counter <= prng_reseed_limit.
> 
> Signed-off-by: Colin Ian King 
> ---
>  arch/s390/crypto/prng.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
> index 79e3a1f..a21fdf4 100644
> --- a/arch/s390/crypto/prng.c
> +++ b/arch/s390/crypto/prng.c
> @@ -412,7 +412,7 @@ static int prng_sha512_reseed(void)
> 
>  static int prng_sha512_generate(u8 *buf, size_t nbytes)
>  {
> - int ret;
> + int ret = 0;
> 
>   /* reseed needed ? */
>   if (prng_data->ppnows.reseed_counter > prng_reseed_limit) {

This issue has been introduced by git commit 0177db01adf26cf9
"s390/crypto: simplify return code handling" which is only on
the features branch right now. And to set ret=0 does not fix
the problem. The correct fix is to return nbytes.

Still a good catch though.

-- 
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html