* [PATCH 0/2] crypto: caam - authenc fixes
From: Horia Geantă @ 2016-08-04 17:02 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto, David S. Miller
The first patch fixes a few typos in the encrypt shared descriptor
used by echainiv(authenc) algorithms.
Second patch fixes the case when .setkey is called before .setauthsize,
avoiding creating authenc descriptors with zero authsize.
Both patches are also being sent to -stable for v4.3+ kernels.
Thanks,
Horia
Horia Geantă (2):
crypto: caam - fix echainiv(authenc) encrypt shared descriptor
crypto: caam - defer aead_set_sh_desc in case of zero authsize
drivers/crypto/caam/caamalg.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
--
2.4.4
^ permalink raw reply
* [PATCHv3 08/11] crypto: omap-aes: Add support for multiple cores
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
Some SoCs like omap4/omap5/dra7 contain multiple AES crypto accelerator
cores. Adapt the driver to support this. The driver picks the last used
device from a list of AES devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: forward ported to 4.7 kernel]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 20 ++++++--------------
1 file changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index f443042..3cf7b8f 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -329,20 +329,12 @@ static void omap_aes_dma_stop(struct omap_aes_dev *dd)
static struct omap_aes_dev *omap_aes_find_dev(struct omap_aes_ctx *ctx)
{
- struct omap_aes_dev *dd = NULL, *tmp;
+ struct omap_aes_dev *dd;
spin_lock_bh(&list_lock);
- if (!ctx->dd) {
- list_for_each_entry(tmp, &dev_list, list) {
- /* FIXME: take fist available aes core */
- dd = tmp;
- break;
- }
- ctx->dd = dd;
- } else {
- /* already found before */
- dd = ctx->dd;
- }
+ dd = list_first_entry(&dev_list, struct omap_aes_dev, list);
+ list_move_tail(&dd->list, &dev_list);
+ ctx->dd = dd;
spin_unlock_bh(&list_lock);
return dd;
@@ -615,7 +607,7 @@ static int omap_aes_prepare_req(struct crypto_engine *engine,
{
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
- struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
+ struct omap_aes_dev *dd = ctx->dd;
struct omap_aes_reqctx *rctx;
if (!dd)
@@ -661,7 +653,7 @@ static int omap_aes_crypt_req(struct crypto_engine *engine,
{
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(
crypto_ablkcipher_reqtfm(req));
- struct omap_aes_dev *dd = omap_aes_find_dev(ctx);
+ struct omap_aes_dev *dd = ctx->dd;
if (!dd)
return -ENODEV;
--
1.9.1
^ permalink raw reply related
* [PATCHv3 04/11] crypto: omap-sham: fix software fallback handling
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
If we have processed any data with the hardware accelerator (digcnt > 0),
we must complete the entire hash by using it. This is because the current
hash value can't be imported to the software fallback algorithm. Otherwise
we end up with wrong hash results.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index aa71e61..b4f5131 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1165,7 +1165,7 @@ static int omap_sham_final(struct ahash_request *req)
* If buffersize is less than 240, we use fallback SW encoding,
* as using DMA + HW in this case doesn't provide any benefit.
*/
- if ((ctx->digcnt + ctx->bufcnt) < 240)
+ if (!ctx->digcnt && ctx->bufcnt < 240)
return omap_sham_final_shash(req);
else if (ctx->bufcnt)
return omap_sham_enqueue(req, OP_FINAL);
--
1.9.1
^ permalink raw reply related
* [PATCHv3 06/11] crypto: omap-des: Fix support for unequal lengths
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel, Lokesh Vutla
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <a0131933@ti.com>
For cases where total length of an input SGs is not same as
length of the input data for encryption, omap-des driver
crashes. This happens in the case when IPsec is trying to use
omap-des driver.
To avoid this, we copy all the pages from the input SG list
into a contiguous buffer and prepare a single element SG list
for this buffer with length as the total bytes to crypt, which is
similar thing that is done in case of unaligned lengths.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Tested-by: Aparna Balasubramanian <aparnab@ti.com>
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-des.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index 5691434..d0b59f6 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -521,29 +521,36 @@ static int omap_des_crypt_dma_stop(struct omap_des_dev *dd)
return 0;
}
-static int omap_des_copy_needed(struct scatterlist *sg)
+static int omap_des_copy_needed(struct scatterlist *sg, int total)
{
+ int len = 0;
+
+ if (!IS_ALIGNED(total, DES_BLOCK_SIZE))
+ return -1;
+
while (sg) {
if (!IS_ALIGNED(sg->offset, 4))
return -1;
if (!IS_ALIGNED(sg->length, DES_BLOCK_SIZE))
return -1;
+
+ len += sg->length;
sg = sg_next(sg);
}
+
+ if (len != total)
+ return -1;
+
return 0;
}
static int omap_des_copy_sgs(struct omap_des_dev *dd)
{
void *buf_in, *buf_out;
- int pages;
-
- pages = dd->total >> PAGE_SHIFT;
-
- if (dd->total & (PAGE_SIZE-1))
- pages++;
+ int pages, total;
- BUG_ON(!pages);
+ total = ALIGN(dd->total, DES_BLOCK_SIZE);
+ pages = get_order(total);
buf_in = (void *)__get_free_pages(GFP_ATOMIC, pages);
buf_out = (void *)__get_free_pages(GFP_ATOMIC, pages);
@@ -605,8 +612,8 @@ static int omap_des_prepare_req(struct crypto_engine *engine,
if (dd->out_sg_len < 0)
return dd->out_sg_len;
- if (omap_des_copy_needed(dd->in_sg) ||
- omap_des_copy_needed(dd->out_sg)) {
+ if (omap_des_copy_needed(dd->in_sg, dd->total) ||
+ omap_des_copy_needed(dd->out_sg, dd->total)) {
if (omap_des_copy_sgs(dd))
pr_err("Failed to copy SGs for unaligned cases\n");
dd->sgs_copied = 1;
--
1.9.1
^ permalink raw reply related
* [PATCHv3 05/11] crypto: omap-sham: fix SW fallback HMAC handling for omap2/omap3
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
If software fallback is used on older hardware accelerator setup (OMAP2/
OMAP3), the first block of data must be purged from the buffer. The
first block contains the pre-generated ipad value required by the HW,
but the software fallback algorithm generates its own, causing wrong
results.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index b4f5131..f9c5fe5 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1145,9 +1145,20 @@ static int omap_sham_final_shash(struct ahash_request *req)
{
struct omap_sham_ctx *tctx = crypto_tfm_ctx(req->base.tfm);
struct omap_sham_reqctx *ctx = ahash_request_ctx(req);
+ int offset = 0;
+
+ /*
+ * If we are running HMAC on limited hardware support, skip
+ * the ipad in the beginning of the buffer if we are going for
+ * software fallback algorithm.
+ */
+ if (test_bit(FLAGS_HMAC, &ctx->flags) &&
+ !test_bit(FLAGS_AUTO_XOR, &ctx->dd->flags))
+ offset = get_block_size(ctx);
return omap_sham_shash_digest(tctx->fallback, req->base.flags,
- ctx->buffer, ctx->bufcnt, req->result);
+ ctx->buffer + offset,
+ ctx->bufcnt - offset, req->result);
}
static int omap_sham_final(struct ahash_request *req)
--
1.9.1
^ permalink raw reply related
* [PATCHv3 11/11] crypto: omap-des: fix crypto engine initialization order
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
The crypto engine must be initialized before registering algorithms,
otherwise the test manager will crash as it attempts to execute
tests for the algos while they are being registered.
Fixes: f1b77aaca85a ("crypto: omap-des - Integrate with the crypto engine framework")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-des.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/omap-des.c b/drivers/crypto/omap-des.c
index d0b59f6..2b07e60 100644
--- a/drivers/crypto/omap-des.c
+++ b/drivers/crypto/omap-des.c
@@ -1085,6 +1085,17 @@ static int omap_des_probe(struct platform_device *pdev)
list_add_tail(&dd->list, &dev_list);
spin_unlock(&list_lock);
+ /* Initialize des crypto engine */
+ dd->engine = crypto_engine_alloc_init(dev, 1);
+ if (!dd->engine)
+ goto err_engine;
+
+ dd->engine->prepare_request = omap_des_prepare_req;
+ dd->engine->crypt_one_request = omap_des_crypt_req;
+ err = crypto_engine_start(dd->engine);
+ if (err)
+ goto err_engine;
+
for (i = 0; i < dd->pdata->algs_info_size; i++) {
for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
algp = &dd->pdata->algs_info[i].algs_list[j];
@@ -1100,27 +1111,18 @@ static int omap_des_probe(struct platform_device *pdev)
}
}
- /* Initialize des crypto engine */
- dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
- goto err_algs;
-
- dd->engine->prepare_request = omap_des_prepare_req;
- dd->engine->crypt_one_request = omap_des_crypt_req;
- err = crypto_engine_start(dd->engine);
- if (err)
- goto err_engine;
-
return 0;
-err_engine:
- crypto_engine_exit(dd->engine);
err_algs:
for (i = dd->pdata->algs_info_size - 1; i >= 0; i--)
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_alg(
&dd->pdata->algs_info[i].algs_list[j]);
+err_engine:
+ if (dd->engine)
+ crypto_engine_exit(dd->engine);
+
omap_des_dma_cleanup(dd);
err_irq:
tasklet_kill(&dd->done_task);
--
1.9.1
^ permalink raw reply related
* [PATCHv3 10/11] crypto: omap-aes: fix crypto engine initialization order
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
The crypto engine must be initialized before registering algorithms,
otherwise the test manager will crash as it attempts to execute
tests for the algos while they are being registered.
Fixes: 0529900a01cb ("crypto: omap-aes - Support crypto engine framework")
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 28 +++++++++++++++-------------
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 6ba4f70..8159523 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -1212,6 +1212,17 @@ static int omap_aes_probe(struct platform_device *pdev)
list_add_tail(&dd->list, &dev_list);
spin_unlock(&list_lock);
+ /* Initialize crypto engine */
+ dd->engine = crypto_engine_alloc_init(dev, 1);
+ if (!dd->engine)
+ goto err_engine;
+
+ dd->engine->prepare_request = omap_aes_prepare_req;
+ dd->engine->crypt_one_request = omap_aes_crypt_req;
+ err = crypto_engine_start(dd->engine);
+ if (err)
+ goto err_engine;
+
for (i = 0; i < dd->pdata->algs_info_size; i++) {
if (!dd->pdata->algs_info[i].registered) {
for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
@@ -1229,26 +1240,17 @@ static int omap_aes_probe(struct platform_device *pdev)
}
}
- /* Initialize crypto engine */
- dd->engine = crypto_engine_alloc_init(dev, 1);
- if (!dd->engine)
- goto err_algs;
-
- dd->engine->prepare_request = omap_aes_prepare_req;
- dd->engine->crypt_one_request = omap_aes_crypt_req;
- err = crypto_engine_start(dd->engine);
- if (err)
- goto err_engine;
-
return 0;
-err_engine:
- crypto_engine_exit(dd->engine);
err_algs:
for (i = dd->pdata->algs_info_size - 1; i >= 0; i--)
for (j = dd->pdata->algs_info[i].registered - 1; j >= 0; j--)
crypto_unregister_alg(
&dd->pdata->algs_info[i].algs_list[j]);
+err_engine:
+ if (dd->engine)
+ crypto_engine_exit(dd->engine);
+
omap_aes_dma_cleanup(dd);
err_irq:
tasklet_kill(&dd->done_task);
--
1.9.1
^ permalink raw reply related
* [PATCHv3 07/11] crypto: omap-aes: use runtime_pm autosuspend for clock handling
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
Calling runtime PM API at the cra_init/exit is bad for power management
purposes, as the lifetime for a CRA can be very long. Instead, use
pm_runtime autosuspend approach for handling the device clocks. Clocks
are enabled when they are actually required, and autosuspend disables
these if they have not been used for a sufficiently long time period.
By default, the timeout value is 1 second.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-aes.c | 43 ++++++++++++++++---------------------------
1 file changed, 16 insertions(+), 27 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 4ab53a6..f443042 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -85,6 +85,8 @@
#define AES_REG_IRQ_DATA_OUT BIT(2)
#define DEFAULT_TIMEOUT (5*HZ)
+#define DEFAULT_AUTOSUSPEND_DELAY 1000
+
#define FLAGS_MODE_MASK 0x000f
#define FLAGS_ENCRYPT BIT(0)
#define FLAGS_CBC BIT(1)
@@ -238,11 +240,19 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, u32 offset,
static int omap_aes_hw_init(struct omap_aes_dev *dd)
{
+ int err;
+
if (!(dd->flags & FLAGS_INIT)) {
dd->flags |= FLAGS_INIT;
dd->err = 0;
}
+ err = pm_runtime_get_sync(dd->dev);
+ if (err < 0) {
+ dev_err(dd->dev, "failed to get sync: %d\n", err);
+ return err;
+ }
+
return 0;
}
@@ -520,6 +530,9 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd, int err)
pr_debug("err: %d\n", err);
crypto_finalize_request(dd->engine, req, err);
+
+ pm_runtime_mark_last_busy(dd->dev);
+ pm_runtime_put_autosuspend(dd->dev);
}
static int omap_aes_crypt_dma_stop(struct omap_aes_dev *dd)
@@ -761,23 +774,6 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request *req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
- struct omap_aes_dev *dd = NULL;
- int err;
-
- /* Find AES device, currently picks the first device */
- spin_lock_bh(&list_lock);
- list_for_each_entry(dd, &dev_list, list) {
- break;
- }
- spin_unlock_bh(&list_lock);
-
- err = pm_runtime_get_sync(dd->dev);
- if (err < 0) {
- dev_err(dd->dev, "%s: failed to get_sync(%d)\n",
- __func__, err);
- return err;
- }
-
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -785,16 +781,6 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
- struct omap_aes_dev *dd = NULL;
-
- /* Find AES device, currently picks the first device */
- spin_lock_bh(&list_lock);
- list_for_each_entry(dd, &dev_list, list) {
- break;
- }
- spin_unlock_bh(&list_lock);
-
- pm_runtime_put_sync(dd->dev);
}
/* ********************** ALGS ************************************ */
@@ -1140,6 +1126,9 @@ static int omap_aes_probe(struct platform_device *pdev)
}
dd->phys_base = res.start;
+ pm_runtime_use_autosuspend(dev);
+ pm_runtime_set_autosuspend_delay(dev, DEFAULT_AUTOSUSPEND_DELAY);
+
pm_runtime_enable(dev);
err = pm_runtime_get_sync(dev);
if (err < 0) {
--
1.9.1
^ permalink raw reply related
* [PATCHv3 09/11] crypto: omap-aes: Add fallback support
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
From: Lokesh Vutla <lokeshvutla@ti.com>
As setting up the DMA operations is quite costly, add software fallback
support for requests smaller than 200 bytes. This change gives some 10%
extra performance in ipsec use case.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
[t-kristo@ti.com: udpated against latest upstream, to use skcipher mainly]
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/Kconfig | 3 +++
drivers/crypto/omap-aes.c | 53 +++++++++++++++++++++++++++++++++++++++++++----
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 1af94e2..19ee6ee 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -318,6 +318,9 @@ config CRYPTO_DEV_OMAP_AES
select CRYPTO_AES
select CRYPTO_BLKCIPHER
select CRYPTO_ENGINE
+ select CRYPTO_CBC
+ select CRYPTO_ECB
+ select CRYPTO_CTR
help
OMAP processors have AES module accelerator. Select this if you
want to use the OMAP module for AES algorithms.
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 3cf7b8f..6ba4f70 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -35,7 +35,7 @@
#include <linux/interrupt.h>
#include <crypto/scatterwalk.h>
#include <crypto/aes.h>
-#include <crypto/algapi.h>
+#include <crypto/internal/skcipher.h>
#define DST_MAXBURST 4
#define DMA_MIN (DST_MAXBURST * sizeof(u32))
@@ -105,6 +105,7 @@ struct omap_aes_ctx {
int keylen;
u32 key[AES_KEYSIZE_256 / sizeof(u32)];
unsigned long flags;
+ struct crypto_skcipher *fallback;
};
struct omap_aes_reqctx {
@@ -701,11 +702,29 @@ static int omap_aes_crypt(struct ablkcipher_request *req, unsigned long mode)
crypto_ablkcipher_reqtfm(req));
struct omap_aes_reqctx *rctx = ablkcipher_request_ctx(req);
struct omap_aes_dev *dd;
+ int ret;
pr_debug("nbytes: %d, enc: %d, cbc: %d\n", req->nbytes,
!!(mode & FLAGS_ENCRYPT),
!!(mode & FLAGS_CBC));
+ if (req->nbytes < 200) {
+ SKCIPHER_REQUEST_ON_STACK(subreq, ctx->fallback);
+
+ skcipher_request_set_tfm(subreq, ctx->fallback);
+ skcipher_request_set_callback(subreq, req->base.flags, NULL,
+ NULL);
+ skcipher_request_set_crypt(subreq, req->src, req->dst,
+ req->nbytes, req->info);
+
+ if (mode & FLAGS_ENCRYPT)
+ ret = crypto_skcipher_encrypt(subreq);
+ else
+ ret = crypto_skcipher_decrypt(subreq);
+
+ skcipher_request_zero(subreq);
+ return ret;
+ }
dd = omap_aes_find_dev(ctx);
if (!dd)
return -ENODEV;
@@ -721,6 +740,7 @@ static int omap_aes_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
unsigned int keylen)
{
struct omap_aes_ctx *ctx = crypto_ablkcipher_ctx(tfm);
+ int ret;
if (keylen != AES_KEYSIZE_128 && keylen != AES_KEYSIZE_192 &&
keylen != AES_KEYSIZE_256)
@@ -731,6 +751,14 @@ static int omap_aes_setkey(struct crypto_ablkcipher *tfm, const u8 *key,
memcpy(ctx->key, key, keylen);
ctx->keylen = keylen;
+ crypto_skcipher_clear_flags(ctx->fallback, CRYPTO_TFM_REQ_MASK);
+ crypto_skcipher_set_flags(ctx->fallback, tfm->base.crt_flags &
+ CRYPTO_TFM_REQ_MASK);
+
+ ret = crypto_skcipher_setkey(ctx->fallback, key, keylen);
+ if (!ret)
+ return 0;
+
return 0;
}
@@ -766,6 +794,17 @@ static int omap_aes_ctr_decrypt(struct ablkcipher_request *req)
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
+ const char *name = crypto_tfm_alg_name(tfm);
+ const u32 flags = CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK;
+ struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
+ struct crypto_skcipher *blk;
+
+ blk = crypto_alloc_skcipher(name, 0, flags);
+ if (IS_ERR(blk))
+ return PTR_ERR(blk);
+
+ ctx->fallback = blk;
+
tfm->crt_ablkcipher.reqsize = sizeof(struct omap_aes_reqctx);
return 0;
@@ -773,6 +812,12 @@ static int omap_aes_cra_init(struct crypto_tfm *tfm)
static void omap_aes_cra_exit(struct crypto_tfm *tfm)
{
+ struct omap_aes_ctx *ctx = crypto_tfm_ctx(tfm);
+
+ if (ctx->fallback)
+ crypto_free_skcipher(ctx->fallback);
+
+ ctx->fallback = NULL;
}
/* ********************** ALGS ************************************ */
@@ -784,7 +829,7 @@ static struct crypto_alg algs_ecb_cbc[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
@@ -806,7 +851,7 @@ static struct crypto_alg algs_ecb_cbc[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
@@ -832,7 +877,7 @@ static struct crypto_alg algs_ctr[] = {
.cra_priority = 300,
.cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
CRYPTO_ALG_KERN_DRIVER_ONLY |
- CRYPTO_ALG_ASYNC,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct omap_aes_ctx),
.cra_alignmask = 0,
--
1.9.1
^ permalink raw reply related
* [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
Context export/import are now required for ahash algorithms due to
required support in algif_hash. Implement these for OMAP SHA driver,
saving and restoring the internal state of the driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 31 +++++++++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 6e53944..aa71e61 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1379,6 +1379,27 @@ exit_unlock:
return ret;
}
+static int omap_sham_export(struct ahash_request *req, void *out)
+{
+ struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
+
+ while (omap_sham_flush(req) == -EINPROGRESS)
+ msleep(10);
+
+ memcpy(out, rctx, sizeof(*rctx) + SHA512_BLOCK_SIZE);
+
+ return 0;
+}
+
+static int omap_sham_import(struct ahash_request *req, const void *in)
+{
+ struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
+
+ memcpy(rctx, in, sizeof(*rctx) + SHA512_BLOCK_SIZE);
+
+ return 0;
+}
+
static struct ahash_alg algs_sha1_md5[] = {
{
.init = omap_sham_init,
@@ -2037,8 +2058,14 @@ static int omap_sham_probe(struct platform_device *pdev)
for (i = 0; i < dd->pdata->algs_info_size; i++) {
for (j = 0; j < dd->pdata->algs_info[i].size; j++) {
- err = crypto_register_ahash(
- &dd->pdata->algs_info[i].algs_list[j]);
+ struct ahash_alg *alg;
+
+ alg = &dd->pdata->algs_info[i].algs_list[j];
+ alg->export = omap_sham_export;
+ alg->import = omap_sham_import;
+ alg->halg.statesize = sizeof(struct omap_sham_reqctx) +
+ SHA512_BLOCK_SIZE;
+ err = crypto_register_ahash(alg);
if (err)
goto err_algs;
--
1.9.1
^ permalink raw reply related
* [PATCHv3 02/11] crypto: omap-sham: add support for flushing the buffer
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
This flushes any full blocks of data from the data buffer. Required for
implementing the export/import APIs for the driver, as the flush allows
saving a much smaller context; basically only one block of buffer is
required.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 60 ++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 55 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index fd50005..6e53944 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -112,6 +112,7 @@
#define FLAGS_DMA_READY 6
#define FLAGS_AUTO_XOR 7
#define FLAGS_BE32_SHA1 8
+#define FLAGS_FLUSH 9
/* context flags */
#define FLAGS_FINUP 16
#define FLAGS_SG 17
@@ -996,15 +997,16 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
ctx->flags |= BIT(FLAGS_ERROR);
}
- /* atomic operation is not needed here */
- dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
- BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY));
-
pm_runtime_mark_last_busy(dd->dev);
pm_runtime_put_autosuspend(dd->dev);
- if (req->base.complete)
+ if (!test_bit(FLAGS_FLUSH, &dd->flags) && req->base.complete)
req->base.complete(&req->base, err);
+
+ /* atomic operation is not needed here */
+ dd->flags &= ~(BIT(FLAGS_BUSY) | BIT(FLAGS_FINAL) | BIT(FLAGS_CPU) |
+ BIT(FLAGS_DMA_READY) | BIT(FLAGS_OUTPUT_READY) |
+ BIT(FLAGS_FLUSH));
}
static int omap_sham_handle_queue(struct omap_sham_dev *dd,
@@ -1329,6 +1331,54 @@ static void omap_sham_cra_exit(struct crypto_tfm *tfm)
}
}
+static int omap_sham_flush(struct ahash_request *req)
+{
+ struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
+ struct omap_sham_dev *dd = rctx->dd;
+ int ret, len, bs;
+ unsigned long flags;
+
+ bs = get_block_size(rctx);
+
+ len = rctx->bufcnt / bs * bs;
+
+ spin_lock_irqsave(&dd->lock, flags);
+
+ if (test_bit(FLAGS_BUSY, &dd->flags)) {
+ ret = -EINPROGRESS;
+ goto exit_unlock;
+ }
+
+ if (!len) {
+ ret = 0;
+ goto exit_unlock;
+ }
+
+ set_bit(FLAGS_BUSY, &dd->flags);
+
+ spin_unlock_irqrestore(&dd->lock, flags);
+
+ rctx->total = 0;
+
+ ret = omap_sham_hw_init(dd);
+ if (ret)
+ goto exit_unlock;
+
+ set_bit(FLAGS_FLUSH, &dd->flags);
+
+ ret = omap_sham_xmit_cpu(dd, rctx->buffer, len, 0);
+ if (ret == -EINPROGRESS) {
+ memcpy(rctx->buffer, rctx->buffer + len, rctx->bufcnt - len);
+ rctx->bufcnt -= len;
+ }
+
+ return ret;
+
+exit_unlock:
+ spin_unlock_irqrestore(&dd->lock, flags);
+ return ret;
+}
+
static struct ahash_alg algs_sha1_md5[] = {
{
.init = omap_sham_init,
--
1.9.1
^ permalink raw reply related
* [PATCHv3 01/11] crypto: omap-sham: avoid executing tasklet where not needed
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
In-Reply-To: <1470306526-27219-1-git-send-email-t-kristo@ti.com>
Some of the call paths of OMAP SHA driver can avoid executing the next
step of the crypto queue under tasklet; instead, execute the next step
directly via function call. This avoids a costly round-trip via the
scheduler giving a slight performance boost.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/crypto/omap-sham.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
index 7fe4eef..fd50005 100644
--- a/drivers/crypto/omap-sham.c
+++ b/drivers/crypto/omap-sham.c
@@ -1005,9 +1005,6 @@ static void omap_sham_finish_req(struct ahash_request *req, int err)
if (req->base.complete)
req->base.complete(&req->base, err);
-
- /* handle new request */
- tasklet_schedule(&dd->done_task);
}
static int omap_sham_handle_queue(struct omap_sham_dev *dd,
@@ -1018,6 +1015,7 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd,
unsigned long flags;
int err = 0, ret = 0;
+retry:
spin_lock_irqsave(&dd->lock, flags);
if (req)
ret = ahash_enqueue_request(&dd->queue, req);
@@ -1061,11 +1059,19 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd,
err = omap_sham_final_req(dd);
}
err1:
- if (err != -EINPROGRESS)
+ dev_dbg(dd->dev, "exit, err: %d\n", err);
+
+ if (err != -EINPROGRESS) {
/* done_task will not finish it, so do it here */
omap_sham_finish_req(req, err);
+ req = NULL;
- dev_dbg(dd->dev, "exit, err: %d\n", err);
+ /*
+ * Execute next request immediately if there is anything
+ * in queue.
+ */
+ goto retry;
+ }
return ret;
}
@@ -1653,6 +1659,10 @@ finish:
dev_dbg(dd->dev, "update done: err: %d\n", err);
/* finish curent request */
omap_sham_finish_req(dd->req, err);
+
+ /* If we are not busy, process next req */
+ if (!test_bit(FLAGS_BUSY, &dd->flags))
+ omap_sham_handle_queue(dd, NULL);
}
static irqreturn_t omap_sham_irq_common(struct omap_sham_dev *dd)
--
1.9.1
^ permalink raw reply related
* [PATCHv3 00/11] crypto: omap HW crypto fixes
From: Tero Kristo @ 2016-08-04 10:28 UTC (permalink / raw)
To: herbert, lokeshvutla, davem, linux-crypto, tony, linux-omap
Cc: linux-arm-kernel
Hi,
This revision took quite a bit time to craft due to the rework needed
for sham buffer handling and export/import. I ended up implementing
a flush functionality for draining out the sham buffer when doing
export/import; just shrinking the buffer to sufficiently small size
impacted the performance with small data chunks too much so I dropped
this approach.
The series also fixes a couple of existing issues with omap2/omap3
hardware acceleration, I ran a full boot test / crypto manager
test suite on all boards accessible to me now.
Based on top of latest mainline, which is somewhere before 4.8-rc1
as of writing this, I am unable to rebase the series during the next
three weeks so wanted to get this out now. Targeted for 4.9 merge
window, some fixes could be picked up earlier though if needed.
-Tero
^ permalink raw reply
* Re: [PATCH] crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading
From: Anton Blanchard @ 2016-08-04 10:26 UTC (permalink / raw)
To: Michael Ellerman
Cc: herbert, paulus, linux-crypto, alastair, linuxppc-dev, davem
In-Reply-To: <87lh0dexp3.fsf@concordia.ellerman.id.au>
Hi Michael,
> Is VEC_CRYPTO the right feature?
>
> That's new power8 crypto stuff.
The vpmsum* instructions are part of the same pipeline as the vcipher*
instructions, introduced in POWER8.
> I thought this only used VMX? (but I haven't looked closely)
Yes, vcipher* and vpmsum* are VMX instructions.
Anton
^ permalink raw reply
* Re: [PATCH] crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading
From: Michael Ellerman @ 2016-08-04 8:38 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, herbert, davem
Cc: linuxppc-dev, linux-crypto, alastair
In-Reply-To: <1470292695-9829-1-git-send-email-anton@ozlabs.org>
Anton Blanchard <anton@ozlabs.org> writes:
> From: Anton Blanchard <anton@samba.org>
>
> This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
> to automatically load the crc32c-vpmsum module if the CPU supports
> it.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> ---
> arch/powerpc/crypto/crc32c-vpmsum_glue.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/crypto/crc32c-vpmsum_glue.c b/arch/powerpc/crypto/crc32c-vpmsum_glue.c
> index bfe3d37..9fa046d 100644
> --- a/arch/powerpc/crypto/crc32c-vpmsum_glue.c
> +++ b/arch/powerpc/crypto/crc32c-vpmsum_glue.c
> @@ -4,6 +4,7 @@
> #include <linux/module.h>
> #include <linux/string.h>
> #include <linux/kernel.h>
> +#include <linux/cpufeature.h>
> #include <asm/switch_to.h>
>
> #define CHKSUM_BLOCK_SIZE 1
> @@ -157,7 +158,7 @@ static void __exit crc32c_vpmsum_mod_fini(void)
> crypto_unregister_shash(&alg);
> }
>
> -module_init(crc32c_vpmsum_mod_init);
> +module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, crc32c_vpmsum_mod_init);
Is VEC_CRYPTO the right feature?
That's new power8 crypto stuff.
I thought this only used VMX? (but I haven't looked closely)
cheers
^ permalink raw reply
* [PATCH] crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading
From: Anton Blanchard @ 2016-08-04 6:38 UTC (permalink / raw)
To: benh, paulus, mpe, herbert, davem; +Cc: alastair, linuxppc-dev, linux-crypto
From: Anton Blanchard <anton@samba.org>
This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
to automatically load the crc32c-vpmsum module if the CPU supports
it.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
arch/powerpc/crypto/crc32c-vpmsum_glue.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/crypto/crc32c-vpmsum_glue.c b/arch/powerpc/crypto/crc32c-vpmsum_glue.c
index bfe3d37..9fa046d 100644
--- a/arch/powerpc/crypto/crc32c-vpmsum_glue.c
+++ b/arch/powerpc/crypto/crc32c-vpmsum_glue.c
@@ -4,6 +4,7 @@
#include <linux/module.h>
#include <linux/string.h>
#include <linux/kernel.h>
+#include <linux/cpufeature.h>
#include <asm/switch_to.h>
#define CHKSUM_BLOCK_SIZE 1
@@ -157,7 +158,7 @@ static void __exit crc32c_vpmsum_mod_fini(void)
crypto_unregister_shash(&alg);
}
-module_init(crc32c_vpmsum_mod_init);
+module_cpu_feature_match(PPC_MODULE_FEATURE_VEC_CRYPTO, crc32c_vpmsum_mod_init);
module_exit(crc32c_vpmsum_mod_fini);
MODULE_AUTHOR("Anton Blanchard <anton@samba.org>");
--
2.7.4
^ permalink raw reply related
* nopea Lainat
From: varainhoitoelimen @ 2016-08-02 21:52 UTC (permalink / raw)
To: Recipients
Apply for a loan at 2% reply to this Email for more Info
Hae lainaa 2% vastausta tähän viestiin lisätietoja
^ permalink raw reply
* [PATCH] crypto: sha3 - Add missing ULL suffixes for 64-bit constants
From: Geert Uytterhoeven @ 2016-08-03 17:37 UTC (permalink / raw)
To: Jeff Garzik, Raveendra Padasalagi, Herbert Xu, David S. Miller
Cc: linux-crypto, linux-kernel, Geert Uytterhoeven
On 32-bit (e.g. with m68k-linux-gnu-gcc-4.1):
crypto/sha3_generic.c:27: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:28: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:29: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:29: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:31: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:31: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:32: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:32: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:32: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:33: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:33: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:34: warning: integer constant is too large for ‘long’ type
crypto/sha3_generic.c:34: warning: integer constant is too large for ‘long’ type
Fixes: 53964b9ee63b7075 ("crypto: sha3 - Add SHA-3 hash algorithm")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
crypto/sha3_generic.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
index 62264397a2d28636..7e8ed96236cefa79 100644
--- a/crypto/sha3_generic.c
+++ b/crypto/sha3_generic.c
@@ -24,14 +24,14 @@
#define ROTL64(x, y) (((x) << (y)) | ((x) >> (64 - (y))))
static const u64 keccakf_rndc[24] = {
- 0x0000000000000001, 0x0000000000008082, 0x800000000000808a,
- 0x8000000080008000, 0x000000000000808b, 0x0000000080000001,
- 0x8000000080008081, 0x8000000000008009, 0x000000000000008a,
- 0x0000000000000088, 0x0000000080008009, 0x000000008000000a,
- 0x000000008000808b, 0x800000000000008b, 0x8000000000008089,
- 0x8000000000008003, 0x8000000000008002, 0x8000000000000080,
- 0x000000000000800a, 0x800000008000000a, 0x8000000080008081,
- 0x8000000000008080, 0x0000000080000001, 0x8000000080008008
+ 0x0000000000000001ULL, 0x0000000000008082ULL, 0x800000000000808aULL,
+ 0x8000000080008000ULL, 0x000000000000808bULL, 0x0000000080000001ULL,
+ 0x8000000080008081ULL, 0x8000000000008009ULL, 0x000000000000008aULL,
+ 0x0000000000000088ULL, 0x0000000080008009ULL, 0x000000008000000aULL,
+ 0x000000008000808bULL, 0x800000000000008bULL, 0x8000000000008089ULL,
+ 0x8000000000008003ULL, 0x8000000000008002ULL, 0x8000000000000080ULL,
+ 0x000000000000800aULL, 0x800000008000000aULL, 0x8000000080008081ULL,
+ 0x8000000000008080ULL, 0x0000000080000001ULL, 0x8000000080008008ULL
};
static const int keccakf_rotc[24] = {
--
1.9.1
^ permalink raw reply related
* [PATCH 0100/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:40 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg, gregkh, hpa, x86
Cc: linux-crypto, linux-kernel, mpm, herbert, jslaby, peter,
lee.jones, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/char/hw_random/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c
index 9203f2d..09dce37 100644
--- a/drivers/char/hw_random/core.c
+++ b/drivers/char/hw_random/core.c
@@ -63,10 +63,10 @@ static u8 *rng_buffer, *rng_fillbuf;
static unsigned short current_quality;
static unsigned short default_quality; /* = 0; default to "off" */
-module_param(current_quality, ushort, 0644);
+module_param(current_quality, ushort, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(current_quality,
"current hwrng entropy estimation per mill");
-module_param(default_quality, ushort, 0644);
+module_param(default_quality, ushort, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(default_quality,
"default entropy content of hwrng per mill");
--
2.9.2
^ permalink raw reply related
* [PATCH 0040/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:36 UTC (permalink / raw)
To: herbert, davem, hpa, x86
Cc: linux-crypto, linux-kernel, chuansheng.liu, baolex.ni, travis
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
crypto/testmgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c727fb0..528e54e 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -36,7 +36,7 @@
#include "internal.h"
static bool notests;
-module_param(notests, bool, 0644);
+module_param(notests, bool, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(notests, "disable crypto self-tests");
#ifdef CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
--
2.9.2
^ permalink raw reply related
* [PATCH 0130/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:42 UTC (permalink / raw)
To: jamie, herbert, davem, hpa, x86
Cc: peter, linux-kernel, baolex.ni, linux-crypto, chuansheng.liu,
lee.jones, linux-arm-kernel
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/crypto/picoxcell_crypto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/picoxcell_crypto.c b/drivers/crypto/picoxcell_crypto.c
index 3b1c7ec..e535d10 100644
--- a/drivers/crypto/picoxcell_crypto.c
+++ b/drivers/crypto/picoxcell_crypto.c
@@ -1224,7 +1224,7 @@ static ssize_t spacc_stat_irq_thresh_store(struct device *dev,
return len;
}
-static DEVICE_ATTR(stat_irq_thresh, 0644, spacc_stat_irq_thresh_show,
+static DEVICE_ATTR(stat_irq_thresh, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH, spacc_stat_irq_thresh_show,
spacc_stat_irq_thresh_store);
static struct spacc_alg ipsec_engine_algs[] = {
--
2.9.2
^ permalink raw reply related
* [PATCH 0129/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:42 UTC (permalink / raw)
To: boris.brezillon, arno, herbert, davem, hpa, x86
Cc: linux-crypto, linux-kernel, chuansheng.liu, baolex.ni, jslaby,
peter, lee.jones
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/crypto/marvell/cesa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index e8ef9fd..5edbcc4 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -32,7 +32,7 @@
#include "cesa.h"
static int allhwsupport = !IS_ENABLED(CONFIG_CRYPTO_DEV_MV_CESA);
-module_param_named(allhwsupport, allhwsupport, int, 0444);
+module_param_named(allhwsupport, allhwsupport, int, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(allhwsupport, "Enable support for all hardware (even it if overlaps with the mv_cesa driver)");
struct mv_cesa_dev *cesa_dev;
--
2.9.2
^ permalink raw reply related
* [PATCH 0128/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:42 UTC (permalink / raw)
To: herbert, davem, hpa, x86
Cc: linux-crypto, linux-kernel, chuansheng.liu, baolex.ni, jslaby,
peter, lee.jones
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/crypto/hifn_795x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/hifn_795x.c b/drivers/crypto/hifn_795x.c
index eee2c7e..dfcaa29 100644
--- a/drivers/crypto/hifn_795x.c
+++ b/drivers/crypto/hifn_795x.c
@@ -33,7 +33,7 @@
#include <crypto/des.h>
static char hifn_pll_ref[sizeof("extNNN")] = "ext";
-module_param_string(hifn_pll_ref, hifn_pll_ref, sizeof(hifn_pll_ref), 0444);
+module_param_string(hifn_pll_ref, hifn_pll_ref, sizeof(hifn_pll_ref), S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(hifn_pll_ref,
"PLL reference clock (pci[freq] or ext[freq], default ext)");
--
2.9.2
^ permalink raw reply related
* [PATCH 0127/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:42 UTC (permalink / raw)
To: thomas.lendacky, gary.hook, herbert, davem, hpa, x86
Cc: linux-crypto, linux-kernel, chuansheng.liu, baolex.ni, jslaby,
peter, lee.jones
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
drivers/crypto/ccp/ccp-crypto-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c b/drivers/crypto/ccp/ccp-crypto-main.c
index e0380e5..34e130c 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -26,11 +26,11 @@ MODULE_VERSION("1.0.0");
MODULE_DESCRIPTION("AMD Cryptographic Coprocessor crypto API support");
static unsigned int aes_disable;
-module_param(aes_disable, uint, 0444);
+module_param(aes_disable, uint, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(aes_disable, "Disable use of AES - any non-zero value");
static unsigned int sha_disable;
-module_param(sha_disable, uint, 0444);
+module_param(sha_disable, uint, S_IRUSR | S_IRGRP | S_IROTH);
MODULE_PARM_DESC(sha_disable, "Disable use of SHA - any non-zero value");
/* List heads for the supported algorithms */
--
2.9.2
^ permalink raw reply related
* [PATCH 0020/1285] Replace numeric parameter like 0444 with macro
From: Baole Ni @ 2016-08-02 10:34 UTC (permalink / raw)
To: herbert, davem, schwidefsky, heiko.carstens
Cc: linux-crypto, linux-s390, linux-kernel, chuansheng.liu, baolex.ni
I find that the developers often just specified the numeric value
when calling a macro which is defined with a parameter for access permission.
As we know, these numeric value for access permission have had the corresponding macro,
and that using macro can improve the robustness and readability of the code,
thus, I suggest replacing the numeric parameter with the macro.
Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
Signed-off-by: Baole Ni <baolex.ni@intel.com>
---
arch/s390/crypto/prng.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/s390/crypto/prng.c b/arch/s390/crypto/prng.c
index 41527b1..dc2342e 100644
--- a/arch/s390/crypto/prng.c
+++ b/arch/s390/crypto/prng.c
@@ -678,7 +678,7 @@ static ssize_t prng_chunksize_show(struct device *dev,
{
return snprintf(buf, PAGE_SIZE, "%u\n", prng_chunk_size);
}
-static DEVICE_ATTR(chunksize, 0444, prng_chunksize_show, NULL);
+static DEVICE_ATTR(chunksize, S_IRUSR | S_IRGRP | S_IROTH, prng_chunksize_show, NULL);
/* counter attribute (ro) */
static ssize_t prng_counter_show(struct device *dev,
@@ -697,7 +697,7 @@ static ssize_t prng_counter_show(struct device *dev,
return snprintf(buf, PAGE_SIZE, "%llu\n", counter);
}
-static DEVICE_ATTR(byte_counter, 0444, prng_counter_show, NULL);
+static DEVICE_ATTR(byte_counter, S_IRUSR | S_IRGRP | S_IROTH, prng_counter_show, NULL);
/* errorflag attribute (ro) */
static ssize_t prng_errorflag_show(struct device *dev,
@@ -706,7 +706,7 @@ static ssize_t prng_errorflag_show(struct device *dev,
{
return snprintf(buf, PAGE_SIZE, "%d\n", prng_errorflag);
}
-static DEVICE_ATTR(errorflag, 0444, prng_errorflag_show, NULL);
+static DEVICE_ATTR(errorflag, S_IRUSR | S_IRGRP | S_IROTH, prng_errorflag_show, NULL);
/* mode attribute (ro) */
static ssize_t prng_mode_show(struct device *dev,
@@ -718,7 +718,7 @@ static ssize_t prng_mode_show(struct device *dev,
else
return snprintf(buf, PAGE_SIZE, "SHA512\n");
}
-static DEVICE_ATTR(mode, 0444, prng_mode_show, NULL);
+static DEVICE_ATTR(mode, S_IRUSR | S_IRGRP | S_IROTH, prng_mode_show, NULL);
/* reseed attribute (w) */
static ssize_t prng_reseed_store(struct device *dev,
@@ -732,7 +732,7 @@ static ssize_t prng_reseed_store(struct device *dev,
return count;
}
-static DEVICE_ATTR(reseed, 0200, NULL, prng_reseed_store);
+static DEVICE_ATTR(reseed, S_IWUSR, NULL, prng_reseed_store);
/* reseed limit attribute (rw) */
static ssize_t prng_reseed_limit_show(struct device *dev,
@@ -762,7 +762,7 @@ static ssize_t prng_reseed_limit_store(struct device *dev,
return count;
}
-static DEVICE_ATTR(reseed_limit, 0644,
+static DEVICE_ATTR(reseed_limit, S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH,
prng_reseed_limit_show, prng_reseed_limit_store);
/* strength attribute (ro) */
@@ -772,7 +772,7 @@ static ssize_t prng_strength_show(struct device *dev,
{
return snprintf(buf, PAGE_SIZE, "256\n");
}
-static DEVICE_ATTR(strength, 0444, prng_strength_show, NULL);
+static DEVICE_ATTR(strength, S_IRUSR | S_IRGRP | S_IROTH, prng_strength_show, NULL);
static struct attribute *prng_sha512_dev_attrs[] = {
&dev_attr_errorflag.attr,
--
2.9.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox