Uri Simchoni <uris@xxxxxxxxx> 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~} <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 linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
