* Re: [PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi
From: Jon Mason @ 2017-02-22 23:32 UTC (permalink / raw)
To: Steve Lin
Cc: Herbert Xu, Rob Herring, Russell King, Ray Jui, Scott Branden,
Florian Fainelli, Mark Rutland, BCM Kernel Feedback,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-kernel, open list, Rob Rice,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1487798543-34229-1-git-send-email-steven.lin1-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On Wed, Feb 22, 2017 at 4:22 PM, Steve Lin <steven.lin1-dY08KVG/lbpWk0Htik3J/w@public.gmane.org> wrote:
> Adds crypto hardware (SPU) to Northstar Plus device tree file.
>
> Signed-off-by: Steve Lin <steven.lin1-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Looks good to me!
Acked-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
>
> ---
> Code changes for this addition were submitted previously by Rob
> Rice: https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=9d12ba86f818aa9cfe9f01b750336aa441f2ffa2
> ---
> arch/arm/boot/dts/bcm-nsp.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
> index b6142bd..9bac0c8 100644
> --- a/arch/arm/boot/dts/bcm-nsp.dtsi
> +++ b/arch/arm/boot/dts/bcm-nsp.dtsi
> @@ -241,6 +241,12 @@
> brcm,nand-has-wp;
> };
>
> + crypto@2f000 {
> + compatible = "brcm,spum-nsp-crypto";
> + reg = <0x2f000 0x900>;
> + mboxes = <&mailbox 0>;
> + };
> +
> gpiob: gpio@30000 {
> compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
> reg = <0x30000 0x50>;
> --
> 2.1.0
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: crypto: xts: regression in 4.10
From: Nicolas Porcel @ 2017-02-22 23:02 UTC (permalink / raw)
To: Milan Broz; +Cc: herbert, linux-crypto
In-Reply-To: <fb8a2f22-053e-7b30-6f0f-58158c832ad5@gmail.com>
On Wed, Feb 22, 2017 at 12:31:30PM +0100, Milan Broz wrote:
> Kernel 4.10 works with LUKS and XTS in general (otherwise I would scream much earlier:-)
I was surprised that it was still broken in the mainline release. All
the other regressions I had have been fixed. Also, I guess LUKS with
aes-xts is quite standard.
> I guess either there is a bug in some specific dependency missing
> dependency in kernel config. Could you send your kernel .config that fails?
>
> Do you have ECB mode compiled-in as well?
Nice guess. I had ECB enabled as a module, and I don't think it was
present in the initramfs. Compiling it in the kernel solves the problem.
Thanks for the clue!
I now have the xts(ecb(aes-generic)) driver appearing in /proc/crypto.
I had no xts driver before.
I don't think it's necessary now to copy my kernel config. Also, it's
quite minimalist: make defconfig with a few drivers I need, mostly compiled
in the kernel.
> (See commit description, shouldn't XTS now select ECB as well? This seems to me
> like a bug...)
I was actually confused by the message, I thought it would fallback to
the old implementation. I guess the XTS module should select ECB if
that's not the case. Should I submit a patch for that? Or maybe it would
be easier if a maintainer directly makes the change?
> What mail on dmcrypt list? I do not see any recent mail.
It was a mail from 2012, I should be more careful with search engines...
--
Nicolas Porcel
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback
From: Marcelo Cerri @ 2017-02-22 22:17 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto
In-Reply-To: <20170222191819.GB20626@gallifrey>
[-- Attachment #1: Type: text/plain, Size: 947 bytes --]
Hi Hebert,
On Wed, Feb 22, 2017 at 04:18:19PM -0300, Marcelo Cerri wrote:
> Hi Paulo.
>
> On Wed, Feb 22, 2017 at 03:00:15PM -0300, Paulo Flabiano Smorigo wrote:
> >
> > if (in_interrupt()) {
> > - ret = crypto_blkcipher_encrypt(&fallback_desc, dst, src,
> > - nbytes);
> > + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> > + skcipher_request_set_tfm(req, ctx->fallback);
> > + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> > + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> > + ret = crypto_skcipher_encrypt(req);
> > + skcipher_request_zero(req);
>
> Probably you have to wait for the completion here before proceeding.
>
> Check Documentation/crypto/api-samples.rst
>
I noticed you used a similar approach in arch/s390/crypto/aes_s390.c
(commit 64e2680).
How do you ensure the skcipher operation will not be asynchronous?
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH 1/1] ARM: dts: NSP: Add crypto (SPU) to dtsi
From: Steve Lin @ 2017-02-22 21:22 UTC (permalink / raw)
To: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
ray.jui-dY08KVG/lbpWk0Htik3J/w,
scott.branden-dY08KVG/lbpWk0Htik3J/w,
jon.mason-dY08KVG/lbpWk0Htik3J/w,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, mark.rutland-5wv7dgnIgG8
Cc: bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
steven.lin1-dY08KVG/lbpWk0Htik3J/w,
rob.rice-dY08KVG/lbpWk0Htik3J/w,
linux-crypto-u79uwXL29TY76Z2rM5mHXA
Adds crypto hardware (SPU) to Northstar Plus device tree file.
Signed-off-by: Steve Lin <steven.lin1-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
---
Code changes for this addition were submitted previously by Rob
Rice: https://git.kernel.org/cgit/linux/kernel/git/herbert/cryptodev-2.6.git/commit/?id=9d12ba86f818aa9cfe9f01b750336aa441f2ffa2
---
arch/arm/boot/dts/bcm-nsp.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-nsp.dtsi b/arch/arm/boot/dts/bcm-nsp.dtsi
index b6142bd..9bac0c8 100644
--- a/arch/arm/boot/dts/bcm-nsp.dtsi
+++ b/arch/arm/boot/dts/bcm-nsp.dtsi
@@ -241,6 +241,12 @@
brcm,nand-has-wp;
};
+ crypto@2f000 {
+ compatible = "brcm,spum-nsp-crypto";
+ reg = <0x2f000 0x900>;
+ mboxes = <&mailbox 0>;
+ };
+
gpiob: gpio@30000 {
compatible = "brcm,iproc-nsp-gpio", "brcm,iproc-gpio";
reg = <0x30000 0x50>;
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 2/2] crypto: vmx - Use skcipher for xts fallback
From: Marcelo Cerri @ 2017-02-22 19:20 UTC (permalink / raw)
To: Paulo Flabiano Smorigo
Cc: herbert, linux-kernel, paulus, linux-crypto, linuxppc-dev, davem
In-Reply-To: <20170222180045.28341-1-pfsmorigo@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3788 bytes --]
In addition to cbc comments:
On Wed, Feb 22, 2017 at 03:00:45PM -0300, Paulo Flabiano Smorigo wrote:
> Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
> ---
> drivers/crypto/vmx/aes_xts.c | 32 ++++++++++++++++++--------------
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
> index 24353ec3..a8245e1 100644
> --- a/drivers/crypto/vmx/aes_xts.c
> +++ b/drivers/crypto/vmx/aes_xts.c
> @@ -28,11 +28,12 @@
> #include <crypto/aes.h>
> #include <crypto/scatterwalk.h>
> #include <crypto/xts.h>
> +#include <crypto/internal/skcipher.h>
>
> #include "aesp8-ppc.h"
>
> struct p8_aes_xts_ctx {
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
> struct aes_key enc_key;
> struct aes_key dec_key;
> struct aes_key tweak_key;
> @@ -41,7 +42,7 @@ struct p8_aes_xts_ctx {
> static int p8_aes_xts_init(struct crypto_tfm *tfm)
> {
> const char *alg;
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
> struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
>
> if (!(alg = crypto_tfm_alg_name(tfm))) {
> @@ -50,7 +51,7 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
> }
>
> fallback =
> - crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> + crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> if (IS_ERR(fallback)) {
> printk(KERN_ERR
> "Failed to allocate transformation for '%s': %ld\n",
> @@ -60,9 +61,9 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
> printk(KERN_INFO "Using '%s' as fallback implementation.\n",
> crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
>
> - crypto_blkcipher_set_flags(
> + crypto_skcipher_set_flags(
> fallback,
> - crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
> + crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
> ctx->fallback = fallback;
>
> return 0;
> @@ -73,7 +74,7 @@ static void p8_aes_xts_exit(struct crypto_tfm *tfm)
> struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
>
> if (ctx->fallback) {
> - crypto_free_blkcipher(ctx->fallback);
> + crypto_free_skcipher(ctx->fallback);
> ctx->fallback = NULL;
> }
> }
> @@ -98,7 +99,7 @@ static int p8_aes_xts_setkey(struct crypto_tfm *tfm, const u8 *key,
> pagefault_enable();
> preempt_enable();
>
> - ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
> + ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
> return ret;
> }
>
> @@ -113,15 +114,18 @@ static int p8_aes_xts_crypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> struct p8_aes_xts_ctx *ctx =
> crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
> - struct blkcipher_desc fallback_desc = {
> - .tfm = ctx->fallback,
> - .info = desc->info,
> - .flags = desc->flags
> - };
>
> if (in_interrupt()) {
> - ret = enc ? crypto_blkcipher_encrypt(&fallback_desc, dst, src, nbytes) :
> - crypto_blkcipher_decrypt(&fallback_desc, dst, src, nbytes);
> + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> + skcipher_request_set_tfm(req, ctx->fallback);
> + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> + ret = crypto_skcipher_encrypt(req);
You probably don't want this crypto_skcipher_encrypt call.
> + if (enc)
> + crypto_skcipher_encrypt(req);
> + else
> + crypto_skcipher_decrypt(req);
And you should check the return values here.
> + skcipher_request_zero(req);
> } else {
> preempt_disable();
> pagefault_disable();
> --
> 2.9.3
>
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback
From: Marcelo Cerri @ 2017-02-22 19:18 UTC (permalink / raw)
To: Paulo Flabiano Smorigo
Cc: herbert, linux-kernel, paulus, linux-crypto, linuxppc-dev, davem
In-Reply-To: <20170222180015.27573-1-pfsmorigo@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4498 bytes --]
Hi Paulo.
On Wed, Feb 22, 2017 at 03:00:15PM -0300, Paulo Flabiano Smorigo wrote:
> Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
> ---
> drivers/crypto/vmx/aes_cbc.c | 41 ++++++++++++++++++++---------------------
> 1 file changed, 20 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
> index 94ad5c0..5aa70997 100644
> --- a/drivers/crypto/vmx/aes_cbc.c
> +++ b/drivers/crypto/vmx/aes_cbc.c
> @@ -27,11 +27,12 @@
> #include <asm/switch_to.h>
> #include <crypto/aes.h>
> #include <crypto/scatterwalk.h>
> +#include <crypto/internal/skcipher.h>
Isn't crypto/skcipher.h enough?
>
> #include "aesp8-ppc.h"
>
> struct p8_aes_cbc_ctx {
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
> struct aes_key enc_key;
> struct aes_key dec_key;
> };
> @@ -39,7 +40,7 @@ struct p8_aes_cbc_ctx {
> static int p8_aes_cbc_init(struct crypto_tfm *tfm)
> {
> const char *alg;
> - struct crypto_blkcipher *fallback;
> + struct crypto_skcipher *fallback;
> struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
>
> if (!(alg = crypto_tfm_alg_name(tfm))) {
> @@ -48,7 +49,7 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
> }
>
> fallback =
> - crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> + crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
> if (IS_ERR(fallback)) {
> printk(KERN_ERR
> "Failed to allocate transformation for '%s': %ld\n",
> @@ -58,9 +59,9 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
> printk(KERN_INFO "Using '%s' as fallback implementation.\n",
> crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
>
> - crypto_blkcipher_set_flags(
> + crypto_skcipher_set_flags(
> fallback,
> - crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
> + crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
> ctx->fallback = fallback;
>
> return 0;
> @@ -71,7 +72,7 @@ static void p8_aes_cbc_exit(struct crypto_tfm *tfm)
> struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
>
> if (ctx->fallback) {
> - crypto_free_blkcipher(ctx->fallback);
> + crypto_free_skcipher(ctx->fallback);
> ctx->fallback = NULL;
> }
> }
> @@ -91,7 +92,7 @@ static int p8_aes_cbc_setkey(struct crypto_tfm *tfm, const u8 *key,
> pagefault_enable();
> preempt_enable();
>
> - ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
> + ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
> return ret;
> }
>
> @@ -103,15 +104,14 @@ static int p8_aes_cbc_encrypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> struct p8_aes_cbc_ctx *ctx =
> crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
> - struct blkcipher_desc fallback_desc = {
> - .tfm = ctx->fallback,
> - .info = desc->info,
> - .flags = desc->flags
> - };
>
> if (in_interrupt()) {
> - ret = crypto_blkcipher_encrypt(&fallback_desc, dst, src,
> - nbytes);
> + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> + skcipher_request_set_tfm(req, ctx->fallback);
> + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> + ret = crypto_skcipher_encrypt(req);
> + skcipher_request_zero(req);
Probably you have to wait for the completion here before proceeding.
Check Documentation/crypto/api-samples.rst
> } else {
> preempt_disable();
> pagefault_disable();
> @@ -144,15 +144,14 @@ static int p8_aes_cbc_decrypt(struct blkcipher_desc *desc,
> struct blkcipher_walk walk;
> struct p8_aes_cbc_ctx *ctx =
> crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
> - struct blkcipher_desc fallback_desc = {
> - .tfm = ctx->fallback,
> - .info = desc->info,
> - .flags = desc->flags
> - };
>
> if (in_interrupt()) {
> - ret = crypto_blkcipher_decrypt(&fallback_desc, dst, src,
> - nbytes);
> + SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
> + skcipher_request_set_tfm(req, ctx->fallback);
> + skcipher_request_set_callback(req, desc->flags, NULL, NULL);
> + skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
> + ret = crypto_skcipher_decrypt(req);
> + skcipher_request_zero(req);
Same here.
> } else {
> preempt_disable();
> pagefault_disable();
> --
> 2.9.3
>
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* [PATCH 2/2] crypto: vmx - Use skcipher for xts fallback
From: Paulo Flabiano Smorigo @ 2017-02-22 18:00 UTC (permalink / raw)
To: linux-kernel
Cc: benh, paulus, mpe, herbert, davem, linux-crypto, linuxppc-dev,
Paulo Flabiano Smorigo
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
---
drivers/crypto/vmx/aes_xts.c | 32 ++++++++++++++++++--------------
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
index 24353ec3..a8245e1 100644
--- a/drivers/crypto/vmx/aes_xts.c
+++ b/drivers/crypto/vmx/aes_xts.c
@@ -28,11 +28,12 @@
#include <crypto/aes.h>
#include <crypto/scatterwalk.h>
#include <crypto/xts.h>
+#include <crypto/internal/skcipher.h>
#include "aesp8-ppc.h"
struct p8_aes_xts_ctx {
- struct crypto_blkcipher *fallback;
+ struct crypto_skcipher *fallback;
struct aes_key enc_key;
struct aes_key dec_key;
struct aes_key tweak_key;
@@ -41,7 +42,7 @@ struct p8_aes_xts_ctx {
static int p8_aes_xts_init(struct crypto_tfm *tfm)
{
const char *alg;
- struct crypto_blkcipher *fallback;
+ struct crypto_skcipher *fallback;
struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
if (!(alg = crypto_tfm_alg_name(tfm))) {
@@ -50,7 +51,7 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
}
fallback =
- crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
+ crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
"Failed to allocate transformation for '%s': %ld\n",
@@ -60,9 +61,9 @@ static int p8_aes_xts_init(struct crypto_tfm *tfm)
printk(KERN_INFO "Using '%s' as fallback implementation.\n",
crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
- crypto_blkcipher_set_flags(
+ crypto_skcipher_set_flags(
fallback,
- crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
+ crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
ctx->fallback = fallback;
return 0;
@@ -73,7 +74,7 @@ static void p8_aes_xts_exit(struct crypto_tfm *tfm)
struct p8_aes_xts_ctx *ctx = crypto_tfm_ctx(tfm);
if (ctx->fallback) {
- crypto_free_blkcipher(ctx->fallback);
+ crypto_free_skcipher(ctx->fallback);
ctx->fallback = NULL;
}
}
@@ -98,7 +99,7 @@ static int p8_aes_xts_setkey(struct crypto_tfm *tfm, const u8 *key,
pagefault_enable();
preempt_enable();
- ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
+ ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
return ret;
}
@@ -113,15 +114,18 @@ static int p8_aes_xts_crypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_xts_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
- struct blkcipher_desc fallback_desc = {
- .tfm = ctx->fallback,
- .info = desc->info,
- .flags = desc->flags
- };
if (in_interrupt()) {
- ret = enc ? crypto_blkcipher_encrypt(&fallback_desc, dst, src, nbytes) :
- crypto_blkcipher_decrypt(&fallback_desc, dst, src, nbytes);
+ SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+ skcipher_request_set_tfm(req, ctx->fallback);
+ skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+ ret = crypto_skcipher_encrypt(req);
+ if (enc)
+ crypto_skcipher_encrypt(req);
+ else
+ crypto_skcipher_decrypt(req);
+ skcipher_request_zero(req);
} else {
preempt_disable();
pagefault_disable();
--
2.9.3
^ permalink raw reply related
* [PATCH 1/2] crypto: vmx - Use skcipher for cbc fallback
From: Paulo Flabiano Smorigo @ 2017-02-22 18:00 UTC (permalink / raw)
To: linux-kernel
Cc: herbert, paulus, linux-crypto, Paulo Flabiano Smorigo,
linuxppc-dev, davem
Signed-off-by: Paulo Flabiano Smorigo <pfsmorigo@linux.vnet.ibm.com>
---
drivers/crypto/vmx/aes_cbc.c | 41 ++++++++++++++++++++---------------------
1 file changed, 20 insertions(+), 21 deletions(-)
diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
index 94ad5c0..5aa70997 100644
--- a/drivers/crypto/vmx/aes_cbc.c
+++ b/drivers/crypto/vmx/aes_cbc.c
@@ -27,11 +27,12 @@
#include <asm/switch_to.h>
#include <crypto/aes.h>
#include <crypto/scatterwalk.h>
+#include <crypto/internal/skcipher.h>
#include "aesp8-ppc.h"
struct p8_aes_cbc_ctx {
- struct crypto_blkcipher *fallback;
+ struct crypto_skcipher *fallback;
struct aes_key enc_key;
struct aes_key dec_key;
};
@@ -39,7 +40,7 @@ struct p8_aes_cbc_ctx {
static int p8_aes_cbc_init(struct crypto_tfm *tfm)
{
const char *alg;
- struct crypto_blkcipher *fallback;
+ struct crypto_skcipher *fallback;
struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
if (!(alg = crypto_tfm_alg_name(tfm))) {
@@ -48,7 +49,7 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
}
fallback =
- crypto_alloc_blkcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
+ crypto_alloc_skcipher(alg, 0, CRYPTO_ALG_NEED_FALLBACK);
if (IS_ERR(fallback)) {
printk(KERN_ERR
"Failed to allocate transformation for '%s': %ld\n",
@@ -58,9 +59,9 @@ static int p8_aes_cbc_init(struct crypto_tfm *tfm)
printk(KERN_INFO "Using '%s' as fallback implementation.\n",
crypto_tfm_alg_driver_name((struct crypto_tfm *) fallback));
- crypto_blkcipher_set_flags(
+ crypto_skcipher_set_flags(
fallback,
- crypto_blkcipher_get_flags((struct crypto_blkcipher *)tfm));
+ crypto_skcipher_get_flags((struct crypto_skcipher *)tfm));
ctx->fallback = fallback;
return 0;
@@ -71,7 +72,7 @@ static void p8_aes_cbc_exit(struct crypto_tfm *tfm)
struct p8_aes_cbc_ctx *ctx = crypto_tfm_ctx(tfm);
if (ctx->fallback) {
- crypto_free_blkcipher(ctx->fallback);
+ crypto_free_skcipher(ctx->fallback);
ctx->fallback = NULL;
}
}
@@ -91,7 +92,7 @@ static int p8_aes_cbc_setkey(struct crypto_tfm *tfm, const u8 *key,
pagefault_enable();
preempt_enable();
- ret += crypto_blkcipher_setkey(ctx->fallback, key, keylen);
+ ret += crypto_skcipher_setkey(ctx->fallback, key, keylen);
return ret;
}
@@ -103,15 +104,14 @@ static int p8_aes_cbc_encrypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_cbc_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
- struct blkcipher_desc fallback_desc = {
- .tfm = ctx->fallback,
- .info = desc->info,
- .flags = desc->flags
- };
if (in_interrupt()) {
- ret = crypto_blkcipher_encrypt(&fallback_desc, dst, src,
- nbytes);
+ SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+ skcipher_request_set_tfm(req, ctx->fallback);
+ skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+ ret = crypto_skcipher_encrypt(req);
+ skcipher_request_zero(req);
} else {
preempt_disable();
pagefault_disable();
@@ -144,15 +144,14 @@ static int p8_aes_cbc_decrypt(struct blkcipher_desc *desc,
struct blkcipher_walk walk;
struct p8_aes_cbc_ctx *ctx =
crypto_tfm_ctx(crypto_blkcipher_tfm(desc->tfm));
- struct blkcipher_desc fallback_desc = {
- .tfm = ctx->fallback,
- .info = desc->info,
- .flags = desc->flags
- };
if (in_interrupt()) {
- ret = crypto_blkcipher_decrypt(&fallback_desc, dst, src,
- nbytes);
+ SKCIPHER_REQUEST_ON_STACK(req, ctx->fallback);
+ skcipher_request_set_tfm(req, ctx->fallback);
+ skcipher_request_set_callback(req, desc->flags, NULL, NULL);
+ skcipher_request_set_crypt(req, src, dst, nbytes, desc->info);
+ ret = crypto_skcipher_decrypt(req);
+ skcipher_request_zero(req);
} else {
preempt_disable();
pagefault_disable();
--
2.9.3
^ permalink raw reply related
* [PATCH 0/2] crypto: vmx - fix vmx failures by changing fallback to skcipher
From: Paulo Flabiano Smorigo @ 2017-02-22 17:58 UTC (permalink / raw)
To: linux-kernel
Cc: herbert, paulus, linux-crypto, Paulo Flabiano Smorigo,
linuxppc-dev, davem
Currently, neither cbc or xts are working with upstream kernel due to a failure
in the fallback allocation. This can be fixed by changing the fallback to
skcipher.
Paulo Flabiano Smorigo (2):
crypto: vmx - Use skcipher for cbc fallback
crypto: vmx - Use skcipher for xts fallback
drivers/crypto/vmx/aes_cbc.c | 41 ++++++++++++++++++++---------------------
drivers/crypto/vmx/aes_xts.c | 32 ++++++++++++++++++--------------
2 files changed, 38 insertions(+), 35 deletions(-)
--
2.9.3
^ permalink raw reply
* Re: crypto: xts: regression in 4.10
From: Marcelo Cerri @ 2017-02-22 17:42 UTC (permalink / raw)
To: Nicolas Porcel; +Cc: herbert, linux-crypto
In-Reply-To: <20170221231717.GA7186@nicolas-laptop>
[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]
What XTS implementations do you have available on /proc/crypto after the
error?
Some drivers that allocate fallback implementations using the older API
started to fail after the generic templates were converted to skcipher.
On Wed, Feb 22, 2017 at 12:17:17AM +0100, Nicolas Porcel wrote:
> Hello,
>
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
>
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
> device-mapper: reload ioctl on failed: No such file or directory
> Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
> Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info)
>
> I found that this commit is responsible for the regression (reverting it
> solves the problem):
>
> > commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> > Author: Herbert Xu <herbert@gondor.apana.org.au>
> > Date: Tue Nov 22 20:08:19 2016 +0800
> >
> > crypto: xts - Convert to skcipher
>
> Some precision: I am using the vanilla kernel source for 4.10. The aes,
> xts and dm-crypt modules are directly compiled in the kernel and not as
> modules. I also had the same problem with kernel 4.10-rc*.
>
> Is it a known issue? I found 1 related email with no answer on the
> dm-crypt mailing. If this is a regression, I can start digging, although
> any guidance would be greatly appreciated.
>
> Thank you in advance,
>
> Best regards,
>
> --
> Nicolas Porcel
--
Regards,
Marcelo
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: crypto/cavium MSI-X fixups
From: David Daney @ 2017-02-22 17:45 UTC (permalink / raw)
To: Christoph Hellwig, David Daney
Cc: George Cherian, George Cherian, David Daney, Herbert Xu,
linux-crypto, linux-kernel
In-Reply-To: <20170222072752.GA18643@lst.de>
On 02/21/2017 11:27 PM, Christoph Hellwig wrote:
> On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote:
>> With respect to pci_enable_msix(), what do you recommend as a replacement?
>
> pci_alloc_irq_vectors. In fact I have a tree ready for after -rc1
> that removes pci_enable_msix() entirely.
I would like to see something that handles the case of this driver that
I am attempting to get merged:
https://lkml.org/lkml/2017/2/15/1209
>
>> For the crypto/cavium driver, you recommend pci_alloc_irq_vectors(), which
>> works well if the required MSI-X indexes are contiguous starting at zero.
>> What would be used for a device that has 184 MSI-X, but only a sparse
>> subset (fewer than half) of these are required for the driver operation.
>> It would waste system resources to use an API that forces us to allocate
>> 184 when only 80 are required.
>
> Currently we don't have a good API for that. I've not been through all
> users of pci_enable_msix_{range,exact} yet, but so far I've only found
> one user not using all vectors from 0 to some limit. Depending how many
> such users we have and how they'll look I will have to look into an API
> to support that use case.
>
See the patch above for the case that doesn't use 0..UPPER_LIMIT
David Daney
^ permalink raw reply
* Re: crypto: xts: regression in 4.10
From: Milan Broz @ 2017-02-22 11:31 UTC (permalink / raw)
To: Nicolas Porcel, herbert, linux-crypto
In-Reply-To: <20170221231717.GA7186@nicolas-laptop>
On 02/22/2017 12:17 AM, Nicolas Porcel wrote:
> Hello,
>
> I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
> the partition cannot be opened and I have the following errors when
> booting:
>
> device-mapper: table: 253:0: crypt: Error allocating crypto tfm
> device-mapper: ioctl: error adding target to table
> device-mapper: reload ioctl on failed: No such file or directory
> Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
> Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info)
>
> I found that this commit is responsible for the regression (reverting it
> solves the problem):
>
>> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Tue Nov 22 20:08:19 2016 +0800
>>
>> crypto: xts - Convert to skcipher
>
> Some precision: I am using the vanilla kernel source for 4.10. The aes,
> xts and dm-crypt modules are directly compiled in the kernel and not as
> modules. I also had the same problem with kernel 4.10-rc*.
Kernel 4.10 works with LUKS and XTS in general (otherwise I would scream much earlier:-)
I guess either there is a bug in some specific dependency missing
dependency in kernel config. Could you send your kernel .config that fails?
Do you have ECB mode compiled-in as well?
(See commit description, shouldn't XTS now select ECB as well? This seems to me
like a bug...)
> Is it a known issue? I found 1 related email with no answer on the
> dm-crypt mailing. If this is a regression, I can start digging, although
> any guidance would be greatly appreciated.
What mail on dmcrypt list? I do not see any recent mail.
Milan
^ permalink raw reply
* Re: crypto/cavium MSI-X fixups
From: Christoph Hellwig @ 2017-02-22 7:27 UTC (permalink / raw)
To: David Daney
Cc: Christoph Hellwig, George Cherian, George Cherian, David Daney,
Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <52c432c9-4dc1-861e-5556-0db2f4a42c98@caviumnetworks.com>
On Tue, Feb 21, 2017 at 09:36:04AM -0800, David Daney wrote:
> With respect to pci_enable_msix(), what do you recommend as a replacement?
pci_alloc_irq_vectors. In fact I have a tree ready for after -rc1
that removes pci_enable_msix() entirely.
> For the crypto/cavium driver, you recommend pci_alloc_irq_vectors(), which
> works well if the required MSI-X indexes are contiguous starting at zero.
> What would be used for a device that has 184 MSI-X, but only a sparse
> subset (fewer than half) of these are required for the driver operation.
> It would waste system resources to use an API that forces us to allocate
> 184 when only 80 are required.
Currently we don't have a good API for that. I've not been through all
users of pci_enable_msix_{range,exact} yet, but so far I've only found
one user not using all vectors from 0 to some limit. Depending how many
such users we have and how they'll look I will have to look into an API
to support that use case.
^ permalink raw reply
* [PATCH v3 4/4] hwrng: meson: add clock handling to driver
From: Heiner Kallweit @ 2017-02-22 7:02 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
Michael Turquette
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4e2d12e5-f75b-3ac6-a3f7-18e8a8b7283b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add handling of RNG0 clock to the driver.
Signed-off-by: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
v2:
- consider that clock is optional
- use managed call to clk_disable_unprepare to ensure that
cleaning up is done in the right order if driver is removed
v3:
- no changes
---
drivers/char/hw_random/meson-rng.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
index 119d6984..2e23be80 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -62,6 +62,7 @@
#include <linux/slab.h>
#include <linux/types.h>
#include <linux/of.h>
+#include <linux/clk.h>
#define RNG_DATA 0x00
@@ -69,6 +70,7 @@ struct meson_rng_data {
void __iomem *base;
struct platform_device *pdev;
struct hwrng rng;
+ struct clk *core_clk;
};
static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
@@ -81,11 +83,17 @@ static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
return sizeof(u32);
}
+static void meson_rng_clk_disable(void *data)
+{
+ clk_disable_unprepare(data);
+}
+
static int meson_rng_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct meson_rng_data *data;
struct resource *res;
+ int ret;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -98,6 +106,20 @@ static int meson_rng_probe(struct platform_device *pdev)
if (IS_ERR(data->base))
return PTR_ERR(data->base);
+ data->core_clk = devm_clk_get(dev, "core");
+ if (IS_ERR(data->core_clk))
+ data->core_clk = NULL;
+
+ if (data->core_clk) {
+ ret = clk_prepare_enable(data->core_clk);
+ if (ret)
+ return ret;
+ ret = devm_add_action_or_reset(dev, meson_rng_clk_disable,
+ data->core_clk);
+ if (ret)
+ return ret;
+ }
+
data->rng.name = pdev->name;
data->rng.read = meson_rng_read;
--
2.11.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 3/4] ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node
From: Heiner Kallweit @ 2017-02-22 7:00 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
Michael Turquette
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <4e2d12e5-f75b-3ac6-a3f7-18e8a8b7283b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add clock CLKID_RNG0 to HW randon number generator node.
Signed-off-by: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
v2:
- splitted first version of patch into two
- add DT binding documentation
- mention that clock is optional
- replace spaces with tabs in DT binding example
v3:
- splitted DT extension and binding documentation update into two patches
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +++++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 5d995f77..620495a4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -380,7 +380,7 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc8834000 0x0 0x2000>;
- rng {
+ hwrng: rng {
compatible = "amlogic,meson-rng";
reg = <0x0 0x0 0x0 0x4>;
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 04b3324b..a375cb21 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -524,3 +524,8 @@
&vpu {
compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
};
+
+&hwrng {
+ clocks = <&clkc CLKID_RNG0>;
+ clock-names = "core";
+};
--
2.11.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 2/4] ARM64: dts: meson-gx: add clock to DT binding documentation for hwrng
From: Heiner Kallweit @ 2017-02-22 6:59 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette
Cc: linux-clk, devicetree
In-Reply-To: <4e2d12e5-f75b-3ac6-a3f7-18e8a8b7283b@gmail.com>
Add clock to DT binding documentation.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- splitted first version of patch into two
- add DT binding documentation
- mention that clock is optional
- replace spaces with tabs in DT binding example
v3:
- splitted DT extension and binding documentation update into two patches
---
Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
index 202f2d09..4d403645 100644
--- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
@@ -6,9 +6,16 @@ Required properties:
- compatible : should be "amlogic,meson-rng"
- reg : Specifies base physical address and size of the registers.
+Optional properties:
+
+- clocks : phandle to the following named clocks
+- clock-names: Name of core clock, must be "core"
+
Example:
rng {
- compatible = "amlogic,meson-rng";
- reg = <0x0 0xc8834000 0x0 0x4>;
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0xc8834000 0x0 0x4>;
+ clocks = <&clkc CLKID_RNG0>;
+ clock-names = "core";
};
--
2.11.1
^ permalink raw reply related
* [PATCH v3 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
From: Heiner Kallweit @ 2017-02-22 6:55 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette
Cc: linux-clk, devicetree
Expose clock CLKID_RNG0 which is needed for the HW random number generator.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- added clk and DT maintainers
- split exposing the clock and using it in DT into two patches
- comment out clock definition in drivers/clk/meson/gxbb.h
- silently move CLKID_SPI to the right place
v3:
- no changes
---
drivers/clk/meson/gxbb.h | 2 +-
include/dt-bindings/clock/gxbb-clkc.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 8ee2022c..cbd62e46 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -193,7 +193,7 @@
/* CLKID_I2C */
/* #define CLKID_SAR_ADC */
#define CLKID_SMART_CARD 24
-#define CLKID_RNG0 25
+/* CLKID_RNG0 */
#define CLKID_UART0 26
#define CLKID_SDHC 27
#define CLKID_STREAM 28
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index 692846c7..63f4c2c4 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -12,9 +12,10 @@
#define CLKID_FCLK_DIV4 6
#define CLKID_CLK81 12
#define CLKID_MPLL2 15
-#define CLKID_SPI 34
#define CLKID_I2C 22
#define CLKID_SAR_ADC 23
+#define CLKID_RNG0 25
+#define CLKID_SPI 34
#define CLKID_ETH 36
#define CLKID_USB0 50
#define CLKID_USB1 51
--
2.11.1
^ permalink raw reply related
* Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt
From: Binoy Jayan @ 2017-02-22 6:12 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Oded, Ofir, Herbert Xu, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra,
Milan Broz
In-Reply-To: <CAOtvUMcN8s886978vE6T=AE79KkZsLBnXsmhewnb5PB0UyAG3A@mail.gmail.com>
Hi Herbert,
On 8 February 2017 at 13:02, Gilad Ben-Yossef <gilad@benyossef.com> wrote:
> On Tue, Feb 7, 2017 at 12:35 PM, Binoy Jayan <binoy.jayan@linaro.org> wrote:
>> ===============================================================================
>> dm-crypt optimization for larger block sizes
>> ===============================================================================
>>
>> Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal
>> is to move these algorithms from the dm layer to the kernel crypto layer by
>> implementing them as template ciphers so they can be used in relation with
>> algorithms like aes, and with multiple modes like cbc, ecb etc. As part of this
>> patchset, the iv-generation code is moved from the dm layer to the crypto layer
>> and adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
>> at a time. Each bio contains the in memory representation of physically
>> contiguous disk blocks. Since the bio itself may not be contiguous in main
>> memory, the dm layer sets up a chained scatterlist of these blocks split into
>> physically contiguous segments in memory so that DMA can be performed.
> Ran Bonnie++ on it last night (Luks mode, plain64, Qemu Virt platform
> Arm64) and it works just fine.
>
> Tested-by: Gilad Ben-Yossef <gilad@benyossef.com>
I was wondering if this is near to be ready for submission (apart from
the testmgr.c
changes) or I need to make some changes to make it similar to the IPSec offload?
Thanks,
Binoy
^ permalink raw reply
* crypto: xts: regression in 4.10
From: Nicolas Porcel @ 2017-02-21 23:17 UTC (permalink / raw)
To: herbert, linux-crypto
Hello,
I am using aes-xts-plain64 with LUKS headers to crypt the root. In 4.10,
the partition cannot be opened and I have the following errors when
booting:
device-mapper: table: 253:0: crypt: Error allocating crypto tfm
device-mapper: ioctl: error adding target to table
device-mapper: reload ioctl on failed: No such file or directory
Failed to setup dm-crypt key mapping for device /dev/mmcblk0p2
Check that the kernel supports aes-xts-plain64 cipher (check syslog for more info)
I found that this commit is responsible for the regression (reverting it
solves the problem):
> commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40
> Author: Herbert Xu <herbert@gondor.apana.org.au>
> Date: Tue Nov 22 20:08:19 2016 +0800
>
> crypto: xts - Convert to skcipher
Some precision: I am using the vanilla kernel source for 4.10. The aes,
xts and dm-crypt modules are directly compiled in the kernel and not as
modules. I also had the same problem with kernel 4.10-rc*.
Is it a known issue? I found 1 related email with no answer on the
dm-crypt mailing. If this is a regression, I can start digging, although
any guidance would be greatly appreciated.
Thank you in advance,
Best regards,
--
Nicolas Porcel
^ permalink raw reply
* Re: [PATCH v2 3/3] hwrng: meson: add clock handling to driver
From: Heiner Kallweit @ 2017-02-21 21:53 UTC (permalink / raw)
To: Neil Armstrong, Jerome Brunet, Kevin Hilman, Herbert Xu,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
Michael Turquette
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <afe93bb2-30de-233d-ed58-d77c018a6d33-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Am 21.02.2017 um 22:21 schrieb Neil Armstrong:
> On 02/21/2017 12:26 PM, Heiner Kallweit wrote:
>> Add handling of RNG0 clock to the driver.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> v2:
>> - consider that clock is optional
>> - use managed call to clk_disable_unprepare to ensure that
>> cleaning up is done in the right order if driver is removed
>> ---
>> drivers/char/hw_random/meson-rng.c | 22 ++++++++++++++++++++++
>> 1 file changed, 22 insertions(+)
>>
>> diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
>> index 119d6984..2e23be80 100644
>> --- a/drivers/char/hw_random/meson-rng.c
>> +++ b/drivers/char/hw_random/meson-rng.c
>> @@ -62,6 +62,7 @@
>> #include <linux/slab.h>
>> #include <linux/types.h>
>> #include <linux/of.h>
>> +#include <linux/clk.h>
>>
>> #define RNG_DATA 0x00
>>
>> @@ -69,6 +70,7 @@ struct meson_rng_data {
>> void __iomem *base;
>> struct platform_device *pdev;
>> struct hwrng rng;
>> + struct clk *core_clk;
>> };
>>
>> static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
>> @@ -81,11 +83,17 @@ static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
>> return sizeof(u32);
>> }
>>
>> +static void meson_rng_clk_disable(void *clk)
>> +{
>> + clk_disable_unprepare(clk);
>> +}
>> +
>> static int meson_rng_probe(struct platform_device *pdev)
>> {
>> struct device *dev = &pdev->dev;
>> struct meson_rng_data *data;
>> struct resource *res;
>> + int ret;
>>
>> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
>> if (!data)
>> @@ -98,6 +106,20 @@ static int meson_rng_probe(struct platform_device *pdev)
>> if (IS_ERR(data->base))
>> return PTR_ERR(data->base);
>>
>> + data->core_clk = devm_clk_get(dev, "core");
>> + if (IS_ERR(data->core_clk))
>> + data->core_clk = NULL;
>> +
>> + if (data->core_clk) {
>
> This "if" is useless, if core_clk is NULL, this will work also.
>
Regarding clk_prepare_enable you're right. However we need this "if" for
the call to devm_add_action_or_reset because we can't provide a NULL
pointer as data argument.
And including clk_prepare_enable in the if clause creates no overhead
and is clearer IMHO.
>> + ret = clk_prepare_enable(data->core_clk);
>> + if (ret)
>> + return ret;
>> + ret = devm_add_action_or_reset(dev, meson_rng_clk_disable,
>> + data->core_clk);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> data->rng.name = pdev->name;
>> data->rng.read = meson_rng_read;
>>
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] hwrng: meson: add clock handling to driver
From: Neil Armstrong @ 2017-02-21 21:21 UTC (permalink / raw)
To: Heiner Kallweit, Jerome Brunet, Kevin Hilman, Herbert Xu,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
Michael Turquette
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <989cf7bf-b7ea-0b41-510b-6eab403f0185-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 02/21/2017 12:26 PM, Heiner Kallweit wrote:
> Add handling of RNG0 clock to the driver.
>
> Signed-off-by: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> v2:
> - consider that clock is optional
> - use managed call to clk_disable_unprepare to ensure that
> cleaning up is done in the right order if driver is removed
> ---
> drivers/char/hw_random/meson-rng.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
> index 119d6984..2e23be80 100644
> --- a/drivers/char/hw_random/meson-rng.c
> +++ b/drivers/char/hw_random/meson-rng.c
> @@ -62,6 +62,7 @@
> #include <linux/slab.h>
> #include <linux/types.h>
> #include <linux/of.h>
> +#include <linux/clk.h>
>
> #define RNG_DATA 0x00
>
> @@ -69,6 +70,7 @@ struct meson_rng_data {
> void __iomem *base;
> struct platform_device *pdev;
> struct hwrng rng;
> + struct clk *core_clk;
> };
>
> static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> @@ -81,11 +83,17 @@ static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
> return sizeof(u32);
> }
>
> +static void meson_rng_clk_disable(void *clk)
> +{
> + clk_disable_unprepare(clk);
> +}
> +
> static int meson_rng_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> struct meson_rng_data *data;
> struct resource *res;
> + int ret;
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data)
> @@ -98,6 +106,20 @@ static int meson_rng_probe(struct platform_device *pdev)
> if (IS_ERR(data->base))
> return PTR_ERR(data->base);
>
> + data->core_clk = devm_clk_get(dev, "core");
> + if (IS_ERR(data->core_clk))
> + data->core_clk = NULL;
> +
> + if (data->core_clk) {
This "if" is useless, if core_clk is NULL, this will work also.
> + ret = clk_prepare_enable(data->core_clk);
> + if (ret)
> + return ret;
> + ret = devm_add_action_or_reset(dev, meson_rng_clk_disable,
> + data->core_clk);
> + if (ret)
> + return ret;
> + }
> +
> data->rng.name = pdev->name;
> data->rng.read = meson_rng_read;
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 2/3] ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node
From: Neil Armstrong @ 2017-02-21 21:20 UTC (permalink / raw)
To: Heiner Kallweit, Jerome Brunet, Kevin Hilman, Herbert Xu,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd,
Michael Turquette
Cc: linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <8bf052e3-de8f-dbdf-be76-369a7bb1ed15-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 02/21/2017 12:18 PM, Heiner Kallweit wrote:
> Add clock CLKID_RNG0 to HW randon number generator node and
> extend the DT binding documentation accordingly.
>
> Signed-off-by: Heiner Kallweit <hkallweit1-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> v2:
> - splitted first version of patch into two
> - add DT binding documentation
Hi Heiner,
Can you move the dt-bindings to a separate patch ?
> - mention that clock is optional
> - replace spaces with tabs in DT binding example
> ---
> Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt | 8 ++++++--
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +++++
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
> index 202f2d09..4c012a04 100644
> --- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
> +++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
> @@ -5,10 +5,14 @@ Required properties:
>
> - compatible : should be "amlogic,meson-rng"
> - reg : Specifies base physical address and size of the registers.
> +- clocks : Optional core clock
> +- clock-names: Name of core clock, must be "core"
Please put these in a separate "Optional Properties" :
Optional Properties:
- clocks : phandle to the following named clocks
- clock-names: Name of core clock, must be "core"
>
> Example:
>
> rng {
> - compatible = "amlogic,meson-rng";
> - reg = <0x0 0xc8834000 0x0 0x4>;
> + compatible = "amlogic,meson-rng";
> + reg = <0x0 0xc8834000 0x0 0x4>;
> + clocks = <&clkc CLKID_RNG0>;
> + clock-names = "core";
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> index 5d995f77..620495a4 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
> @@ -380,7 +380,7 @@
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xc8834000 0x0 0x2000>;
>
> - rng {
> + hwrng: rng {
> compatible = "amlogic,meson-rng";
> reg = <0x0 0x0 0x0 0x4>;
> };
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index 04b3324b..a375cb21 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -524,3 +524,8 @@
> &vpu {
> compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
> };
> +
> +&hwrng {
> + clocks = <&clkc CLKID_RNG0>;
> + clock-names = "core";
> +};
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 3/3] hwrng: meson: add clock handling to driver
From: Heiner Kallweit @ 2017-02-21 20:26 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette
Cc: linux-clk, devicetree
In-Reply-To: <daf765e2-1a60-8dea-fee0-8af6ddecdf8e@gmail.com>
Add handling of RNG0 clock to the driver.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- consider that clock is optional
- use managed call to clk_disable_unprepare to ensure that
cleaning up is done in the right order if driver is removed
---
drivers/char/hw_random/meson-rng.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/char/hw_random/meson-rng.c b/drivers/char/hw_random/meson-rng.c
index 119d6984..2e23be80 100644
--- a/drivers/char/hw_random/meson-rng.c
+++ b/drivers/char/hw_random/meson-rng.c
@@ -62,6 +62,7 @@
#include <linux/slab.h>
#include <linux/types.h>
#include <linux/of.h>
+#include <linux/clk.h>
#define RNG_DATA 0x00
@@ -69,6 +70,7 @@ struct meson_rng_data {
void __iomem *base;
struct platform_device *pdev;
struct hwrng rng;
+ struct clk *core_clk;
};
static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
@@ -81,11 +83,17 @@ static int meson_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
return sizeof(u32);
}
+static void meson_rng_clk_disable(void *clk)
+{
+ clk_disable_unprepare(clk);
+}
+
static int meson_rng_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct meson_rng_data *data;
struct resource *res;
+ int ret;
data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
if (!data)
@@ -98,6 +106,20 @@ static int meson_rng_probe(struct platform_device *pdev)
if (IS_ERR(data->base))
return PTR_ERR(data->base);
+ data->core_clk = devm_clk_get(dev, "core");
+ if (IS_ERR(data->core_clk))
+ data->core_clk = NULL;
+
+ if (data->core_clk) {
+ ret = clk_prepare_enable(data->core_clk);
+ if (ret)
+ return ret;
+ ret = devm_add_action_or_reset(dev, meson_rng_clk_disable,
+ data->core_clk);
+ if (ret)
+ return ret;
+ }
+
data->rng.name = pdev->name;
data->rng.read = meson_rng_read;
--
2.11.1
^ permalink raw reply related
* [PATCH v2 2/3] ARM64: dts: meson-gx: add clock CLKID_RNG0 to hwrng node
From: Heiner Kallweit @ 2017-02-21 20:18 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette
Cc: linux-clk, devicetree
In-Reply-To: <daf765e2-1a60-8dea-fee0-8af6ddecdf8e@gmail.com>
Add clock CLKID_RNG0 to HW randon number generator node and
extend the DT binding documentation accordingly.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- splitted first version of patch into two
- add DT binding documentation
- mention that clock is optional
- replace spaces with tabs in DT binding example
---
Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt | 8 ++++++--
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 2 +-
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +++++
3 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
index 202f2d09..4c012a04 100644
--- a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
@@ -5,10 +5,14 @@ Required properties:
- compatible : should be "amlogic,meson-rng"
- reg : Specifies base physical address and size of the registers.
+- clocks : Optional core clock
+- clock-names: Name of core clock, must be "core"
Example:
rng {
- compatible = "amlogic,meson-rng";
- reg = <0x0 0xc8834000 0x0 0x4>;
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0xc8834000 0x0 0x4>;
+ clocks = <&clkc CLKID_RNG0>;
+ clock-names = "core";
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index 5d995f77..620495a4 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -380,7 +380,7 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc8834000 0x0 0x2000>;
- rng {
+ hwrng: rng {
compatible = "amlogic,meson-rng";
reg = <0x0 0x0 0x0 0x4>;
};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 04b3324b..a375cb21 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -524,3 +524,8 @@
&vpu {
compatible = "amlogic,meson-gxbb-vpu", "amlogic,meson-gx-vpu";
};
+
+&hwrng {
+ clocks = <&clkc CLKID_RNG0>;
+ clock-names = "core";
+};
--
2.11.1
^ permalink raw reply related
* [PATCH v2 1/3] clk: meson-gxbb: expose clock CLKID_RNG0
From: Heiner Kallweit @ 2017-02-21 20:11 UTC (permalink / raw)
To: Jerome Brunet, Kevin Hilman, Herbert Xu, Neil Armstrong,
linux-amlogic, linux-crypto, Stephen Boyd, Michael Turquette
Cc: linux-clk, devicetree
Expose clock CLKID_RNG0 which is needed for the HW random number generator.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
---
v2:
- added clk and DT maintainers
- split exposing the clock and using it in DT into two patches
- comment out clock definition in drivers/clk/meson/gxbb.h
- silently move CLKID_SPI to the right place
---
drivers/clk/meson/gxbb.h | 2 +-
include/dt-bindings/clock/gxbb-clkc.h | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 8ee2022c..cbd62e46 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -193,7 +193,7 @@
/* CLKID_I2C */
/* #define CLKID_SAR_ADC */
#define CLKID_SMART_CARD 24
-#define CLKID_RNG0 25
+/* CLKID_RNG0 */
#define CLKID_UART0 26
#define CLKID_SDHC 27
#define CLKID_STREAM 28
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index 692846c7..63f4c2c4 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -12,9 +12,10 @@
#define CLKID_FCLK_DIV4 6
#define CLKID_CLK81 12
#define CLKID_MPLL2 15
-#define CLKID_SPI 34
#define CLKID_I2C 22
#define CLKID_SAR_ADC 23
+#define CLKID_RNG0 25
+#define CLKID_SPI 34
#define CLKID_ETH 36
#define CLKID_USB0 50
#define CLKID_USB1 51
--
2.11.1
^ 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