Patch: Remove leftover from spinlock previous used in sahara driver

[Mogens Lauridsen]

Hi,

The Freescale sahara driver has previously used a spinlock. This
spinlock has been removed, but the spinlock variable is still there
and is also being initialized. This patch removes the leftover.

Thanks,
Mogens Lauridsen

Signed-off-by: Mogens Lauridsen 

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 9538c52..b35cbda 100644
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -202,7 +202,6 @@ struct sahara_dev {
 struct completiondma_completion;

 struct sahara_ctx*ctx;
-spinlock_tlock;
 struct crypto_queuequeue;
 unsigned longflags;

@@ -1487,7 +1486,6 @@ static int sahara_probe(struct platform_device *pdev)

 crypto_init_queue(>queue, SAHARA_QUEUE_LENGTH);

-spin_lock_init(>lock);
 mutex_init(>queue_mutex);

 dev_ptr = dev;

Fix dma unmap direction in iMX sahara aes calculation

[Mogens Lauridsen]

Hi,

The direction used in dma_unmap_sg in aes calc in sahara.c is wrong.
This result in the cache not being invalidated correct when aes
calculation is done and result is dma'ed to memory.
This is seen as sporadic wrong result from aes calc.

Thanks,
Mogens

Signed-off-by: Mogens Lauridsen 

diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 1d9ecd3..9538c52 100644ae
--- a/drivers/crypto/sahara.c
+++ b/drivers/crypto/sahara.c
@@ -543,10 +543,10 @@ static int sahara_hw_descriptor_create(struct sahara_dev *

 unmap_out:
dma_unmap_sg(dev->device, dev->out_sg, dev->nb_out_sg,
-   DMA_TO_DEVICE);
+   DMA_FROM_DEVICE);
 unmap_in:
dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
-   DMA_FROM_DEVICE);
+   DMA_TO_DEVICE);

return -EINVAL;
 }
@@ -594,9 +594,9 @@ static int sahara_aes_process(struct ablkcipher_request *req
}

dma_unmap_sg(dev->device, dev->out_sg, dev->nb_out_sg,
-   DMA_TO_DEVICE);
-   dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
DMA_FROM_DEVICE);
+   dma_unmap_sg(dev->device, dev->in_sg, dev->nb_in_sg,
+   DMA_TO_DEVICE);

return 0;
 }

[PATCH] crypto/rng: ensure that the RNG is ready before using

[Jason A. Donenfeld]

Otherwise, we might be seeding the RNG using bad randomness, which is
dangerous. The one use of this function from within the kernel -- not
from userspace -- is being removed (keys/big_key), so that call site
isn't relevant in assessing this.

Cc: Herbert Xu 
Signed-off-by: Jason A. Donenfeld 
---
 crypto/rng.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/crypto/rng.c b/crypto/rng.c
index 5e8469244960..b4a618668161 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -43,12 +43,14 @@ int crypto_rng_reset(struct crypto_rng *tfm, const u8 
*seed, unsigned int slen)
if (!buf)
return -ENOMEM;
 
-   get_random_bytes(buf, slen);
+   err = get_random_bytes_wait(buf, slen);
+   if (err)
+   goto out;
seed = buf;
}
 
err = crypto_rng_alg(tfm)->seed(tfm, seed, slen);
-
+out:
kzfree(buf);
return err;
 }
-- 
2.13.3

Re: [PATCH 00/10] Fix alignment issues in staging/ccree

[Simon Sandström]

Hi

On Tue, Jul 11, 2017 at 07:00:33PM +0200, Greg KH wrote:
> Not all of these applied, some did, if you could rebase the remaining
> against my staging-testing branch at the moment, and resend, that would
> be great.

I'm not sure about the preferred procedure. Is it OK to send the
rebased patches in this mail thread, or should I send them as a
new patchset in a new mail thread?

- Simon