On Wed, Mar 8, 2023 at 11:19 AM Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, Mar 08, 2023 at 06:10:14PM +0800, Herbert Xu wrote:
> >
> > If it's just empty messages, which we know are broken with ux500
> > to begin with, then we can simply not do the hash at all (doing
> > it and then throwing it away seems pointless).
>
> Here is a patch to not process empty messages at all.
Hey it works :D
I had to tweak it slightly because we need to set the state right:
@@ -374,9 +387,20 @@ static int stm32_hash_xmit_cpu(struct stm32_hash_dev *hdev,
const u32 *buffer = (const u32 *)buf;
u32 reg;
- if (final)
+ if (final) {
hdev->flags |= HASH_FLAGS_FINAL;
+ /* Do not process empty messages if hw is buggy. */
+ if (!(hdev->flags & HASH_FLAGS_INIT) && !length &&
+ hdev->pdata->broken_emptymsg) {
+ struct stm32_hash_request_ctx *rctx =
ahash_request_ctx(hdev->req);
+ struct stm32_hash_state *state = &rctx->state;
+
+ state->flags |= HASH_FLAGS_EMPTY;
+ return 0;
+ }
+ }
+
len32 = DIV_ROUND_UP(length, sizeof(u32));
dev_dbg(hdev->dev, "%s: length: %zd, final: %x len32 %i\n",
After this it WORKS!
For the "v5.5" patch and this (and my other patch) folded in:
Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
Tested-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
So now the driver is fixed from a Ux500 point of view.
I actually have the STM32MP board, I can try to find some
time to test the final patch set on it as well if it has the same
has as the other STM32 SoCs.
Yours,
Linus Walleij
