| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The last commit merged nx-842.c's code into nx-842-crypto.c. It
did not rename nx-842-crypto.c to nx-842.c, in order to let the
patch more clearly show what was merged. This just renames
nx-842-crypto.c to nx-842.c, with no changes to its code.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Merge the nx-842.c code into nx-842-crypto.c.
This allows later patches to remove the 'platform' driver, and instead
allow each platform driver to directly register with the crypto
compression api.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Replace the duplicated finishing code (set destination buffer length and
set return code to 0) in the case of decompressing a buffer with no header
with a goto to the success case of decompressing a buffer with a header.
This is a trivial change that allows both success cases to use common code,
and includes the pr_debug() msg in both cases as well.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
The transform context is shared memory and must not be written
to without locking. This patch adds locking to nx-842 to prevent
context corruption.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Replace the NX842_MEM_COMPRESS define with a function that returns the
specific platform driver's required working memory size.
The common nx-842.c driver refuses to load if there is no platform
driver present, so instead of defining an approximate working memory
size that's the maximum approximate size of both platform driver's
size requirements, the platform driver can directly provide its
specific, i.e. sizeof(struct nx842_workmem), size requirements which
the 842-nx crypto compression driver will use.
This saves memory by both reducing the required size of each driver
to the specific sizeof() amount, as well as using the specific loaded
platform driver's required amount, instead of the maximum of both.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Move the contents of the include/linux/nx842.h header file into the
drivers/crypto/nx/nx-842.h header file. Remove the nx842.h header
file and its entry in the MAINTAINERS file.
The include/linux/nx842.h header originally was there because the
crypto/842.c driver needed it to communicate with the nx-842 hw
driver. However, that crypto compression driver was moved into
the drivers/crypto/nx/ directory, and now can directly include the
nx-842.h header. Nothing else needs the public include/linux/nx842.h
header file, as all use of the nx-842 hardware driver will be through
the "842-nx" crypto compression driver, since the direct nx-842 api is
very limited in the buffer alignments and sizes that it will accept,
and the crypto compression interface handles those limitations and
allows any alignment and size buffers.
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Remove the null checks for tfm, src, slen, dst, dlen; tfm will never
be null and the other fields are always expected to be set correctly.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
|
Add crypto compression alg for 842 hardware compression and decompression,
using the alg name "842" and driver_name "842-nx".
This uses only the PowerPC coprocessor hardware for 842 compression. It
also uses the hardware for decompression, but if the hardware fails it will
fall back to the 842 software decompression library, so that decompression
never fails (for valid 842 compressed buffers). A header must be used in
most cases, due to the hardware's restrictions on the buffers being
specifically aligned and sized.
Due to the header this driver adds, compressed buffers it creates cannot be
directly passed to the 842 software library for decompression. However,
compressed buffers created by the software 842 library can be passed to
this driver for hardware 842 decompression (with the exception of buffers
containing the "short data" template, as lib/842/842.h explains).
Signed-off-by: Dan Streetman <ddstreet@ieee.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
|
