Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp46992ybh; Wed, 11 Mar 2020 20:26:40 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvKkdcqI+ABle2J+gBmnGqgXZ1FhNjtOLP5I94Hu4jWVLur+SAOFFMe36AgOWN0I+1Oxh5C X-Received: by 2002:aca:b703:: with SMTP id h3mr1203816oif.148.1583983600611; Wed, 11 Mar 2020 20:26:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583983600; cv=none; d=google.com; s=arc-20160816; b=EdfVoM1K8TfduUPquwbpZSYTu5Y2c8s6u12BN4fBphN2nAr/3zHKVj/QQnTE1BerIP GtygVXmk2VVLwzANgVIZC2A2AQjZa4vk2CaEIEeLO5l4Q0Vz5cxSqT1thJivR1bCCzWq oR2sTjTH2FBWnY6+kFfpSebc8rfhq8a4AD9gmWUMxPTuci+fXce0ubIWp4lLw/s+HDbh wXPp4BAuLIm8NvEdmmdXoc52SEx8d/JjT8Zkb58lpPRBYNojJvDfhdN2O/GSYl3sz1Dk ErmHqk+ktkei/4JpckFIfwQFGl20sNFaXIq72RWOi4t/TpPJdCnHu+jwfyvmslujZjDl Z7RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=C0Q5K835yDTecy+MezEtOIL0qKZNLrH6+mw4B2KOnAg=; b=FxTmOAYdt15vXBhUNVOc8X2UkuImn22WbwAGVF+5pjId+dbx2NIhXDj8shLTcM2sJ1 IFR8W4UA7lHjdpP/N358KOcu40ts3Wzn4g2b+Bkg7kbFquXSnt0cbUVuoJFTzWFmr+X/ IWrWEz/+aOnVM6ZXC1JIWg6K9K3Ay9jmQrZnjB1i9sr8Nf8F0WMWyzl/G/KKNTdcBtcF 670AiHqVvEk+s/w6E0+7wzft0kTeX4qm55Y71cnvZ/UtUmfQ+drzaUsfEm8JuYuFtMZp 99mTtJzbDk9DXvB0aB8iH0zd+cD05+zYSVWzTAEkNeiEGTWN95LBZBAwUaMhI89so28A bPEw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x189si2116450oia.270.2020.03.11.20.26.17; Wed, 11 Mar 2020 20:26:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730931AbgCLD0O (ORCPT + 99 others); Wed, 11 Mar 2020 23:26:14 -0400 Received: from helcar.hmeau.com ([216.24.177.18]:56914 "EHLO fornost.hmeau.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730913AbgCLD0O (ORCPT ); Wed, 11 Mar 2020 23:26:14 -0400 Received: from gwarestrin.me.apana.org.au ([192.168.0.7] helo=gwarestrin.arnor.me.apana.org.au) by fornost.hmeau.com with smtp (Exim 4.89 #2 (Debian)) id 1jCETp-0001y0-P7; Thu, 12 Mar 2020 14:25:54 +1100 Received: by gwarestrin.arnor.me.apana.org.au (sSMTP sendmail emulation); Thu, 12 Mar 2020 14:25:53 +1100 Date: Thu, 12 Mar 2020 14:25:53 +1100 From: Herbert Xu To: Iuliana Prodan Cc: Baolin Wang , Ard Biesheuvel , Corentin Labbe , Horia Geanta , Maxime Coquelin , Alexandre Torgue , Maxime Ripard , Aymen Sghaier , "David S. Miller" , Silvano Di Ninno , Franck Lenormand , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, linux-imx Subject: Re: [PATCH v4 1/2] crypto: engine - support for parallel requests Message-ID: <20200312032553.GB19920@gondor.apana.org.au> References: <1583707893-23699-1-git-send-email-iuliana.prodan@nxp.com> <1583707893-23699-2-git-send-email-iuliana.prodan@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1583707893-23699-2-git-send-email-iuliana.prodan@nxp.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Mar 09, 2020 at 12:51:32AM +0200, Iuliana Prodan wrote: > > ret = enginectx->op.do_one_request(engine, async_req); > - if (ret) { > - dev_err(engine->dev, "Failed to do one request from queue: %d\n", ret); > - goto req_err; > + can_enq_more = ret; > + if (can_enq_more < 0) { > + dev_err(engine->dev, "Failed to do one request from queue: %d\n", > + ret); > + goto req_err_1; > + } So this now includes the case of the hardware queue being full and the request needs to be queued until space opens up again. In this case, we should not do dev_err. So you need to be able to distinguish between the hardware queue being full vs. a real fatal error on the request (e.g., out-of-memory or some hardware failure). Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt