Uri Simchoni <u...@ctera.com> wrote: > Hi, > > I'd like to add sha1/hmac-sha1 support to the Marvell CESA driver. I couldn't > see an ahash driver that I can use as a reference. Is there such a driver?
We did have an implementation but it had to be removed because it wasn't reentrant so it's not a good model for you to follow anyway. > Assuming the client code is using the init->update->final sequence (and not > just the digest call): > - Should it be using it on the same ahash_request object? (probably yes - > that's the whole point...) Yes. > - If the same ahash_request object is used, it means the driver has to save > the SG info per such call, it cannot simply queue the ahash_request as is > often done in crypto drivers, right? I mean, the req->src is changing between > crypto_ahash_update() calls. First of all to support init/update/final at all, your hardware must be able to provide partial hash results in a "standard" format. See the export/import interface in sha1 for how that should work. Now if your hardware is only able to produce a final result, then you should simply implement finup + digest, and do the update operations using a software fallback. To answer your actual question, a single request supports only one outstanding operation at a time. So it is illegal for the user to issue a new update operation prior to the previous completing. IOW you have nothing to worry about. > - Same for callback? (.complete pointer) Ditto. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herb...@gondor.apana.org.au> 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 linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
