[PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
Expose Talitos's XOR functionality to be used for
RAID Parity calculation via the Async_tx layer.
Known Issue:
When used with fsldma, random crashes are observed
on some platforms. Hence, inter-operability with fsldma
is currently disabled
Thanks to Surender Kumar and Lee Nipper for their help in
realising this driver
Signed-off-by: Kim Phillips
Signed-off-by: Dipen Dudhat
Signed-off-by: Maneesh Gupta
Signed-off-by: Vishnu Suresh
---
Changes with respect to v1 as per comments received
o. Rebased to linux-next as of 20091216
o. The selection is based exclusive of fsldma
o. Intoduced a new Kernel Configuration variable
*. This enables selecting the Cryptographic functionality
of Talitos along with fsldma.
*. Disables the XOR parity calculation offload, if fsldma enabled
either as kernel in-built or as a module
*. Once the inter-operability with fsldma is resolved, this option
can be removed
drivers/crypto/Kconfig |9 +
drivers/crypto/talitos.c | 402 +-
drivers/crypto/talitos.h |2 +
3 files changed, 412 insertions(+), 1 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index b08403d..f8a6376 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -203,6 +203,15 @@ config CRYPTO_DEV_TALITOS
To compile this driver as a module, choose M here: the module
will be called talitos.
+config CRYPTO_DEV_TALITOS_RAIDXOR
+ bool "Talitos RAID5 XOR Calculation Offload"
+ select DMA_ENGINE
+ depends on CRYPTO_DEV_TALITOS
+ depends on FSL_DMA=n
+ help
+ Say 'Y' here to use the Freescale Security Engine (SEC) to
+ offload RAID XOR parity Calculation
+
config CRYPTO_DEV_IXP4XX
tristate "Driver for IXP4xx crypto hardware acceleration"
depends on ARCH_IXP4XX
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c47ffe8..e63b25a 100644
--- a/drivers/crypto/talitos.c
+++ b/drivers/crypto/talitos.c
@@ -1,7 +1,7 @@
/*
* talitos - Freescale Integrated Security Engine (SEC) device driver
*
- * Copyright (c) 2008 Freescale Semiconductor, Inc.
+ * Copyright (c) 2008-2009 Freescale Semiconductor, Inc.
*
* Scatterlist Crypto API glue code copied from files with the following:
* Copyright (c) 2006-2007 Herbert Xu
@@ -37,6 +37,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -140,6 +142,10 @@ struct talitos_private {
/* hwrng device */
struct hwrng rng;
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+ /* XOR Device */
+ struct dma_device dma_dev_common;
+#endif /* CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR */
};
/* .features flag */
@@ -684,6 +690,375 @@ static void talitos_unregister_rng(struct device *dev)
hwrng_unregister(&priv->rng);
}
+#ifdef CONFIG_CRYPTO_DEV_TALITOS_RAIDXOR
+/*
+ * async_tx interface for XOR-capable SECs
+ *
+ * Dipen Dudhat
+ * Maneesh Gupta
+ * Vishnu Suresh
+ */
+
+/**
+ * talitos_xor_chan - context management for the async_tx channel
+ * @completed_cookie: the last completed cookie
+ * @desc_lock: lock for tx queue
+ * @total_desc: number of descriptors allocated
+ * @submit_q: queue of submitted descriptors
+ * @pending_q: queue of pending descriptors
+ * @in_progress_q: queue of descriptors in progress
+ * @free_desc: queue of unused descriptors
+ * @dev: talitos device implementing this channel
+ * @common: the corresponding xor channel in async_tx
+ */
+struct talitos_xor_chan {
+ dma_cookie_t completed_cookie;
+ spinlock_t desc_lock;
+ unsigned int total_desc;
+ struct list_head submit_q;
+ struct list_head pending_q;
+ struct list_head in_progress_q;
+ struct list_head free_desc;
+ struct device *dev;
+ struct dma_chan common;
+};
+
+/**
+ * talitos_xor_desc - software xor descriptor
+ * @async_tx: the referring async_tx descriptor
+ * @node:
+ * @hwdesc: h/w descriptor
+ */
+struct talitos_xor_desc {
+ struct dma_async_tx_descriptor async_tx;
+ struct list_head tx_list;
+ struct list_head node;
+ struct talitos_desc hwdesc;
+};
+
+static enum dma_status talitos_is_tx_complete(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ dma_cookie_t *done,
+ dma_cookie_t *used)
+{
+ struct talitos_xor_chan *xor_chan;
+ dma_cookie_t last_used;
+ dma_cookie_t last_complete;
+
+ xor_chan = container_of(chan, struct talitos_xor_chan, common);
+
+ last_used = chan->cookie;
+ last_complete = xor_chan->completed_cookie;
+
+ if (done)
+ *done = last_complete;
+
+ if (used)
+ *used = last_used;
+
+ return dma_async_is_complete(cookie, last_complete, last_used);
+}
+
+static voi
Re: [PATCH v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
On Wed, 16 Dec 2009 21:04:58 +0530 Vishnu Suresh wrote: > Expose Talitos's XOR functionality to be used for > RAID Parity calculation via the Async_tx layer. > > Known Issue: > When used with fsldma, random crashes are observed > on some platforms. Hence, inter-operability with fsldma > is currently disabled > > Thanks to Surender Kumar and Lee Nipper for their help in > realising this driver > > Signed-off-by: Kim Phillips > Signed-off-by: Dipen Dudhat > Signed-off-by: Maneesh Gupta > Signed-off-by: Vishnu Suresh > --- > Changes with respect to v1 as per comments received > o. Rebased to linux-next as of 20091216 > o. The selection is based exclusive of fsldma > o. Intoduced a new Kernel Configuration variable >*. This enables selecting the Cryptographic functionality > of Talitos along with fsldma. >*. Disables the XOR parity calculation offload, if fsldma enabled > either as kernel in-built or as a module >*. Once the inter-operability with fsldma is resolved, this option > can be removed wait, why can't the interoperability bug be fixed in the first place? Kim -- 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 v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
On Dec 16, 2009, at 4:41 PM, Kim Phillips wrote: > On Wed, 16 Dec 2009 21:04:58 +0530 > Vishnu Suresh wrote: > >> Expose Talitos's XOR functionality to be used for >> RAID Parity calculation via the Async_tx layer. >> >> Known Issue: >> When used with fsldma, random crashes are observed >> on some platforms. Hence, inter-operability with fsldma >> is currently disabled >> >> Thanks to Surender Kumar and Lee Nipper for their help in >> realising this driver >> >> Signed-off-by: Kim Phillips >> Signed-off-by: Dipen Dudhat >> Signed-off-by: Maneesh Gupta >> Signed-off-by: Vishnu Suresh >> --- >> Changes with respect to v1 as per comments received >> o. Rebased to linux-next as of 20091216 >> o. The selection is based exclusive of fsldma >> o. Intoduced a new Kernel Configuration variable >> *. This enables selecting the Cryptographic functionality >> of Talitos along with fsldma. >> *. Disables the XOR parity calculation offload, if fsldma enabled >> either as kernel in-built or as a module >> *. Once the inter-operability with fsldma is resolved, this option >> can be removed > > wait, why can't the interoperability bug be fixed in the first place? I agree w/Kim. We need to better understand what the bug is and how to reproduce it so we can get to the root cause. Paper taping over it by disabling fsldma is not the right solution. - k-- 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 v2 2/2] Crypto: Talitos: Support for Async_tx XOR offload
Kumar Gala wrote: Changes with respect to v1 as per comments received o. Rebased to linux-next as of 20091216 o. The selection is based exclusive of fsldma o. Intoduced a new Kernel Configuration variable *. This enables selecting the Cryptographic functionality of Talitos along with fsldma. *. Disables the XOR parity calculation offload, if fsldma enabled either as kernel in-built or as a module *. Once the inter-operability with fsldma is resolved, this option can be removed wait, why can't the interoperability bug be fixed in the first place? I agree w/Kim. We need to better understand what the bug is and how to reproduce it so we can get to the root cause. Paper taping over it by disabling fsldma is not the right solution. Hopefully this prompts fsldma authors to get involved because the interoperability issue has been out there without comment*, just band-aids, since October. -- Dan * well one comment from Ira saying the interrupt functionality worked for him. -- 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
