[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+S5fBjZQZli9nBg@gondor.apana.org.au>
Date: Thu, 9 Feb 2023 17:14:36 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Jia Jie Ho <jiajie.ho@...rfivetech.com>
Cc: "David S . Miller" <davem@...emloft.net>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Emil Renner Berthing <kernel@...il.dk>,
Conor Dooley <conor.dooley@...rochip.com>,
linux-crypto@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-riscv@...ts.infradead.org
Subject: Re: [PATCH v2 4/4] crypto: starfive - Add hash and HMAC support
On Mon, Jan 30, 2023 at 11:42:42PM +0800, Jia Jie Ho wrote:
>
> + cryp->hash_data = (void *)__get_free_pages(GFP_KERNEL | GFP_DMA32, pages);
Why do you copy everything before you feed it to the hardware?
If the issue is alignment then surely you should only to copy
a small amount of header (and perhaps trailer) for that?
> +static int starfive_hash_export(struct ahash_request *req, void *out)
> +{
> + struct starfive_cryp_request_ctx *rctx = ahash_request_ctx(req);
> +
> + memcpy(out, rctx, sizeof(*rctx));
> +
> + return 0;
> +}
You are supposed to extract the entire hardware state after each
operation and store that in the request context. Since your
request context doesn't appear to contain any hash state, this
can't possibly work.
Does your hardware allow the non-finalised hash state to be
exported, and re-imported later? If not then you can only
implement support for digest and must use a fallback for
everything else.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists