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 8C088C05027 for ; Thu, 9 Feb 2023 09:33:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229689AbjBIJdi convert rfc822-to-8bit (ORCPT ); Thu, 9 Feb 2023 04:33:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40572 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230315AbjBIJdX (ORCPT ); Thu, 9 Feb 2023 04:33:23 -0500 Received: from fd01.gateway.ufhost.com (fd01.gateway.ufhost.com [61.152.239.71]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C78CE65ED4; Thu, 9 Feb 2023 01:33:13 -0800 (PST) Received: from EXMBX166.cuchost.com (unknown [175.102.18.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "EXMBX166", Issuer "EXMBX166" (not verified)) by fd01.gateway.ufhost.com (Postfix) with ESMTP id AF01B24E2B9; Thu, 9 Feb 2023 17:33:06 +0800 (CST) Received: from EXMBX167.cuchost.com (172.16.6.77) by EXMBX166.cuchost.com (172.16.6.76) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 9 Feb 2023 17:33:06 +0800 Received: from EXMBX168.cuchost.com (172.16.6.78) by EXMBX167.cuchost.com (172.16.6.77) with Microsoft SMTP Server (TLS) id 15.0.1497.42; Thu, 9 Feb 2023 17:33:06 +0800 Received: from EXMBX168.cuchost.com ([fe80::3c2d:dee5:4938:3fc4]) by EXMBX168.cuchost.com ([fe80::3c2d:dee5:4938:3fc4%16]) with mapi id 15.00.1497.044; Thu, 9 Feb 2023 17:33:06 +0800 From: JiaJie Ho To: Herbert Xu 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 Thread-Topic: [PATCH v2 4/4] crypto: starfive - Add hash and HMAC support Thread-Index: AQHZNMIM/vLXVq3JgUiER7vBRC/T367F3jsAgACIQGA= Date: Thu, 9 Feb 2023 09:33:06 +0000 Message-ID: <88a62a7a11814d629e2198583a0349b6@EXMBX168.cuchost.com> References: <20230130154242.112613-1-jiajie.ho@starfivetech.com> <20230130154242.112613-5-jiajie.ho@starfivetech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [202.188.176.82] x-yovoleruleagent: yovoleflag Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org > -----Original Message----- > From: Herbert Xu > Sent: 9 February, 2023 5:15 PM > To: JiaJie 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 > > 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? > The DMA can only support 32-bit addressing. So, I am copying everything in case kernel allocated memory region >32-bit for a user app. > > +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. The hardware doesn't support this. I'll add the fallback in the next version. Thanks for taking time reviewing this patch series. Regards, Jia Jie