From: Fabien DESSENNE <fabien.dessenne@st.com>
To: Corentin Labbe <clabbe.montjoie@gmail.com>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>
Cc: "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 2/3] crypto: engine - find request type with cra_type
Date: Tue, 15 Aug 2017 07:51:14 +0000 [thread overview]
Message-ID: <f2185b14d944433c9737cabc32e3cef9@SFHDAG5NODE3.st.com> (raw)
In-Reply-To: <20170814131725.9402-3-clabbe.montjoie@gmail.com>
Hi Corentin,
Since I have just sent a patch to add the support of "aead_request" to crypto engine, I am wondering if your proposed change (checking cra_type instead of crypto_tfm_alg_type) and mine are compatible.
It looks like they are (assuming we export crypto_aead_type): can you confirm?
BR
Fabien.
>-----Original Message-----
>From: linux-crypto-owner@vger.kernel.org [mailto:linux-crypto-
>owner@vger.kernel.org] On Behalf Of Corentin Labbe
>Sent: lundi 14 août 2017 15:17
>To: herbert@gondor.apana.org.au; davem@davemloft.net
>Cc: linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org; Corentin Labbe
><clabbe.montjoie@gmail.com>
>Subject: [PATCH 2/3] crypto: engine - find request type with cra_type
>
>The current method for finding request type is based on crypto_tfm_alg_type.
>
>But in case of skcipher, it is the same than ablkcipher.
>Using cra_type for this work permits to make the distinction between the two.
>
>Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>---
> crypto/crypto_engine.c | 19 ++++++++-----------
> 1 file changed, 8 insertions(+), 11 deletions(-)
>
>diff --git a/crypto/crypto_engine.c b/crypto/crypto_engine.c index
>61e7c4e02fd2..74b840749074 100644
>--- a/crypto/crypto_engine.c
>+++ b/crypto/crypto_engine.c
>@@ -38,7 +38,8 @@ static void crypto_pump_requests(struct crypto_engine
>*engine,
> struct ablkcipher_request *breq;
> unsigned long flags;
> bool was_busy = false;
>- int ret, rtype;
>+ int ret;
>+ const struct crypto_type *cratype;
>
> spin_lock_irqsave(&engine->queue_lock, flags);
>
>@@ -94,7 +95,7 @@ static void crypto_pump_requests(struct crypto_engine
>*engine,
>
> spin_unlock_irqrestore(&engine->queue_lock, flags);
>
>- rtype = crypto_tfm_alg_type(engine->cur_req->tfm);
>+ cratype = engine->cur_req->tfm->__crt_alg->cra_type;
> /* Until here we get the request need to be encrypted successfully */
> if (!was_busy && engine->prepare_crypt_hardware) {
> ret = engine->prepare_crypt_hardware(engine);
>@@ -104,8 +105,7 @@ static void crypto_pump_requests(struct crypto_engine
>*engine,
> }
> }
>
>- switch (rtype) {
>- case CRYPTO_ALG_TYPE_AHASH:
>+ if (cratype == &crypto_ahash_type) {
> hreq = ahash_request_cast(engine->cur_req);
> if (engine->prepare_hash_request) {
> ret = engine->prepare_hash_request(engine, hreq); @@
>-122,7 +122,7 @@ static void crypto_pump_requests(struct crypto_engine
>*engine,
> goto req_err;
> }
> return;
>- case CRYPTO_ALG_TYPE_ABLKCIPHER:
>+ } else if (cratype == &crypto_ablkcipher_type) {
> breq = ablkcipher_request_cast(engine->cur_req);
> if (engine->prepare_cipher_request) {
> ret = engine->prepare_cipher_request(engine, breq);
>@@ -139,21 +139,18 @@ static void crypto_pump_requests(struct
>crypto_engine *engine,
> goto req_err;
> }
> return;
>- default:
>+ } else {
> dev_err(engine->dev, "failed to prepare request of unknown
>type\n");
> return;
> }
>
> req_err:
>- switch (rtype) {
>- case CRYPTO_ALG_TYPE_AHASH:
>+ if (cratype == &crypto_ahash_type) {
> hreq = ahash_request_cast(engine->cur_req);
> crypto_finalize_hash_request(engine, hreq, ret);
>- break;
>- case CRYPTO_ALG_TYPE_ABLKCIPHER:
>+ } else if (cratype == &crypto_ablkcipher_type) {
> breq = ablkcipher_request_cast(engine->cur_req);
> crypto_finalize_cipher_request(engine, breq, ret);
>- break;
> }
> return;
>
>--
>2.13.0
next prev parent reply other threads:[~2017-08-15 7:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-14 13:17 [PATCH 0/3 v3] crypto: engine - Permit to enqueue skcipher request Corentin Labbe
2017-08-14 13:17 ` [PATCH 1/3] crypto: skcipher - export crypto_skcipher_type2 Corentin Labbe
2017-08-14 13:17 ` [PATCH 2/3] crypto: engine - find request type with cra_type Corentin Labbe
2017-08-15 7:51 ` Fabien DESSENNE [this message]
2017-08-16 8:58 ` Corentin Labbe
2017-08-18 8:28 ` Herbert Xu
2017-08-18 11:40 ` Corentin Labbe
2017-08-14 13:17 ` [PATCH 3/3] crypto: engine - Permit to enqueue skcipher request Corentin Labbe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f2185b14d944433c9737cabc32e3cef9@SFHDAG5NODE3.st.com \
--to=fabien.dessenne@st.com \
--cc=clabbe.montjoie@gmail.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®