Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Iuliana Prodan <iuliana.prodan@nxp.com>
To:     Herbert Xu <herbert@gondor.apana.org.au>
CC:     Baolin Wang <baolin.wang@linaro.org>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Corentin Labbe <clabbe.montjoie@gmail.com>,
        Horia Geanta <horia.geanta@nxp.com>,
        Maxime Coquelin <mcoquelin.stm32@gmail.com>,
        Alexandre Torgue <alexandre.torgue@st.com>,
        Maxime Ripard <mripard@kernel.org>,
        Aymen Sghaier <aymen.sghaier@nxp.com>,
        "David S. Miller" <davem@davemloft.net>,
        Silvano Di Ninno <silvano.dininno@nxp.com>,
        Franck Lenormand <franck.lenormand@nxp.com>,
        "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v3 1/2] crypto: engine - support for parallel requests
Thread-Topic: [PATCH v3 1/2] crypto: engine - support for parallel requests
Thread-Index: AQHV3bM2rqEL0DY5X0yRqygyPRgnNA==
Date:   Fri, 14 Feb 2020 01:25:50 +0000
Message-ID: <AM0PR04MB717171C785D20ECC74B415638C150@AM0PR04MB7171.eurprd04.prod.outlook.com>
References: <1581078974-14778-1-git-send-email-iuliana.prodan@nxp.com>
 <1581078974-14778-2-git-send-email-iuliana.prodan@nxp.com>
 <20200213061808.t6udjbgskc2hs7sa@gondor.apana.org.au>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 66899f02-96b0-40a3-dfa5-08d7b0ecd397
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2020 01:25:50.3984
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: GVox/P56UsA0gc6eIIm0i12WC4TRPU0kZu+bt+RTjPIkBPNA9kzvPLKMldSo7yvWroCi9AU3G54sp+shl+Z9Lg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR04MB5442
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 2/13/2020 8:18 AM, Herbert Xu wrote:=0A=
> On Fri, Feb 07, 2020 at 02:36:13PM +0200, Iuliana Prodan wrote:=0A=
>>=0A=
>> +start_request:=0A=
>> +	/* If hardware is busy, do not send any request */=0A=
>> +	if (engine->can_enqueue_more) {=0A=
>> +		if (!engine->can_enqueue_more(engine))=0A=
>> +			goto out;=0A=
> =0A=
> Instead of a driver callback I'd rather the driver called into=0A=
> the engine telling it to stop/start, similar to how net drivers=0A=
> work.=0A=
> =0A=
=0A=
Given your suggestion, I=92m thinking of implementing do_one_request, in =
=0A=
the driver, to return -IN_PROGRESS if the hw can enqueue more and -EBUSY =
=0A=
if otherwise (solution 1). But, this implies to update all the drivers =0A=
that use crypto-engine (something I wouldn=92t mind doing, but I don=92t =
=0A=
have the hw to test it).=0A=
=0A=
My current proposal keeps the backward compatibility of crypto-engine, =0A=
so no need to change the other drivers. If they want to use multiple =0A=
requests or batch requests, they can implement can_enqueue_more, =0A=
respective do_batch_requests (solution 2).=0A=
=0A=
Please, let me know how do you want me to proceed?  Solution 1 or =0A=
solution 2, or=85 maybe I=92ve missed something?=0A=
=0A=
Thanks,=0A=
Iulia=0A=
=0A=
=0A=
=0A=