Precalculated hash for empty message are now present in hash headers.
This patch just use them.
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Crypto driver support:
     ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
You can alloc tags above in your case.

And other algorithms and platforms will be added later on.
Signed-off-by: NZain Wang <zain.wang@rock-chips.com>
Tested-by: NHeiko Stuebner <heiko@sntech.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The Atmel at91 crypto driver unconditionally selects AT_HDMAC,
which results in a Kconfig warning if that driver is not enabled:

warning: (CRYPTO_DEV_ATMEL_AES) selects AT_HDMAC which has unmet direct dependencies (DMADEVICES && ARCH_AT91)

The crypto driver itself does not actually have a dependency
on a particular dma engine, other than this being the one that
is used in at91.

Removing the 'select' gets rid of the warning, but can cause
the driver to be unusable if the HDMAC is not enabled at the
same time. To work around that, this patch clarifies the runtime
dependency to be 'AT_HDMAC || AT_XDMAC', but adds an alternative
for COMPILE_TEST, which lets the driver get build on all systems.

The ARCH_AT91 dependency is implied by AT_XDMAC || AT_HDMAC now
and no longer needs to be listed separately.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The mxs-dcp driver relies on the stmp_reset_block() helper function, which
is provided by CONFIG_STMP_DEVICE. This symbol is always set on MXS,
but the driver can now also be built for MXC (i.MX6), which results
in a built error if no other driver selects STMP_DEVICE:

drivers/built-in.o: In function `mxs_dcp_probe':
vf610-ocotp.c:(.text+0x3df302): undefined reference to `stmp_reset_block'

This adds the 'select', like all other stmp drivers have it.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: a2712e6c ("crypto: mxs-dcp - Allow MXS_DCP to be used on MX6SL")
Acked-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The CCP is meant to be more of an offload engine than an accelerator
engine. To avoid any confusion, change references to accelerator to
offload.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

MX6SL has the same DCP crypto block as in MX23/MX28, so allow it to be
built for ARCH_MXC.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This code uses FP (floating point), Altivec and VSX (Vector-Scalar
Extension). It can just depend on CONFIG_VSX though, because that
already depends on FP and Altivec.

Otherwise we get lots of link errors such as:

  drivers/built-in.o: In function `.p8_aes_setkey':
  aes.c:(.text+0x2d325c): undefined reference to `.enable_kernel_altivec'
  aes.c:(.text+0x2d326c): undefined reference to `.enable_kernel_vsx'
Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for the Security System included in Allwinner SoC A20.
The Security System is a hardware cryptographic accelerator that support:
- MD5 and SHA1 hash algorithms
- AES block cipher in CBC/ECB mode with 128/196/256bits keys.
- DES and 3DES block cipher in CBC/ECB mode
Signed-off-by: NLABBE Corentin <clabbe.montjoie@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The CESA driver calls phys_to_virt() which is not available on all
architectures.
Remove the depency on COMPILE_TEST to prevent building this driver on
non ARM architectures.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Reported-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Suggested-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The CESA IP supports CPU offload through a dedicated DMA engine (TDMA)
which can control the crypto block.
When you use this mode, all the required data (operation metadata and
payload data) are transferred using DMA, and the results are retrieved
through DMA when possible (hash results are not retrieved through DMA yet),
thus reducing the involvement of the CPU and providing better performances
in most cases (for small requests, the cost of DMA preparation might
exceed the performance gain).

Note that some CESA IPs do not embed this dedicated DMA, hence the
activation of this feature on a per platform basis.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The existing mv_cesa driver supports some features of the CESA IP but is
quite limited, and reworking it to support new features (like involving the
TDMA engine to offload the CPU) is almost impossible.
This driver has been rewritten from scratch to take those new features into
account.

This commit introduce the base infrastructure allowing us to add support
for DMA optimization.
It also includes support for one hash (SHA1) and one cipher (AES)
algorithm, and enable those features on the Armada 370 SoC.

Other algorithms and platforms will be added later on.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NArnaud Ebalard <arno@natisbad.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The mv_cesa driver currently expects the SRAM memory region to be passed
as a platform device resource.

This approach implies two drawbacks:
- the DT representation is wrong
- the only one that can access the SRAM is the crypto engine

The last point is particularly annoying in some cases: for example on
armada 370, a small region of the crypto SRAM is used to implement the
cpuidle, which means you would not be able to enable both cpuidle and the
CESA driver.

To address that problem, we explicitly define the SRAM device in the DT
and then reference the sram node from the crypto engine node.

Also note that the old way of retrieving the SRAM memory region is still
supported, or in other words, backward compatibility is preserved.
Signed-off-by: NBoris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch fixes a number of problems in crypto driver Kconfig
entries:

1. Select BLKCIPHER instead of BLKCIPHER2.  The latter is internal
and should not be used outside of the crypto API itself.
2. Do not select ALGAPI unless you use a legacy type like
CRYPTO_ALG_TYPE_CIPHER.
3. Select the algorithm type that you are implementing, e.g., AEAD.
4. Do not select generic C code such as CBC/ECB unless you use them
as a fallback.
5. Remove default n since that is the default default.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The top-level CRYPTO_DEV_VMX option already depends on PPC64 so
there is no need to depend on it again at CRYPTO_DEV_VMX_ENCRYPT.

This patch also removes a redundant "default n".
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add NX-842 frontend that allows using either the pSeries platform or
PowerNV platform driver (to be added by later patch) for the NX-842
hardware.  Update the MAINTAINERS file to include the new filenames.
Update Kconfig files to clarify titles and descriptions, and correct
dependencies.
Signed-off-by: NDan Streetman <ddstreet@ieee.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

If NO_DMA=y:

    drivers/built-in.o: In function `img_hash_write_via_dma_stop':
    img-hash.c:(.text+0xa2b822): undefined reference to `dma_unmap_sg'
    drivers/built-in.o: In function `img_hash_xmit_dma':
    img-hash.c:(.text+0xa2b8d8): undefined reference to `dma_map_sg'
    img-hash.c:(.text+0xa2b948): undefined reference to `dma_unmap_sg'

