[PATCH 10/11] crypto: sun4i-ss: fix large block size support
Corentin Labbe
clabbe.montjoie at gmail.com
Fri May 26 07:55:01 PDT 2017
On Wed, May 24, 2017 at 09:06:51PM +0200, Antoine Tenart wrote:
> 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 <antoine.tenart at free-electrons.com>
> ---
> 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
Hello
Small typo here (diesgt/digest)
> + * 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
and here.
This behaviour is very strange since I didnt get it on other platform.
Could you give me the board name where you get it ?
Does any wmb() after the writel(..SS_DATA_END..) do the trick ?
Which speed are the SS clocks ?
Anyway the whole serie seems good, I will test it just after this weekend.
Thanks
Regards
Corentin Labbe
More information about the linux-arm-kernel
mailing list