linux.git/drivers/crypto/caam, branch v4.8-rc2

crypto: caam - add support for RSA algorithm

2016-07-05T15:05:24+00:00

Add RSA support to caam driver.

Initial author is Yashpal Dutta .

Signed-off-by: Tudor Ambarus 
Signed-off-by: Herbert Xu

crypto: caam - replace deprecated EXTRA_CFLAGS

2016-06-20T11:25:00+00:00

EXTRA_CFLAGS is still supported but its usage is deprecated.

Signed-off-by: Tudor Ambarus 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - fix misspelled upper_32_bits

2016-06-20T11:24:39+00:00

An endianess fix mistakenly used higher_32_bits() instead of
upper_32_bits(), and that doesn't exist:

drivers/crypto/caam/desc_constr.h: In function 'append_ptr':
drivers/crypto/caam/desc_constr.h:84:75: error: implicit declaration of function 'higher_32_bits' [-Werror=implicit-function-declaration]
  *offset = cpu_to_caam_dma(ptr);

Signed-off-by: Arnd Bergmann 
Fixes: 261ea058f016 ("crypto: caam - handle core endianness != caam endianness")
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - add ARCH_LAYERSCAPE to supported architectures

2016-05-31T08:41:54+00:00

This basically adds support for ls1043a platform.

Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - handle core endianness != caam endianness

2016-05-31T08:41:54+00:00

There are SoCs like LS1043A where CAAM endianness (BE) does not match
the default endianness of the core (LE).
Moreover, there are requirements for the driver to handle cases like
CPU_BIG_ENDIAN=y on ARM-based SoCs.
This requires for a complete rewrite of the I/O accessors.

PPC-specific accessors - {in,out}_{le,be}XX - are replaced with
generic ones - io{read,write}[be]XX.

Endianness is detected dynamically (at runtime) to allow for
multiplatform kernels, for e.g. running the same kernel image
on LS1043A (BE CAAM) and LS2080A (LE CAAM) armv8-based SoCs.

While here: debugfs entries need to take into consideration the
endianness of the core when displaying data. Add the necessary
glue code so the entries remain the same, but they are properly
read, regardless of the core and/or SEC endianness.

Note: pdb.h fixes only what is currently being used (IPsec).

Reviewed-by: Tudor Ambarus 
Signed-off-by: Horia Geantă 
Signed-off-by: Alex Porosanu 
Signed-off-by: Herbert Xu

crypto: caam - fix offset field in hw sg entries

2016-05-31T08:41:53+00:00

The offset field is 13 bits wide; make sure we don't overwrite more than
that in the caam hardware scatter gather structure.

Signed-off-by: Cristian Stoica 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu

remove lots of IS_ERR_VALUE abuses

2016-05-27T22:26:11+00:00

Most users of IS_ERR_VALUE() in the kernel are wrong, as they
pass an 'int' into a function that takes an 'unsigned long'
argument. This happens to work because the type is sign-extended
on 64-bit architectures before it gets converted into an
unsigned type.

However, anything that passes an 'unsigned short' or 'unsigned int'
argument into IS_ERR_VALUE() is guaranteed to be broken, as are
8-bit integers and types that are wider than 'unsigned long'.

Andrzej Hajda has already fixed a lot of the worst abusers that
were causing actual bugs, but it would be nice to prevent any
users that are not passing 'unsigned long' arguments.

This patch changes all users of IS_ERR_VALUE() that I could find
on 32-bit ARM randconfig builds and x86 allmodconfig. For the
moment, this doesn't change the definition of IS_ERR_VALUE()
because there are probably still architecture specific users
elsewhere.

Almost all the warnings I got are for files that are better off
using 'if (err)' or 'if (err < 0)'.
The only legitimate user I could find that we get a warning for
is the (32-bit only) freescale fman driver, so I did not remove
the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
For 9pfs, I just worked around one user whose calling conventions
are so obscure that I did not dare change the behavior.

I was using this definition for testing:

 #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
       unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))

which ends up making all 16-bit or wider types work correctly with
the most plausible interpretation of what IS_ERR_VALUE() was supposed
to return according to its users, but also causes a compile-time
warning for any users that do not pass an 'unsigned long' argument.

I suggested this approach earlier this year, but back then we ended
up deciding to just fix the users that are obviously broken. After
the initial warning that caused me to get involved in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.

[ Updated the 9p parts as per Al Viro  - Linus ]

Signed-off-by: Arnd Bergmann 
Cc: Andrzej Hajda 
Cc: Andrew Morton 
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
Acked-by: Srinivas Kandagatla  # For nvmem part
Signed-off-by: Linus Torvalds

crypto: caam - fix caam_jr_alloc() ret code

2016-05-10T09:49:21+00:00

caam_jr_alloc() used to return NULL if a JR device could not be
allocated for a session. In turn, every user of this function used
IS_ERR() function to verify if anything went wrong, which does NOT look
for NULL values. This made the kernel crash if the sanity check failed,
because the driver continued to think it had allocated a valid JR dev
instance to the session and at some point it tries to do a caam_jr_free()
on a NULL JR dev pointer.
This patch is a fix for this issue.

Cc: 
Signed-off-by: Catalin Vasile 
Signed-off-by: Herbert Xu

crypto: caam - Staticize caam_jr_shutdown()

2016-02-16T20:07:52+00:00

caam_jr_shutdown() is only used in this file, so it can be
made static.

This avoids the following sparse warning:

drivers/crypto/caam/jr.c:68:5: warning: symbol 'caam_jr_shutdown' was not declared. Should it be static?

Signed-off-by: Fabio Estevam 
Signed-off-by: Herbert Xu

crypto: caam - enable LARGE_BURST for enhancing DMA transactions size

2016-01-25T14:39:03+00:00

Increasing CAAM DMA engine transaction size either
-reduces the number of required transactions or
-adds the ability to transfer more data with same transaction count

Signed-off-by: Horia Geant? 
Signed-off-by: Herbert Xu