From mboxrd@z Thu Jan 1 00:00:00 1970 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 D9C66C6FD20 for ; Wed, 8 Mar 2023 03:40:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229808AbjCHDkZ (ORCPT ); Tue, 7 Mar 2023 22:40:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42576 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229627AbjCHDkX (ORCPT ); Tue, 7 Mar 2023 22:40:23 -0500 Received: from 167-179-156-38.a7b39c.syd.nbn.aussiebb.net (167-179-156-38.a7b39c.syd.nbn.aussiebb.net [167.179.156.38]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EEC4793E3F; Tue, 7 Mar 2023 19:40:21 -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 1pZkeo-001YNx-FH; Wed, 08 Mar 2023 11:40:03 +0800 Received: by loth.rohan.me.apana.org.au (sSMTP sendmail emulation); Wed, 08 Mar 2023 11:40:02 +0800 Date: Wed, 8 Mar 2023 11:40:02 +0800 From: Herbert Xu To: Linus Walleij Cc: Lionel Debieve , Li kunyu , davem@davemloft.net, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, mcoquelin.stm32@gmail.com Subject: Re: [v5 PATCH 7/7] crypto: stm32 - Save and restore between each request Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 08, 2023 at 11:23:24AM +0800, Herbert Xu wrote: > > Nevermind, I know why it doesn't work. It's specific to ux500 > where you're polling the DCAL bit. But the DCAL bit only works > for the final hash, it doesn't work for the intermediate state. > > Let me check how the old ux500 handled this case. Hmm, it seems to use the same bit. I guess the meaning must be different with ux500. Could you check for me which wait_busy() call is actually failing? Is it the one I added right before we save the state, or is it something else? If it's something perhaps we aren't restoring the state in the right way, because the stm32 state restoring code is quite different compared to the ux500 code. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt