mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@codeaurora.org>
To: Stanimir Varbanov <svarbanov@mm-sol.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 5/9] crypto: qce: Adds sha and hmac transforms
Date: Tue, 8 Apr 2014 17:09:31 -0700	[thread overview]
Message-ID: <20140409000931.GN9985@codeaurora.org> (raw)
In-Reply-To: <1396541886-10966-6-git-send-email-svarbanov@mm-sol.com>

On 04/03, Stanimir Varbanov wrote:
> +static void qce_ahash_dma_done(void *data)
> +{
> +	struct crypto_async_request *async_req = data;
> +	struct ahash_request *req = ahash_request_cast(async_req);
> +	struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
> +	struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> +	struct qce_alg_template *tmpl = to_ahash_tmpl(async_req->tfm);
> +	struct qce_device *qce = tmpl->qce;
> +	struct qce_result_dump *result = qce->dma.result_buf;
> +	unsigned int digestsize = crypto_ahash_digestsize(ahash);
> +	int error;
> +	u32 status;
> +
> +	qce_dma_terminate_all(&qce->dma);
> +
> +	qce_unmapsg(qce->dev, req->src, rctx->src_nents, DMA_TO_DEVICE,
> +		     rctx->src_chained);
> +	qce_unmapsg(qce->dev, &rctx->result_sg, 1, DMA_FROM_DEVICE, 0);
> +
> +	memcpy(rctx->digest, result->auth_iv, digestsize);
> +	if (req->result)
> +		memcpy(req->result, result->auth_iv, digestsize);
> +
> +	rctx->byte_count[0] = cpu_to_be32(result->auth_byte_count[0]);
> +	rctx->byte_count[1] = cpu_to_be32(result->auth_byte_count[1]);

Does rctx->byte_count need to be marked __be32?

> +
> +	error = qce_check_status(qce, &status);
> +	if (error < 0)
> +		dev_err(qce->dev, "ahash operation error (%x)\n", status);
> +
> +	req->src = rctx->src;
> +	req->nbytes = rctx->nbytes;
> +
> +	rctx->last_blk = false;
> +	rctx->first_blk = false;
> +
> +	tmpl->async_req_done(tmpl->qce, error);
> +}
> +
[...]
> +static int qce_import_common(struct ahash_request *req, u64 in_count,
> +				 u32 *state, u8 *buffer, bool hmac)
> +{
> +	struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
> +	struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> +	u64 count = in_count;
> +	unsigned int digestsize = crypto_ahash_digestsize(ahash);
> +	unsigned int blocksize;
> +
> +	blocksize = crypto_tfm_alg_blocksize(crypto_ahash_tfm(ahash));
> +	rctx->count = in_count;
> +	memcpy(rctx->trailing_buf, buffer, blocksize);
> +
> +	if (in_count <= blocksize) {
> +		rctx->first_blk = 1;
> +	} else {
> +		rctx->first_blk = 0;
> +		/*
> +		 * For HMAC, there is a hardware padding done when first block
> +		 * is set. Therefore the byte_count must be incremened by 64
> +		 * after the first block operation.
> +		 */
> +		if (hmac)
> +			count += SHA_PADDING;
> +	}
> +
> +	rctx->byte_count[0] = (u32)(count & ~SHA_PADDING_MASK);
> +	rctx->byte_count[1] = (u32)(count >> 32);
> +	qce_cpu_to_be32p_array((__be32 *)rctx->digest, (const u8 *)state,
> +			       digestsize);
> +	rctx->trailing_buf_len = (unsigned int)(in_count & (blocksize - 1));

Is this a way to say

	(unsigned int)clamp_t(u64, in_count, blocksize - 1)

?

> +
> +	return 0;
> +}
> +
> +static int qce_ahash_import(struct ahash_request *req, const void *in)
> +{
> +	struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> +	u32 flags = rctx->flags;
> +	bool hmac = IS_SHA_HMAC(flags);
> +	int ret;
> +
> +	if (IS_SHA1(flags) || IS_SHA1_HMAC(flags)) {
> +		struct sha1_state *state = (struct sha1_state *)in;

Unnecessary cast from void *.

> +
> +		ret = qce_import_common(req, state->count, state->state,
> +					state->buffer, hmac);
> +	} else if (IS_SHA256(flags) || IS_SHA256_HMAC(flags)) {
> +		struct sha256_state *state = (struct sha256_state *)in;

Ditto.

> +
> +		ret = qce_import_common(req, state->count, state->state,
> +					state->buf, hmac);
> +	} else {
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}
> +
> +static int qce_ahash_update(struct ahash_request *req)
> +{
> +	struct crypto_ahash *tfm = crypto_ahash_reqtfm(req);
> +	struct qce_sha_reqctx *rctx = ahash_request_ctx(req);
> +	struct qce_alg_template *tmpl = to_ahash_tmpl(req->base.tfm);
> +	unsigned int total, len;
> +	int nents;
> +	struct scatterlist *sg_last;
> +	u8 *buf;

> +	u32 pad_len;
> +	u32 trailing_buf_len;
> +	u32 nbytes;
> +	u32 offset;
> +	u32 bytes;

size_t for these?

> +	u8 *staging;
> +	bool chained;
> +	unsigned int blocksize;
> +
> +	blocksize = crypto_tfm_alg_blocksize(crypto_ahash_tfm(tfm));
> +	rctx->count += req->nbytes;
> +
> +	/* check for trailing buffer from previous updates and append it */
> +	total = req->nbytes + rctx->trailing_buf_len;
> +	len = req->nbytes;
[...]
> +
> +struct qce_ahash_def {
> +	u32 flags;

unsigned long?

> +	const char *name;
> +	const char *drv_name;
> +	unsigned int digestsize;
> +	unsigned int blocksize;
> +	unsigned int statesize;
> +	const __be32 *std_iv;
> +};
[..]
> +
> +/*

Nit: This isn't kernel doc notation

> + * @flags: operation flags
> + * @src: request sg
> + * @src_chained: is source scatterlist chained
> + * @src_nents: source number of entries
> + * @nbytes: request number of bytes
> + * @byte_count: byte count
> + * @count: save count in states during update, import and export
> + * @first_blk: is it the first block
> + * @last_blk: is it the last block
> + * @trailing_buf: used during update, import and export
> + * @trailing_buf_len: lenght of the trailing buffer
> + * @staging_buf: buffer for internal use
> + * @digest: calculated digest
> + * @sg: used to chain sg lists
> + * @authkey: pointer to auth key in sha ctx
> + * @authklen: auth key length
> + * @result_sg: scatterlist used for result buffer
> + */
> +struct qce_sha_reqctx {
> +	u32 flags;

unsigned long?

> +	struct scatterlist *src;
> +	bool src_chained;
> +	int src_nents;
> +	unsigned int nbytes;
> +	u32 byte_count[2];
> +	u64 count;
> +	bool first_blk;

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

  reply	other threads:[~2014-04-09  0:09 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03 16:17 [PATCH 0/9] Add Qualcomm crypto driver Stanimir Varbanov
2014-04-03 16:17 ` [PATCH 1/9] crypto: qce: Add core driver implementation Stanimir Varbanov
2014-04-03 18:19   ` Josh Cartwright
2014-04-04 15:54     ` Stanimir Varbanov
2014-04-03 23:38   ` Courtney Cavin
2014-04-08 16:26     ` Stanimir Varbanov
2014-04-08 22:00       ` Courtney Cavin
2014-04-14  8:19         ` Stanimir Varbanov
2014-04-03 16:17 ` [PATCH 2/9] crypto: qce: Add register defines Stanimir Varbanov
2014-04-03 16:24   ` Kumar Gala
2014-04-03 16:33     ` Stanimir Varbanov
2014-04-03 16:42       ` Kumar Gala
2014-04-04  9:23   ` Srinivas Kandagatla
2014-04-04 22:14     ` Stanimir Vabanov
2014-04-03 16:18 ` [PATCH 3/9] crypto: qce: Add dma and sg helpers Stanimir Varbanov
2014-04-03 18:25   ` Josh Cartwright
2014-04-04  8:49     ` Stanimir Varbanov
2014-04-03 23:15   ` Courtney Cavin
2014-04-04 13:07     ` Stanimir Varbanov
2014-04-07 22:42       ` Courtney Cavin
2014-04-08 12:08         ` Stanimir Varbanov
2014-04-03 16:18 ` [PATCH 4/9] crypto: qce: Add ablkcipher algorithms Stanimir Varbanov
2014-04-03 16:18 ` [PATCH 5/9] crypto: qce: Adds sha and hmac transforms Stanimir Varbanov
2014-04-09  0:09   ` Stephen Boyd [this message]
2014-04-10 14:40     ` Stanimir Varbanov
2014-04-11 20:12       ` Stephen Boyd
2014-04-14  8:23         ` Stanimir Varbanov
2014-04-03 16:18 ` [PATCH 6/9] crypto: qce: Adds infrastructure to setup the crypto block Stanimir Varbanov
2014-04-03 16:18 ` [PATCH 7/9] crypto: qce: Adds Makefile to build the driver Stanimir Varbanov
2014-04-03 16:18 ` [PATCH 8/9] crypto: qce: Build Qualcomm qce driver Stanimir Varbanov
2014-04-03 16:18 ` [PATCH 9/9] ARM: DT: qcom: Add Qualcomm crypto driver binding document Stanimir Varbanov

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=20140409000931.GN9985@codeaurora.org \
    --to=sboyd@codeaurora.org \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=svarbanov@mm-sol.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

Powered by JetHome