From: romain.perier@free-electrons•com (Romain Perier)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req
Date: Thu, 16 Jun 2016 14:02:42 +0200 [thread overview]
Message-ID: <57629562.9030908@free-electrons.com> (raw)
In-Reply-To: <20160615224249.3e1e477b@bbrezillon>
Hello,
Le 15/06/2016 22:42, Boris Brezillon a ?crit :
> On Wed, 15 Jun 2016 21:15:31 +0200
> Romain Perier <romain.perier@free-electrons•com> wrote:
>
>> Actually the only way to access the tdma chain is to use the 'req' union
>
> Currently, ...
ok
> Now that the dma specific fields are part of the base request there's no
> reason to keep this union.
>
> You can just put struct mv_cesa_req base; directly under struct
> mv_cesa_ablkcipher_req, and move mv_cesa_ablkcipher_std_req fields in
> mv_cesa_ablkcipher_req.
Well, I think that I might keep the changes related to mv_cesa_tdma_req
in this commit (+ put struct mv_cesa_req base; direct under struct
mv_cesa_ablkcipher_req) and move the changes related to
mv_cesa_ablkcipher_std_req into another commit. What do you think ?
> Initialize basereq earlier and pass it as the first argument of
> mv_cesa_dma_process().
ok
>> @@ -174,9 +174,9 @@ static inline void
>> mv_cesa_ablkcipher_dma_prepare(struct ablkcipher_request *req)
>> {
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(req);
>> - struct mv_cesa_tdma_req *dreq = &creq->req.dma;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> You named it basereq in mv_cesa_ablkcipher_step(). Try to be
> consistent, no matter the name.
ack
>
>>
>> - mv_cesa_dma_prepare(dreq, dreq->base.engine);
>> + mv_cesa_dma_prepare(dreq, dreq->engine);
>> }
>>
>> static inline void
>> @@ -199,7 +199,7 @@ static inline void mv_cesa_ablkcipher_prepare(struct crypto_async_request *req,
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(ablkreq);
>> creq->req.base.engine = engine;
>>
>> - if (creq->req.base.type == CESA_DMA_REQ)
>> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
>> mv_cesa_ablkcipher_dma_prepare(ablkreq);
>> else
>> mv_cesa_ablkcipher_std_prepare(ablkreq);
>> @@ -302,14 +302,13 @@ static int mv_cesa_ablkcipher_dma_req_init(struct ablkcipher_request *req,
>> struct mv_cesa_ablkcipher_req *creq = ablkcipher_request_ctx(req);
>> gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
>> GFP_KERNEL : GFP_ATOMIC;
>> - struct mv_cesa_tdma_req *dreq = &creq->req.dma;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> Ditto.
ack
>> @@ -256,9 +256,9 @@ static int mv_cesa_ahash_std_process(struct ahash_request *req, u32 status)
>> static inline void mv_cesa_ahash_dma_prepare(struct ahash_request *req)
>> {
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> - struct mv_cesa_tdma_req *dreq = &creq->req.dma.base;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> Ditto.
ack
>> @@ -340,7 +340,7 @@ static void mv_cesa_ahash_prepare(struct crypto_async_request *req,
>>
>> creq->req.base.engine = engine;
>>
>> - if (creq->req.base.type == CESA_DMA_REQ)
>> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
>> mv_cesa_ahash_dma_prepare(ahashreq);
>> else
>> mv_cesa_ahash_std_prepare(ahashreq);
>> @@ -555,8 +555,7 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request *req)
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> gfp_t flags = (req->base.flags & CRYPTO_TFM_REQ_MAY_SLEEP) ?
>> GFP_KERNEL : GFP_ATOMIC;
>> - struct mv_cesa_ahash_dma_req *ahashdreq = &creq->req.dma;
>> - struct mv_cesa_tdma_req *dreq = &ahashdreq->base;
>> + struct mv_cesa_req *dreq = &creq->req.base;
>
> Ditto.
ack
>
>> struct mv_cesa_ahash_dma_iter iter;
>> struct mv_cesa_op_ctx *op = NULL;
>> unsigned int frag_len;
>> @@ -662,11 +661,6 @@ static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
>> struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
>> int ret;
>>
>> - if (cesa_dev->caps->has_tdma)
>> - creq->req.base.type = CESA_DMA_REQ;
>> - else
>> - creq->req.base.type = CESA_STD_REQ;
>> -
>
> Hm, where is it decided now? I mean, I don't see this test anywhere
> else in your patch, which means you're now always using standard mode.
It has been replaced by mv_cesa_req_get_type() + initializing
chain.first to NULL in std_init. So, that's the same thing, no ?
>
>> creq->src_nents = sg_nents_for_len(req->src, req->nbytes);
>> if (creq->src_nents < 0) {
>> dev_err(cesa_dev->dev, "Invalid number of src SG");
>> @@ -680,7 +674,7 @@ static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
>> if (*cached)
>> return 0;
>>
>> - if (creq->req.base.type == CESA_DMA_REQ)
>> + if (mv_cesa_req_get_type(&creq->req.base) == CESA_DMA_REQ)
>
> Should be
>
> if (cesa_dev->caps->has_tdma)
>
>> ret = mv_cesa_ahash_dma_req_init(req);
Why ? mv_cesa_req_get_type() tests mv_cesa_req->chain and returns a code
depending on its value. This value is initialized according to what is
set un "has_tdma"...
Thanks,
Regards,
Romain
--
Romain Perier, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2016-06-16 12:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-15 19:15 [PATCH 0/7] Chain crypto requests together at the DMA level Romain Perier
2016-06-15 19:15 ` [PATCH 1/7] crypto: marvell: Add a macro constant for the size of the crypto queue Romain Perier
2016-06-15 19:20 ` Boris Brezillon
2016-06-15 19:15 ` [PATCH 2/7] crypto: marvell: Check engine is not already running when enabling a req Romain Perier
2016-06-15 19:37 ` Boris Brezillon
2016-06-16 8:18 ` Romain Perier
2016-06-15 19:15 ` [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests Romain Perier
2016-06-15 20:07 ` Boris Brezillon
2016-06-16 8:29 ` Romain Perier
2016-06-16 8:32 ` Gregory CLEMENT
2016-06-15 20:48 ` Boris Brezillon
2016-06-15 19:15 ` [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req Romain Perier
2016-06-15 20:42 ` Boris Brezillon
2016-06-16 12:02 ` Romain Perier [this message]
2016-06-16 12:45 ` Boris Brezillon
2016-06-16 12:57 ` Boris Brezillon
2016-06-15 19:15 ` [PATCH 5/7] crypto: marvell: Adding a complete operation for async requests Romain Perier
2016-06-15 20:55 ` Boris Brezillon
2016-06-16 13:41 ` Romain Perier
2016-06-15 19:15 ` [PATCH 6/7] crypto: marvell: Adding load balancing between engines Romain Perier
2016-06-15 21:13 ` Boris Brezillon
2016-06-16 13:44 ` Romain Perier
2016-06-15 19:15 ` [PATCH 7/7] crypto: marvell: Add support for chaining crypto requests in TDMA mode Romain Perier
2016-06-15 21:43 ` Boris Brezillon
2016-06-17 9:54 ` Romain Perier
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=57629562.9030908@free-electrons.com \
--to=romain.perier@free-electrons$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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