Re: [PATCH 0/7] arm64: marvell: add cryptographic engine support for 7k/8k
On Tue, Apr 11, 2017 at 06:12:25PM +0200, Gregory CLEMENT wrote: > > > I have no problems with the crypto bits. > > Does it means that you agree that I apply the arm-soc related patches > (from 4 to 7) to my mvebu trees? Yes sure. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[PATCH v5 1/2] linux/kernel.h: Add ALIGN_DOWN macro
Few parts of kernel define their own macro for aligning down so provide
a common define for this, with the same usage and assumptions as existing
ALIGN.
Convert also three existing implementations to this one.
Signed-off-by: Krzysztof Kozlowski
---
The metag change was not even compiled due to lack of cross compiler.
---
arch/metag/kernel/stacktrace.c | 2 --
drivers/gpu/drm/udl/udl_fb.c | 2 +-
include/linux/kernel.h | 1 +
include/video/udlfb.h | 2 +-
4 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/metag/kernel/stacktrace.c b/arch/metag/kernel/stacktrace.c
index 91ffc4b75c33..09d67b7f51ca 100644
--- a/arch/metag/kernel/stacktrace.c
+++ b/arch/metag/kernel/stacktrace.c
@@ -31,8 +31,6 @@ static void tbi_boing_init(void)
}
#endif
-#define ALIGN_DOWN(addr, size) ((addr)&(~((size)-1)))
-
/*
* Unwind the current stack frame and store the new register values in the
* structure passed as argument. Unwinding is equivalent to a function return,
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index d05abc69e305..4a6500362564 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -37,7 +37,7 @@ struct udl_fbdev {
};
#define DL_ALIGN_UP(x, a) ALIGN(x, a)
-#define DL_ALIGN_DOWN(x, a) ALIGN(x-(a-1), a)
+#define DL_ALIGN_DOWN(x, a) ALIGN_DOWN(x, a)
/** Read the red component (0..255) of a 32 bpp colour. */
#define DLO_RGB_GETRED(col) (uint8_t)((col) & 0xFF)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 4c26dc3a8295..3d9f8420f973 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -47,6 +47,7 @@
/* @a is a power of 2 value */
#define ALIGN(x, a)__ALIGN_KERNEL((x), (a))
+#define ALIGN_DOWN(x, a) __ALIGN_KERNEL((x) - ((a) - 1), (a))
#define __ALIGN_MASK(x, mask) __ALIGN_KERNEL_MASK((x), (mask))
#define PTR_ALIGN(p, a)((typeof(p))ALIGN((unsigned long)(p),
(a)))
#define IS_ALIGNED(x, a) (((x) & ((typeof(x))(a) - 1)) == 0)
diff --git a/include/video/udlfb.h b/include/video/udlfb.h
index f9466fa54ba4..3ea90aea5617 100644
--- a/include/video/udlfb.h
+++ b/include/video/udlfb.h
@@ -92,6 +92,6 @@ struct dlfb_data {
/* remove these once align.h patch is taken into kernel */
#define DL_ALIGN_UP(x, a) ALIGN(x, a)
-#define DL_ALIGN_DOWN(x, a) ALIGN(x-(a-1), a)
+#define DL_ALIGN_DOWN(x, a) ALIGN_DOWN(x, a)
#endif
--
2.9.3
[PATCH v5 0/2] crypto: hw_random - Add new Exynos RNG driver
Hi, This is a follow up of my questions around exynos-rng [1]. Changes since v4: = 1. Patch 2/2: Use "stdrng" name, as suggested by Herbert. 2. Patch 2/2: Add Bartlomiej's reviewed-by. Changes since v3: = 1. New patch: 1/2 for ALIGN_DOWN macro. The change in metag architecture was not compiled. Please test it. 2. Dropped patches touching ARM defconfig as they are not changing and they pollute this submission. 3. Utilize all seed provided by kcapi (suggested by Stephan Müller). 4. Drop dev->ctx (suggested by PrasannaKumar Muralidharan). 5. Remove any printks from set_seed callback as this might be a way for unprivileged user to pollute the log (suggested by Stephan). 6. Minor cleanups: initialize 'read' variable in exynos_rng_reseed() for readability (it is not strictly required). 7. Add review tags from Stephen and PrasannaKumar. Changes since v2: = 1. Do not re-use random numbers for re-seed (neither for system resume nor for periodic re-seed). Instead the driver will just generate new random numbers (suggested by Stephan Müller). Suspend path tested with suspend-to-freeze, not real suspend. Testing on Trats2 would be welcomed. Changes since v1: = 1. Re-work the code for seeding after system resume, following suggestions and review by Stephan Müller. 2. Re-seed itself from time to time (every 100 ms), suggested by Stephan Müller. 3. Use a define for retries (Bartlomiej Zolnierkiewicz). 4. Add some docs. Description: The existing exynos-rng has many issues. The most important one is that it is a pseudo RNG device but uses hw_random interface which does not allow proper seeding. The RNG module on Exynos4 requires seeding. On newer SoCs (like Exynos5420) it can seed itself from a true RNG. Converting the existing driver to use TRNG would effectively drop support for Exynos4 and break compatibility with existing users. Instead I decided to convert it to crypto API. In the future I hope to add support for seeding from TRNG module. Tested with app [2]. Patches are independent. I will take the defconfig changes (2/3 and 3/3) through samsung-soc tree. Best regards, Krzysztof [1] https://www.spinics.net/lists/arm-kernel/msg569641.html [2] https://www.spinics.net/lists/arm-kernel/msg571184.html Krzysztof Kozlowski (2): linux/kernel.h: Add ALIGN_DOWN macro crypto: hw_random - Add new Exynos RNG driver MAINTAINERS | 8 + arch/metag/kernel/stacktrace.c | 2 - drivers/char/hw_random/Kconfig | 14 -- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_random/exynos-rng.c | 231 - drivers/crypto/Kconfig | 15 ++ drivers/crypto/Makefile | 1 + drivers/crypto/exynos-rng.c | 389 drivers/gpu/drm/udl/udl_fb.c| 2 +- include/linux/kernel.h | 1 + include/video/udlfb.h | 2 +- 11 files changed, 416 insertions(+), 250 deletions(-) delete mode 100644 drivers/char/hw_random/exynos-rng.c create mode 100644 drivers/crypto/exynos-rng.c -- 2.9.3
[PATCH v5 2/2] crypto: hw_random - Add new Exynos RNG driver
Replace existing hw_ranndom/exynos-rng driver with a new, reworked one. This is a driver for pseudo random number generator block which on Exynos4 chipsets must be seeded with some value. On newer Exynos5420 chipsets it might seed itself from true random number generator block but this is not implemented yet. New driver is a complete rework to use the crypto ALGAPI instead of hw_random API. Rationale for the change: 1. hw_random interface is for true RNG devices. 2. The old driver was seeding itself with jiffies which is not a reliable source for randomness. 3. Device generates five random 32-bit numbers in each pass but old driver was returning only one 32-bit number thus its performance was reduced. Compatibility with DeviceTree bindings is preserved. New driver does not use runtime power management but manually enables and disables the clock when needed. This is preferred approach because using runtime PM just to toggle clock is huge overhead. Another difference is reseeding itself with generated random data periodically and during resuming from system suspend (previously driver was re-seeding itself again with jiffies). Signed-off-by: Krzysztof Kozlowski Reviewed-by: Stephan Müller Reviewed-by: PrasannaKumar Muralidharan Reviewed-by: Bartlomiej Zolnierkiewicz --- MAINTAINERS | 8 + drivers/char/hw_random/Kconfig | 14 -- drivers/char/hw_random/Makefile | 1 - drivers/char/hw_random/exynos-rng.c | 231 - drivers/crypto/Kconfig | 15 ++ drivers/crypto/Makefile | 1 + drivers/crypto/exynos-rng.c | 389 7 files changed, 413 insertions(+), 246 deletions(-) delete mode 100644 drivers/char/hw_random/exynos-rng.c create mode 100644 drivers/crypto/exynos-rng.c diff --git a/MAINTAINERS b/MAINTAINERS index affecc6d59f4..371fda859d43 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10977,6 +10977,14 @@ L: alsa-de...@alsa-project.org (moderated for non-subscribers) S: Supported F: sound/soc/samsung/ +SAMSUNG EXYNOS PSEUDO RANDOM NUMBER GENERATOR (RNG) DRIVER +M: Krzysztof Kozlowski +L: linux-crypto@vger.kernel.org +L: linux-samsung-...@vger.kernel.org +S: Maintained +F: drivers/crypto/exynos-rng.c +F: Documentation/devicetree/bindings/rng/samsung,exynos-rng4.txt + SAMSUNG FRAMEBUFFER DRIVER M: Jingoo Han L: linux-fb...@vger.kernel.org diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig index 0cafe08919c9..bdae802e7154 100644 --- a/drivers/char/hw_random/Kconfig +++ b/drivers/char/hw_random/Kconfig @@ -294,20 +294,6 @@ config HW_RANDOM_POWERNV If unsure, say Y. -config HW_RANDOM_EXYNOS - tristate "EXYNOS HW random number generator support" - depends on ARCH_EXYNOS || COMPILE_TEST - depends on HAS_IOMEM - default HW_RANDOM - ---help--- - This driver provides kernel-side support for the Random Number - Generator hardware found on EXYNOS SOCs. - - To compile this driver as a module, choose M here: the - module will be called exynos-rng. - - If unsure, say Y. - config HW_RANDOM_TPM tristate "TPM HW Random Number Generator support" depends on TCG_TPM diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile index 5f52b1e4e7be..6f1eecc2045c 100644 --- a/drivers/char/hw_random/Makefile +++ b/drivers/char/hw_random/Makefile @@ -24,7 +24,6 @@ obj-$(CONFIG_HW_RANDOM_OCTEON) += octeon-rng.o obj-$(CONFIG_HW_RANDOM_NOMADIK) += nomadik-rng.o obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o -obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o obj-$(CONFIG_HW_RANDOM_HISI) += hisi-rng.o obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o diff --git a/drivers/char/hw_random/exynos-rng.c b/drivers/char/hw_random/exynos-rng.c deleted file mode 100644 index 23d358553b21.. --- a/drivers/char/hw_random/exynos-rng.c +++ /dev/null @@ -1,231 +0,0 @@ -/* - * exynos-rng.c - Random Number Generator driver for the exynos - * - * Copyright (C) 2012 Samsung Electronics - * Jonghwa Lee - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA - * - */ - -#include -#include -#include -#include -#include -#incl
Re: [PATCH 0/7] arm64: marvell: add cryptographic engine support for 7k/8k
Hi Herbert, On lun., avril 10 2017, Herbert Xu wrote: > On Wed, Mar 29, 2017 at 02:44:25PM +0200, Antoine Tenart wrote: >> Hi all, >> >> This series adds support for the Inside Secure SafeXcel EIP197 >> cryptographic engine which can be found on Marvell Armada 7k and 8k >> boards. A new cryptographic engine driver is added, as well as the >> relevant device tree definition for the Armada 7040 DB and 8040 DB >> boards. >> >> This driver needs two firmwares to work correctly. These firmware are >> usually used for more advanced operations than the ones supported (as of >> now), but we still need them to pass the data to the internal >> cryptographic engine. >> >> This series was tested in various ways on both the Armada 7040 DB and >> the Armada 8040 DB: using the crypto framework self tests, using tcrypt >> and while performing various transfers with iperf on top of IPsec. >> >> This series is based on top of v4.11-rc1, and is available on a branch >> (which also contains the PPv2 support for 7k/8k, to ease the process of >> testing IPsec): https://github.com/atenart/linux v4.11-rc1/7k8k-crypto >> I can rebase if needed. >> >> Thanks, >> Antoine >> >> >> Antoine Tenart (7): >> Documentation/bindings: Document the SafeXel cryptographic engine >> driver >> crypto: inside-secure: add SafeXcel EIP197 crypto engine driver >> MAINTAINERS: add a maintainer for the Inside Secure crypto driver >> arm64: marvell: dts: add crypto engine description for 7k/8k >> arm64: marvell: dts: enable the crypto engine on the Armada 7040 DB >> arm64: marvell: dts: enable the crypto engine on the Armada 8040 DB >> arm64: defconfig: enable the Safexcel crypto engine as a module > > I have no problems with the crypto bits. Does it means that you agree that I apply the arm-soc related patches (from 4 to 7) to my mvebu trees? Thanks, Gregory > > Thanks, > -- > Email: Herbert Xu > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
[PATCH -next] crypto: caam - fix error return code in caam_qi_init()
From: Wei Yongjun
Fix to return error code -ENOMEM from the kmem_cache_create() error
handling case instead of 0(err is 0 here), as done elsewhere in this
function.
Fixes: 67c2315def06 ("crypto: caam - add Queue Interface (QI) backend support")
Signed-off-by: Wei Yongjun
---
drivers/crypto/caam/qi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/caam/qi.c b/drivers/crypto/caam/qi.c
index 45de8fd..1990ed4 100644
--- a/drivers/crypto/caam/qi.c
+++ b/drivers/crypto/caam/qi.c
@@ -789,7 +789,7 @@ int caam_qi_init(struct platform_device *caam_pdev)
dev_err(qidev, "Can't allocate CAAM cache\n");
free_rsp_fqs();
platform_device_unregister(qi_pdev);
- return err;
+ return -ENOMEM;
}
/* Done with the CGRs; restore the cpus allowed mask */
Re: Fwd: [linux-next:master 7274/8070] undefined reference to `crypto_alloc_shash'
Am Dienstag, 11. April 2017, 12:50:00 CEST schrieb Herbert Xu: Hi Herbert, > I see the problem. When you select CRYPTO_HASH you must also > select CRYPTO. Thank you very much. I will prepare a patch. Ciao Stephan
Re: Fwd: [linux-next:master 7274/8070] undefined reference to `crypto_alloc_shash'
On Mon, Apr 10, 2017 at 12:46:22PM +0200, Stephan Müller wrote: > Am Montag, 10. April 2017, 12:22:23 CEST schrieb Herbert Xu: > > Hi Herbert, > > > Hmm that's weird because CRYPTO_HASH selects CRYPTO_HASH2. Do > > you have a kconfig file that reproduces this? > > Please see attached. I see the problem. When you select CRYPTO_HASH you must also select CRYPTO. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
[bug report] padata: simplify serialization mechanism
Hello Steffen Klassert,
The patch 5f1a8c1bc724: "padata: simplify serialization mechanism"
from Jul 7, 2010, leads to the following static checker warning:
kernel/padata.c:243 padata_reorder()
warn: 'padata' is an error pointer or valid
kernel/padata.c
231 if (!spin_trylock_bh(&pd->lock))
232 return;
233
234 while (1) {
235 padata = padata_get_next(pd);
236
237 /*
238 * All reorder queues are empty, or the next object
that needs
239 * serialization is parallel processed by another cpu
and is
240 * still on it's way to the cpu's reorder queue,
nothing to
241 * do for now.
242 */
243 if (!padata || PTR_ERR(padata) == -EINPROGRESS)
^^
The comments still say that we sometimes return NULL but we removed that
in 2010.
244 break;
245
246 /*
247 * This cpu has to do the parallel processing of the
next
248 * object. It's waiting in the cpu's parallelization
queue,
249 * so exit immediately.
250 */
251 if (PTR_ERR(padata) == -ENODATA) {
252 del_timer(&pd->timer);
253 spin_unlock_bh(&pd->lock);
254 return;
255 }
regards,
dan carpenter
Re: [PATCH v4 2/2] crypto: hw_random - Add new Exynos RNG driver
On Mon, Apr 10, 2017 at 12:55 PM, Herbert Xu
wrote:
> On Sat, Apr 08, 2017 at 03:32:45PM +0200, Krzysztof Kozlowski wrote:
>>
>> +static struct rng_alg exynos_rng_alg = {
>> + .generate = exynos_rng_generate,
>> + .seed = exynos_rng_seed,
>> + .seedsize = EXYNOS_RNG_SEED_SIZE,
>> + .base = {
>> + .cra_name = "exynos_rng",
>
> Please use stdrng. Or is there a reason why this can't be used
> by the crypto layer itself?
I think there is no reason against, I'll fix it.
Best regards,
Krzysztof
