From: Corentin Labbe <clabbe.montjoie@gmail.com>
To: Antoine Tenart <antoine.tenart@free-electrons.com>
Cc: herbert@gondor.apana.org.au, davem@davemloft.net,
maxime.ripard@free-electrons.com, wens@csie.org,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 10/11] crypto: sun4i-ss: fix large block size support
Date: Fri, 26 May 2017 16:55:01 +0200 [thread overview]
Message-ID: <20170526145501.GA19284@Red> (raw)
In-Reply-To: <20170524190652.13278-11-antoine.tenart@free-electrons.com>
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@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
WARNING: multiple messages have this Message-ID (diff)
From: clabbe.montjoie@gmail.com (Corentin Labbe)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 10/11] crypto: sun4i-ss: fix large block size support
Date: Fri, 26 May 2017 16:55:01 +0200 [thread overview]
Message-ID: <20170526145501.GA19284@Red> (raw)
In-Reply-To: <20170524190652.13278-11-antoine.tenart@free-electrons.com>
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@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
next prev parent reply other threads:[~2017-05-26 14:55 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 19:06 [PATCH 00/11] ARM: sun5i: cryptographic engine support Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 01/11] crypto: sun4i-ss: group variable definitions in sun4i_hash() Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 02/11] crypto: sun4i-ss: remove conditional checks against 0 Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 03/11] crypto: sun4i-ss: use lower/upper_32_bits helpers Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 04/11] crypto: sun4i-ss: cannot use DMA is the request is 0 length Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 05/11] crypto: sun4i-ss: do not dynamically set parts of the last buffer to 0 Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 06/11] crypto: sun4i-ss: simplify the pad length calculation Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 07/11] crypto: sun4i-ss: simplify the appended bit assignment Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 08/11] crypto: sun4i-ss: use GENMASK to generate masks Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 09/11] crypto: sun4i-ss: move from ablkcipher to skcipher API Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-29 14:47 ` Corentin Labbe
2017-05-29 14:47 ` Corentin Labbe
2017-05-29 14:56 ` Antoine Tenart
2017-05-29 14:56 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 10/11] crypto: sun4i-ss: fix large block size support Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
2017-05-26 14:55 ` Corentin Labbe [this message]
2017-05-26 14:55 ` Corentin Labbe
2017-05-29 8:09 ` Antoine Tenart
2017-05-29 8:09 ` Antoine Tenart
2017-05-29 8:29 ` Maxime Ripard
2017-05-29 8:29 ` Maxime Ripard
2017-05-29 9:15 ` Antoine Tenart
2017-05-29 9:15 ` Antoine Tenart
2017-05-24 19:06 ` [PATCH 11/11] ARM: sun5i: add a cryptographic engine node Antoine Tenart
2017-05-24 19:06 ` Antoine Tenart
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170526145501.GA19284@Red \
--to=clabbe.montjoie@gmail.com \
--cc=antoine.tenart@free-electrons.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=maxime.ripard@free-electrons.com \
--cc=wens@csie.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.