Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964973AbdLVJej (ORCPT ); Fri, 22 Dec 2017 04:34:39 -0500 Received: from mail-wm0-f67.google.com ([74.125.82.67]:46762 "EHLO mail-wm0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758084AbdLVJeV (ORCPT ); Fri, 22 Dec 2017 04:34:21 -0500 X-Google-Smtp-Source: ACJfBot0d35us7tU7rOutKq87yKy7F9WqdpurF3QiewCtzOQTNEDBFBCTra162XFp4sEOHS2zEYqdA== Date: Fri, 22 Dec 2017 10:34:18 +0100 From: Corentin Labbe To: Herbert Xu Cc: alexandre.torgue@st.com, arei.gonglei@huawei.com, davem@davemloft.net, jasowang@redhat.com, mcoquelin.stm32@gmail.com, mst@redhat.com, fabien.dessenne@st.com, linux-arm-kernel@lists.infradead.org, linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests Message-ID: <20171222093418.GB3024@Red> References: <20171129084121.9385-1-clabbe.montjoie@gmail.com> <20171129084121.9385-2-clabbe.montjoie@gmail.com> <20171222065724.GA27149@gondor.apana.org.au> <20171222084148.GA3024@Red> <20171222090603.GB32542@gondor.apana.org.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171222090603.GB32542@gondor.apana.org.au> User-Agent: Mutt/1.7.2 (2016-11-26) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1074 Lines: 23 On Fri, Dec 22, 2017 at 08:06:03PM +1100, Herbert Xu wrote: > On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote: > > > > It's you that was suggesting using crypto_async_request: > > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1474434.html > > "The only wart with this scheme is that the drivers end up seeing > > struct crypto_async_request and will need to convert that to the > > respective request types but I couldn't really find a better way." > > > > So I wait for any suggestion. > > The core engine code obviously will use the base type but it should > not be exposed to the driver authors. IOW all exposed API should > take the final types such as aead_request before casting it. > For driver->engine calls(crypto_finalize_request/crypto_transfer_request_to_engine) it's easy. But I do not see how to do it for crypto_engine_op appart re-introducing the big if/then/else that you didnt want. Or do you agree to set the request parameter for crypto_engine_op(prepare_request/unprepare_request/do_one_request) to void * ? Regards