Also move the "depends" section below the "tristate" line while we're at
it.
Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch adds a CONFIG option to select SEC1, SEC2+ or both.
Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The Kconfig entry for CRYPTO_DEV_IMGTEC_HASH incorrectly selects
CRYPTO_SHA224, which does not exist (and is covered by CRYPTO_SHA256
which covers both 224 and 256). Remove it.

Also correct typo CRYPTO_ALG_API to be CRYPTO_ALGPI.
Reported-by: NValentin Rothberg <valentinrothberg@gmail.com>
Signed-off-by: NJames Hartley <james.hartley@imgtec.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This adds support for the Imagination Technologies hash accelerator which
provides hardware acceleration for SHA1 SHA224 SHA256 and MD5 hashes.
Signed-off-by: NJames Hartley <james.hartley@imgtec.com>
Reviewed-by: NAndrew Bresticker <abrestic@chromium.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch enables VMX module in PPC64.
Signed-off-by: NLeonidas S. Barbosa <leosilva@linux.vnet.ibm.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for ACPI to the CCP platform driver.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add HAS_IOMEM as a Kconfig dependency. Always include ccp-platform.c
in the CCP build and conditionally include ccp-pci.c.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

'DEV_QCE' needs both HAS_DMA and HAS_IOMEM, so let it depend on them.

The related error (with allmodconfig under score):

    MODPOST 1365 modules
  ERROR: "devm_ioremap_resource" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_map_sg" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_set_mask" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_supported" [drivers/crypto/qce/qcrypto.ko] undefined!
  ERROR: "dma_unmap_sg" [drivers/crypto/qce/qcrypto.ko] undefined!
Signed-off-by: NChen Gang <gang.chen.5i5j@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Make qce crypto driver depend on ARCH_QCOM and make
possible to test driver compilation.
Signed-off-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Modify crypto Kconfig and Makefile in order to build the qce
driver and adds qce Makefile as well.
Signed-off-by: NStanimir Varbanov <svarbanov@mm-sol.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Update to makefiles etc.
Don't update the firmware/Makefile yet since there is no FW binary in
the crypto repo yet. This will be added later.

