This contains the generic APIs for aligning SG buffers.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Convert the driver to use autosuspend for runtime_pm. This boosts the
performance, and optimizes the power consumption for the driver. By
default, the timeout value for autosuspend is set to one second.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

OMAP DES crypto accelerator itself is unable to detect weak keys, so
add a specific call to the generic des driver to check the key strength
if requested.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

AES can have multiple HW accelerator cores in the system, in which case
each core has its own crypto engine in use. Currently, the used hardware
device is stored under the omap_aes_ctx struct, which is global for
the algorithm itself, causing conflicts when used with multiple cores.
Fix this by moving the used HW device under reqctx, which is stored
per-request basis.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This is not used for anything, so drop it.
Signed-off-by: NTero Kristo <t-kristo@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This fixes the following warning when building with clang:

crypto/rng.c:35:34: error: unused function '__crypto_rng_cast'
    [-Werror,-Wunused-function]
Signed-off-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When a hw_random device's quality is non-zero, it will automatically be
used to fill the kernel's entropy pool.  Since timeriomem_rng is used by
many different devices, the quality needs to be provided by platform
data or device tree.
Signed-off-by: NRick Altherr <raltherr@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NRick Altherr <raltherr@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make the module autoloadable by tying it to the CPU feature bits that
describe whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: NGary R Hook <gary.hook@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Reviewed-by: NMatthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Acked-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch simply replace all occurrence of HMAC IPAD/OPAD value by their
define.
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Many HMAC users directly use directly 0x36/0x5c values.
It's better with crypto to use a name instead of directly some crypto
constant.

This patch simply add HMAC_IPAD_VALUE/HMAC_OPAD_VALUE defines in a new
include file "crypto/hmac.h" and use them in crypto/hmac.c
Signed-off-by: NCorentin Labbe <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

When using the "aes-asm" implementation of AES (*not* the AES-NI
implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the
following warning was reported, along with a long unwinder dump:

	WARNING: kernel stack regs at ffffc90000643558 in kworker/u4:2:155 has bad 'bp' value 000000000000001c

The problem is that aes_enc_block() and aes_dec_block() use %rbp as a
temporary register, which breaks stack traces if an interrupt occurs.

Fix this by replacing %rbp with %r9, which was being used to hold the
saved value of %rbp.  This required rearranging the AES round macro
slightly since %r9d cannot be used as the target of a move from %ah-%dh.

Performance is essentially unchanged --- actually about 0.2% faster than
before.  Interestingly, I also measured aes-generic as being nearly 7%
faster than aes-asm, so perhaps aes-asm has outlived its usefulness...
Signed-off-by: NEric Biggers <ebiggers@google.com>
Reviewed-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NChristoph Hellwig <hch@lst.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Here, Clock enable can failed. So adding an error check for
clk_prepare_enable.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Here, Clock enable can failed. So adding an error check for
clk_prepare_enable.
Signed-off-by: NArvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Now that the asm side of things can support all the valid lengths of ICV
and all lengths of associated data, provide the glue code to expose a
generic gcm(aes) crypto algorithm.
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This is the first step to make the aesni AES-GCM implementation
generic. The current code was written for rfc4106, so it handles only
some specific sizes of associated data.
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This is the first step to make the aesni AES-GCM implementation
generic. The current code was written for rfc4106, so it handles
only some specific sizes of associated data.
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This is the first step to make the aesni AES-GCM implementation
generic. The current code was written for rfc4106, so it handles only
some specific sizes of associated data.
Signed-off-by: NSabrina Dubroca <sd@queasysnail.net>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Replace the inline asm which exports struct offsets as ELF symbols
with proper const variables exposing the same values. This works
around an issue with Clang which does not interpret the "i" (or "I")
constraints in the same way as GCC.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: NMatthias Kaehlcke <mka@chromium.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

CC: <stable@vger.kernel.org> # 4.9.x+
Signed-off-by: NGary R Hook <gary.hook@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

CAAM RSA private key may have either of three representations.

1. The first representation consists of the pair (n, d), where the
   components have the following meanings:
      n      the RSA modulus
      d      the RSA private exponent

2. The second representation consists of the triplet (p, q, d), where
the
   components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      d      the RSA private exponent

3. The third representation consists of the quintuple (p, q, dP, dQ,
qInv),
   where the components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      dP     the first factors's CRT exponent
      dQ     the second factors's CRT exponent
      qInv   the (first) CRT coefficient

The benefit of using the third or the second key form is lower
computational cost for the decryption and signature operations.

This patch adds support for the third RSA private key
representations and extends caampkc to use the fastest key when all
related components are present in the private key.
Signed-off-by: NTudor Ambarus <tudor-dan.ambarus@nxp.com>
Signed-off-by: NRadu Alexe <radu.alexe@nxp.com>
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

CAAM RSA private key may have either of three representations.

1. The first representation consists of the pair (n, d), where the
   components have the following meanings:
      n      the RSA modulus
      d      the RSA private exponent

2. The second representation consists of the triplet (p, q, d), where
the
   components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      d      the RSA private exponent

3. The third representation consists of the quintuple (p, q, dP, dQ,
qInv),
   where the components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      dP     the first factors's CRT exponent
      dQ     the second factors's CRT exponent
      qInv   the (first) CRT coefficient

The benefit of using the third or the second key form is lower
computational cost for the decryption and signature operations.

This patch adds support for the second RSA private key
representation.
Signed-off-by: NTudor Ambarus <tudor-dan.ambarus@nxp.com>
Signed-off-by: NRadu Alexe <radu.alexe@nxp.com>
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This function will be used into further patches.
Signed-off-by: NRadu Alexe <radu.alexe@nxp.com>
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The function returns NULL if buf is composed only of zeros.
Signed-off-by: NTudor Ambarus <tudor-dan.ambarus@nxp.com>
Signed-off-by: NHoria Geantă <horia.geanta@nxp.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

We recently added some new locking but missed the unlocks on these
error paths in sha512_ctx_mgr_submit().

Fixes: c459bd7b ("crypto: sha512-mb - Protect sha512 mb ctx mgr access")
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Acked-by: NTim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>