summaryrefslogtreecommitdiff
path: root/drivers/crypto/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2018-03-23crypto: bfin_crc - remove blackfin CRC driverArnd Bergmann1-1/+0
The blackfin architecture is getting removed, so this driver won't be used any more. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-02-15crypto: ccree - introduce CryptoCell driverGilad Ben-Yossef1-0/+1
Introduce basic low level Arm TrustZone CryptoCell HW support. This first patch doesn't actually register any Crypto API transformations, these will follow up in the next patch. This first revision supports the CC 712 REE component. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-11-14Merge branch 'linus' of ↵Linus Torvalds1-1/+0
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto updates from Herbert Xu: "Here is the crypto update for 4.15: API: - Disambiguate EBUSY when queueing crypto request by adding ENOSPC. This change touches code outside the crypto API. - Reset settings when empty string is written to rng_current. Algorithms: - Add OSCCA SM3 secure hash. Drivers: - Remove old mv_cesa driver (replaced by marvell/cesa). - Enable rfc3686/ecb/cfb/ofb AES in crypto4xx. - Add ccm/gcm AES in crypto4xx. - Add support for BCM7278 in iproc-rng200. - Add hash support on Exynos in s5p-sss. - Fix fallback-induced error in vmx. - Fix output IV in atmel-aes. - Fix empty GCM hash in mediatek. Others: - Fix DoS potential in lib/mpi. - Fix potential out-of-order issues with padata" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (162 commits) lib/mpi: call cond_resched() from mpi_powm() loop crypto: stm32/hash - Fix return issue on update crypto: dh - Remove pointless checks for NULL 'p' and 'g' crypto: qat - Clean up error handling in qat_dh_set_secret() crypto: dh - Don't permit 'key' or 'g' size longer than 'p' crypto: dh - Don't permit 'p' to be 0 crypto: dh - Fix double free of ctx->p hwrng: iproc-rng200 - Add support for BCM7278 dt-bindings: rng: Document BCM7278 RNG200 compatible crypto: chcr - Replace _manual_ swap with swap macro crypto: marvell - Add a NULL entry at the end of mv_cesa_plat_id_table[] hwrng: virtio - Virtio RNG devices need to be re-registered after suspend/resume crypto: atmel - remove empty functions crypto: ecdh - remove empty exit() MAINTAINERS: update maintainer for qat crypto: caam - remove unused param of ctx_map_to_sec4_sg() crypto: caam - remove unneeded edesc zeroization crypto: atmel-aes - Reset the controller before each use crypto: atmel-aes - properly set IV after {en,de}crypt hwrng: core - Reset user selected rng by writing "" to rng_current ...
2017-11-03crypto: marvell - Remove the old mv_cesa driverBoris BREZILLON1-1/+0
All defconfigs selecting the old driver have been patched to select the new one instead. We can now remove the old driver along with the allhwsupports module parameter in the new driver that was used to check whether the new driver was allowed to take control of the CESA engine or not. Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-11-02License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseGreg Kroah-Hartman1-0/+1
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-08-22crypto: axis - add ARTPEC-6/7 crypto accelerator driverLars Persson1-0/+1
This is an asynchronous crypto API driver for the accelerator present in the ARTPEC-6 and -7 SoCs from Axis Communications AB. The driver supports AES in ECB/CTR/CBC/XTS/GCM modes and SHA1/2 hash standards. Signed-off-by: Lars Persson <larper@axis.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-28crypto: stm32 - Rename module to use generic cryptolionel.debieve@st.com1-1/+1
The complete stm32 module is rename as crypto in order to use generic naming Signed-off-by: Lionel Debieve <lionel.debieve@st.com> Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-07-18crypto: atmel-ecc - introduce Microchip / Atmel ECC driverTudor-Dan Ambarus1-0/+1
Add ECDH support for ATECC508A (I2C) device. The device features hardware acceleration for the NIST standard P256 prime curve and supports the complete key life cycle from private key generation to ECDH key agreement. Random private key generation is supported internally within the device to ensure that the private key can never be known outside of the device. If the user wants to use its own private keys, the driver will fallback to the ecdh software implementation. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-06-10crypto: cavium - Add support for CNN55XX adapters.Srikanth Jampala1-0/+1
Add Physical Function driver support for CNN55XX crypto adapters. CNN55XX adapters belongs to Cavium NITROX family series, which accelerate both Symmetric and Asymmetric crypto workloads. These adapters have crypto engines that need firmware to become operational. Signed-off-by: Srikanth Jampala <Jampala.Srikanth@cavium.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-06-10crypto: inside-secure - add SafeXcel EIP197 crypto engine driverAntoine Ténart1-0/+1
Add support for Inside Secure SafeXcel EIP197 cryptographic engine, which can be found on Marvell Armada 7k and 8k boards. This driver currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and hmac(sah1) algorithms. Two firmwares are needed for this engine to work. Their are mostly used for more advanced operations than the ones supported (as of now), but we still need them to pass the data to the internal cryptographic engine. Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-06-10crypto: omap-aes - Add support for GCM modeTero Kristo1-1/+2
OMAP AES hw supports AES-GCM mode. This patch adds support for GCM and RFC4106 GCM mode in omap-aes driver. The GCM implementation is mostly written into its own source file, which gets built into the same driver binary as the existing AES support. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> [t-kristo@ti.com: forward port to latest upstream kernel, conversion to use omap-crypto lib and some additional fixes] Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-06-10crypto: omap - add base support library for common routinesTero Kristo1-0/+1
This contains the generic APIs for aligning SG buffers. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-04-21crypto: exynos - Add new Exynos RNG driverKrzysztof Kozlowski1-0/+1
Replace existing hw_ranndom/exynos-rng driver with a new, reworked one. This is a driver for pseudo random number generator block which on Exynos4 chipsets must be seeded with some value. On newer Exynos5420 chipsets it might seed itself from true random number generator block but this is not implemented yet. New driver is a complete rework to use the crypto ALGAPI instead of hw_random API. Rationale for the change: 1. hw_random interface is for true RNG devices. 2. The old driver was seeding itself with jiffies which is not a reliable source for randomness. 3. Device generates five random 32-bit numbers in each pass but old driver was returning only one 32-bit number thus its performance was reduced. Compatibility with DeviceTree bindings is preserved. New driver does not use runtime power management but manually enables and disables the clock when needed. This is preferred approach because using runtime PM just to toggle clock is huge overhead. Another difference is reseeding itself with generated random data periodically and during resuming from system suspend (previously driver was re-seeding itself again with jiffies). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Stephan Müller <smueller@chronox.de> Reviewed-by: PrasannaKumar Muralidharan <prasannatsmkumar@gmail.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-04-05crypto: stm32 - Support for STM32 CRC32 crypto moduleFabien DESSENNE1-0/+1
This module registers a CRC32 ("Ethernet") and a CRC32C (Castagnoli) algorithm that make use of the STMicroelectronics STM32 crypto hardware. Theses algorithms are compatible with the little-endian generic ones. Both algorithms use ~0 as default seed (key). With CRC32C the output is xored with ~0. Using TCRYPT CRC32C speed test, this shows up to 900% speedup compared to the crc32c-generic algorithm. Signed-off-by: Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-03-09crypto: zip - Add ThunderX ZIP driver coreMahipal Challa1-0/+1
Add a driver for the ZIP engine found on Cavium ThunderX SOCs. The ZIP engine supports hardware accelerated compression and decompression. It includes 2 independent ZIP cores and supports: - DEFLATE compression and decompression (RFC 1951) - LZS compression and decompression (RFC 2395 and ANSI X3.241-1994) - ADLER32 and CRC32 checksums for ZLIB (RFC 1950) and GZIP (RFC 1952) The ZIP engine is presented as a PCI device. It supports DMA and scatter-gather. Signed-off-by: Mahipal Challa <Mahipal.Challa@cavium.com> Signed-off-by: Jan Glauber <jglauber@cavium.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-11crypto: brcm - Add Broadcom SPU driverRob Rice1-0/+1
Add Broadcom Secure Processing Unit (SPU) crypto driver for SPU hardware crypto offload. The driver supports ablkcipher, ahash, and aead symmetric crypto operations. Signed-off-by: Steve Lin <steven.lin1@broadcom.com> Signed-off-by: Rob Rice <rob.rice@broadcom.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2017-02-11crypto: cavium - Enable CPT options crypto for buildGeorge Cherian1-0/+1
Add the CPT options in crypto Kconfig and update the crypto Makefile Update the MAINTAINERS file too. Signed-off-by: George Cherian <george.cherian@cavium.com> Reviewed-by: David Daney <david.daney@cavium.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-27crypto: mediatek - Add crypto driver support for some MediaTek chipsRyder Lee1-0/+1
This adds support for the MediaTek hardware accelerator on mt7623/mt2701/mt8521p SoC. This driver currently implement: - SHA1 and SHA2 family(HMAC) hash algorithms. - AES block cipher in CBC/ECB mode with 128/196/256 bits keys. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-27crypto: drivers - bring back alphabetical order of MakefileCorentin LABBE1-7/+7
THe major content of drivers/crypto/Makefile is sorted, only recent addition break this sort. This patch bring back this alphabetical sorting. Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2016-12-16crypto: add virtio-crypto driverGonglei1-0/+1
This patch introduces virtio-crypto driver for Linux Kernel. The virtio crypto device is a virtual cryptography device as well as a kind of virtual hardware accelerator for virtual machines. The encryption anddecryption requests are placed in the data queue and are ultimately handled by thebackend crypto accelerators. The second queue is the control queue used to create or destroy sessions for symmetric algorithms and will control some advanced features in the future. The virtio crypto device provides the following cryptoservices: CIPHER, MAC, HASH, and AEAD. For more information about virtio-crypto device, please see: http://qemu-project.org/Features/VirtioCrypto CC: Michael S. Tsirkin <mst@redhat.com> CC: Cornelia Huck <cornelia.huck@de.ibm.com> CC: Stefan Hajnoczi <stefanha@redhat.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: Halil Pasic <pasic@linux.vnet.ibm.com> CC: David S. Miller <davem@davemloft.net> CC: Zeng Xin <xin.zeng@intel.com> Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2016-08-19crypto: Added Chelsio Menu to the Kconfig fileHariprasad Shenai1-0/+1
Adds the config entry for the Chelsio Crypto Driver, Makefile changes for the same. Signed-off-by: Atul Gupta <atul.gupta@chelsio.com> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2016-04-15crypto: mxc-scc - add basic driver for the MXC SCCSteffen Trumtrar1-0/+1
According to the Freescale GPL driver code, there are two different Security Controller (SCC) versions: SCC and SCC2. The SCC is found on older i.MX SoCs, e.g. the i.MX25. This is the version implemented and tested here. As there is no publicly available documentation for this IP core, all information about this unit is gathered from the GPL'ed driver from Freescale. Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-11-27crypto: rockchip - add crypto driver for rk3288Zain Wang1-0/+1
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: Zain Wang <zain.wang@rock-chips.com> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-07-20crypto: sunxi-ss - Add Allwinner Security System crypto acceleratorLABBE Corentin1-0/+1
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: LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-06-19crypto: marvell/cesa - add a new driver for Marvell's CESABoris BREZILLON1-0/+1
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: Boris Brezillon <boris.brezillon@free-electrons.com> Signed-off-by: Arnaud Ebalard <arno@natisbad.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-03-16crypto: img-hash - Add Imagination Technologies hw hash acceleratorJames Hartley1-0/+1
This adds support for the Imagination Technologies hash accelerator which provides hardware acceleration for SHA1 SHA224 SHA256 and MD5 hashes. Signed-off-by: James Hartley <james.hartley@imgtec.com> Reviewed-by: Andrew Bresticker <abrestic@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2015-02-28crypto: vmx - Enabling VMX module for PPC64Leonidas S. Barbosa1-0/+1
This patch enables VMX module in PPC64. Signed-off-by: Leonidas S. Barbosa <leosilva@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-07-03crypto: qce - Build Qualcomm crypto driverStanimir Varbanov1-0/+1
Modify crypto Kconfig and Makefile in order to build the qce driver and adds qce Makefile as well. Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-06-20crypto: qat - Update to makefilesTadeusz Struk1-0/+1
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: Bruce W. Allan <bruce.w.allan@intel.com> Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-02-27crypto: tegra - remove driverStephen Warren1-1/+0
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: Stephen Warren <swarren@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-02-27crypto: omap-des - Add config and build optionsJoel Fernandes1-0/+1
Add config and build options for the omap-des driver. Signed-off-by: Joel Fernandes <joelf@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2014-01-05crypto: drivers - Sort drivers/crypto/MakefileMarek Vasut1-17/+17
The order in the Makefile was a mess, sort it. Signed-off-by: Marek 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: Herbert Xu <herbert@gondor.apana.org.au>
2014-01-05crypto: mxs - Add Freescale MXS DCP driverMarek Vasut1-0/+1
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: Marek 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: Herbert Xu <herbert@gondor.apana.org.au>
2014-01-05crypto: mxs - Remove the old DCP driverMarek Vasut1-1/+0
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: Marek 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: Herbert Xu <herbert@gondor.apana.org.au>
2013-12-05crytpo: ccp - CCP device driver build filesTom Lendacky1-0/+1
These files provide the ability to configure and build the AMD CCP device driver and crypto API support. Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-05-28crypto: dcp - Added support for Freescale's DCP co-processorTobias Rauter1-0/+1
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: Tobias Rauter <tobias.rauter@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2013-03-21crypto: sahara - Add driver for SAHARA2 accelerator.Javier Martin1-0/+1
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: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Javier Martin <javier.martin@vista-silicon.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-11crypto: atmel - add Atmel SHA1/SHA256 driverNicolas Royer1-0/+1
Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-11crypto: atmel - add Atmel DES/TDES driverNicolas Royer1-0/+1
Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-07-11crypto: atmel - add Atmel AES driverNicolas Royer1-0/+1
Signed-off-by: Nicolas Royer <nicolas@eukrea.com> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com> Acked-by: Eric Bénard <eric@eukrea.com> Tested-by: Eric Bénard <eric@eukrea.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-06-27crypto: nx - move nx build to driver/crypto MakefileSeth Jennings1-0/+1
When the nx driver was pulled, the Makefile that actually builds it is arch/powerpc/Makefile. This is unnatural. This patch moves the line that builds the nx driver from arch/powerpc/Makefile to drivers/crypto/Makefile where it belongs. Signed-off-by: Seth Jennings <sjenning@linux.vnet.ibm.com> Acked-by: Kent Yoder <key@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-06-12crypto: bfin_crc - CRC hardware driver for BF60x family processors.Sonic Zhang1-1/+2
The CRC peripheral is a hardware block used to compute the CRC of the block of data. This is based on a CRC32 engine which computes the CRC value of 32b data words presented to it. For data words of < 32b in size, this driver pack 0 automatically into 32b data units. This driver implements the async hash crypto framework API. Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-05-04crypto: ux500 - Add driver for CRYP hardwareAndreas Westin1-0/+1
This adds a driver for the ST-Ericsson ux500 crypto hardware module. It supports AES, DES and 3DES, the driver implements support for AES-ECB,CBC and CTR. Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Andreas Westin <andreas.westin@stericsson.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2012-01-13crypto: driver for Tegra AES hardwareVarun Wadekar1-0/+1
driver supports ecb/cbc/ofb/ansi_x9.31rng modes, 128, 192 and 256-bit key sizes Signed-off-by: Varun Wadekar <vwadekar@nvidia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-04-08crypto: s5p-sss - add S5PV210 advanced crypto engine supportVladimir Zapolskiy1-0/+1
This change adds support for AES encrypting and decrypting using advanced crypto engine found on Samsung S5PV210 and S5PC110 SoCs. Signed-off-by: Vladimir Zapolskiy <vzapolskiy@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-03-27crypto: caam - Add support for the Freescale SEC4/CAAMKim Phillips1-0/+1
The SEC4 supercedes the SEC2.x/3.x as Freescale's Integrated Security Engine. Its programming model is incompatible with all prior versions of the SEC (talitos). The SEC4 is also known as the Cryptographic Accelerator and Assurance Module (CAAM); this driver is named caam. This initial submission does not include support for Data Path mode operation - AEAD descriptors are submitted via the job ring interface, while the Queue Interface (QI) is enabled for use by others. Only AEAD algorithms are implemented at this time, for use with IPsec. Many thanks to the Freescale STC team for their contributions to this driver. Signed-off-by: Steve Cornelius <sec@pobox.com> Signed-off-by: Kim Phillips <kim.phillips@freescale.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2011-02-21crypto: picoxcell - add support for the picoxcell crypto enginesJamie Iles1-1/+1
Picochip picoXcell devices have two crypto engines, one targeted at IPSEC offload and the other at WCDMA layer 2 ciphering. Signed-off-by: Jamie Iles <jamie@jamieiles.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-10-19crypto: Makefile - replace the use of <module>-objs with <module>-yTracey Dent1-1/+1
Changed <module>-objs to <module>-y in Makefile. Signed-off-by: Tracey Dent <tdent48227@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-09-03crypto: omap-aes - OMAP2/3 AES hw accelerator driverDmitry Kasatkin1-0/+1
Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@nokia.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2010-05-19crypto: n2 - Add Niagara2 crypto driverDavid S. Miller1-0/+2
Current deficiencies: 1) No HMAC hash support yet. 2) Although the algs are registered as ASYNC they always run synchronously. Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>