v3 - removed change to ./firmware/Makefile
Reviewed-by: NBruce W. Allan <bruce.w.allan@intel.com>
Signed-off-by: NTadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for the CCP on arm64 as a platform device.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The NX driver has endian issues so disable it for now.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

This patch modifies Kconfig such that ARCH_EXYNOS SoCs
which includes (Exynos4210, Exynos5250 and Exynos5420)
can also select Samsung SSS(Security SubSystem) driver.
Signed-off-by: NNaveen Krishna Chatradhi <ch.naveen@samsung.com>
Reviewed-by: NTomasz Figa <t.figa@samsung.com>
CC: David S. Miller <davem@davemloft.net>
CC: <linux-samsung-soc@vger.kernel.org>
Acked-by: NVladimir Zapolskiy <vz@mleia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This driver has never been hooked up in any board file, and cannot be
instantiated via device tree. I've been told that, at least on Tegra20,
the HW is slower at crypto than the main CPU. I have no test-case for
it. Hence, remove it.

Cc: Varun Wadekar <vwadekar@nvidia.com>
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add config and build options for the omap-des driver.
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Add support for the MXS DCP block. The driver currently supports
SHA-1/SHA-256 hashing and AES-128 CBC/ECB modes. The non-standard
CRC32 is not yet supported.
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Remove the old DCP driver as it had multiple severe issues. The driver
will be replaced by a more robust implementation. Here is a short list
of problems with this driver:

1) It only supports AES_CBC
2) The driver was apparently never ran behind anyone working with MXS. ie.:
   -> Restarting the DCP block is not done via mxs_reset_block()
   -> The DT name is not "fsl,dcp" or "fsl,mxs-dcp" as other MXS drivers
3) Introduces new ad-hoc IOCTLs
4) The IRQ handler can't use usual completion() in the driver because that'd
   trigger "scheduling while atomic" oops, yes?
Signed-off-by: NMarek Vasut <marex@denx.de>
Cc: David S. Miller <davem@davemloft.net>
Cc: Fabio Estevam <fabio.estevam@freescale.com>
Cc: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Update the Kconfig to include PCI on the 'depends on'
and add 'select HW_RANDOM' to insure the necessary PCI
and HW_RANDOM functions are available/included in the
build.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

These files provide the ability to configure and build the
AMD CCP device driver and crypto API support.
Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

For AM437x SoC, ARCH_OMAP2 and ARCH_OMAP3 is not enabled in the defconfig. We
follow same thing as SHA driver, and add depends on ARCH_OMAP2PLUS so that the
config is selectable for AES driver on AM437x SoC builds.
Signed-off-by: NJoel Fernandes <joelf@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

Adding support for SHA348 and SHA512 in addition to MD5, SHA1, SHA224
SHA256 that the omap sha module supports.

In order to add the support
- Removed hard coded register offsets and passing offsets from pdata
- Updating Flag offsets so that they can be used for SHA256 and SHA512
- Adding the algo info.
Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

This patch enables the DCP crypto functionality on imx28.
Currently, only aes-128-cbc is supported.
Moreover, the dcpboot misc-device, which is used by Freescale's
SDK tools and uses a non-software-readable OTP-key, is added.

Changes of v2:
- ring buffer for hardware-descriptors
- use of ablkcipher walk
- OTP key encryption/decryption via misc-device
  (compatible to Freescale-SDK)
- overall cleanup

The DCP is also capable of sha1/sha256 but I won't be able to add
that anytime soon.
Tested with built-in runtime-self-test, tcrypt and openssl via
cryptodev 1.6 on imx28-evk and a custom built imx28-board.
Signed-off-by: NTobias Rauter <tobias.rauter@gmail.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

The Kconfig symbol EXPERIMENTAL was removed in v3.9. So this dependency
makes it impossible to set CRYPTO_DEV_SAHARA. It's unlikely that this is
what is intended, so let's remove this dependency.
Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>

SAHARA2 HW module is included in the i.MX27 SoC from
Freescale. It is capable of performing cipher algorithms
such as AES, 3DES..., hashing and RNG too.

This driver provides support for AES-CBC and AES-ECB
by now.
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NJavier Martin <javier.martin@vista-silicon.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>