Cleanup the list of headers we include here. For the tools build we only
need to exclude <cyclic.h> as that's used by the target build for the
prototype for schedule(), and we don't need to get that via
<watchdog.h>. We can also make use of our <string.h> intentionally
existing as a redirection to <linux/string.h> to reduce ifdef'd lines.
Reviewed-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Globally replace all occurances of WATCHDOG_RESET() with schedule(),
which handles the HW_WATCHDOG functionality and the cyclic
infrastructure.
Signed-off-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Tom Rini <trini@konsulko.com> [am335x_evm, mx6cuboxi, rpi_3,dra7xx_evm, pine64_plus, am65x_evm, j721e_evm]
SHA512_ALGO was used as a "either SHA512 or SHA384", although the
implementations of these two algorithms share a majority of code.
From a Kconfig interface perspective, it makes sense to present two
distinct options. This requires #ifdefing out the SHA512
implementation from sha512.c. The latter doesn't make any sense.
It's reasonable to say in Kconfig that SHA384 depends on SHA512, and
seems to be the more polite way to handle the selection.
Thus, automatically select SHA512 when SHA384 is enabled.
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Include "compiler.h" in sha512.c. This is needed by 'cpu_to_be64' macro
that used in 'sha512_base_do_finalize' function.
Signed-off-by: Siew Chin Lim <elly.siew.chin.lim@intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
The current recommendation for best security practice from the US government
is to use SHA384 for TOP SECRET [1].
This patch adds support for SHA384 and SHA512 in the hash command, and also
allows FIT images to be hashed with these algorithms, and signed with
sha384,rsaXXXX and sha512,rsaXXXX
The SHA implementation is adapted from the linux kernel implementation.
[1] Commercial National Security Algorithm Suite
http://www.iad.gov/iad/programs/iad-initiatives/cnsa-suite.cfm
Signed-off-by: Reuben Dowle <reuben.dowle@4rf.com>
