Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 26DA3C05027 for ; Thu, 9 Feb 2023 09:15:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229935AbjBIJPP (ORCPT ); Thu, 9 Feb 2023 04:15:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48792 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229641AbjBIJPO (ORCPT ); Thu, 9 Feb 2023 04:15:14 -0500 Received: from formenos.hmeau.com (167-179-156-38.a7b39c.syd.nbn.aussiebb.net [167.179.156.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DF59811148; Thu, 9 Feb 2023 01:15:10 -0800 (PST) Received: from loth.rohan.me.apana.org.au ([192.168.167.2]) by formenos.hmeau.com with smtp (Exim 4.94.2 #2 (Debian)) id 1pQ30m-009DIL-7L; Thu, 09 Feb 2023 17:14:37 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Thu, 09 Feb 2023 17:14:36 +0800 Date: Thu, 9 Feb 2023 17:14:36 +0800 From: Herbert Xu To: Jia Jie Ho Cc: "David S . Miller" , Rob Herring , Krzysztof Kozlowski , Emil Renner Berthing , Conor Dooley , linux-crypto@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org Subject: Re: [PATCH v2 4/4] crypto: starfive - Add hash and HMAC support Message-ID: References: <20230130154242.112613-1-jiajie.ho@starfivetech.com> <20230130154242.112613-5-jiajie.ho@starfivetech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230130154242.112613-5-jiajie.ho@starfivetech.com> Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org 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 Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt