[PATCH v7 0/3] crypto: ux500 crypto and hash driver
Changed config to depend on correct ARCH, also removed an unnecessary if statement check in the hash driver. 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. Patches are also available at: http://www.df.lth.se/~triad/ux500-crypto/ Andreas Westin (3): crypto: ux500: Add driver for CRYP hardware. crypto: ux500: Add driver for HASH hardware mach-ux500: Crypto: core support for CRYP/HASH module. arch/arm/mach-ux500/board-mop500.c | 48 + arch/arm/mach-ux500/board-u5500.c | 48 + arch/arm/mach-ux500/clock.c | 18 +- arch/arm/mach-ux500/devices-common.c| 16 + arch/arm/mach-ux500/devices-common.h| 23 + arch/arm/mach-ux500/devices-db5500.h|4 + arch/arm/mach-ux500/devices-db8500.h|4 + arch/arm/mach-ux500/include/mach/crypto-ux500.h | 21 + arch/arm/mach-ux500/include/mach/devices.h |3 + arch/arm/mach-ux500/ste-dma40-db5500.h |9 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile |1 + drivers/crypto/ux500/Kconfig| 30 + drivers/crypto/ux500/Makefile |8 + drivers/crypto/ux500/cryp/Makefile | 13 + drivers/crypto/ux500/cryp/cryp.c| 391 + drivers/crypto/ux500/cryp/cryp.h| 308 drivers/crypto/ux500/cryp/cryp_core.c | 1785 drivers/crypto/ux500/cryp/cryp_irq.c| 45 + drivers/crypto/ux500/cryp/cryp_irq.h| 31 + drivers/crypto/ux500/cryp/cryp_irqp.h | 125 ++ drivers/crypto/ux500/cryp/cryp_p.h | 124 ++ drivers/crypto/ux500/hash/Makefile | 11 + drivers/crypto/ux500/hash/hash_alg.h| 395 + drivers/crypto/ux500/hash/hash_core.c | 2019 +++ 25 files changed, 5480 insertions(+), 11 deletions(-) create mode 100644 arch/arm/mach-ux500/include/mach/crypto-ux500.h create mode 100644 drivers/crypto/ux500/Kconfig create mode 100644 drivers/crypto/ux500/Makefile create mode 100644 drivers/crypto/ux500/cryp/Makefile create mode 100644 drivers/crypto/ux500/cryp/cryp.c create mode 100644 drivers/crypto/ux500/cryp/cryp.h create mode 100644 drivers/crypto/ux500/cryp/cryp_core.c create mode 100644 drivers/crypto/ux500/cryp/cryp_irq.c create mode 100644 drivers/crypto/ux500/cryp/cryp_irq.h create mode 100644 drivers/crypto/ux500/cryp/cryp_irqp.h create mode 100644 drivers/crypto/ux500/cryp/cryp_p.h create mode 100644 drivers/crypto/ux500/hash/Makefile create mode 100644 drivers/crypto/ux500/hash/hash_alg.h create mode 100644 drivers/crypto/ux500/hash/hash_core.c -- 1.7.10 -- 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
[PATCH v7 3/3] mach-ux500: Crypto: core support for CRYP/HASH module.
This adds the required platform data and calls to enable
the CRYP/HASH driver.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Andreas Westin andreas.wes...@stericsson.com
---
arch/arm/mach-ux500/board-mop500.c | 48
arch/arm/mach-ux500/board-u5500.c | 48
arch/arm/mach-ux500/clock.c| 18 ++-
arch/arm/mach-ux500/devices-common.c | 16 ++
arch/arm/mach-ux500/devices-common.h | 23 +
arch/arm/mach-ux500/devices-db5500.h |4 +++
arch/arm/mach-ux500/devices-db8500.h |4 +++
arch/arm/mach-ux500/include/mach/devices.h |3 ++
arch/arm/mach-ux500/ste-dma40-db5500.h |9 --
9 files changed, 162 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index 5c00712..4e9bcd6 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -44,6 +44,7 @@
#include mach/setup.h
#include mach/devices.h
#include mach/irqs.h
+#include mach/crypto-ux500.h
#include pins-db8500.h
#include ste-dma40-db8500.h
@@ -409,6 +410,45 @@ static void mop500_prox_deactivate(struct device *dev)
regulator_put(prox_regulator);
}
+static struct cryp_platform_data u8500_cryp1_platform_data = {
+ .mem_to_engine = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_4,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_4,
+ },
+ .engine_to_mem = {
+ .dir = STEDMA40_PERIPH_TO_MEM,
+ .src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
+ .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_4,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_4,
+ }
+};
+
+static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_16,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_16,
+};
+
+static struct hash_platform_data u8500_hash1_platform_data = {
+ .mem_to_engine = u8500_hash_dma_cfg_tx,
+ .dma_filter = stedma40_filter,
+};
+
/* add any platform devices here - TODO */
static struct platform_device *mop500_platform_devs[] __initdata = {
mop500_gpio_keys_device,
@@ -594,6 +634,12 @@ static void __init mop500_uart_init(void)
db8500_add_uart2(uart2_plat);
}
+static void __init u8500_cryp1_hash1_init(void)
+{
+ db8500_add_cryp1(u8500_cryp1_platform_data);
+ db8500_add_hash1(u8500_hash1_platform_data);
+}
+
static struct platform_device *snowball_platform_devs[] __initdata = {
snowball_led_dev,
snowball_key_dev,
@@ -611,6 +657,8 @@ static void __init mop500_init_machine(void)
mop500_pins_init();
+ u8500_cryp1_hash1_init();
+
platform_add_devices(mop500_platform_devs,
ARRAY_SIZE(mop500_platform_devs));
diff --git a/arch/arm/mach-ux500/board-u5500.c
b/arch/arm/mach-ux500/board-u5500.c
index 9de9e9c..865aaf8 100644
--- a/arch/arm/mach-ux500/board-u5500.c
+++ b/arch/arm/mach-ux500/board-u5500.c
@@ -23,9 +23,11 @@
#include mach/hardware.h
#include mach/devices.h
#include mach/setup.h
+#include mach/crypto-ux500.h
#include pins-db5500.h
#include devices-db5500.h
+#include ste-dma40-db5500.h
#include linux/led-lm3530.h
/*
@@ -89,6 +91,45 @@ static struct lm3530_platform_data u5500_als_platform_data =
{
.brt_val = 0x7F,/* Max brightness */
};
+static struct cryp_platform_data u5500_cryp1_platform_data = {
+ .mem_to_engine = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB5500_DMA_DEV48_CRYPTO1_TX,
+
[PATCH v7 0/3] crypto: ux500 crypto and hash driver
Resending, something seems to have gone wrong the first time. Changed config to depend on correct ARCH, also removed an unnecessary if statement check in the hash driver. 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. Patches are also available at: http://www.df.lth.se/~triad/ux500-crypto/ Andreas Westin (3): crypto: ux500: Add driver for CRYP hardware. crypto: ux500: Add driver for HASH hardware mach-ux500: Crypto: core support for CRYP/HASH module. arch/arm/mach-ux500/board-mop500.c | 48 + arch/arm/mach-ux500/board-u5500.c | 48 + arch/arm/mach-ux500/clock.c | 18 +- arch/arm/mach-ux500/devices-common.c| 16 + arch/arm/mach-ux500/devices-common.h| 23 + arch/arm/mach-ux500/devices-db5500.h|4 + arch/arm/mach-ux500/devices-db8500.h|4 + arch/arm/mach-ux500/include/mach/crypto-ux500.h | 21 + arch/arm/mach-ux500/include/mach/devices.h |3 + arch/arm/mach-ux500/ste-dma40-db5500.h |9 +- drivers/crypto/Kconfig | 11 + drivers/crypto/Makefile |1 + drivers/crypto/ux500/Kconfig| 30 + drivers/crypto/ux500/Makefile |8 + drivers/crypto/ux500/cryp/Makefile | 13 + drivers/crypto/ux500/cryp/cryp.c| 391 + drivers/crypto/ux500/cryp/cryp.h| 308 drivers/crypto/ux500/cryp/cryp_core.c | 1785 drivers/crypto/ux500/cryp/cryp_irq.c| 45 + drivers/crypto/ux500/cryp/cryp_irq.h| 31 + drivers/crypto/ux500/cryp/cryp_irqp.h | 125 ++ drivers/crypto/ux500/cryp/cryp_p.h | 124 ++ drivers/crypto/ux500/hash/Makefile | 11 + drivers/crypto/ux500/hash/hash_alg.h| 395 + drivers/crypto/ux500/hash/hash_core.c | 2019 +++ 25 files changed, 5480 insertions(+), 11 deletions(-) create mode 100644 arch/arm/mach-ux500/include/mach/crypto-ux500.h create mode 100644 drivers/crypto/ux500/Kconfig create mode 100644 drivers/crypto/ux500/Makefile create mode 100644 drivers/crypto/ux500/cryp/Makefile create mode 100644 drivers/crypto/ux500/cryp/cryp.c create mode 100644 drivers/crypto/ux500/cryp/cryp.h create mode 100644 drivers/crypto/ux500/cryp/cryp_core.c create mode 100644 drivers/crypto/ux500/cryp/cryp_irq.c create mode 100644 drivers/crypto/ux500/cryp/cryp_irq.h create mode 100644 drivers/crypto/ux500/cryp/cryp_irqp.h create mode 100644 drivers/crypto/ux500/cryp/cryp_p.h create mode 100644 drivers/crypto/ux500/hash/Makefile create mode 100644 drivers/crypto/ux500/hash/hash_alg.h create mode 100644 drivers/crypto/ux500/hash/hash_core.c -- 1.7.10 -- 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
[PATCH v7 3/3] mach-ux500: Crypto: core support for CRYP/HASH module.
This adds the required platform data and calls to enable
the CRYP/HASH driver.
Acked-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Andreas Westin andreas.wes...@stericsson.com
---
arch/arm/mach-ux500/board-mop500.c | 48
arch/arm/mach-ux500/board-u5500.c | 48
arch/arm/mach-ux500/clock.c| 18 ++-
arch/arm/mach-ux500/devices-common.c | 16 ++
arch/arm/mach-ux500/devices-common.h | 23 +
arch/arm/mach-ux500/devices-db5500.h |4 +++
arch/arm/mach-ux500/devices-db8500.h |4 +++
arch/arm/mach-ux500/include/mach/devices.h |3 ++
arch/arm/mach-ux500/ste-dma40-db5500.h |9 --
9 files changed, 162 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-ux500/board-mop500.c
b/arch/arm/mach-ux500/board-mop500.c
index 5c00712..4e9bcd6 100644
--- a/arch/arm/mach-ux500/board-mop500.c
+++ b/arch/arm/mach-ux500/board-mop500.c
@@ -44,6 +44,7 @@
#include mach/setup.h
#include mach/devices.h
#include mach/irqs.h
+#include mach/crypto-ux500.h
#include pins-db8500.h
#include ste-dma40-db8500.h
@@ -409,6 +410,45 @@ static void mop500_prox_deactivate(struct device *dev)
regulator_put(prox_regulator);
}
+static struct cryp_platform_data u8500_cryp1_platform_data = {
+ .mem_to_engine = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB8500_DMA_DEV48_CAC1_TX,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_4,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_4,
+ },
+ .engine_to_mem = {
+ .dir = STEDMA40_PERIPH_TO_MEM,
+ .src_dev_type = DB8500_DMA_DEV48_CAC1_RX,
+ .dst_dev_type = STEDMA40_DEV_DST_MEMORY,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_4,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_4,
+ }
+};
+
+static struct stedma40_chan_cfg u8500_hash_dma_cfg_tx = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB8500_DMA_DEV50_HAC1_TX,
+ .src_info.data_width = STEDMA40_WORD_WIDTH,
+ .dst_info.data_width = STEDMA40_WORD_WIDTH,
+ .mode = STEDMA40_MODE_LOGICAL,
+ .src_info.psize = STEDMA40_PSIZE_LOG_16,
+ .dst_info.psize = STEDMA40_PSIZE_LOG_16,
+};
+
+static struct hash_platform_data u8500_hash1_platform_data = {
+ .mem_to_engine = u8500_hash_dma_cfg_tx,
+ .dma_filter = stedma40_filter,
+};
+
/* add any platform devices here - TODO */
static struct platform_device *mop500_platform_devs[] __initdata = {
mop500_gpio_keys_device,
@@ -594,6 +634,12 @@ static void __init mop500_uart_init(void)
db8500_add_uart2(uart2_plat);
}
+static void __init u8500_cryp1_hash1_init(void)
+{
+ db8500_add_cryp1(u8500_cryp1_platform_data);
+ db8500_add_hash1(u8500_hash1_platform_data);
+}
+
static struct platform_device *snowball_platform_devs[] __initdata = {
snowball_led_dev,
snowball_key_dev,
@@ -611,6 +657,8 @@ static void __init mop500_init_machine(void)
mop500_pins_init();
+ u8500_cryp1_hash1_init();
+
platform_add_devices(mop500_platform_devs,
ARRAY_SIZE(mop500_platform_devs));
diff --git a/arch/arm/mach-ux500/board-u5500.c
b/arch/arm/mach-ux500/board-u5500.c
index 9de9e9c..865aaf8 100644
--- a/arch/arm/mach-ux500/board-u5500.c
+++ b/arch/arm/mach-ux500/board-u5500.c
@@ -23,9 +23,11 @@
#include mach/hardware.h
#include mach/devices.h
#include mach/setup.h
+#include mach/crypto-ux500.h
#include pins-db5500.h
#include devices-db5500.h
+#include ste-dma40-db5500.h
#include linux/led-lm3530.h
/*
@@ -89,6 +91,45 @@ static struct lm3530_platform_data u5500_als_platform_data =
{
.brt_val = 0x7F,/* Max brightness */
};
+static struct cryp_platform_data u5500_cryp1_platform_data = {
+ .mem_to_engine = {
+ .dir = STEDMA40_MEM_TO_PERIPH,
+ .src_dev_type = STEDMA40_DEV_SRC_MEMORY,
+ .dst_dev_type = DB5500_DMA_DEV48_CRYPTO1_TX,
+
Re: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus
Hrm... I don't like that much:
+ if (op-timeout)
+ deadline = jiffies + msecs_to_jiffies(op-timeout);
+
+ while (true) {
+ hret = plpar_hcall_norets(H_COP, op-flags,
+ vdev-resource_id,
+ op-in, op-inlen, op-out,
+ op-outlen, op-csbcpb);
+
+ if (hret == H_SUCCESS ||
+ (hret != H_NOT_ENOUGH_RESOURCES
+ hret != H_BUSY hret != H_RESOURCE) ||
+ (op-timeout time_after(deadline, jiffies)))
+ break;
+
+ dev_dbg(dev, %s: hcall ret(%ld), retrying.\n, __func__, hret);
+ }
+
Is this meant to be called in atomic context ? If not, maybe it should
at the very least do a cond_resched() ?
Else, what about ceding the processor ? Or at the very least reducing
the thread priority for a bit ?
Shouldn't we also enforce to always have a timeout ? IE. Something like
30s or so if nothing specified to avoid having the kernel just hard
lock...
In general I don't like that sort of synchronous code, I'd rather return
the busy status up the chain which gives a chance to the caller to take
more appropriate measures depending on what it's doing, but that really
depends what you use that synchronous call for. I suppose if it's for
configuration type operations, it's ok...
Cheers,
Ben.
--
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: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus
Else, what about ceding the processor ? Or at the very least reducing the thread priority for a bit ? Shouldn't we also enforce to always have a timeout ? IE. Something like 30s or so if nothing specified to avoid having the kernel just hard lock... In general I don't like that sort of synchronous code, I'd rather return the busy status up the chain which gives a chance to the caller to take more appropriate measures depending on what it's doing, but that really depends what you use that synchronous call for. I suppose if it's for configuration type operations, it's ok... In any case, don't resend the whole series, just that one patch. Cheers, Ben. -- 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
