On Fri, May 22, 2015 at 03:33:48PM +0200, Boris Brezillon wrote:
>
> +struct ahash_alg mv_ahmac_sha1_alg = {
> + .init = mv_cesa_ahmac_sha1_init,
> + .update = mv_cesa_ahash_update,
> + .final = mv_cesa_ahash_final,
> + .finup = mv_cesa_ahash_finup,
> + .digest = mv_cesa_ahmac_sha1_digest,
> + .setkey = mv_cesa_ahmac_sha1_setkey,
> + .halg = {
> + .digestsize = SHA1_DIGEST_SIZE,
> + .statesize = sizeof(struct sha1_state),
> + .base = {
> + .cra_name = "hmac(sha1)",
> + .cra_driver_name = "mv-hmac-sha1",
> + .cra_priority = 300,
> + .cra_flags = CRYPTO_ALG_ASYNC |
> + CRYPTO_ALG_KERN_DRIVER_ONLY,
> + .cra_blocksize = SHA1_BLOCK_SIZE,
> + .cra_ctxsize = sizeof(struct mv_cesa_hmac_ctx),
> + .cra_init = mv_cesa_ahmac_cra_init,
> + .cra_module = THIS_MODULE,
> + }
> + }
> +};
So your hmac implementation is purely done in software. Since
you've already written the code, could you please generalise this
and make it a template?
When you're done just add it to crypto/hmac.c and have it operate
on ahash algorithms while the existing hmac can continue to oeprate
on shash ones. For an example of a template that operates on two
different types of algorithms check out crypto/seqiv.c. I'm happy
to help you with the glue code should you have any issues.
This way the next guy who comes along won't have to rewrite hmac
yet again. Who knows one of our existing hash drivers may also
be doing things purely in software and then we can kill the duplicate
code.
Thanks,
--
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
