[PATCH -next] crypto: hisilicon - Make function sec_send_request() static
Fixes the following sparse warning:
drivers/crypto/hisilicon/sec/sec_algs.c:396:5: warning:
symbol 'sec_send_request' was not declared. Should it be static?
Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
Signed-off-by: Wei Yongjun
---
drivers/crypto/hisilicon/sec/sec_algs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/hisilicon/sec/sec_algs.c
b/drivers/crypto/hisilicon/sec/sec_algs.c
index d69d3ce..03ba1df 100644
--- a/drivers/crypto/hisilicon/sec/sec_algs.c
+++ b/drivers/crypto/hisilicon/sec/sec_algs.c
@@ -393,7 +393,8 @@ static void sec_alg_free_el(struct sec_request_el *el,
}
/* queuelock must be held */
-int sec_send_request(struct sec_request *sec_req, struct sec_queue *queue)
+static int sec_send_request(struct sec_request *sec_req,
+ struct sec_queue *queue)
{
struct sec_request_el *el, *temp;
int ret = 0;
[PATCH] crypto: arm64/sm4-ce - check for the right CPU feature bit
ARMv8.2 specifies special instructions for the SM3 cryptographic hash and the SM4 symmetric cipher. While it is unlikely that a core would implement one and not the other, we should only use SM4 instructions if the SM4 CPU feature bit is set, and we currently check the SM3 feature bit instead. So fix that. Signed-off-by: Ard Biesheuvel --- It would be good to get this backported to -stable but there is no need to merge this as a fix at -rc8 arch/arm64/crypto/sm4-ce-glue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/crypto/sm4-ce-glue.c b/arch/arm64/crypto/sm4-ce-glue.c index b7fb5274b250..0c4fc223f225 100644 --- a/arch/arm64/crypto/sm4-ce-glue.c +++ b/arch/arm64/crypto/sm4-ce-glue.c @@ -69,5 +69,5 @@ static void __exit sm4_ce_mod_fini(void) crypto_unregister_alg(_ce_alg); } -module_cpu_feature_match(SM3, sm4_ce_mod_init); +module_cpu_feature_match(SM4, sm4_ce_mod_init); module_exit(sm4_ce_mod_fini); -- 2.18.0
Re: [RESEND PATCH 2/2] crypto: caam - Support deferred probing in JR dependent drivers
On 8/7/2018 11:00 AM, Marcin Niestroj wrote:
> It is possible, that caam_jr_alloc() is called before JR devices are
> probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
> they are probed at later stage.
>
These drivers don't have a probe() callback.
Returning -EPROBE_DEFER in module's init() (caamrng) or crypto algorithm's
init() (caamalg etc.) callbacks is not going to help, they won't be called
later.
Does adding request_module("caam_jr") in module's init() solve the issue?
Regards,
Horia
[RESEND PATCH 0/2] crypto: caam - Support deferred probing of JR dependend drivers
Hi, I'm resending patch series, as I forgot to CC linux-crypto list. This patch series fixes/improves CAAM JR dependent drivers initialization. So far successful initialization depended on link and device-tree nodes order. These changes make sure all drivers that use JRs (i.e. call caam_jr_alloc() function) return -EPROBE_DEFER whem JRs are not yet available (initialized). Patches were developed and tested on v4.18-rc8. Marcin Niestroj (2): crypto: caam/jr - Fix race by statically initializing global data crypto: caam - Support deferred probing in JR dependent drivers drivers/crypto/caam/caamalg.c| 3 +++ drivers/crypto/caam/caamalg_qi.c | 3 +++ drivers/crypto/caam/caamhash.c | 3 +++ drivers/crypto/caam/caampkc.c| 3 +++ drivers/crypto/caam/caamrng.c| 3 +++ drivers/crypto/caam/jr.c | 20 +--- 6 files changed, 20 insertions(+), 15 deletions(-) -- 2.18.0
Re: [RFC PATCH cryptodev] crypto: sec_send_request() can be static
On Sat, Aug 04, 2018 at 06:21:01AM +0800, kbuild test robot wrote:
>
> Fixes: 915e4e8413da ("crypto: hisilicon - SEC security accelerator driver")
> Signed-off-by: kbuild test robot
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH 0/2] crypto: arm64/ghash-ce - performance improvements
On Sat, Aug 04, 2018 at 08:46:23PM +0200, Ard Biesheuvel wrote: > Another bit of performance work on the GHASH driver: this time it is not > the combined AES/GCM algorithm but the bare GHASH driver that gets updated. > > Even though ARM cores that implement the polynomical multiplication > instructions that these routines depend on are guaranteed to also support > the AES instructions, and can thus use the AES/GCM driver, there could > be reasons to use the accelerated GHASH in isolation, e.g., with another > symmetric blockcipher, with a faster h/w accelerator, or potentially with > an accelerator that does not expose the AES key to the OS. > > The resulting code runs at 1.1 cycles per byte on Cortex-A53 (down from > 2.4 cycles per byte) > > Ard Biesheuvel (2): > crypto: arm64/ghash-ce - replace NEON yield check with block limit > crypto: arm64/ghash-ce - implement 4-way aggregation > > arch/arm64/crypto/ghash-ce-core.S | 153 ++-- > arch/arm64/crypto/ghash-ce-glue.c | 87 ++- > 2 files changed, 161 insertions(+), 79 deletions(-) All applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: [PATCH v2] crypto: x86/aegis,morus - Fix and simplify CPUID checks
On Fri, Aug 03, 2018 at 01:37:50PM +0200, Ondrej Mosnacek wrote:
> It turns out I had misunderstood how the x86_match_cpu() function works.
> It evaluates a logical OR of the matching conditions, not logical AND.
> This caused the CPU feature checks for AEGIS to pass even if only SSE2
> (but not AES-NI) was supported (or vice versa), leading to potential
> crashes if something tried to use the registered algs.
>
> This patch switches the checks to a simpler method that is used e.g. in
> the Camellia x86 code.
>
> The patch also removes the MODULE_DEVICE_TABLE declarations which
> actually seem to cause the modules to be auto-loaded at boot, which is
> not desired. The crypto API on-demand module loading is sufficient.
>
> Fixes: 1d373d4e8e15 ("crypto: x86 - Add optimized AEGIS implementations")
> Fixes: 6ecc9d9ff91f ("crypto: x86 - Add optimized MORUS implementations")
> Signed-off-by: Ondrej Mosnacek
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[RESEND PATCH 2/2] crypto: caam - Support deferred probing in JR dependent drivers
It is possible, that caam_jr_alloc() is called before JR devices are
probed. Return -EPROBE_DEFER in drivers that rely on JR devices, so
they are probed at later stage.
Signed-off-by: Marcin Niestroj
---
drivers/crypto/caam/caamalg.c| 3 +++
drivers/crypto/caam/caamalg_qi.c | 3 +++
drivers/crypto/caam/caamhash.c | 3 +++
drivers/crypto/caam/caampkc.c| 3 +++
drivers/crypto/caam/caamrng.c| 3 +++
5 files changed, 15 insertions(+)
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index d67667970f7e..610a3f72ac5d 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -3253,6 +3253,9 @@ static int caam_init_common(struct caam_ctx *ctx, struct
caam_alg_entry *caam,
ctx->jrdev = caam_jr_alloc();
if (IS_ERR(ctx->jrdev)) {
+ if (PTR_ERR(ctx->jrdev))
+ return -EPROBE_DEFER;
+
pr_err("Job Ring Device allocation for transform failed\n");
return PTR_ERR(ctx->jrdev);
}
diff --git a/drivers/crypto/caam/caamalg_qi.c b/drivers/crypto/caam/caamalg_qi.c
index 6e61cc93c2b0..85c69a8b5126 100644
--- a/drivers/crypto/caam/caamalg_qi.c
+++ b/drivers/crypto/caam/caamalg_qi.c
@@ -2547,6 +2547,9 @@ static int caam_init_common(struct caam_ctx *ctx, struct
caam_alg_entry *caam,
*/
ctx->jrdev = caam_jr_alloc();
if (IS_ERR(ctx->jrdev)) {
+ if (PTR_ERR(ctx->jrdev))
+ return -EPROBE_DEFER;
+
pr_err("Job Ring Device allocation for transform failed\n");
return PTR_ERR(ctx->jrdev);
}
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index 0beb28196e20..c2ccb802b7d5 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1746,6 +1746,9 @@ static int caam_hash_cra_init(struct crypto_tfm *tfm)
*/
ctx->jrdev = caam_jr_alloc();
if (IS_ERR(ctx->jrdev)) {
+ if (PTR_ERR(ctx->jrdev))
+ return -EPROBE_DEFER;
+
pr_err("Job Ring Device allocation for transform failed\n");
return PTR_ERR(ctx->jrdev);
}
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
index 578ea63a3109..072da03207a1 100644
--- a/drivers/crypto/caam/caampkc.c
+++ b/drivers/crypto/caam/caampkc.c
@@ -972,6 +972,9 @@ static int caam_rsa_init_tfm(struct crypto_akcipher *tfm)
ctx->dev = caam_jr_alloc();
if (IS_ERR(ctx->dev)) {
+ if (PTR_ERR(ctx->dev))
+ return -EPROBE_DEFER;
+
pr_err("Job Ring Device allocation for transform failed\n");
return PTR_ERR(ctx->dev);
}
diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
index fde07d4ff019..56616b94416b 100644
--- a/drivers/crypto/caam/caamrng.c
+++ b/drivers/crypto/caam/caamrng.c
@@ -340,6 +340,9 @@ static int __init caam_rng_init(void)
dev = caam_jr_alloc();
if (IS_ERR(dev)) {
+ if (PTR_ERR(dev))
+ return -EPROBE_DEFER;
+
pr_err("Job Ring Device allocation for transform failed\n");
return PTR_ERR(dev);
}
--
2.18.0
[RESEND PATCH 1/2] crypto: caam/jr - Fix race by statically initializing global data
There is a race condition, when driver is not initialized
yet (jr_driver_init() was not called yet), but another kernel
code calls caam_jr_alloc(). This results in warnings about
uninitialized lock and NULL pointer dereference error.
Fix that by statically initializing global driver data, so
caam_jr_alloc() always works on initialized variables.
Signed-off-by: Marcin Niestroj
---
drivers/crypto/caam/jr.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index f4f258075b89..1352a4875d5a 100644
--- a/drivers/crypto/caam/jr.c
+++ b/drivers/crypto/caam/jr.c
@@ -21,7 +21,10 @@ struct jr_driver_data {
spinlock_t jr_alloc_lock; /* jr_list lock */
} cacheline_aligned;
-static struct jr_driver_data driver_data;
+static struct jr_driver_data driver_data = {
+ .jr_list = LIST_HEAD_INIT(driver_data.jr_list),
+ .jr_alloc_lock = __SPIN_LOCK_UNLOCKED(driver_data.jr_alloc_lock),
+};
static int caam_reset_hw_jr(struct device *dev)
{
@@ -561,20 +564,7 @@ static struct platform_driver caam_jr_driver = {
.remove = caam_jr_remove,
};
-static int __init jr_driver_init(void)
-{
- spin_lock_init(_data.jr_alloc_lock);
- INIT_LIST_HEAD(_data.jr_list);
- return platform_driver_register(_jr_driver);
-}
-
-static void __exit jr_driver_exit(void)
-{
- platform_driver_unregister(_jr_driver);
-}
-
-module_init(jr_driver_init);
-module_exit(jr_driver_exit);
+module_platform_driver(caam_jr_driver);
MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("FSL CAAM JR request backend");
--
2.18.0
