This driver allows using Tegra AES engines within BSEV and BSEA blocks to
encrypt and decrypt data using different AES algorithms.

One use case is allowing u-boot to self update by using the already loaded
AES key in the engine's SBK slot by the bootrom.

Particular care must be taken as chainloaded u-boot's may not have the SBK
slot loaded as the vendor bootloader erases it before leaving it.

Signed-off-by: Ion Agorria <ion@agorria.com>

Svyatoslav Ryhel <clamor95@gmail.com> says:

Add uclass for HW AES cryptographic devices found on some devices, like
Tegra20/Tegra30 SoC AES engine.

Link: https://lore.kernel.org/r/20250629105711.24687-1-clamor95@gmail.com

This adds AES crypto engine using the AES Uclass implemented in software,
serves as example implementation and for uclass tests.

Those implementing HW AES crypto engine drivers can use this as basis and
replace software parts with the HW specifics of their device.

Signed-off-by: Ion Agorria <ion@agorria.com>

Create a basic framework for a group of devices that perform AES
cryptographic operations.

Signed-off-by: Ion Agorria <ion@agorria.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>

Some of the aspeed platform drivers cannot build without platform
specific headers being available. Express those requirements in Kconfig as
well.

Signed-off-by: Tom Rini <trini@konsulko.com>

These drivers require various headers which only exist on the ARM /
PowerPC platforms which implement the hardware. Express that requirement
in Kconfig as well.

Reviewed-by: Peng Fan <peng.fan@nxp.com>
Signed-off-by: Tom Rini <trini@konsulko.com>

The nuvoton AES driver cannot build without platform specific headers
being available. Express that requirement in Kconfig as well.

Signed-off-by: Tom Rini <trini@konsulko.com>

This reverts commit 159b6f0e119962ce5da645f548cefe9196c8778e.

Since commit 159b6f0e1199 ("caam: Fix CAAM error on startup") the following
regression was reported by Tim Harvey:

"I've found that this patch causes a regression on an imx8mm board
(imx8mm_venice_defconfig) where the first call to caam_rng_read fails
here in jr_dequeue but if you call it again it works. With some
debugging added:
SEC0:  RNG instantiated
...
Hit any key to stop autoboot:  0
u-boot=> rng list
RNG #0 - caam-rng
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
Error in SEC deq: -1
caam_rng_read_one run_descriptor_jr failed: -1
caam_rng_read caam-rng caam_rng_read_one failed: -5
Reading RNG failed
u-boot=> rng 0 10
caam_rng_read caam-rng len=16
run_descriptor_jr_idx idx=0
00000000: ad 2e ad c0 2a 12 27 c4 65 82 66 19 be ef f6 07  ....*.'.e.f.....

If I revert your patch caam_rng_read works initially and on subsequent
calls."

" I ran into this when I was testing
lwIP HTTPS as it causes anything that uses dm_rng to fail the first
time (such as HTTPS)."

Revert it for now to avoid the regression.

Reported-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Acked-by: Peng Fan <peng.fan@nxp.com>

In rare cases U-Boot returns an error message when intantiating the RNG
of the CAAM device:
“SEC0:  RNG4 SH0 instantiation failed with error 0xffffffff”
This  means, that even when the CAAM device reports a finished
descriptor, none is found in the output ring.
This might be caused by a missing cache invalidation before
reading the memory of the output ring
This patch moves the cache invalidation of the output ring from start of
the job to immediately after the notification from hardware where the
output ring will be read.

Signed-off-by: Olaf Baehring <olaf.baehring@draeger.com>
Signed-off-by: Fabio Estevam <festevam@gmail.com>

Loading a FIT kernel image with hash hardware acceleration enabled
(CONFIG_SHA_HW_ACCEL=y) displays the following CACHE warning:

    [...]
    Trying 'kernel-1' kernel subimage
    [...]
    Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [16000128, 1673fae8]
    [...]
    Trying 'ramdisk-1' ramdisk subimage
    [...]
    Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [1676d6d4, 1737a5d4]
    [...]
    Trying 'fdt-imx6q-xxx.dtb' fdt subimage
    [...]
    Verifying Hash Integrity ... sha256CACHE: Misaligned operation at
range [1673fbdc, 1674b0dc]
    [...]

This patch fixes it.

Tested on:
- i.MX 6 custom board
- LS1021A custom board

Signed-off-by: Benjamin Lemouzy <blemouzy@centralp.fr>
Signed-off-by: Peng Fan <peng.fan@nxp.com>