linux-crypto.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Iuliana Prodan <iuliana.prodan@nxp.com>
To: Horia Geanta <horia.geanta@nxp.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Gary Hook <gary.hook@amd.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 07/12] crypto: caam - refactor caam_jr_enqueue
Date: Tue, 19 Nov 2019 22:49:19 +0000	[thread overview]
Message-ID: <VI1PR04MB44452654BA9716CA43992AA68C4C0@VI1PR04MB4445.eurprd04.prod.outlook.com> (raw)
In-Reply-To: VI1PR0402MB34853893505F95195F4C125B984C0@VI1PR0402MB3485.eurprd04.prod.outlook.com

On 11/19/2019 7:55 PM, Horia Geanta wrote:
> On 11/18/2019 12:31 AM, Iuliana Prodan wrote:
>> Added a new struct - caam_jr_request_entry, to keep each request
>> information. This has a crypto_async_request, used to determine
>> the request type, and a bool to check if the request has backlog
>> flag or not.
>> This struct is passed to CAAM, via enqueue function - caam_jr_enqueue.
>>
>> The new added caam_jr_enqueue_no_bklog function is used to enqueue a job
>> descriptor head for cases like caamrng, key_gen, digest_key, where we
> Enqueuing terminology: either generic "job" or more HW-specific
> "job descriptor".
> Job descriptor *head* has no meaning.
> 
>> don't have backlogged requests.
>>
> ...because the "requests" are not crypto requests - they are either coming
> from hwrng (caamrng's case) or are driver-internal (key_gen, digest_key -
> used for key hashing / derivation during .setkey callback).
> 

Right, I'll update the patch description in v2.

>> diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
>> index 21b6172..abebcfc 100644
>> --- a/drivers/crypto/caam/caamalg.c
>> +++ b/drivers/crypto/caam/caamalg.c
> [...]
>> @@ -1416,7 +1424,7 @@ static inline int chachapoly_crypt(struct aead_request *req, bool encrypt)
>>   			     DUMP_PREFIX_ADDRESS, 16, 4, desc, desc_bytes(desc),
>>   			     1);
>>   
>> -	ret = caam_jr_enqueue(jrdev, desc, aead_crypt_done, req);
>> +	ret = caam_jr_enqueue(jrdev, desc, aead_crypt_done, &edesc->jrentry);
>>   	if (ret != -EINPROGRESS) {
>>   		aead_unmap(jrdev, edesc, req);
>>   		kfree(edesc);
>> @@ -1440,6 +1448,7 @@ static inline int aead_crypt(struct aead_request *req, bool encrypt)
>>   	struct aead_edesc *edesc;
>>   	struct crypto_aead *aead = crypto_aead_reqtfm(req);
>>   	struct caam_ctx *ctx = crypto_aead_ctx(aead);
>> +	struct caam_jr_request_entry *jrentry;
>>   	struct device *jrdev = ctx->jrdev;
>>   	bool all_contig;
>>   	u32 *desc;
>> @@ -1459,7 +1468,9 @@ static inline int aead_crypt(struct aead_request *req, bool encrypt)
>>   			     desc_bytes(edesc->hw_desc), 1);
>>   
>>   	desc = edesc->hw_desc;
>> -	ret = caam_jr_enqueue(jrdev, desc, aead_crypt_done, req);
>> +	jrentry = &edesc->jrentry;
>> +
>> +	ret = caam_jr_enqueue(jrdev, desc, aead_crypt_done, jrentry);
> Let's avoid adding a new local variable by using &edesc->jrentry directly,
> like in chachapoly_crypt().
> Similar for the other places.
> 
I've removed jrentry and req (as mentioned below) in patch #11 of this 
series, but I'll remove them, from this patch, in v2.

>> diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
>> index baf4ab1..d9de3dc 100644
>> --- a/drivers/crypto/caam/caamhash.c
>> +++ b/drivers/crypto/caam/caamhash.c
> [...]
>> @@ -933,11 +943,13 @@ static int ahash_final_ctx(struct ahash_request *req)
>>   			     DUMP_PREFIX_ADDRESS, 16, 4, desc, desc_bytes(desc),
>>   			     1);
>>   
>> -	ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
>> +	jrentry = &edesc->jrentry;
>> +
>> +	ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, jrentry);
>>   	if (ret == -EINPROGRESS)
>>   		return ret;
>>   
>> - unmap_ctx:
>> +unmap_ctx:
> That's correct, however whitespace fixing should be done separately.
> 
Should I make a separate patch for these two whitespaces?

