Re: Fwd: crypto accelerator driver problems
Vakul Garg va...@freescale.com wrote: Herbert Xu herbert at gondor.apana.org.au writes: On Wed, Jan 26, 2011 at 10:26:33AM +0330, Hamid Nassiby wrote: As you know, I posted my problem again to crypto list and no one answered. Now I emphasize one aspect of the problem as a concept related to IPSec protocol, free of my problem's nature, and I hope to get some guidelines at this time. The question is as following: If IPSec delivers IP packets to hardware crypto accelerator in sequential manner (e.g, packets in order: 1, 2, 3, ..., 36, 37, 38,...) and crypto accelerator possibly returns back packets out of entering order to IPSec (e.g, packet 37 is returned back before the packet 36 to IPSec, so the order of packets is not the same before entering crypto accelerator and after exiting it); Is it possible to rise any problem here? We do not allow such reordering. All crypto drivers must ensure ordering within a single tfm. Between different tfms there is no ordering requirement. Cheers, Hello Herbert, Does this mean that processing of all the crypto requests from a single tfm must be serialized even if they execute on multiple different cores? Correct. Conceptually a single tfm is like a thread, if one wanted parallelism then multiple tfms should be used. Of course there are exceptions such as pcrypt. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 1/9 v2] crypto: ux500/hash - Prepare clock before enabling it
On Fri, Apr 19, 2013 at 2:24 PM, Lee Jones lee.jo...@linaro.org wrote: Slight change of plan for v2. Now we're doing a seperate clk_prepare(), as the clk_enable() in the previous patch turned out to be called inside a spin_lock(). Arnd, can you confirm your Ack please? Do you really want letters to Arnd to be part of the commit log? --- Note: stuff following the three dashes (---) will be *omitted* from the change log. This seems to be turned upside-down. crypto: ux500/hash - Prepare clock before enabling it If we fail to prepare the ux500-hash clock before enabling it the platform will fail to boot. Here we insure this happens. Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Andreas Westin andreas.wes...@stericsson.com Cc: linux-crypto@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Lee Jones lee.jo...@linaro.org Pls include Ulf Hansson ulf.hans...@linaro.org on this patch. Yours, Linus Walleij -- 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 2/9] crypto: ux500/hash - Set DMA configuration though dma_slave_config()
Pls include magnus.p.pers...@stericsson.com on all these crypto/hash
postings.
On Thu, Apr 18, 2013 at 12:26 PM, Lee Jones lee.jo...@linaro.org wrote:
The DMA controller currently takes configuration information from
information passed though dma_channel_request(), but it shouldn't.
Using the API, the DMA channel should only be configured during
a dma_slave_config() call.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: Andreas Westin andreas.wes...@stericsson.com
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
(...)
#define HASH_BLOCK_SIZE64
+#define HASH_DMA_FIFO 4
This is an address so write 0x0004 here please. Some hex notation atleast.
/**
* struct hash_device_data - structure for a hash device.
- * @base: Pointer to the hardware base address.
+ * @base: Pointer to virtual base address of the hash device.
+ * @phybase: Pointer to physical memory location of the hash
device.
* @list_node: For inclusion in klist.
* @dev: Pointer to the device dev structure.
* @ctx_lock: Spinlock for current_ctx.
@@ -361,6 +363,7 @@ struct hash_req_ctx {
*/
struct hash_device_data {
struct hash_register __iomem*base;
+ phys_addr_t phybase;
What you pass to the config function is a dma_addr_t actually.
This is the same thing on the platform, but generally:
phys_addr_t = in the address space as the memory controller sees it.
dma_addr_t = in the address space as the DMA controller sees it.
Often the same. Not always. So use dma_addr_t.
Apart from this a real nice patch!
Yours,
Linus Walleij
--
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 4/9 v2] crypto: ux500/cryp - Prepare clock before enabling it
On Fri, Apr 19, 2013 at 2:22 PM, Lee Jones lee.jo...@linaro.org wrote: Slight change of plan for v2. Now we're doing a seperate clk_prepare(), as the clk_enable() in the previous patch turned out to be called inside a spin_lock(). Arnd, can you confirm your Ack please? crypto: ux500/cryp - Prepare clock before enabling it If we fail to prepare the ux500-cryp clock before enabling it the platform will fail to boot. Here we insure this happens. Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Andreas Westin andreas.wes...@stericsson.com Cc: linux-crypto@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Lee Jones lee.jo...@linaro.org Same formatting problems as the other prepare/enable patch. Include Ulf Hansson. (Apart from this it looks OK.) Yours, Linus Walleij -- 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 5/9] crypto: ux500/cryp - Fix compile error
On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones lee.jo...@linaro.org wrote: Clearly this driver hasn't been tested, or even enabled in a while. drivers/crypto/ux500/cryp/cryp_core.c:1771:3: error: request for member ‘pm’ in something not a structure or union Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Andreas Westin andreas.wes...@stericsson.com Cc: linux-crypto@vger.kernel.org Signed-off-by: Lee Jones lee.jo...@linaro.org NAK. I already fixed this. It is in v3.9-rc7. Yours, Linus Walleij -- 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 8/9] crypto: ux500/[cryp|hash] - Show successful start-up in the bootlog
On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones lee.jo...@linaro.org wrote: The Cryp driver is currently silent and the Hash driver prints the name of its probe function unnecessarily. Let's just put a nice descriptive one-liner there instead. Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Andreas Westin andreas.wes...@stericsson.com Cc: linux-crypto@vger.kernel.org Signed-off-by: Lee Jones lee.jo...@linaro.org Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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] ARM: crypto: fix stack frame handling in SHA1 asm code
The current code increases its stack frame size a couple of times throughout the function, but still performs some writes below the stack pointer. This change applies the fix from the original author so all writes to the stack are above the stack pointer. Taken from origin: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1a9d60d2 Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org --- arch/arm/crypto/sha1-armv4-large.S |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/crypto/sha1-armv4-large.S b/arch/arm/crypto/sha1-armv4-large.S index 92c6eed..99207c4 100644 --- a/arch/arm/crypto/sha1-armv4-large.S +++ b/arch/arm/crypto/sha1-armv4-large.S @@ -195,6 +195,7 @@ ENTRY(sha1_block_data_order) add r3,r3,r10 @ E+=F_00_19(B,C,D) cmp r14,sp bne .L_00_15@ [((11+4)*5+2)*3] + sub sp,sp,#25*4 #if __ARM_ARCH__7 ldrbr10,[r1,#2] ldrbr9,[r1,#3] @@ -290,7 +291,6 @@ ENTRY(sha1_block_data_order) add r3,r3,r10 @ E+=F_00_19(B,C,D) ldr r8,.LK_20_39@ [+15+16*4] - sub sp,sp,#25*4 cmn sp,#0 @ [+3], clear carry to denote 20_39 .L_20_39_or_60_79: ldr r9,[r14,#15*4] -- 1.7.10.4 -- 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] Fix prototype definitions of sha256_transform_asm, sha512_transform_asm
On Fri, Apr 19, 2013 at 01:25:12PM -0700, Tim Chen wrote: Herbert, This is a follow on patch to the optimized sha256 and sha512 patch series that's just merged into the crypto-dev. Let me know if you prefer me to respin the patch series. This patch corrects the prototype of sha256_transform_asm and sha512_transform_asm function pointer declaration to static. It also fixes a typo in sha512_ssse3_final function that affects the computation of upper 64 bits of the buffer size. Thanks, I've folded this into the original patches in order to maintain bisectability. -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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] crypto: aesni_intel - fix Kconfig problem with CRYPTO_GLUE_HELPER_X86
On Wed, Apr 10, 2013 at 06:39:20PM +0300, Jussi Kivilinna wrote: The Kconfig setting for glue helper module is CRYPTO_GLUE_HELPER_X86, but recent change for aesni_intel used CRYPTO_GLUE_HELPER instead. Patch corrects this issue. Cc: kbuild-...@01.org Reported-by: kbuild test robot fengguang...@intel.com Signed-off-by: Jussi Kivilinna jussi.kivili...@iki.fi Patch applied. Thanks! -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 1/4] Wrap crc_t10dif function all to use crypto transform framework
On Wed, Apr 17, 2013 at 09:12:52AM -0700, Tim Chen wrote: When CRC T10 DIF is calculated using the crypto transform framework, we wrap the crc_t10dif function call to utilize it. This allows us to take advantage of any accelerated CRC T10 DIF transform that is plugged into the crypto framework. Signed-off-by: Tim Chen tim.c.c...@linux.intel.com Please wrap the generic implementation as we do for crc32c. Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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 6/9] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
On Thu, 25 Apr 2013, Linus Walleij wrote:
On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones lee.jo...@linaro.org wrote:
The DMA controller currently takes configuration information from
information passed though dma_channel_request(), but it shouldn't.
Using the API, the DMA channel should only be configured during
a dma_slave_config() call.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: Andreas Westin andreas.wes...@stericsson.com
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
(...)
/* Cryp DMA interface */
+#define HASH_DMA_TX_FIFO 0x08
+#define HASH_DMA_RX_FIFO 0x10
Yes, this is nice address notation :-)
/**
* struct cryp_device_data - structure for a cryp device.
- * @base: Pointer to the hardware base address.
+ * @base: Pointer to virtual base address of the cryp device.
+ * @phybase: Pointer to physical memory location of the cryp device.
* @dev: Pointer to the devices dev structure.
* @clk: Pointer to the device's clock control.
* @pwr_regulator: Pointer to the device's power control.
@@ -232,6 +236,7 @@ struct cryp_dma {
*/
struct cryp_device_data {
struct cryp_register __iomem *base;
+ phys_addr_t phybase;
Use dma_addr_t. Maybe phybase is misleading,
dmabase is probably better. (Also applies to the
cryp patch).
Accept it's not the dmabase.
It's the phybase (U8500_CRYP1_BASE) i.e. the physical base address of
the device's regs.
--
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 5/9] crypto: ux500/cryp - Fix compile error
On Thu, 25 Apr 2013, Linus Walleij wrote: On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones lee.jo...@linaro.org wrote: Clearly this driver hasn't been tested, or even enabled in a while. drivers/crypto/ux500/cryp/cryp_core.c:1771:3: error: request for member ‘pm’ in something not a structure or union Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Andreas Westin andreas.wes...@stericsson.com Cc: linux-crypto@vger.kernel.org Signed-off-by: Lee Jones lee.jo...@linaro.org NAK. I already fixed this. It is in v3.9-rc7. Yes, I saw it when I rebased. I've dropped the patch. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/9 v2] crypto: ux500/hash - Prepare clock before enabling it
On Thu, 25 Apr 2013, Linus Walleij wrote: On Fri, Apr 19, 2013 at 2:24 PM, Lee Jones lee.jo...@linaro.org wrote: Slight change of plan for v2. Now we're doing a seperate clk_prepare(), as the clk_enable() in the previous patch turned out to be called inside a spin_lock(). Arnd, can you confirm your Ack please? Do you really want letters to Arnd to be part of the commit log? --- Note: stuff following the three dashes (---) will be *omitted* from the change log. This seems to be turned upside-down. Ah, I didn't know that, thanks. This patch wasn't due for 'plucking', just reviewing. crypto: ux500/hash - Prepare clock before enabling it If we fail to prepare the ux500-hash clock before enabling it the platform will fail to boot. Here we insure this happens. Cc: Herbert Xu herb...@gondor.apana.org.au Cc: David S. Miller da...@davemloft.net Cc: Andreas Westin andreas.wes...@stericsson.com Cc: linux-crypto@vger.kernel.org Acked-by: Arnd Bergmann a...@arndb.de Signed-off-by: Lee Jones lee.jo...@linaro.org Pls include Ulf Hansson ulf.hans...@linaro.org on this patch. Sure. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 6/9] crypto: ux500/cryp - Set DMA configuration though dma_slave_config()
On Thu, Apr 25, 2013 at 3:44 PM, Lee Jones lee.jo...@linaro.org wrote:
On Thu, 25 Apr 2013, Linus Walleij wrote:
On Thu, Apr 18, 2013 at 12:27 PM, Lee Jones lee.jo...@linaro.org wrote:
The DMA controller currently takes configuration information from
information passed though dma_channel_request(), but it shouldn't.
Using the API, the DMA channel should only be configured during
a dma_slave_config() call.
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: Andreas Westin andreas.wes...@stericsson.com
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Lee Jones lee.jo...@linaro.org
(...)
/* Cryp DMA interface */
+#define HASH_DMA_TX_FIFO 0x08
+#define HASH_DMA_RX_FIFO 0x10
Yes, this is nice address notation :-)
/**
* struct cryp_device_data - structure for a cryp device.
- * @base: Pointer to the hardware base address.
+ * @base: Pointer to virtual base address of the cryp device.
+ * @phybase: Pointer to physical memory location of the cryp device.
* @dev: Pointer to the devices dev structure.
* @clk: Pointer to the device's clock control.
* @pwr_regulator: Pointer to the device's power control.
@@ -232,6 +236,7 @@ struct cryp_dma {
*/
struct cryp_device_data {
struct cryp_register __iomem *base;
+ phys_addr_t phybase;
Use dma_addr_t. Maybe phybase is misleading,
dmabase is probably better. (Also applies to the
cryp patch).
Accept it's not the dmabase.
It's the phybase (U8500_CRYP1_BASE) i.e. the physical base address of
the device's regs.
So when you assign the src_addr or dst_addr in struct
dmaengine_slave_config in this code,
you notice that this looks like so:
struct dma_slave_config {
enum dma_transfer_direction direction;
dma_addr_t src_addr;
dma_addr_t dst_addr;
enum dma_slave_buswidth src_addr_width;
enum dma_slave_buswidth dst_addr_width;
u32 src_maxburst;
u32 dst_maxburst;
bool device_fc;
};
So when you do this:
+ struct dma_slave_config mem2cryp = {
+ .direction = DMA_MEM_TO_DEV,
+ .dst_addr = device_data-phybase + HASH_DMA_TX_FIFO,
+ .dst_addr_width = DMA_SLAVE_BUSWIDTH_2_BYTES,
+ .dst_maxburst = 4,
+};
on .dst_addr you are effectively casting a phys_addr_t
into a dma_addr_t.
But we must do this at some point, and now I think
that doing it here may be just as good (because we might
just add a physical-to-dma memory translation if need
be).
So allright.
Yours,
Linus Walleij
--
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 1/4] Wrap crc_t10dif function all to use crypto transform framework
On Thu, 2013-04-25 at 21:22 +0800, Herbert Xu wrote:
Please wrap the generic implementation as we do for crc32c.
Herbert,
I've updated this patch to add the generic crct10dif transform (see
below). Let me know if this address your comment. Thanks.
Tim
When CRC T10 DIF is calculated using the crypto transform framework, we
wrap the crc_t10dif function call to utilize it. This allows us to
take advantage of any accelerated CRC T10 DIF transform that is
plugged into the crypto framework.
Signed-off-by: Tim Chen tim.c.c...@linux.intel.com
---
crypto/Makefile| 1 +
crypto/crct10dif.c | 126 +
include/linux/crc-t10dif.h | 10
lib/crc-t10dif.c | 96 ++
4 files changed, 233 insertions(+)
create mode 100644 crypto/crct10dif.c
diff --git a/crypto/Makefile b/crypto/Makefile
index a8e9b0f..62af87d 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_CRYPTO_ZLIB) += zlib.o
obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
obj-$(CONFIG_CRYPTO_CRC32) += crc32.o
+obj-$(CONFIG_CRYPTO_CRCT10DIF) += crct10dif.o
obj-$(CONFIG_CRYPTO_AUTHENC) += authenc.o authencesn.o
obj-$(CONFIG_CRYPTO_LZO) += lzo.o
obj-$(CONFIG_CRYPTO_842) += 842.o
diff --git a/crypto/crct10dif.c b/crypto/crct10dif.c
new file mode 100644
index 000..76b059a
--- /dev/null
+++ b/crypto/crct10dif.c
@@ -0,0 +1,126 @@
+/*
+ * Cryptographic API.
+ *
+ * T10 Data Integrity Field CRC16 Crypto Xform
+ *
+ * Copyright (C) 2013 Intel Corporation
+ * Author: Tim Chen tim.c.c...@linux.intel.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+#include linux/types.h
+#include linux/module.h
+#include linux/crc-t10dif.h
+#include crypto/internal/hash.h
+#include linux/init.h
+#include linux/string.h
+#include linux/kernel.h
+
+struct chksum_desc_ctx {
+ __u16 crc;
+};
+
+/*
+ * Steps through buffer one byte at at time, calculates reflected
+ * crc using table.
+ */
+
+static int chksum_init(struct shash_desc *desc)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ ctx-crc = 0;
+
+ return 0;
+}
+
+static int chksum_update(struct shash_desc *desc, const u8 *data,
+unsigned int length)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ ctx-crc = crc_t10dif_generic(ctx-crc, data, length);
+ return 0;
+}
+
+static int chksum_final(struct shash_desc *desc, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ *(__u16 *)out = ctx-crc;
+ return 0;
+}
+
+static int __chksum_finup(__u16 *crcp, const u8 *data, unsigned int len,
+ u8 *out)
+{
+ *(__u16 *)out = crc_t10dif_generic(*crcp, data, len);
+ return 0;
+}
+
+static int chksum_finup(struct shash_desc *desc, const u8 *data,
+ unsigned int len, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ return __chksum_finup(ctx-crc, data, len, out);
+}
+
+static int chksum_digest(struct shash_desc *desc, const u8 *data,
+unsigned int length, u8 *out)
+{
+ struct chksum_desc_ctx *ctx = shash_desc_ctx(desc);
+
+ return __chksum_finup(ctx-crc, data, length, out);
+}
+
+static struct shash_alg alg = {
+ .digestsize = CRC_T10DIF_DIGEST_SIZE,
+ .init = chksum_init,
+ .update = chksum_update,
+ .final = chksum_final,
+ .finup = chksum_finup,
+ .digest = chksum_digest,
+ .descsize = sizeof(struct chksum_desc_ctx),
+ .base = {
+ .cra_name = crct10dif,
+ .cra_driver_name= crct10dif-generic,
+ .cra_priority = 100,
+ .cra_blocksize = CRC_T10DIF_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static int __init crct10dif_mod_init(void)
+{
+ int ret;
+
+ ret = crypto_register_shash(alg);
+ return ret;
+}
+
+static void __exit
Re: [PATCH 1/2] lib: Add lz4 compressor module
gcc seems to define __builtin_clz as __clzsi2 in some architecture.
But, kernel doesn't link libgcc.a.
If kernel should use gcc's built-in function without libgcc.a,
do we need to port __clzsi2 to 'arch/*/lib/*'?
This breaks alpha (gcc-4.4.4) as well. Can we please get this fixed
promptly?
__clzsi2 can be implemented by using generic functions.
It can be overridden by linking arch-specific versions may not be implemented.
does this way look acceptable?
diff --git a/lib/Makefile b/lib/Makefile
index af79e8c..e17b3ee 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -23,7 +23,7 @@ lib-y += kobject.o klist.o
obj-y += bcd.o div64.o sort.o parser.o halfmd4.o debug_locks.o random32.o \
bust_spinlocks.o hexdump.o kasprintf.o bitmap.o scatterlist.o \
- gcd.o lcm.o list_sort.o uuid.o flex_array.o \
+ gcd.o lcm.o list_sort.o uuid.o flex_array.o clz.o\
bsearch.o find_last_bit.o find_next_bit.o llist.o memweight.o kfifo.o
obj-y += string_helpers.o
obj-$(CONFIG_TEST_STRING_HELPERS) += test-string_helpers.o
diff --git a/lib/clz.c b/lib/clz.c
index e69de29..6794b83 100644
--- a/lib/clz.c
+++ b/lib/clz.c
@@ -0,0 +1,23 @@
+#include linux/kernel.h
+
+int __attribute__((weak)) __clzsi2(int val)
+{
+ return BITS_PER_LONG - fls(val);
+}
+EXPORT_SYMBOL(__clzsi2);
+
+#if BITS_PER_LONG == 32
+int __attribute__((weak)) __clzdi2(long val)
+{
+ return BITS_PER_LONG - fls((int)val);
+}
+EXPORT_SYMBOL(__clzdi2);
+#elif BITS_PER_LONG == 64
+int __attribute__((weak)) __clzdi2(long val)
+{
+ return BITS_PER_LONG - fls64((u64)val);
+}
+EXPORT_SYMBOL(__clzdi2);
+#else
+#error BITS_PER_LONG not 32 or 64
+#endif
--
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 1/2] lib: Add lz4 compressor module
Hi, On Fri, 26 Apr 2013 14:02:01 +0900 Chanho Min chanho@lge.com wrote: @@ -0,0 +1,23 @@ +#include linux/kernel.h + +int __attribute__((weak)) __clzsi2(int val) We have __weak in linux/compiler.h -- Cheers, Stephen Rothwells...@canb.auug.org.au pgp21BCDTqop1.pgp Description: PGP signature
