From: Kim Phillips <kim.phillips@freescale.com>
To: <lee.nipper@gmail.com>
Cc: linux-crypto@vger.kernel.org
Subject: Re: [PATCH 3/3] crypto: talitos - add hash algorithms
Date: Thu, 29 Apr 2010 22:07:51 -0500 [thread overview]
Message-ID: <20100429220751.224037c0.kim.phillips@freescale.com> (raw)
In-Reply-To: <4bd82b34.0e0bca0a.475e.ffffa572@mx.google.com>
On Wed, 28 Apr 2010 05:33:56 -0700
<lee.nipper@gmail.com> wrote:
> Add the following alorithms to talitos:
> md5,
> sha1,
> sha256,
> sha384,
> sha512.
> These are all type ahash.
sha224 is left as an exercise for the reader, I see ;)
> It has been tested successfully on MPC8349E.
curious, is that an 8349E/sec2.1 or 8349EA/sec2.4?
> It needs a load on a board with SEC 3.x (hint hint).
loaded on an fsl,sec3.0 (8572) - all selftests passed.
> +const struct talitos_ptr zero_entry = {
CHECK drivers/crypto/talitos.c
drivers/crypto/talitos.c:71:26: warning: symbol 'zero_entry' was not declared. Should it be static?
> - edesc->dma_link_tbl = dma_map_single(dev, &edesc->link_tbl[0],
> + if (dma_len)
> + edesc->dma_link_tbl = dma_map_single(dev, &edesc->link_tbl[0],
> edesc->dma_len, DMA_BIDIRECTIONAL);
broken indentation.
> + /* HMAC key */
> + if (ctx->keylen)
> + map_single_talitos_ptr(dev, &desc->ptr[2], ctx->keylen,
> + (char *)&ctx->key, 0, DMA_TO_DEVICE);
> + else {
> + desc->ptr[2] = zero_entry;
> + }
unnecessary braces.
> + if (!req_ctx->last && (index + nbytes) < blocksize) {
> + /* Buffer the partial block */
> + sg_copy_to_buffer(areq->src,
> + sg_count(areq->src, nbytes, &chained),
> + req_ctx->buf + index, nbytes);
> + } else {
> + if (index) {
> + /* partial block from previous update; chain it in. */
> + sg_init_table(req_ctx->bufsl, (nbytes) ? 2 : 1);
> + sg_set_buf(req_ctx->bufsl, req_ctx->buf, index);
> + if (nbytes)
> + scatterwalk_sg_chain(req_ctx->bufsl, 2,
> + areq->src);
> + req_ctx->psrc = req_ctx->bufsl;
> + } else {
> + req_ctx->psrc = areq->src;
> + }
> + nbytes_to_hash = index + nbytes;
> + if (!req_ctx->last) {
> + to_hash_later = (nbytes_to_hash & (blocksize - 1));
> + if (to_hash_later) {
> + int nents;
> + /* Must copy to_hash_later bytes from the end
> + * to bufnext (a partial block) for later.
> + */
> + nents = sg_count(areq->src, nbytes, &chained);
> + sg_copy_end_to_buffer(areq->src, nents,
> + req_ctx->bufnext,
> + to_hash_later,
> + nbytes - to_hash_later);
> +
> + /* Adjust count for what will be hashed now */
> + nbytes_to_hash -= to_hash_later;
> + }
> + req_ctx->to_hash_later = to_hash_later;
> + }
> +
> + /* allocate extended descriptor */
> + edesc = ahash_edesc_alloc(areq, nbytes_to_hash);
> + if (IS_ERR(edesc))
> + return PTR_ERR(edesc);
> +
> + edesc->desc.hdr = ctx->desc_hdr_template;
> +
> + /* On last one, request SEC to pad; otherwise continue */
> + if (req_ctx->last)
> + edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_PAD;
> + else
> + edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_CONT;
> +
> + /* On first one, request SEC to INIT hash. */
> + if (req_ctx->first)
> + edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_INIT;
> +
> + /* When the tfm context has a keylen, it's an HMAC. */
> + if (ctx->keylen) {
> + /* All but middle descriptors request HMAC. */
> + if (req_ctx->first || req_ctx->last)
> + edesc->desc.hdr |= DESC_HDR_MODE0_MDEU_HMAC;
> + }
if (ctx->keylen && (req_ctx->first || req_ctx->last))
hdr |= ...
> +
> + return common_nonsnoop_hash(edesc, areq, nbytes_to_hash,
> + ahash_done);
> + }
> + return 0;
instead of
if (cond) {
do a;
} else {
do b;
return x;
}
return 0;
can we do:
if (cond) {
do a;
return 0;
}
do b;
return x;
> - struct talitos_crypto_alg *talitos_alg;
> + struct talitos_crypto_alg *talitos_alg =
> + crypto_alg_to_talitos_crypto_alg(alg);
> struct talitos_ctx *ctx = crypto_tfm_ctx(tfm);
>
> - talitos_alg = container_of(alg, struct talitos_crypto_alg,
> - algt.alg.crypto);
> -
this undoes what "[PATCH 2/3] crypto: talitos - second prepare step for
adding ahash algorithms" did better IMO.
Thanks!
Kim
next prev parent reply other threads:[~2010-05-01 7:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-28 12:33 [PATCH 3/3] crypto: talitos - add hash algorithms lee.nipper
2010-04-30 3:07 ` Kim Phillips [this message]
2010-04-30 12:17 ` Lee Nipper
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=20100429220751.224037c0.kim.phillips@freescale.com \
--to=kim.phillips@freescale.com \
--cc=lee.nipper@gmail.com \
--cc=linux-crypto@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;
as well as URLs for NNTP newsgroup(s).