Following on from the previous series, this series addresses further problems with the Marvell CESA hash driver found while testing it my openssl/ssh scenarios. The first patch improves one from the previous series: we can get the transform more directly using req->base.tfm rather than going round the houses. The next few patches rework the algorithm endianness conversions. There are two things which depend on the algorithm endianness - the format of the result, and the format of the bit length in the last block. We introduce a flag to convey this information, and keep the creq->state format in CPU endian mode for consistency. Some of the inconsistent hash results are down to the template operation not being properly initialised - so we zero initialise all template operations. The following patches (from "factor out first fragment decisions to helper") rework the digest handling to ensure that we always provide the hardware with a complete block of data to hash, otherwise it can be left mid-calculation, which then causes state to leak to subsequent operations. This requires a re-structure of the way we put together the DMA entries, so it's done in relatively small steps. This results in the CESA driver passing all tests I can throw at it via the AF_ALG openssl plugin with the exception of asking for the hash of /dev/null. This returns an all zero result, rather than the correct hash value. This bug is pending further diagnosis, but it is believed not to be a driver specific bug as iMX6 CAAM also behaves the same. Unfortunately, this is a large series, but the driver unfortunately needs this level of bug fixing to work properly. drivers/crypto/marvell/cesa.h | 11 +- drivers/crypto/marvell/hash.c | 307 +++++++++++++++++++++--------------------- 2 files changed, 164 insertions(+), 154 deletions(-) -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- 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