Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Algorithms must never be added to a driver unless there is a generic
implementation.  These truncated versions of sha512 slipped through.
Remove them as they are useless.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Use the new crypto_engine_op interface where the callback is stored
in the algorithm object.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Rather than having the callback in the request, move it into the
crypto_alg object.  This avoids having crypto_engine look into the
request context is private to the driver.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Most drivers should not access the internal details of struct
crypto_engine.  Move it into the internal header file.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Inlucde internal/engine.h because this driver uses directly
accesses attributes inside struct crypto_engine.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Inlucde internal/engine.h because this driver uses directly
accesses attributes inside struct crypto_engine.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Create crypto/internal/engine.h to house details that should not
be used by drivers.  It is empty for the time being.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Include crypto/scatterwalk.h explicitly instead of getting it
through random header files.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The engine file does not need the actual crypto type definitions
so move those header inclusions to where they are actually used.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The header file jh7110-cryp uses ahash_request without including
crypto/hash.h.  Fix that by adding the inclusion.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

The callbacks for prepare and unprepare request in crypto_engine
is superfluous.  They can be done directly from do_one_request.

Move the code into do_one_request and remove the unused callbacks.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Some newer SoCs (like SM8450) do not require a clock vote for the PRNG
to function. Make it entirely optional and rely on the bindings checker
to ensure platforms that need it, consume one.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

SM8450's PRNG does not require a core clock reference. Add a new
compatible with a qcom,prng-ee fallback and handle that.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Some configurations with gcc-12 or gcc-13 produce a warning for the source
and destination of a memcpy() in atmel_sha_hmac_compute_ipad_hash() potentially
overlapping:

In file included from include/linux/string.h:254,
                 from drivers/crypto/atmel-sha.c:15:
drivers/crypto/atmel-sha.c: In function 'atmel_sha_hmac_compute_ipad_hash':
include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing 129 or more bytes at offsets 408 and 280 overlaps 1 or more bytes at offset 408 [-Werror=restrict]
   57 | #define __underlying_memcpy     __builtin_memcpy
      |                                 ^
include/linux/fortify-string.h:648:9: note: in expansion of macro '__underlying_memcpy'
  648 |         __underlying_##op(p, q, __fortify_size);                        \
      |         ^~~~~~~~~~~~~
include/linux/fortify-string.h:693:26: note: in expansion of macro '__fortify_memcpy_chk'
  693 | #define memcpy(p, q, s)  __fortify_memcpy_chk(p, q, s,                  \
      |                          ^~~~~~~~~~~~~~~~~~~~
drivers/crypto/atmel-sha.c:1773:9: note: in expansion of macro 'memcpy'
 1773 |         memcpy(hmac->opad, hmac->ipad, bs);
      |         ^~~~~~

The same thing happens in two more drivers that have the same logic:

drivers/crypto/chelsio/chcr_algo.c: In function 'chcr_ahash_setkey':
include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing 129 or more bytes at offsets 260 and 132 overlaps 1 or more bytes at offset 260 [-Werror=restrict]
drivers/crypto/bcm/cipher.c: In function 'ahash_hmac_setkey':
include/linux/fortify-string.h:57:33: error: '__builtin_memcpy' accessing between 129 and 4294967295 bytes at offsets 840 and 712 overlaps between 1 and 4294967167 bytes at offset 840 [-Werror=restrict]

I don't think it can actually happen because the size is strictly bounded
to the available block sizes, at most 128 bytes, though inlining decisions
could lead gcc to not see that.

Use the unsafe_memcpy() helper instead of memcpy(), with the only difference
being that this skips the hardening checks that produce the warning.
Suggested-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Chips such as BCM7278 support system wide suspend/resume which will
cause the HWRNG block to lose its state and reset to its power on reset
register values. We need to cleanup and re-initialize the HWRNG for it
to be functional coming out of a system suspend cycle.

Fixes: c3577f61 ("hwrng: iproc-rng200 - Add support for BCM7278")
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Remove duplicated include of linux/random.h. Resolves checkincludes
message. And adjust includes in alphabetical order.
Signed-off-by: GUO Zihua <guozihua@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

'type' is an enum, thus cast of pointer on 64-bit compile test with W=1
causes:

  exynos-rng.c:280:14: error: cast to smaller integer type 'enum exynos_prng_type' from 'const void *' [-Werror,-Wvoid-pointer-to-enum-cast]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Commit d8cba25d ("crypto: qat - Intel(R) QAT driver framework")
declared but never implemented these functions.
Signed-off-by: Yue Haibing <yuehaibing@huawei.com>
Acked-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>