Re: [PATCH 03/10] crypto: aead: Add aead_request_cast() api
On Thu, Jul 02, 2015 at 10:48:33AM +0530, Lokesh Vutla wrote:
Add aead_request_cast() api to get pointer to aead_request
from cryto_async_request.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
include/linux/crypto.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 10df5d2..20fac3d 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1460,6 +1460,12 @@ static inline void aead_request_set_tfm(struct
aead_request *req,
req-base.tfm = crypto_aead_tfm(crypto_aead_crt(tfm)-base);
}
+static inline struct aead_request *aead_request_cast(
+ struct crypto_async_request *req)
+{
+ return container_of(req, struct aead_request, base);
container_of() ensures type safety, this can be a macro just fine.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 02/10] crypto: omap-aes: Fix configuring of AES mode
On Thu, Jul 02, 2015 at 10:48:32AM +0530, Lokesh Vutla wrote: AES_CTRL_REG is used to configure AES mode. Before configuring any mode we need to make sure all other modes are reset or else driver will misbehave. So mask all modes before configuring any AES mode. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/crypto/omap-aes.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index a923101..96fc7f7 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -63,6 +63,7 @@ #define AES_REG_CTRL_DIRECTION (1 2) #define AES_REG_CTRL_INPUT_READY (1 1) #define AES_REG_CTRL_OUTPUT_READY(1 0) +#define AES_REG_CTRL_MASKFLD_MASK(24, 2) you end up masking bits which aren't even defined in this driver. What are those bits ? Perhaps add macros for them and define AES_REG_CTRL_MASK by explicitly ORing those macros ? That would, at least, be clearer -- balbi signature.asc Description: Digital signature
Re: [PATCH 01/10] crypto: omap-aes: Add support for lengths not aligned with AES_BLOCK_SIZE
On Thu, Jul 02, 2015 at 10:48:31AM +0530, Lokesh Vutla wrote:
OMAP AES driver returns an error if the data is not aligned with
AES_BLOCK_SIZE bytes.
But OMAP AES hw allows data input upto 1 byte aligned, but still
zeros are to be appended and complete AES_BLOCK_SIZE has to be written.
And correct length has to be passed in LENGTH field.
Adding support for inputs not aligned with AES_BLOCK_SIZE.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-aes.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 9a28b7e..a923101 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -558,6 +558,9 @@ static int omap_aes_check_aligned(struct scatterlist *sg,
int total)
{
int len = 0;
+ if (!IS_ALIGNED(total, AES_BLOCK_SIZE))
+ return -1;
-EINVAL?
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 04/10] crypto: omap-aes: Use BIT() macro
On Thu, Jul 02, 2015 at 10:48:34AM +0530, Lokesh Vutla wrote: Use BIT()/GENMASK() macros for all register definitions instead of hand-writing bit masks. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/crypto/omap-aes.c | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index 96fc7f7..d974ab6 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -52,30 +52,30 @@ #define AES_REG_IV(dd, x)((dd)-pdata-iv_ofs + ((x) * 0x04)) #define AES_REG_CTRL(dd) ((dd)-pdata-ctrl_ofs) -#define AES_REG_CTRL_CTR_WIDTH_MASK (3 7) -#define AES_REG_CTRL_CTR_WIDTH_32(0 7) -#define AES_REG_CTRL_CTR_WIDTH_64(1 7) -#define AES_REG_CTRL_CTR_WIDTH_96(2 7) -#define AES_REG_CTRL_CTR_WIDTH_128 (3 7) -#define AES_REG_CTRL_CTR (1 6) -#define AES_REG_CTRL_CBC (1 5) -#define AES_REG_CTRL_KEY_SIZE(3 3) -#define AES_REG_CTRL_DIRECTION (1 2) -#define AES_REG_CTRL_INPUT_READY (1 1) -#define AES_REG_CTRL_OUTPUT_READY(1 0) -#define AES_REG_CTRL_MASKFLD_MASK(24, 2) +#define AES_REG_CTRL_CTR_WIDTH_MASK GENMASK(8, 7) +#define AES_REG_CTRL_CTR_WIDTH_320 +#define AES_REG_CTRL_CTR_WIDTH_64BIT(7) +#define AES_REG_CTRL_CTR_WIDTH_96BIT(8) +#define AES_REG_CTRL_CTR_WIDTH_128 GENMASK(8, 7) +#define AES_REG_CTRL_CTR BIT(6) +#define AES_REG_CTRL_CBC BIT(5) +#define AES_REG_CTRL_KEY_SIZEGENMASK(4, 3) +#define AES_REG_CTRL_DIRECTION BIT(2) +#define AES_REG_CTRL_INPUT_READY BIT(1) +#define AES_REG_CTRL_OUTPUT_READYBIT(0) +#define AES_REG_CTRL_MASKGENMASK(24, 2) this was defined a couple patches ago, why didn't you define it with GENMASK() to start with ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 08/10] crypto: omap-aes: gmc: Add algo info
Am Donnerstag, 2. Juli 2015, 10:48:38 schrieb Lokesh Vutla:
Hi Lokesh,
Now the driver supports gcm mode, add omap-aes-gcm
algo info to omap-aes driver.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-aes.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index e5e9a19..11f3850 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -789,6 +789,28 @@ static struct crypto_alg algs_ctr[] = {
.decrypt= omap_aes_ctr_decrypt,
}
},
+{
+ .cra_name = gcm(aes),
+ .cra_driver_name= gcm-aes-omap,
+ .cra_priority = 100,
Why did you choose the priority 100? The software implementations commonly use
100. crypto/gcm.c uses the prio of the underlying cipher. In case of ARM,
there seem to be assembler implementations of AES which have the prio of 200
or 300. So, such software implementation of gcm(aes) would have a higher
precedence than your hw implementation.
So, if a user would use gcm(aes), isn't it more likely that he gets the
software implementation?
+ .cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC |
+CRYPTO_ALG_KERN_DRIVER_ONLY,
+ .cra_blocksize = AES_BLOCK_SIZE,
+ .cra_ctxsize= sizeof(struct omap_aes_ctx),
+ .cra_alignmask = 0xf,
+ .cra_type = crypto_aead_type,
+ .cra_module = THIS_MODULE,
+ .cra_init = omap_aes_gcm_cra_init,
+ .cra_exit = omap_aes_cra_exit,
+ .cra_u.aead = {
+ .maxauthsize= AES_BLOCK_SIZE,
+ .geniv = eseqiv,
+ .ivsize = AES_BLOCK_SIZE,
+ .setkey = omap_aes_gcm_setkey,
+ .encrypt= omap_aes_gcm_encrypt,
+ .decrypt= omap_aes_gcm_decrypt,
+ }
+},
};
static struct omap_aes_algs_info omap_aes_algs_info_ecb_cbc[] = {
Ciao
Stephan
--
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 09/10] crypto: omap-aes: gcm: Add support for PIO mode
On Thu, Jul 02, 2015 at 10:48:39AM +0530, Lokesh Vutla wrote: Add support for PIO mode for GCM mode. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com why do you require PIO ? Is there any situation where DMA can't be used? What would that case be ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 06/10] crypto: omap-aes: gcm: Handle inputs properly
On Thu, Jul 02, 2015 at 10:48:36AM +0530, Lokesh Vutla wrote:
Its not necessary that assoc data and plain text is passed always.
Add these checks before processing the input.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
why can't this be combined with patch which added GCM in the first
place ?
---
drivers/crypto/omap-aes-gcm.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 1be9d91..72815af 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -87,7 +87,7 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
struct aead_request *req)
{
void *buf_in;
- int alen, clen;
+ int alen, clen, nsg;
struct crypto_aead *aead = crypto_aead_reqtfm(req);
unsigned int authlen = crypto_aead_authsize(aead);
u32 dec = !(dd-flags FLAGS_ENCRYPT);
@@ -97,12 +97,18 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
dd-sgs_copied = 0;
- sg_init_table(dd-in_sgl, 2);
- buf_in = sg_virt(req-assoc);
- sg_set_buf(dd-in_sgl, buf_in, alen);
+ nsg = 1 + !!(req-assoclen req-cryptlen);
- buf_in = sg_virt(req-src);
- sg_set_buf(dd-in_sgl[1], buf_in, clen);
+ sg_init_table(dd-in_sgl, nsg);
+ if (req-assoclen) {
+ buf_in = sg_virt(req-assoc);
+ sg_set_buf(dd-in_sgl, buf_in, alen);
+ }
+
+ if (req-cryptlen) {
+ buf_in = sg_virt(req-src);
+ sg_set_buf(dd-in_sgl[nsg - 1], buf_in, clen);
+ }
dd-in_sg = dd-in_sgl;
dd-total = clen;
@@ -258,6 +264,8 @@ static int omap_aes_gcm_crypt(struct aead_request *req,
unsigned long mode)
{
struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
struct omap_aes_reqctx *rctx = aead_request_ctx(req);
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ unsigned int authlen = crypto_aead_authsize(aead);
struct omap_aes_dev *dd;
__be32 counter = cpu_to_be32(1);
int err;
@@ -270,6 +278,12 @@ static int omap_aes_gcm_crypt(struct aead_request *req,
unsigned long mode)
if (err)
return err;
+ if (req-assoclen + req-cryptlen == 0) {
+ scatterwalk_map_and_copy(ctx-auth_tag, req-dst, 0, authlen,
+ 1);
+ return 0;
+ }
+
dd = omap_aes_find_dev(ctx);
if (!dd)
return -ENODEV;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 07/10] crypto: omap-aes: gcm: Add support for unaligned lengths
On Thu, Jul 02, 2015 at 10:48:37AM +0530, Lokesh Vutla wrote: Check if the inputs are not aligned, if not process the input before starting the hw acceleration. Similarly after completition of hw acceleration. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com and this ? -- balbi signature.asc Description: Digital signature
Re: [PATCH 05/10] crypto: omap-aes: Add support for GCM mode
On Thu, Jul 02, 2015 at 10:48:35AM +0530, Lokesh Vutla wrote:
OMAP AES hw supports aes gcm mode.
here you refer to it as 'gcm'
Adding support for GCM mode in omap-aes driver.
while here and in subject as 'GCM'.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/Makefile |3 +-
drivers/crypto/omap-aes-gcm.c | 304
+
why does this have to be a separate source file ? Patch gets really
large with all the macro and structure definition being shuffled around.
drivers/crypto/omap-aes.c | 238 +---
drivers/crypto/omap-aes.h | 205 +++
4 files changed, 575 insertions(+), 175 deletions(-)
create mode 100644 drivers/crypto/omap-aes-gcm.c
create mode 100644 drivers/crypto/omap-aes.h
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..3afad7b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -13,7 +13,8 @@ obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
obj-$(CONFIG_CRYPTO_DEV_NX) += nx/
-obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
+obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes-driver.o
+omap-aes-driver-objs := omap-aes.o omap-aes-gcm.o
... I mean, considering you unconditionally link these two together...
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
new file mode 100644
index 000..1be9d91
--- /dev/null
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -0,0 +1,304 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for OMAP AES GCM HW acceleration.
+ *
+ * Copyright (c) 2015 Texas Instruments Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
published
+ * by the Free Software Foundation.
+ *
+ */
+
+#include linux/err.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/io.h
+#include linux/crypto.h
+#include linux/interrupt.h
+#include crypto/scatterwalk.h
+#include crypto/aes.h
+#include omap-aes.h
+
+static int omap_aes_gcm_handle_queue(struct omap_aes_dev *dd,
+ struct aead_request *req);
+
+static void omap_aes_gcm_finish_req(struct omap_aes_dev *dd, int ret)
+{
+ struct aead_request *req = dd-aead_req;
+
+ dd-flags = ~FLAGS_BUSY;
+ dd-in_sg = NULL;
+ dd-out_sg = NULL;
+
+ req-base.complete(req-base, ret);
+}
+
+static void omap_aes_gcm_done_task(struct omap_aes_dev *dd)
+{
+ u8 *tag;
+ int alen, clen, i, ret = 0, nsg;
+
+ alen = ALIGN(dd-assoc_len, AES_BLOCK_SIZE);
+ clen = ALIGN(dd-total, AES_BLOCK_SIZE);
+
+ nsg = 1 + !!(dd-assoc_len dd-total);
+
+ if (!dd-pio_only) {
+ dma_sync_sg_for_device(dd-dev, dd-out_sg, dd-out_sg_len,
+DMA_FROM_DEVICE);
+ dma_unmap_sg(dd-dev, dd-in_sg, dd-in_sg_len, DMA_TO_DEVICE);
+ dma_unmap_sg(dd-dev, dd-out_sg, dd-out_sg_len,
+ DMA_FROM_DEVICE);
+ omap_aes_crypt_dma_stop(dd);
+ }
+
+ if (dd-flags FLAGS_ENCRYPT)
+ scatterwalk_map_and_copy(dd-ctx-auth_tag, dd-aead_req-dst,
+ dd-total, dd-authsize, 1);
+
+ if (!(dd-flags FLAGS_ENCRYPT)) {
+ tag = (u8 *)dd-ctx-auth_tag;
+ for (i = 0; i dd-authsize; i++) {
+ if (tag[i]) {
+ dev_err(dd-dev, GCM decryption: Tag Message
is wrong\n);
+ ret = -EBADMSG;
+ }
+ }
+ }
+
+ omap_aes_gcm_finish_req(dd, ret);
+ omap_aes_gcm_handle_queue(dd, NULL);
+}
+
+static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
+ struct aead_request *req)
+{
+ void *buf_in;
+ int alen, clen;
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ unsigned int authlen = crypto_aead_authsize(aead);
+ u32 dec = !(dd-flags FLAGS_ENCRYPT);
+
+ alen = req-assoclen;
+ clen = req-cryptlen - (dec * authlen);
+
+ dd-sgs_copied = 0;
+
+ sg_init_table(dd-in_sgl, 2);
+ buf_in = sg_virt(req-assoc);
+ sg_set_buf(dd-in_sgl, buf_in, alen);
+
+ buf_in = sg_virt(req-src);
+ sg_set_buf(dd-in_sgl[1], buf_in, clen);
+
+ dd-in_sg = dd-in_sgl;
+ dd-total = clen;
+ dd-assoc_len = req-assoclen;
+ dd-authsize = authlen;
+ dd-out_sg = req-dst;
+
+
Re: [PATCH 05/10] crypto: omap-aes: Add support for GCM mode
On Thursday 02 July 2015 01:34 PM, Felipe Balbi wrote:
On Thu, Jul 02, 2015 at 10:48:35AM +0530, Lokesh Vutla wrote:
OMAP AES hw supports aes gcm mode.
here you refer to it as 'gcm'
Will update it in next revision.
Adding support for GCM mode in omap-aes driver.
while here and in subject as 'GCM'.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/Makefile |3 +-
drivers/crypto/omap-aes-gcm.c | 304
+
why does this have to be a separate source file ? Patch gets really
large with all the macro and structure definition being shuffled around.
GCM is an aead(authenticated encryption and decryption) but
other modes are just block ciphers(encryption and decryption).
Crypto library defines differ structures and routines for aead and normal
block ciphers.
So I started off with a new driver, and later able to combine common parts.
Since GCM is a bit different from all other modes, I left it in a new file.
If I combine into same file, it will be difficult to track all these fucntions
at a time.
Thanks and regards,
Lokesh
drivers/crypto/omap-aes.c | 238 +---
drivers/crypto/omap-aes.h | 205 +++
4 files changed, 575 insertions(+), 175 deletions(-)
create mode 100644 drivers/crypto/omap-aes-gcm.c
create mode 100644 drivers/crypto/omap-aes.h
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index fb84be7..3afad7b 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -13,7 +13,8 @@ obj-$(CONFIG_CRYPTO_DEV_MXS_DCP) += mxs-dcp.o
obj-$(CONFIG_CRYPTO_DEV_NIAGARA2) += n2_crypto.o
n2_crypto-y := n2_core.o n2_asm.o
obj-$(CONFIG_CRYPTO_DEV_NX) += nx/
-obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes.o
+obj-$(CONFIG_CRYPTO_DEV_OMAP_AES) += omap-aes-driver.o
+omap-aes-driver-objs := omap-aes.o omap-aes-gcm.o
... I mean, considering you unconditionally link these two together...
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
new file mode 100644
index 000..1be9d91
--- /dev/null
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -0,0 +1,304 @@
+/*
+ * Cryptographic API.
+ *
+ * Support for OMAP AES GCM HW acceleration.
+ *
+ * Copyright (c) 2015 Texas Instruments Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
published
+ * by the Free Software Foundation.
+ *
+ */
+
+#include linux/err.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/kernel.h
+#include linux/platform_device.h
+#include linux/scatterlist.h
+#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/io.h
+#include linux/crypto.h
+#include linux/interrupt.h
+#include crypto/scatterwalk.h
+#include crypto/aes.h
+#include omap-aes.h
+
+static int omap_aes_gcm_handle_queue(struct omap_aes_dev *dd,
+ struct aead_request *req);
+
+static void omap_aes_gcm_finish_req(struct omap_aes_dev *dd, int ret)
+{
+struct aead_request *req = dd-aead_req;
+
+dd-flags = ~FLAGS_BUSY;
+dd-in_sg = NULL;
+dd-out_sg = NULL;
+
+req-base.complete(req-base, ret);
+}
+
+static void omap_aes_gcm_done_task(struct omap_aes_dev *dd)
+{
+u8 *tag;
+int alen, clen, i, ret = 0, nsg;
+
+alen = ALIGN(dd-assoc_len, AES_BLOCK_SIZE);
+clen = ALIGN(dd-total, AES_BLOCK_SIZE);
+
+nsg = 1 + !!(dd-assoc_len dd-total);
+
+if (!dd-pio_only) {
+dma_sync_sg_for_device(dd-dev, dd-out_sg, dd-out_sg_len,
+ DMA_FROM_DEVICE);
+dma_unmap_sg(dd-dev, dd-in_sg, dd-in_sg_len, DMA_TO_DEVICE);
+dma_unmap_sg(dd-dev, dd-out_sg, dd-out_sg_len,
+ DMA_FROM_DEVICE);
+omap_aes_crypt_dma_stop(dd);
+}
+
+if (dd-flags FLAGS_ENCRYPT)
+scatterwalk_map_and_copy(dd-ctx-auth_tag, dd-aead_req-dst,
+ dd-total, dd-authsize, 1);
+
+if (!(dd-flags FLAGS_ENCRYPT)) {
+tag = (u8 *)dd-ctx-auth_tag;
+for (i = 0; i dd-authsize; i++) {
+if (tag[i]) {
+dev_err(dd-dev, GCM decryption: Tag Message
is wrong\n);
+ret = -EBADMSG;
+}
+}
+}
+
+omap_aes_gcm_finish_req(dd, ret);
+omap_aes_gcm_handle_queue(dd, NULL);
+}
+
+static int omap_aes_gcm_copy_buffers(struct omap_aes_dev *dd,
+ struct aead_request *req)
+{
+void *buf_in;
+int alen, clen;
+struct crypto_aead *aead = crypto_aead_reqtfm(req);
+unsigned int
Re: [PATCH 06/10] crypto: omap-aes: gcm: Handle inputs properly
On Thursday 02 July 2015 01:34 PM, Felipe Balbi wrote:
On Thu, Jul 02, 2015 at 10:48:36AM +0530, Lokesh Vutla wrote:
Its not necessary that assoc data and plain text is passed always.
Add these checks before processing the input.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
why can't this be combined with patch which added GCM in the first
place ?
Yes, my initial patch is all combined. But it was very big.
I tried my best in breaking down into different patches inorder to
help reviewer.
So, I kept the functionality part in one patch, and handled corner case
like these in separate patches.
Thanks and regards,
Lokesh
---
drivers/crypto/omap-aes-gcm.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/omap-aes-gcm.c b/drivers/crypto/omap-aes-gcm.c
index 1be9d91..72815af 100644
--- a/drivers/crypto/omap-aes-gcm.c
+++ b/drivers/crypto/omap-aes-gcm.c
@@ -87,7 +87,7 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
struct aead_request *req)
{
void *buf_in;
-int alen, clen;
+int alen, clen, nsg;
struct crypto_aead *aead = crypto_aead_reqtfm(req);
unsigned int authlen = crypto_aead_authsize(aead);
u32 dec = !(dd-flags FLAGS_ENCRYPT);
@@ -97,12 +97,18 @@ static int omap_aes_gcm_copy_buffers(struct omap_aes_dev
*dd,
dd-sgs_copied = 0;
-sg_init_table(dd-in_sgl, 2);
-buf_in = sg_virt(req-assoc);
-sg_set_buf(dd-in_sgl, buf_in, alen);
+nsg = 1 + !!(req-assoclen req-cryptlen);
-buf_in = sg_virt(req-src);
-sg_set_buf(dd-in_sgl[1], buf_in, clen);
+sg_init_table(dd-in_sgl, nsg);
+if (req-assoclen) {
+buf_in = sg_virt(req-assoc);
+sg_set_buf(dd-in_sgl, buf_in, alen);
+}
+
+if (req-cryptlen) {
+buf_in = sg_virt(req-src);
+sg_set_buf(dd-in_sgl[nsg - 1], buf_in, clen);
+}
dd-in_sg = dd-in_sgl;
dd-total = clen;
@@ -258,6 +264,8 @@ static int omap_aes_gcm_crypt(struct aead_request *req,
unsigned long mode)
{
struct omap_aes_ctx *ctx = crypto_aead_ctx(crypto_aead_reqtfm(req));
struct omap_aes_reqctx *rctx = aead_request_ctx(req);
+struct crypto_aead *aead = crypto_aead_reqtfm(req);
+unsigned int authlen = crypto_aead_authsize(aead);
struct omap_aes_dev *dd;
__be32 counter = cpu_to_be32(1);
int err;
@@ -270,6 +278,12 @@ static int omap_aes_gcm_crypt(struct aead_request *req,
unsigned long mode)
if (err)
return err;
+if (req-assoclen + req-cryptlen == 0) {
+scatterwalk_map_and_copy(ctx-auth_tag, req-dst, 0, authlen,
+ 1);
+return 0;
+}
+
dd = omap_aes_find_dev(ctx);
if (!dd)
return -ENODEV;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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 02/10] crypto: omap-aes: Fix configuring of AES mode
On Thursday 02 July 2015 01:27 PM, Felipe Balbi wrote: On Thu, Jul 02, 2015 at 10:48:32AM +0530, Lokesh Vutla wrote: AES_CTRL_REG is used to configure AES mode. Before configuring any mode we need to make sure all other modes are reset or else driver will misbehave. So mask all modes before configuring any AES mode. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/crypto/omap-aes.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c index a923101..96fc7f7 100644 --- a/drivers/crypto/omap-aes.c +++ b/drivers/crypto/omap-aes.c @@ -63,6 +63,7 @@ #define AES_REG_CTRL_DIRECTION (1 2) #define AES_REG_CTRL_INPUT_READY(1 1) #define AES_REG_CTRL_OUTPUT_READY (1 0) +#define AES_REG_CTRL_MASK FLD_MASK(24, 2) you end up masking bits which aren't even defined in this driver. What are those bits ? Perhaps add macros for them and define AES_REG_CTRL_MASK by explicitly ORing those macros ? That would, at least, be clearer Hardware supports ECB, CBC, CTR, CFB, F8, CBC_MAC, F9, GCM, CCM, XTS modes. But current driver has only ECB, CBC, CTR modes support. That is why the other fields are not yet defined. So, defining these is fine, but ORing all these will be very big and looks a bit ugly. So I kept it as mask of all these bits. Ill move it to GEN_MASK here only. Thanks and regards, Lokesh -- 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 03/10] crypto: aead: Add aead_request_cast() api
On Thursday 02 July 2015 01:28 PM, Felipe Balbi wrote:
On Thu, Jul 02, 2015 at 10:48:33AM +0530, Lokesh Vutla wrote:
Add aead_request_cast() api to get pointer to aead_request
from cryto_async_request.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
include/linux/crypto.h |6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 10df5d2..20fac3d 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1460,6 +1460,12 @@ static inline void aead_request_set_tfm(struct
aead_request *req,
req-base.tfm = crypto_aead_tfm(crypto_aead_crt(tfm)-base);
}
+static inline struct aead_request *aead_request_cast(
+struct crypto_async_request *req)
+{
+return container_of(req, struct aead_request, base);
container_of() ensures type safety, this can be a macro just fine.
There are many similar definitions for ablkcipher.. etc,in
crypto library. So I tried to make it uniform for the entire library.
Thanks and regards,
Lokesh
--
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 08/10] crypto: omap-aes: gmc: Add algo info
Am Donnerstag, 2. Juli 2015, 15:24:58 schrieb Lokesh Vutla:
Hi Lokesh,
+{
+ .cra_name = gcm(aes),
+ .cra_driver_name= gcm-aes-omap,
+ .cra_priority = 100,
Why did you choose the priority 100? The software implementations commonly
use 100. crypto/gcm.c uses the prio of the underlying cipher. In case of
ARM, there seem to be assembler implementations of AES which have the prio
of 200 or 300. So, such software implementation of gcm(aes) would have a
higher precedence than your hw implementation.
Yes, you are right.
Other hw algos in omap-aes also uses priority 100.
Only sw and hw implementations are enabled right now and both are at same
priority. And till now its lucky enough that hw algo gets picked.
Maybe those HW prios should be updated too?
Ciao
Stephan
--
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 08/10] crypto: omap-aes: gmc: Add algo info
On Thursday 02 July 2015 01:30 PM, Stephan Mueller wrote:
Am Donnerstag, 2. Juli 2015, 10:48:38 schrieb Lokesh Vutla:
Hi Lokesh,
Now the driver supports gcm mode, add omap-aes-gcm
algo info to omap-aes driver.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-aes.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index e5e9a19..11f3850 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -789,6 +789,28 @@ static struct crypto_alg algs_ctr[] = {
.decrypt= omap_aes_ctr_decrypt,
}
},
+{
+.cra_name = gcm(aes),
+.cra_driver_name= gcm-aes-omap,
+.cra_priority = 100,
Why did you choose the priority 100? The software implementations commonly
use
100. crypto/gcm.c uses the prio of the underlying cipher. In case of ARM,
there seem to be assembler implementations of AES which have the prio of 200
or 300. So, such software implementation of gcm(aes) would have a higher
precedence than your hw implementation.
Yes, you are right.
Other hw algos in omap-aes also uses priority 100.
Only sw and hw implementations are enabled right now and both are at same
priority.
And till now its lucky enough that hw algo gets picked.
Ill change the priority to 300 for all the modes.
Thanks for pointing it.
Regards,
Lokesh
So, if a user would use gcm(aes), isn't it more likely that he gets the
software implementation?
+.cra_flags = CRYPTO_ALG_TYPE_AEAD | CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+.cra_blocksize = AES_BLOCK_SIZE,
+.cra_ctxsize= sizeof(struct omap_aes_ctx),
+.cra_alignmask = 0xf,
+.cra_type = crypto_aead_type,
+.cra_module = THIS_MODULE,
+.cra_init = omap_aes_gcm_cra_init,
+.cra_exit = omap_aes_cra_exit,
+.cra_u.aead = {
+.maxauthsize= AES_BLOCK_SIZE,
+.geniv = eseqiv,
+.ivsize = AES_BLOCK_SIZE,
+.setkey = omap_aes_gcm_setkey,
+.encrypt= omap_aes_gcm_encrypt,
+.decrypt= omap_aes_gcm_decrypt,
+}
+},
};
static struct omap_aes_algs_info omap_aes_algs_info_ecb_cbc[] = {
Ciao
Stephan
--
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 09/10] crypto: omap-aes: gcm: Add support for PIO mode
On Thursday 02 July 2015 01:36 PM, Felipe Balbi wrote: On Thu, Jul 02, 2015 at 10:48:39AM +0530, Lokesh Vutla wrote: Add support for PIO mode for GCM mode. Signed-off-by: Lokesh Vutla lokeshvu...@ti.com why do you require PIO ? Is there any situation where DMA can't be used? What would that case be ? Cannot think of any case where DMA can't be used. But the current driver already supports PIO for all other AES modes. I do not want to break it, so added support for PIO for GCM :) Thanks and regards, Lokesh -- 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 01/10] crypto: omap-aes: Add support for lengths not aligned with AES_BLOCK_SIZE
On Thursday 02 July 2015 01:23 PM, Felipe Balbi wrote:
On Thu, Jul 02, 2015 at 10:48:31AM +0530, Lokesh Vutla wrote:
OMAP AES driver returns an error if the data is not aligned with
AES_BLOCK_SIZE bytes.
But OMAP AES hw allows data input upto 1 byte aligned, but still
zeros are to be appended and complete AES_BLOCK_SIZE has to be written.
And correct length has to be passed in LENGTH field.
Adding support for inputs not aligned with AES_BLOCK_SIZE.
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
---
drivers/crypto/omap-aes.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 9a28b7e..a923101 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -558,6 +558,9 @@ static int omap_aes_check_aligned(struct scatterlist
*sg, int total)
{
int len = 0;
+if (!IS_ALIGNED(total, AES_BLOCK_SIZE))
+return -1;
-EINVAL?
Okay, will update it.
Thanks and regards,
Lokesh
--
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] crypto: omap-des: Fix unmapping of dma channels
dma_unmap_sg() is being called twice after completing the task. Looks like this is a copy paste error when creating des driver. With this the following warn appears during boot: [4.210457] [ cut here ] [4.215114] WARNING: CPU: 0 PID: 0 at lib/dma-debug.c:1080 check_unmap+0x710/0x9a0() [4.222899] omap-des 480a5000.des: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xab2ce000] [size=8 bytes] [4.236785] Modules linked in: [4.239860] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.39-02999-g1bc045a-dirty #182 [4.247918] [c001678c] (unwind_backtrace) from [c0012574] (show_stack+0x10/0x14) [4.255710] [c0012574] (show_stack) from [c05a37e8] (dump_stack+0x84/0xb8) [4.262977] [c05a37e8] (dump_stack) from [c0046464] (warn_slowpath_common+0x68/0x8c) [4.271107] [c0046464] (warn_slowpath_common) from [c004651c] (warn_slowpath_fmt+0x30/0x40) [4.279854] [c004651c] (warn_slowpath_fmt) from [c02d50a4] (check_unmap+0x710/0x9a0) [4.287991] [c02d50a4] (check_unmap) from [c02d5478] (debug_dma_unmap_sg+0x90/0x19c) [4.296128] [c02d5478] (debug_dma_unmap_sg) from [c04a77d8] (omap_des_done_task+0x1cc/0x3e4) [4.304963] [c04a77d8] (omap_des_done_task) from [c004a090] (tasklet_action+0x84/0x124) [4.313370] [c004a090] (tasklet_action) from [c004a4ac] (__do_softirq+0xf0/0x20c) [4.321235] [c004a4ac] (__do_softirq) from [c004a840] (irq_exit+0x98/0xec) [4.328500] [c004a840] (irq_exit) from [c000f9ac] (handle_IRQ+0x50/0xb0) [4.335589] [c000f9ac] (handle_IRQ) from [c0008688] (gic_handle_irq+0x28/0x5c) Removing the duplicate call to dma_unmap_sg(). Reported-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Lokesh Vutla lokeshvu...@ti.com --- drivers/crypto/omap-des.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c index 4630709..0a70e46 100644 --- a/drivers/crypto/omap-des.c +++ b/drivers/crypto/omap-des.c @@ -536,9 +536,6 @@ static int omap_des_crypt_dma_stop(struct omap_des_dev *dd) dmaengine_terminate_all(dd-dma_lch_in); dmaengine_terminate_all(dd-dma_lch_out); - dma_unmap_sg(dd-dev, dd-in_sg, dd-in_sg_len, DMA_TO_DEVICE); - dma_unmap_sg(dd-dev, dd-out_sg, dd-out_sg_len, DMA_FROM_DEVICE); - return err; } -- 1.9.1 -- 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/6] crypto/nx-842-{powerpc,pseries}: only load on the appropriate machine type
On Thu, 2015-07-02 at 15:40 -0700, Nishanth Aravamudan wrote:
While we never would successfully load on the wrong machine type, there
is extra output by default regardless of machine type.
For instance, on a PowerVM LPAR, we see the following:
nx_compress_powernv: loading
nx_compress_powernv: no coprocessors found
even though those coprocessors could never be found. Similar pseries
messages are printed on powernv.
I know I've been converting init calls to machine_initcalls() to avoid these
sort of issues in platform code. But for a driver it should be trivial for it
to only probe when the hardware is found.
By which I mean I think we shouldn't need these.
diff --git a/drivers/crypto/nx/nx-842-powernv.c
b/drivers/crypto/nx/nx-842-powernv.c
index 33b3b0abf4ae..6b5e5143c95b 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -594,6 +594,9 @@ static __init int nx842_powernv_init(void)
BUILD_BUG_ON(DDE_BUFFER_ALIGN % DDE_BUFFER_SIZE_MULT);
BUILD_BUG_ON(DDE_BUFFER_SIZE_MULT % DDE_BUFFER_LAST_MULT);
+ if (!machine_is(powernv))
+ return -ENODEV;
+
pr_info(loading\n);
This is just too chatty, drop it.
for_each_compatible_node(dn, NULL, ibm,power-nx)
It shouldn't be printing anything unless it finds some devices in this loop.
And you should drop the print in here:
if (!nx842_ct) {
pr_err(no coprocessors found\n);
return -ENODEV;
}
And that should mean no output unless hardware is found I think?
@@ -625,6 +628,9 @@ static void __exit nx842_powernv_exit(void)
{
struct nx842_coproc *coproc, *n;
+ if (!machine_is(powernv))
+ return;
You shouldn't need to touch the exit paths if the drivers were never loaded?
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index b84b0ceeb46e..75a7bfdc160e 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -1091,6 +1091,9 @@ static int __init nx842_pseries_init(void)
struct nx842_devdata *new_devdata;
int ret;
+ if (!machine_is(pseries))
+ return -ENODEV;
+
pr_info(Registering IBM Power 842 compression driver\n);
Again this is too chatty, just remove it.
if (!of_find_compatible_node(NULL, NULL, ibm,compression))
return -ENODEV;
That should do the trick shouldn't it?
cheers
--
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 1/6] crypto/nx-842-pseries: nx842_OF_upd_status should return ENODEV if device is not 'okay'
The current documention mentions explicitly that EINVAL should be
returned if the device is not available, but nx842_OF_upd_status()
always returns 0. However, nx842_probe() specifically checks for
non-ENODEV returns from nx842_of_upd() (which in turn calls
nx842_OF_upd_status()) and emits an extra error in that case. It seems
like the proper return code of a disabled device is ENODEV.
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-842-pseries.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index 3040a6091bf2..819c23c546e3 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -556,7 +556,7 @@ static int nx842_OF_set_defaults(struct nx842_devdata
*devdata)
*
* Returns:
* 0 - Device is available
- * -EINVAL - Device is not available
+ * -ENODEV - Device is not available
*/
static int nx842_OF_upd_status(struct nx842_devdata *devdata,
struct property *prop) {
@@ -569,6 +569,7 @@ static int nx842_OF_upd_status(struct nx842_devdata
*devdata,
dev_info(devdata-dev, %s: status '%s' is not 'okay'\n,
__func__, status);
devdata-status = UNAVAILABLE;
+ ret = -ENODEV;
}
return ret;
--
2.1.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
[PATCH 0/6] drivers/nx-842: reduce verbosity of logging
Currently, on a LPAR with the nx-842 device disabled, the following
messages are emitted:
nx_compress: no nx842 driver found. [1]
Registering IBM Power 842 compression driver
nx_compress_pseries ibm,compression-v1: nx842_OF_upd_status: status 'disabled'
is not 'okay'
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: max_sync_size new:4096
old:0 [2]
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: max_sync_sg new:510 old:0
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: max_sg_len new:4080 old:0
nx_compress_powernv: loading [3]
nx_compress_powernv: no coprocessors found
alg: No test for 842 (842-nx) [4]
[1] is the result of an ordering issue when the CONFIG_ options are set =y. [2]
is the result of nx842_OF_upd_status() not returning the correct error code.
[3] is the result of attempting to load the PowerNV platform driver on a
non-PowerNV platform. [4] is the result of there simply not being any test for
842 in the crypto test manager.
After the changes in the series, the same system as above emits:
Registering IBM Power 842 compression driver
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: device disabled
which seems to me, at least, to be far clearer.
Dan, I think there is still a issue in the code. If CONFIG_DEV_NX_COMPRESS=y
and CONFIG_DEV_NX_COMPRESS_PSERIES=m/CONFIG_DEV_NX_COMPRESS_POWERNV=m, it seems
like the request_module() is not working properly and we simply get a
nx_compress: no nx842 driver found. at boot (even if I ensure the platform
drivers are in the initrd). If I make CONFIG_DEV_NX_COMPRESS=m, though, the
module(s) load successfully. Does it make sense/is it possible to have these
three symbols always be the same (either all =y or all =m)?
[1/6] crypto/nx-842-pseries: nx842_OF_upd_status should return ENODEV if device
is not 'okay'
drivers/crypto/nx/nx-842-pseries.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
[2/6] nx-842-pseries: rename nx842_{init,exit} to nx842_pseries_{init,exit}
drivers/crypto/nx/nx-842-pseries.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
[3/6] nx-842-pseries: do not emit extra output if status is disabled
drivers/crypto/nx/nx-842-pseries.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
[4/6] crypto/nx-842-{powerpc,pseries}: only load on the appropriate machine type
drivers/crypto/nx/nx-842-powernv.c | 6 ++
drivers/crypto/nx/nx-842-pseries.c | 6 ++
drivers/crypto/nx/nx-842.h | 1 +
3 files changed, 13 insertions(+)
[5/6] crypto/testmgr: add null test for 842 algorithm
crypto/testmgr.c | 3 +++
1 file changed, 3 insertions(+)
[6/6] nx-842-platform: if NX842 platform drivers are not modules, don't try to
load them
drivers/crypto/nx/nx-842-platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
--
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 4/6] crypto/nx-842-{powerpc,pseries}: only load on the appropriate machine type
While we never would successfully load on the wrong machine type, there
is extra output by default regardless of machine type.
For instance, on a PowerVM LPAR, we see the following:
nx_compress_powernv: loading
nx_compress_powernv: no coprocessors found
even though those coprocessors could never be found. Similar pseries
messages are printed on powernv.
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-842-powernv.c | 6 ++
drivers/crypto/nx/nx-842-pseries.c | 6 ++
drivers/crypto/nx/nx-842.h | 1 +
3 files changed, 13 insertions(+)
diff --git a/drivers/crypto/nx/nx-842-powernv.c
b/drivers/crypto/nx/nx-842-powernv.c
index 33b3b0abf4ae..6b5e5143c95b 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -594,6 +594,9 @@ static __init int nx842_powernv_init(void)
BUILD_BUG_ON(DDE_BUFFER_ALIGN % DDE_BUFFER_SIZE_MULT);
BUILD_BUG_ON(DDE_BUFFER_SIZE_MULT % DDE_BUFFER_LAST_MULT);
+ if (!machine_is(powernv))
+ return -ENODEV;
+
pr_info(loading\n);
for_each_compatible_node(dn, NULL, ibm,power-nx)
@@ -625,6 +628,9 @@ static void __exit nx842_powernv_exit(void)
{
struct nx842_coproc *coproc, *n;
+ if (!machine_is(powernv))
+ return;
+
nx842_platform_driver_unset(nx842_powernv_driver);
list_for_each_entry_safe(coproc, n, nx842_coprocs, list) {
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index b84b0ceeb46e..75a7bfdc160e 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -1091,6 +1091,9 @@ static int __init nx842_pseries_init(void)
struct nx842_devdata *new_devdata;
int ret;
+ if (!machine_is(pseries))
+ return -ENODEV;
+
pr_info(Registering IBM Power 842 compression driver\n);
if (!of_find_compatible_node(NULL, NULL, ibm,compression))
@@ -1129,6 +1132,9 @@ static void __exit nx842_pseries_exit(void)
struct nx842_devdata *old_devdata;
unsigned long flags;
+ if (!machine_is(pseries))
+ return;
+
pr_info(Exiting IBM Power 842 compression driver\n);
nx842_platform_driver_unset(nx842_pseries_driver);
spin_lock_irqsave(devdata_mutex, flags);
diff --git a/drivers/crypto/nx/nx-842.h b/drivers/crypto/nx/nx-842.h
index ac0ea79d0f8b..ea89c661e476 100644
--- a/drivers/crypto/nx/nx-842.h
+++ b/drivers/crypto/nx/nx-842.h
@@ -10,6 +10,7 @@
#include linux/io.h
#include linux/mm.h
#include linux/ratelimit.h
+#include asm/machdep.h
/* Restrictions on Data Descriptor List (DDL) and Entry (DDE) buffers
*
--
2.1.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
[PATCH 2/6] nx-842-pseries: rename nx842_{init,exit} to nx842_pseries_{init,exit}
While there is no technical reason that both nx-842.c and
nx-842-pseries.c can have the same name for the init/exit functions, it
is a bit confusing with initcall_debug. Rename the pseries specific
functions appropriately
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-842-pseries.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index 819c23c546e3..e17f4d2e96e0 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -1080,7 +1080,7 @@ static struct vio_driver nx842_vio_driver = {
.id_table = nx842_vio_driver_ids,
};
-static int __init nx842_init(void)
+static int __init nx842_pseries_init(void)
{
struct nx842_devdata *new_devdata;
int ret;
@@ -1116,9 +1116,9 @@ static int __init nx842_init(void)
return 0;
}
-module_init(nx842_init);
+module_init(nx842_pseries_init);
-static void __exit nx842_exit(void)
+static void __exit nx842_pseries_exit(void)
{
struct nx842_devdata *old_devdata;
unsigned long flags;
@@ -1137,5 +1137,5 @@ static void __exit nx842_exit(void)
vio_unregister_driver(nx842_vio_driver);
}
-module_exit(nx842_exit);
+module_exit(nx842_pseries_exit);
--
2.1.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
[PATCH 3/6] nx-842-pseries: do not emit extra output if status is disabled
If the device-tree indicates the nx-842 device's status is 'disabled',
we emit two messages:
nx_compress_pseries ibm,compression-v1: nx842_OF_upd_status: status 'disabled'
is not 'okay'.
nx_compress_pseries ibm,compression-v1: nx842_OF_upd: device disabled
Given that 'disabled' is a valid state, and we are going to emit that
the device is disabled, only print out a non-'okay' status if it is not
'disabled'.
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
drivers/crypto/nx/nx-842-pseries.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index e17f4d2e96e0..b84b0ceeb46e 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -566,8 +566,14 @@ static int nx842_OF_upd_status(struct nx842_devdata
*devdata,
if (!strncmp(status, okay, (size_t)prop-length)) {
devdata-status = AVAILABLE;
} else {
- dev_info(devdata-dev, %s: status '%s' is not 'okay'\n,
+ /*
+* Caller will log that the device is disabled, so only
+* output if there is an unexpected status.
+*/
+ if (strncmp(status, disabled, (size_t)prop-length)) {
+ dev_info(devdata-dev, %s: status '%s' is not
'okay'\n,
__func__, status);
+ }
devdata-status = UNAVAILABLE;
ret = -ENODEV;
}
--
2.1.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
[PATCH 5/6] [RFC] crypto/testmgr: add null test for 842 algorithm
Currently, when the nx-842-pseries driver loads, the following message
is emitted:
alg: No test for 842 (842-nx)
It seems like the simplest way to fix this message (other than adding a
proper test) is to just insert the null test into the list in the
testmgr.
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
---
crypto/testmgr.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index d0a42bd3aae9..ff0f76e0d0b4 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -1982,6 +1982,9 @@ static int alg_test_null(const struct alg_test_desc *desc,
/* Please keep this list sorted by algorithm name. */
static const struct alg_test_desc alg_test_descs[] = {
{
+ .alg = 842,
+ .test = alg_test_null,
+ }, {
.alg = __cbc-cast5-avx,
.test = alg_test_null,
}, {
--
2.1.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
[PATCH 6/6] nx-842-platform: if NX842 platform drivers are not modules, don't try to load them
Based off the CONFIG_SPU_FS_MODULE code, only attempt to load platform
modules if the nx-842 pseries/powernv drivers are built as modules.
Otherwise, if CONFIG_DEV_NX_COMPRESS=y,
CONFIG_DEV_NX_COMPRESS_PSERIES=y, CONFIG_DEV_NX_POWERNV=y, the following
message is emitted at boot:
nx_compress: no nx842 driver found.
even though the drivers successfully loads.
This is because in the =y case, the module_init() calls get converted to
initcalls and the nx842_init() runs before the platform driver
nx842_pseries_init() or nx842_powernv_init() functions, which are what
normally set the static platform driver.
Signed-off-by: Nishanth Aravamudan n...@linux.vnet.ibm.com
Cc: Dan Streetman ddstr...@us.ibm.com
Cc: Herbert Xu herb...@gondor.apana.org.au
Cc: David S. Miller da...@davemloft.net
Cc: linux-crypto@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
---
drivers/crypto/nx/nx-842-platform.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/nx/nx-842-platform.c
b/drivers/crypto/nx/nx-842-platform.c
index 664f13dd06ed..5363c72593b4 100644
--- a/drivers/crypto/nx/nx-842-platform.c
+++ b/drivers/crypto/nx/nx-842-platform.c
@@ -53,6 +53,7 @@ void nx842_platform_driver_unset(struct nx842_driver *_driver)
}
EXPORT_SYMBOL_GPL(nx842_platform_driver_unset);
+#if defined(CONFIG_CRYPTO_DEV_NX_COMPRESS_PSERIES_MODULE) ||
defined(CONFIG_CRYPTO_DEV_NX_COMPRESS_POWERNV_MODULE)
bool nx842_platform_driver_get(void)
{
bool ret = false;
@@ -66,7 +67,6 @@ bool nx842_platform_driver_get(void)
return ret;
}
-EXPORT_SYMBOL_GPL(nx842_platform_driver_get);
void nx842_platform_driver_put(void)
{
@@ -77,6 +77,17 @@ void nx842_platform_driver_put(void)
spin_unlock(driver_lock);
}
+#else
+bool nx842_platform_driver_get(void)
+{
+ return true;
+}
+
+void nx842_platform_driver_put(void)
+{
+}
+#endif
+EXPORT_SYMBOL_GPL(nx842_platform_driver_get);
EXPORT_SYMBOL_GPL(nx842_platform_driver_put);
MODULE_LICENSE(GPL);
--
2.1.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