>> @@ -1009,11 +1022,13 @@ static int ahash_finup_ctx(struct ahash_request *req)
>>   			     DUMP_PREFIX_ADDRESS, 16, 4, desc, desc_bytes(desc),
>>   			     1);
>>   
>> -	ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, req);
>> +	jrentry = &edesc->jrentry;
>> +
>> +	ret = caam_jr_enqueue(jrdev, desc, ahash_done_ctx_src, jrentry);
>>   	if (ret == -EINPROGRESS)
>>   		return ret;
>>   
>> - unmap_ctx:
>> +unmap_ctx:
> Again, unrelated whitespace fix.
> 
>> diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
>> index 7f7ea32..bb0e4b9 100644
>> --- a/drivers/crypto/caam/caampkc.c
>> +++ b/drivers/crypto/caam/caampkc.c
> [...]
>> @@ -315,6 +317,8 @@ static struct rsa_edesc *rsa_edesc_alloc(struct akcipher_request *req,
>>   	edesc->mapped_src_nents = mapped_src_nents;
>>   	edesc->mapped_dst_nents = mapped_dst_nents;
>>   
>> +	edesc->jrentry.base = &req->base;
>> +
>>   	edesc->sec4_sg_dma = dma_map_single(dev, edesc->sec4_sg,
>>   					    sec4_sg_bytes, DMA_TO_DEVICE);
>>   	if (dma_mapping_error(dev, edesc->sec4_sg_dma)) {
> [...]
>> @@ -633,7 +638,10 @@ static int caam_rsa_enc(struct akcipher_request *req)
>>   	/* Initialize Job Descriptor */
>>   	init_rsa_pub_desc(edesc->hw_desc, &edesc->pdb.pub);
>>   
>> -	ret = caam_jr_enqueue(jrdev, edesc->hw_desc, rsa_pub_done, req);
>> +	jrentry = &edesc->jrentry;
>> +	jrentry->base = &req->base;
> This field is already set in rsa_edesc_alloc().
> 
>> @@ -666,7 +675,10 @@ static int caam_rsa_dec_priv_f1(struct akcipher_request *req)
>>   	/* Initialize Job Descriptor */
>>   	init_rsa_priv_f1_desc(edesc->hw_desc, &edesc->pdb.priv_f1);
>>   
>> -	ret = caam_jr_enqueue(jrdev, edesc->hw_desc, rsa_priv_f_done, req);
>> +	jrentry = &edesc->jrentry;
>> +	jrentry->base = &req->base;
> The same here.
> 
>> @@ -699,7 +712,10 @@ static int caam_rsa_dec_priv_f2(struct akcipher_request *req)
>>   	/* Initialize Job Descriptor */
>>   	init_rsa_priv_f2_desc(edesc->hw_desc, &edesc->pdb.priv_f2);
>>   
>> -	ret = caam_jr_enqueue(jrdev, edesc->hw_desc, rsa_priv_f_done, req);
>> +	jrentry = &edesc->jrentry;
>> +	jrentry->base = &req->base;
> And here.
> 
>> @@ -732,7 +749,10 @@ static int caam_rsa_dec_priv_f3(struct akcipher_request *req)
>>   	/* Initialize Job Descriptor */
>>   	init_rsa_priv_f3_desc(edesc->hw_desc, &edesc->pdb.priv_f3);
>>   
>> -	ret = caam_jr_enqueue(jrdev, edesc->hw_desc, rsa_priv_f_done, req);
>> +	jrentry = &edesc->jrentry;
>> +	jrentry->base = &req->base;
> Also here.
> 
>> diff --git a/drivers/crypto/caam/intern.h b/drivers/crypto/caam/intern.h
>> index c7c10c9..58be66c 100644
>> --- a/drivers/crypto/caam/intern.h
>> +++ b/drivers/crypto/caam/intern.h
> [...]
>> @@ -104,6 +105,15 @@ struct caam_drv_private {
>>   #endif
>>   };
>>   
>> +/*
>> + * Storage for tracking each request that is processed by a ring
>> + */
>> +struct caam_jr_request_entry {
>> +	/* Common attributes for async crypto requests */
>> +	struct crypto_async_request *base;
>> +	bool bklog;	/* Stored to determine if the request needs backlog */
>> +};
>> +
> Could we use kernel-doc here?

Sure, will do in v2.

Thanks,
Iulia

> 
> Horia
> 


  reply	other threads:[~2019-11-19 22:49 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-17 22:30 [PATCH 00/12] crypto: caam - backlogging support Iuliana Prodan
2019-11-17 22:30 ` [PATCH 01/12] crypto: add helper function for akcipher_request Iuliana Prodan
2019-11-18 13:29   ` Corentin Labbe
2019-11-19 14:27   ` Horia Geanta
2019-11-19 15:10   ` Gary R Hook
2019-11-22  9:08   ` Herbert Xu
2019-11-22 10:29     ` Iuliana Prodan
2019-11-22 10:34       ` Herbert Xu
2019-11-17 22:30 ` [PATCH 02/12] crypto: caam - refactor skcipher/aead/gcm/chachapoly {en,de}crypt functions Iuliana Prodan
2019-11-19 14:41   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 03/12] crypto: caam - refactor ahash_done callbacks Iuliana Prodan
2019-11-19 14:56   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 04/12] crypto: caam - refactor ahash_edesc_alloc Iuliana Prodan
2019-11-19 15:05   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 05/12] crypto: caam - refactor RSA private key _done callbacks Iuliana Prodan
2019-11-19 15:06   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 06/12] crypto: caam - change return code in caam_jr_enqueue function Iuliana Prodan
2019-11-19 15:21   ` Horia Geanta
2019-12-10 11:56   ` Bastian Krause
2019-12-10 12:28     ` Iuliana Prodan
2019-11-17 22:30 ` [PATCH 07/12] crypto: caam - refactor caam_jr_enqueue Iuliana Prodan
2019-11-19 17:55   ` Horia Geanta
2019-11-19 22:49     ` Iuliana Prodan [this message]
2019-11-20  6:48       ` Horia Geanta
2019-11-17 22:30 ` [PATCH 08/12] crypto: caam - support crypto_engine framework for SKCIPHER algorithms Iuliana Prodan
2019-11-21 11:46   ` Horia Geanta
2019-11-22 10:33   ` Herbert Xu
2019-11-22 11:05     ` Iuliana Prodan
2019-11-22 11:09       ` Herbert Xu
2019-11-22 14:11         ` Iuliana Prodan
2019-11-22 14:31           ` Herbert Xu
2019-12-10 15:27   ` Bastian Krause
2019-12-11 12:20     ` Iuliana Prodan
2019-12-11 13:33       ` Bastian Krause
2019-11-17 22:30 ` [PATCH 09/12] crypto: caam - bypass crypto-engine sw queue, if empty Iuliana Prodan
2019-11-21 11:53   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 10/12] crypto: caam - add crypto_engine support for AEAD algorithms Iuliana Prodan
2019-11-21 16:46   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 11/12] crypto: caam - add crypto_engine support for RSA algorithms Iuliana Prodan
2019-11-21 16:53   ` Horia Geanta
2019-11-17 22:30 ` [PATCH 12/12] crypto: caam - add crypto_engine support for HASH algorithms Iuliana Prodan
2019-11-21 17:06   ` Horia Geanta

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=VI1PR04MB44452654BA9716CA43992AA68C4C0@VI1PR04MB4445.eurprd04.prod.outlook.com \
    --to=iuliana.prodan@nxp.com \
    --cc=aymen.sghaier@nxp.com \
    --cc=davem@davemloft.net \
    --cc=gary.hook@amd.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horia.geanta@nxp.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thomas.lendacky@amd.com \
    /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;
as well as URLs for NNTP newsgroup(s).