Re: [WIP] crypto: add support for Orion5X crypto engine
* Ben Dooks | 2009-05-07 22:39:22 [+0100]:
Sorry for the late reply.
>> diff --git a/drivers/crypto/mv_crypto.c b/drivers/crypto/mv_crypto.c
>> new file mode 100644
>> index 000..40eb083
>> --- /dev/null
>> +++ b/drivers/crypto/mv_crypto.c
>> +struct req_progress {
>> +struct sg_mapping_iter src_sg_it;
>> +struct sg_mapping_iter dst_sg_it;
>> +
>> +/* src mostly */
>> +int this_sg_b_left;
>> +int src_start;
>> +int crypt_len;
>> +/* dst mostly */
>> +int this_dst_sg_b_left;
>> +int dst_start;
>> +int total_req_bytes;
>> +};
>
>kerneldoc style documentation wouldn't go amiss here.
added
>> +
>> +static void reg_write(void __iomem *mem, u32 val)
>> +{
>> +__raw_writel(val, mem);
>> +}
>> +
>> +static u32 reg_read(void __iomem *mem)
>> +{
>> +return __raw_readl(mem);
>> +}
>
>do you really need to wrapper these?
Not really. Initially I planned to pass the device handle instead of the
memory pointer. Also using (addr, val) looks better than the other way
around.
>it is also readl/writel for pointers obtained from ioremap()
correct. So I get rid of my wrapper and switch to readl/writel
>> +
>> +#if 0
>> +static void hex_dump(unsigned char *info, unsigned char *buf, unsigned int
>> len)
>> +{
>> +printk(KERN_ERR "%s\n", info);
>> +print_hex_dump(KERN_ERR, "", DUMP_PREFIX_OFFSET,
>> +16, 1,
>> +buf, len, false);
>> +printk(KERN_CONT "\n");
>> +}
>> +#endif
>
>#if 0 considered bad.
I needed this a few times. Now I don't and its gone.
>> +
>> +static int m_probe(struct platform_device *pdev)
>> +{
>> +struct crypto_priv *cp;
>> +struct resource *res;
>> +int irq;
>> +int ret;
>> +
>> +if (cpg) {
>> +printk(KERN_ERR "Second crypto dev?\n");
>> +return -EBUSY;
>> +}
>> +
>> +res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
>> +if (!res)
>> +return -ENODEV;
>
>Returning -ENODEV is considered harmful, it will not trigger any warning
>from the driver core.
I switched to ENXIO because that fits better (No such device or address)
I thing. However this also doesn't trigger any warning from the core.
What do you suggest?
>
>--
>Ben
Thanks for the review Ben.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP] crypto: add support for Orion5X crypto engine
On Thu, May 07, 2009 at 11:03:21PM +0200, Sebastian Andrzej Siewior wrote:
> update since last post, unfortunately not much:
> - interrupt handler fix
> - s/mav/mv
>
> the dm-crypt still crashes but a few delays seem to help argh
>
> Signed-off-by: Sebastian Andrzej Siewior
> ---
> drivers/crypto/Kconfig |9 +
> drivers/crypto/Makefile |1 +
> drivers/crypto/mv_crypto.c | 725 +++
> 3 files changed, 735 insertions(+), 0 deletions(-)
> create mode 100644 drivers/crypto/mv_crypto.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index e522144..fa564b5 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -157,6 +157,15 @@ config S390_PRNG
> ANSI X9.17 standard. The PRNG is usable via the char device
> /dev/prandom.
>
> +config CRYPTO_DEV_MARVELL_CRYPTO_ENGINE
> + tristate "Marvell's Cryptographic Engine"
> + depends on PLAT_ORION
> + select CRYPTO_ALGAPI
> + select CRYPTO_AES
> + help
> + This driver allows you utilize the cryptographic engine which can be
> + found on certain SoC like QNAP's TS-209.
> +
> config CRYPTO_DEV_HIFN_795X
> tristate "Driver HIFN 795x crypto accelerator chips"
> select CRYPTO_DES
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index 73557b2..6020a58 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -2,5 +2,6 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
> obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
> obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
> obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
> +obj-$(CONFIG_CRYPTO_DEV_MARVELL_CRYPTO_ENGINE) += mv_crypto.o
> obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
> obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
> diff --git a/drivers/crypto/mv_crypto.c b/drivers/crypto/mv_crypto.c
> new file mode 100644
> index 000..40eb083
> --- /dev/null
> +++ b/drivers/crypto/mv_crypto.c
> @@ -0,0 +1,725 @@
> +/*
> + * Support for Marvell's crypto engine which can be found on some Orion5X
> + * boards.
> + *
> + * Author: Sebastian Andrzej Siewior < sebastian at breakpoint dot cc >
> + * License: GPL
> + *
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum engine_status {
> + engine_idle,
> + engine_busy,
> + engine_w_dequeue,
> +};
> +
> +struct req_progress {
> + struct sg_mapping_iter src_sg_it;
> + struct sg_mapping_iter dst_sg_it;
> +
> + /* src mostly */
> + int this_sg_b_left;
> + int src_start;
> + int crypt_len;
> + /* dst mostly */
> + int this_dst_sg_b_left;
> + int dst_start;
> + int total_req_bytes;
> +};
kerneldoc style documentation wouldn't go amiss here.
> +
> +static void reg_write(void __iomem *mem, u32 val)
> +{
> + __raw_writel(val, mem);
> +}
> +
> +static u32 reg_read(void __iomem *mem)
> +{
> + return __raw_readl(mem);
> +}
do you really need to wrapper these?
it is also readl/writel for pointers obtained from ioremap()
> +#define DIGEST_INITIAL_VAL_A 0xdd00
> +#define DES_CMD_REG 0xdd58
> +
> +#define SEC_ACCEL_CMD0xde00
> +#define SEC_CMD_EN_SEC_ACCL0 (1 << 0)
> +#define SEC_CMD_EN_SEC_ACCL1 (1 << 1)
> +#define SEC_CMD_DISABLE_SEC (1 << 2)
> +
> +#define SEC_ACCEL_DESC_P00xde04
> +#define SEC_DESC_P0_PTR(x) (x)
> +
> +#define SEC_ACCEL_DESC_P10xde14
> +#define SEC_DESC_P1_PTR(x) (x)
> +
> +#define SEC_ACCEL_CFG0xde08
> +#define SEC_CFG_STOP_DIG_ERR (1 << 0)
> +#define SEC_CFG_CH0_W_IDMA (1 << 7)
> +#define SEC_CFG_CH1_W_IDMA (1 << 8)
> +#define SEC_CFG_ACT_CH0_IDMA (1 << 9)
> +#define SEC_CFG_ACT_CH1_IDMA (1 << 10)
> +
> +#define SEC_ACCEL_STATUS 0xde0c
> +#define SEC_ST_ACT_0 (1 << 0)
> +#define SEC_ST_ACT_1 (1 << 1)
> +
> +
> +/*
> + * FPGA_INT_STATUS looks like a FPGA leftover and is undocumented. I asumme
> + * that it was part of an IRQ-controller in FPGA and someone forgot to remove
> + * it while switching to the core and moving to SEC_ACCEL_INT_STATUS.
> + */
> +#define FPGA_INT_STATUS 0xdd68
> +#define SEC_ACCEL_INT_STATUS 0xde20
> +#define SEC_INT_AUTH_DONE(1 << 0)
> +#define SEC_INT_DES_E_DONE (1 << 1)
> +#define SEC_INT_AES_E_DONE (1 << 2)
> +#define SEC_INT_AES_D_DONE (1 << 3)
> +#define SEC_INT_ENC_DONE (1 << 4)
> +#define SEC_INT_ACCEL0_DONE (1 << 5)
> +#define SEC_INT_ACCEL1_DONE (1 << 6)
> +#define SEC_INT_ACC0_IDMA_DONE (1 << 7)
> +#define SEC_INT_ACC1_IDMA_DONE (1 << 8)
> +
> +#define SEC_ACCEL_INT_MASK 0xde24
> +
> +#define AES_KEY_LEN (8 * 4)
> +
> +struct sec_accel_config {
> +
> + u32 config;
> +#define CFG_OP_MAC_ONLY 0
> +#define CFG_OP_CRYPT_ONLY1
> +#define CFG_OP_MAC_CRYPT 2
> +#define CFG_OP_CRYPT_MAC 3
> +#define CFG_MACM_MD5 (4 << 4)
>
[WIP] crypto: add support for Orion5X crypto engine
update since last post, unfortunately not much:
- interrupt handler fix
- s/mav/mv
the dm-crypt still crashes but a few delays seem to help argh
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile |1 +
drivers/crypto/mv_crypto.c | 725 +++
3 files changed, 735 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/mv_crypto.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index e522144..fa564b5 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -157,6 +157,15 @@ config S390_PRNG
ANSI X9.17 standard. The PRNG is usable via the char device
/dev/prandom.
+config CRYPTO_DEV_MARVELL_CRYPTO_ENGINE
+ tristate "Marvell's Cryptographic Engine"
+ depends on PLAT_ORION
+ select CRYPTO_ALGAPI
+ select CRYPTO_AES
+ help
+ This driver allows you utilize the cryptographic engine which can be
+ found on certain SoC like QNAP's TS-209.
+
config CRYPTO_DEV_HIFN_795X
tristate "Driver HIFN 795x crypto accelerator chips"
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 73557b2..6020a58 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,5 +2,6 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CRYPTO_ENGINE) += mv_crypto.o
obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
diff --git a/drivers/crypto/mv_crypto.c b/drivers/crypto/mv_crypto.c
new file mode 100644
index 000..40eb083
--- /dev/null
+++ b/drivers/crypto/mv_crypto.c
@@ -0,0 +1,725 @@
+/*
+ * Support for Marvell's crypto engine which can be found on some Orion5X
+ * boards.
+ *
+ * Author: Sebastian Andrzej Siewior < sebastian at breakpoint dot cc >
+ * License: GPL
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+enum engine_status {
+ engine_idle,
+ engine_busy,
+ engine_w_dequeue,
+};
+
+struct req_progress {
+ struct sg_mapping_iter src_sg_it;
+ struct sg_mapping_iter dst_sg_it;
+
+ /* src mostly */
+ int this_sg_b_left;
+ int src_start;
+ int crypt_len;
+ /* dst mostly */
+ int this_dst_sg_b_left;
+ int dst_start;
+ int total_req_bytes;
+};
+
+struct crypto_priv {
+ void __iomem *reg;
+ void __iomem *sram;
+ int irq;
+ struct task_struct *queue_th;
+
+ spinlock_t lock;
+ struct crypto_queue queue;
+ enum engine_status eng_st;
+ struct ablkcipher_request *cur_req;
+ struct req_progress p;
+};
+
+static struct crypto_priv *cpg;
+
+static void reg_write(void __iomem *mem, u32 val)
+{
+ __raw_writel(val, mem);
+}
+
+static u32 reg_read(void __iomem *mem)
+{
+ return __raw_readl(mem);
+}
+
+#define DIGEST_INITIAL_VAL_A 0xdd00
+#define DES_CMD_REG0xdd58
+
+#define SEC_ACCEL_CMD 0xde00
+#define SEC_CMD_EN_SEC_ACCL0 (1 << 0)
+#define SEC_CMD_EN_SEC_ACCL1 (1 << 1)
+#define SEC_CMD_DISABLE_SEC(1 << 2)
+
+#define SEC_ACCEL_DESC_P0 0xde04
+#define SEC_DESC_P0_PTR(x) (x)
+
+#define SEC_ACCEL_DESC_P1 0xde14
+#define SEC_DESC_P1_PTR(x) (x)
+
+#define SEC_ACCEL_CFG 0xde08
+#define SEC_CFG_STOP_DIG_ERR (1 << 0)
+#define SEC_CFG_CH0_W_IDMA (1 << 7)
+#define SEC_CFG_CH1_W_IDMA (1 << 8)
+#define SEC_CFG_ACT_CH0_IDMA (1 << 9)
+#define SEC_CFG_ACT_CH1_IDMA (1 << 10)
+
+#define SEC_ACCEL_STATUS 0xde0c
+#define SEC_ST_ACT_0 (1 << 0)
+#define SEC_ST_ACT_1 (1 << 1)
+
+
+/*
+ * FPGA_INT_STATUS looks like a FPGA leftover and is undocumented. I asumme
+ * that it was part of an IRQ-controller in FPGA and someone forgot to remove
+ * it while switching to the core and moving to SEC_ACCEL_INT_STATUS.
+ */
+#define FPGA_INT_STATUS0xdd68
+#define SEC_ACCEL_INT_STATUS 0xde20
+#define SEC_INT_AUTH_DONE (1 << 0)
+#define SEC_INT_DES_E_DONE (1 << 1)
+#define SEC_INT_AES_E_DONE (1 << 2)
+#define SEC_INT_AES_D_DONE (1 << 3)
+#define SEC_INT_ENC_DONE (1 << 4)
+#define SEC_INT_ACCEL0_DONE(1 << 5)
+#define SEC_INT_ACCEL1_DONE(1 << 6)
+#define SEC_INT_ACC0_IDMA_DONE (1 << 7)
+#define SEC_INT_ACC1_IDMA_DONE (1 << 8)
+
+#define SEC_ACCEL_INT_MASK 0xde24
+
+#define AES_KEY_LEN(8 * 4)
+
+struct sec_accel_config {
+
+ u32 config;
+#define CFG_OP_MAC_ONLY0
+#define CFG_OP_CRYPT_ONLY 1
+#define CFG_OP_MAC_CRYPT 2
+#define CFG_OP_CRYPT_MAC 3
+#define CFG_MACM_MD5 (4 << 4)
+#define CFG_MACM_SHA1 (5 << 4)
+#define CFG_MACM_HMAC_MD5 (6 << 4)
+#define CFG_MA
Re: [WIP] crypto: add support for Orion5X crypto engine
* Ronen Shitrit | 2009-03-04 18:05:12 [+0200]: >However a SW calculation is also possible. >Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes >created by the expansion algorithm. So I picked the key expand routine >from generic aes module and just passed the crypto test for decryption >with a 16 byte long key. The other two key sizes failed. Probably the >the key slots are different. Currently I have no idea what's wrong. > >[Ronen Shitrit] on our driver we also chose the SW calculation WA, I'm not >sure why your code fail, but I can refer you to our driver as a reference, >maybe you can find it as a good reference also for other issues. > >This is an old LSP for the 5182, but the crypto driver supposed to work on the >5182 just fine: >http://downloads.buffalo.nas-central.org/KBPro_ARM9/GPL/source/linux-2.6.12_lsp.1.10.3.src.tar.gz > >Look for aesMakeKey API under arch/arm/mach-mv88fxx81/Soc/cesa/ Oh thanks a lot. I take a look on this. >I also wanted to point that the crypto engine on the 5182 passed 2 more >evolutions after the 5182, which included: >- Add a dedicated DMA to the crypto unit. Does this mean that the crypto unit itself is now able to copy data and I don't have to use the idma for that? That sounds great. >- Support only one channel. >- Fix main erratas. >- Decrease SRAM size to 2K. >- Add support for chain mode. I can understand that, since SRAM is not that cheap and with chaining support it should not matter. >Maybe you should take those into account in your design to allow support for >other crypto versions in the future. >If you need more details pls check the security chapter on: >http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf I take a look on this as well. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [WIP] crypto: add support for Orion5X crypto engine
The only functional part is ecb-aes in encryption mode. The decryption seems to work in 16 byte key mode. According to the spec [1] the decryption key is different and has to be computed by the HW. Chapter 11.1.4 says, that the decryption key is computed by performing a dummy encrypt operation. This does not alter my key at all. Point 1 on the next side is referring to the AesKeyRdMode bit which must be set prior reading the key. I can't find a definition of this bit so I guess the spec is out of date here. [Ronen Shitrit] you are right, this should be fix accordingly: " To decrypt a data block with a given key, the host must first load this key into the decryption engine, then start the key generation process setting field in the AES Decryption Command Register bit to 1. At the end of the key generation process, the host reads the key registers from the Encryption engine. This decryption key is loaded by the host into the decryption key registers, to start the required description process. To read the decryption key from the encryption engine, the host must set the field in the AES Decryption Command Register to 1 prior to the reading of the AES encryption key registers. Setting this bit enables reading of the internal key in the AES Encryption engine, which at the end of an encryption process, is the key for the decryption start point." However a SW calculation is also possible. Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes created by the expansion algorithm. So I picked the key expand routine from generic aes module and just passed the crypto test for decryption with a 16 byte long key. The other two key sizes failed. Probably the the key slots are different. Currently I have no idea what's wrong. [Ronen Shitrit] on our driver we also chose the SW calculation WA, I'm not sure why your code fail, but I can refer you to our driver as a reference, maybe you can find it as a good reference also for other issues. This is an old LSP for the 5182, but the crypto driver supposed to work on the 5182 just fine: http://downloads.buffalo.nas-central.org/KBPro_ARM9/GPL/source/linux-2.6.12_lsp.1.10.3.src.tar.gz Look for aesMakeKey API under arch/arm/mach-mv88fxx81/Soc/cesa/ I also wanted to point that the crypto engine on the 5182 passed 2 more evolutions after the 5182, which included: - Add a dedicated DMA to the crypto unit. - Support only one channel. - Fix main erratas. - Decrease SRAM size to 2K. - Add support for chain mode. Maybe you should take those into account in your design to allow support for other crypto versions in the future. If you need more details pls check the security chapter on: http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP] crypto: add support for Orion5X crypto engine
* Jason | 2009-03-03 12:49:37 [-0500]: > I found the nuts and bolts starting at page 174 of [3], with registers > listed starting on page 634. they look the same to me. The registers seem to be on the same spot, the description is the same from what I recall. > thx, > > Jason. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [WIP] crypto: add support for Orion5X crypto engine
Sebastian Andrzej Siewior wrote: From: Sebastian Andrzej Siewior This is my current status of an async crypto driver for the Orion5X crypto unit. The driver uses the crypto accelerator. Is this the same security engine found in the new SheevaPlug Devkit [1]? It's has the Marvell 88F6281 (Kirkwood) processor in it. This diagram [2] shows a "Security Engine", but doesn't give any detail... I found the nuts and bolts starting at page 174 of [3], with registers listed starting on page 634. thx, Jason. [1] - http://www.marvell.com/products/embedded_processors/developer/kirkwood/sheevaplug.jsp [2] - http://www.marvell.com/products/embedded_processors/kirkwood/index.jsp [3] - http://www.marvell.com/files/products/embedded_processors/kirkwood/FS_88F6180_9x_6281_OpenSource.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[WIP] crypto: add support for Orion5X crypto engine
From: Sebastian Andrzej Siewior
This is my current status of an async crypto driver for the Orion5X crypto
unit. The driver uses the crypto accelerator. The data is copied via
memcpy() and will be replaced with idma once the infrastructure around
it is working. This patch depends on "arm/orion5x: add sram support for
crypto" posted earler to the arm ml [0].
The only functional part is ecb-aes in encryption mode. The decryption
seems to work in 16 byte key mode. According to the spec [1] the
decryption key is different and has to be computed by the HW.
Chapter 11.1.4 says, that the decryption key is computed by performing a
dummy encrypt operation. This does not alter my key at all. Point 1 on
the next side is referring to the AesKeyRdMode bit which must be set
prior reading the key. I can't find a definition of this bit so I guess
the spec is out of date here.
The register definition of the decryption unit has a bit called AesDecMakeKey.
Setting this bit alters the dec key after writing to it and reading it
back. The dummy decryption seems not to be required. However, with this key
the result of the decrypt operation does not match the expecting result.
The errata [2] in chapter 3.2 says that the computed key may be wrong. The
work around is to "write the first key twice". This did not help, so I must
have done it wrong. However if I write parts of the again I get
different results which are wrong.
However a SW calculation is also possible.
Chapter 11.1.4 in [1] says, that the decrypt key is the last 16/24/32 bytes
created by the expansion algorithm. So I picked the key expand routine
from generic aes module and just passed the crypto test for decryption
with a 16 byte long key. The other two key sizes failed. Probably the
the key slots are different. Currently I have no idea what's wrong.
[0]
http://lists.arm.linux.org.uk/lurker/message/20090301.231447.6af0663c.en.html
[1] 88F5182, Doc. No. MV-S103345-01, Rev. C, April 29, 2008, Preliminary
[2] 88F5182, Doc. No. MV-S500802-00, Rev. E, April 29, 2008, Preliminary
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/crypto/Kconfig |9 +
drivers/crypto/Makefile |1 +
drivers/crypto/mav_crypto.c | 578 +++
3 files changed, 588 insertions(+), 0 deletions(-)
create mode 100644 drivers/crypto/mav_crypto.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 01afd75..514fe78 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -157,6 +157,15 @@ config S390_PRNG
ANSI X9.17 standard. The PRNG is usable via the char device
/dev/prandom.
+config CRYPTO_DEV_MARVELL_CRYPTO_ENGINE
+ tristate "Marvell's Cryptographic Engine"
+ depends on PLAT_ORION
+ select CRYPTO_ALGAPI
+ select CRYPTO_AES
+ help
+ This driver allows you utilize the cryptographic engine which can be
+ found on certain SoC like QNAP's TS-209.
+
config CRYPTO_DEV_HIFN_795X
tristate "Driver HIFN 795x crypto accelerator chips"
select CRYPTO_DES
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 9bf4a2b..9c7053c 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -2,6 +2,7 @@ obj-$(CONFIG_CRYPTO_DEV_PADLOCK_AES) += padlock-aes.o
obj-$(CONFIG_CRYPTO_DEV_PADLOCK_SHA) += padlock-sha.o
obj-$(CONFIG_CRYPTO_DEV_GEODE) += geode-aes.o
obj-$(CONFIG_CRYPTO_DEV_HIFN_795X) += hifn_795x.o
+obj-$(CONFIG_CRYPTO_DEV_MARVELL_CRYPTO_ENGINE) += mav_crypto.o
obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
obj-$(CONFIG_CRYPTO_DEV_IXP4XX) += ixp4xx_crypto.o
obj-$(CONFIG_CRYPTO_DEV_PPC4XX) += amcc/
diff --git a/drivers/crypto/mav_crypto.c b/drivers/crypto/mav_crypto.c
new file mode 100644
index 000..969edcf
--- /dev/null
+++ b/drivers/crypto/mav_crypto.c
@@ -0,0 +1,578 @@
+/*
+ * Support for Marvell's crypto engine which can be found on some Orion5X
+ * boards.
+ *
+ * Author: Sebastian Andrzej Siewior < sebastian at breakpoint dot cc >
+ * License: GPL
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct crypto_priv {
+ void __iomem *reg;
+ void __iomem *sram;
+ wait_queue_head_t wq;
+ int irq;
+};
+
+static struct crypto_priv *cpg;
+
+static void reg_write(void __iomem *mem, u32 val)
+{
+ __raw_writel(val, mem);
+}
+
+static u32 reg_read(void __iomem *mem)
+{
+ return __raw_readl(mem);
+}
+
+#define DIGEST_INITIAL_VAL_A 0xdd00
+#define DES_CMD_REG0xdd58
+
+#define SEC_ACCEL_CMD 0xde00
+#define SEC_CMD_EN_SEC_ACCL0 (1 << 0)
+#define SEC_CMD_EN_SEC_ACCL1 (1 << 1)
+#define SEC_CMD_DISABLE_SEC(1 << 2)
+
+#define SEC_ACCEL_DESC_P0 0xde04
+#define SEC_DESC_P0_PTR(x) (x)
+
+#define SEC_ACCEL_DESC_P1 0xde14
+#define SEC_DESC_P1_PTR(x) (x)
+
+#define SEC_ACCEL_CFG 0xde08
+#define SEC_CFG_STOP_DIG_ERR (1 << 0)
+#define SEC_CFG_CH0_W_IDMA (1 << 7)
+#define
