From patchwork Wed May 24 19:06:51 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Antoine Tenart X-Patchwork-Id: 9746925 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5058160246 for ; Wed, 24 May 2017 21:27:16 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4122C26E47 for ; Wed, 24 May 2017 21:27:16 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3295E26E16; Wed, 24 May 2017 21:27:16 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2207C26E16 for ; Wed, 24 May 2017 21:27:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S937623AbdEXV1M (ORCPT ); Wed, 24 May 2017 17:27:12 -0400 Received: from mail.free-electrons.com ([62.4.15.54]:50265 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932415AbdEXV1M (ORCPT ); Wed, 24 May 2017 17:27:12 -0400 Received: by mail.free-electrons.com (Postfix, from userid 110) id D2AA120824; Wed, 24 May 2017 23:27:09 +0200 (CEST) Received: from localhost (unknown [80.12.37.224]) by mail.free-electrons.com (Postfix) with ESMTPSA id 8DB2320772; Wed, 24 May 2017 23:27:09 +0200 (CEST) From: Antoine Tenart To: herbert@gondor.apana.org.au, davem@davemloft.net, maxime.ripard@free-electrons.com, wens@csie.org, clabbe.montjoie@gmail.com Cc: Antoine Tenart , linux-crypto@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH 10/11] crypto: sun4i-ss: fix large block size support Date: Wed, 24 May 2017 21:06:51 +0200 Message-Id: <20170524190652.13278-11-antoine.tenart@free-electrons.com> X-Mailer: git-send-email 2.9.4 In-Reply-To: <20170524190652.13278-1-antoine.tenart@free-electrons.com> References: <20170524190652.13278-1-antoine.tenart@free-electrons.com> Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The run-time self-tests fail quite early, as soon as the input block size is larger than 64 bytes: alg: hash: Test 4 failed for sha1-sun4i-ss 00000000: b9 c9 1e 52 c0 26 d8 39 81 ff f2 3c 99 b1 27 b2 00000010: 30 d6 c9 85 One thing to notice is the value of the last word, which is the one expected (it can sometime be the last two words). The datasheet isn't very clear about when the digest is ready to retrieve and is seems the bit SS_DATA_END is cleared when the digest was computed *but* that doesn't mean the digest is ready to retrieve in the registers. A ndelay(1) is added before reading the computed digest to ensure it is available in the SS_MD[] registers. Signed-off-by: Antoine Tenart --- drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c index 685de5b6ab17..6da8d2bbd4da 100644 --- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c @@ -358,6 +358,15 @@ static int sun4i_hash(struct ahash_request *areq) goto release_ss; } + /* + * The datasheet isn't very clear about when to retrieve the digest. The + * bit SS_DATA_END is cleared when the engine has processed the data and + * when the digest is computed *but* it doesn't mean the digest is + * available in the diesgt registers. Hence the delay to be sure we can + * read it. + */ + ndelay(1); + for (i = 0; i < crypto_ahash_digestsize(tfm) / 4; i++) op->hash[i] = readl(ss->base + SS_MD0 + i * 4); @@ -446,6 +455,15 @@ static int sun4i_hash(struct ahash_request *areq) goto release_ss; } + /* + * The datasheet isn't very clear about when to retrieve the digest. The + * bit SS_DATA_END is cleared when the engine has processed the data and + * when the digest is computed *but* it doesn't mean the digest is + * available in the diesgt registers. Hence the delay to be sure we can + * read it. + */ + ndelay(1); + /* Get the hash from the device */ if (op->mode == SS_OP_SHA1) { for (i = 0; i < 5; i++) {