summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTero Kristo <t-kristo@ti.com>2016-08-04 13:28:39 +0300
committerHerbert Xu <herbert@gondor.apana.org.au>2016-09-13 15:20:56 +0300
commit5a793bcadbe97df7823598b429c0af052e50df1c (patch)
treeac6f0219ae6ca838436f68ab78c0224eb57b9146
parent4e7813a0b2aebb210416a418595ceb91ba4e5a37 (diff)
downloadlinux-5a793bcadbe97df7823598b429c0af052e50df1c.tar.xz
crypto: omap-sham - fix software fallback handling
If we have processed any data with the hardware accelerator (digcnt > 0), we must complete the entire hash by using it. This is because the current hash value can't be imported to the software fallback algorithm. Otherwise we end up with wrong hash results. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
-rw-r--r--drivers/crypto/omap-sham.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index fd50005fd942..f788319f7ba7 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1163,7 +1163,7 @@ static int omap_sham_final(struct ahash_request *req)
* If buffersize is less than 240, we use fallback SW encoding,
* as using DMA + HW in this case doesn't provide any benefit.
*/
- if ((ctx->digcnt + ctx->bufcnt) < 240)
+ if (!ctx->digcnt && ctx->bufcnt < 240)
return omap_sham_final_shash(req);
else if (ctx->bufcnt)
return omap_sham_enqueue(req, OP_FINAL);