[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200214033942.uatozeoqzrhu7shq@gondor.apana.org.au>
Date: Fri, 14 Feb 2020 11:39:42 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Iuliana Prodan <iuliana.prodan@....com>
Cc: Baolin Wang <baolin.wang@...aro.org>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Corentin Labbe <clabbe.montjoie@...il.com>,
Horia Geanta <horia.geanta@....com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...com>,
Maxime Ripard <mripard@...nel.org>,
Aymen Sghaier <aymen.sghaier@....com>,
"David S. Miller" <davem@...emloft.net>,
Silvano Di Ninno <silvano.dininno@....com>,
Franck Lenormand <franck.lenormand@....com>,
"linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v3 1/2] crypto: engine - support for parallel requests
On Fri, Feb 14, 2020 at 01:25:50AM +0000, Iuliana Prodan wrote:
>
> Given your suggestion, I’m thinking of implementing do_one_request, in
> the driver, to return -IN_PROGRESS if the hw can enqueue more and -EBUSY
> if otherwise (solution 1). But, this implies to update all the drivers
> that use crypto-engine (something I wouldn’t mind doing, but I don’t
> have the hw to test it).
We could always maintain a legacy interface for existing drivers
until they are all converted.
Thanks,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists