On Wed, Apr 8, 2015 at 10:16 AM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Tue, Apr 07, 2015 at 01:34:28PM -0400, Dan Streetman wrote: >> Update the crypto 842 driver to no longer fallback to LZO if the 842 >> hardware is unavailable. Simplify the crpypto 842 driver to remove all >> headers indicating 842/lzo. >> >> The crypto 842 driver should do 842-format compression and decompression >> only. It should not fallback to LZO compression/decompression. The >> user of the crypto 842 driver can fallback to another format if desired. >> >> Signed-off-by: Dan Streetman <ddstr...@ieee.org> > > Thanks for the series. I don't know how I missed it when it was > merged originally but crypto/842.c needs to be moved over to > drivers/crypto. Your software implementation should take its > places as the reference implementation.
So, the sw implementation is only for decompression; there's no sw compression implementation in these patches. The hw 842 driver is currently at drivers/crypto/nx, and the crypto/842 driver just calls the hw driver (after correctly aligning/sizing the provided buffers to what the hw driver expects), and falls back to the sw decompression if the hw decompression fails (there is no compression fallback, a failure is reported to the caller). Is that setup ok? If users had to directly call the hw driver, instead of using the generic crypto_comp interface, it would complicate things, e.g. in zswap it only expects to call crypto_comp_compress()/decompress(), not call the 842 hw driver directly. > > Cheers, > -- > Email: Herbert Xu <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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
