Re: [PATCH v3 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver

2017-05-22 Thread Thomas Petazzoni 
Hello,

On Mon, 22 May 2017 16:02:33 +0100, Marc Zyngier wrote:

> > It also says: 87 =>  34 En Lv 5, which is the IRQ I'm looking for.  
> 
> Ah, that one as well. So how is the interrupt routed? Via the ICU, and
> then to the GIC (with several ICU sources mapped on a single SPI)?

The crypto block being in the CP part, it has a wired interrupt to the
ICU (also in the CP). The ICU then turns this wired interrupt into a
memory write transaction to a register called GICP SPI in the AP, which
triggers a SPI interrupt in the GIC.

In the current mainline kernel, the ICU is configured by the firmware
and creates static associations between wired interrupts in the CP and
corresponding SPI interrupts. Therefore the Device Tree currently
reference such SPI interrupts directly.

However, I have a patch series that I plan to submit hopefully in the
next days that adds an ICU driver, and changes the Device Tree to refer
to the ICU interrupt instead.

Therefore, I don't think the binding should reference anything else
than the usual info about the interrupts property.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v5 1/4] Documentation/bindings: Document the SafeXel cryptographic engine driver

2017-05-22 Thread Thomas Petazzoni 
Hello,

On Mon, 22 May 2017 16:45:11 +0200, Antoine Tenart wrote:
> + interrupts =  IRQ_TYPE_LEVEL_HIGH)>,

You already got the feedback previously that an interrupt that is both
edge and level at the same time doesn't make sense. Could you fix this?

Also, the DTs that have already been merged by Grégory are wrong for
the same reason and should be fixed.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v2 1/2] dt-bindings: timeriomem_rng: Add entropy quality property

2017-05-22 Thread Rick Altherr 
Signed-off-by: Rick Altherr 
---

Changes in v2: None

 Documentation/devicetree/bindings/rng/timeriomem_rng.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt 
b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt
index 6616d15866a3..214940093b55 100644
--- a/Documentation/devicetree/bindings/rng/timeriomem_rng.txt
+++ b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt
@@ -5,6 +5,13 @@ Required properties:
 - reg : base address to sample from
 - period : wait time in microseconds to use between samples
 
+Optional properties:
+- quality : estimated number of bits of true entropy per 1024 bits read from 
the
+rng.  Defaults to zero which causes the kernel's default quality to
+be used instead.  Note that the default quality is usually zero
+which disables using this rng to automatically fill the kernel's
+entropy pool.
+
 N.B. currently 'reg' must be four bytes wide and aligned
 
 Example:
-- 
2.13.0.303.g4ebf302169-goog

[PATCH v2 2/2] hw_random: timeriomem_rng: Allow setting RNG quality from platform data

2017-05-22 Thread Rick Altherr 
When a hw_random device's quality is non-zero, it will automatically be
used to fill the kernel's entropy pool.  Since timeriomem_rng is used by
many different devices, the quality needs to be provided by platform
data or device tree.

Signed-off-by: Rick Altherr 
---

Changes in v2:
- Adjust header comment for platform data quality property to match code
and DT bindings

 drivers/char/hw_random/timeriomem-rng.c | 7 +++
 include/linux/timeriomem-rng.h  | 3 +++
 2 files changed, 10 insertions(+)

diff --git a/drivers/char/hw_random/timeriomem-rng.c 
b/drivers/char/hw_random/timeriomem-rng.c
index a0faa5f05deb..03ff5483d865 100644
--- a/drivers/char/hw_random/timeriomem-rng.c
+++ b/drivers/char/hw_random/timeriomem-rng.c
@@ -151,8 +151,15 @@ static int timeriomem_rng_probe(struct platform_device 
*pdev)
dev_err(>dev, "missing period\n");
return -EINVAL;
}
+
+   if (!of_property_read_u32(pdev->dev.of_node,
+   "quality", ))
+   priv->rng_ops.quality = i;
+   else
+   priv->rng_ops.quality = 0;
} else {
period = pdata->period;
+   priv->rng_ops.quality = pdata->quality;
}
 
priv->period = ns_to_ktime(period * NSEC_PER_USEC);
diff --git a/include/linux/timeriomem-rng.h b/include/linux/timeriomem-rng.h
index 46eb27ddbfab..3e00122bcf88 100644
--- a/include/linux/timeriomem-rng.h
+++ b/include/linux/timeriomem-rng.h
@@ -13,4 +13,7 @@ struct timeriomem_rng_data {
 
/* measures in usecs */
unsigned intperiod;
+
+   /* bits of entropy per 1024 bits read */
+   unsigned intquality;
 };
-- 
2.13.0.303.g4ebf302169-goog

Re: [PATCH] crypto: stm32 - Add CRC32 support for STM32F4XX

2017-05-22 Thread Rob Herring 
On Wed, May 17, 2017 at 12:18:50AM +0300, Cosar Dindar wrote:
> This patch series add hardware CRC32 ("Ethernet") calculation support
> for STMicroelectronics STM32F4XX series devices.
> 
> As an hardware limitation polynomial and key setting are not supported
> as they are fixed as 0x4C11DB7 (poly) and 0x (key).
> 
> CRC32C Castagnoli algorithm is not supported also.
> Module is tested on STM32F429-disco board with crypto testmgr using
> cases within the key 0x.
> 
> Signed-off-by: Cosar Dindar 
> ---
>  .../devicetree/bindings/crypto/st,stm32-crc.txt|  4 +-
>  arch/arm/boot/dts/stm32429i-eval.dts   |  4 ++
>  arch/arm/boot/dts/stm32f429-disco.dts  |  4 ++
>  arch/arm/boot/dts/stm32f429.dtsi   |  7 +++
>  arch/arm/boot/dts/stm32f469-disco.dts  |  4 ++
>  drivers/crypto/stm32/stm32_crc32.c | 68 
> ++
>  6 files changed, 79 insertions(+), 12 deletions(-)

Acked-by: Rob Herring

Re: [PATCH v1] crypto: img-hash - Handle return value of clk_prepare_enable

2017-05-22 Thread Herbert Xu 
On Tue, May 16, 2017 at 01:57:41PM +0530, Arvind Yadav wrote:
> Here, Clock enable can failed. So adding an error check for
> clk_prepare_enable.
> 
> Signed-off-by: Arvind Yadav 

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] crypto: x86/aes - Don't use %rbp as temporary register

2017-05-22 Thread Herbert Xu 
On Tue, May 16, 2017 at 09:03:08PM -0700, Eric Biggers wrote:
> From: Eric Biggers 
> 
> When using the "aes-asm" implementation of AES (*not* the AES-NI
> implementation) on an x86_64, v4.12-rc1 kernel with lockdep enabled, the
> following warning was reported, along with a long unwinder dump:
> 
>   WARNING: kernel stack regs at c9643558 in kworker/u4:2:155 has 
> bad 'bp' value 001c
> 
> The problem is that aes_enc_block() and aes_dec_block() use %rbp as a
> temporary register, which breaks stack traces if an interrupt occurs.
> 
> Fix this by replacing %rbp with %r9, which was being used to hold the
> saved value of %rbp.  This required rearranging the AES round macro
> slightly since %r9d cannot be used as the target of a move from %ah-%dh.
> 
> Performance is essentially unchanged --- actually about 0.2% faster than
> before.  Interestingly, I also measured aes-generic as being nearly 7%
> faster than aes-asm, so perhaps aes-asm has outlived its usefulness...
> 
> Signed-off-by: Eric Biggers 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Crypto Fixes for 4.12

2017-05-22 Thread Herbert Xu 
Hi Linus:

This push fixes a regression in the skcipher interface that allows
bogus key parameters to hit underlying implementations which can
cause crashes.


Please pull from

git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus


Herbert Xu (1):
  crypto: skcipher - Add missing API setkey checks

 crypto/skcipher.c |   40 +++-
 1 file changed, 39 insertions(+), 1 deletion(-)

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

2017-05-22 Thread Herbert Xu 
On Thu, Apr 27, 2017 at 05:17:58PM +0300, Tudor Ambarus wrote:
> Hi, Herbert,
> 
> I'm working with a crypto accelerator that is capable of generating and
> retaining ecc private keys in hardware and further use them for ecdh.
> The private keys can not be read from the device. This is good because
> the less software has access to secrets, the better.
> 
> Generation and retention of ecc private keys are also helpful in a user
> space to kernel ecdh offload. The privkey can be generated in kernel and
> never revealed to user space.
> 
> I propose to extend the ecc software support to allow the generation of
> private keys. ECDH software implementation and drivers will permit the
> users to provide NULL keys. In this case, the kernel (or the device, if
> possible) will generate the ecc private key and further use it for ecdh.
> 
> What's your feeling on this?

It sounds sane to me.

It does raise the question though whether we need the ability to set the
secret at all.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH 6/8] crypto: dh - fix dh_max_size

2017-05-22 Thread Herbert Xu 
On Fri, May 12, 2017 at 01:11:44PM +0300, Tudor Ambarus wrote:
> The function should return minimum size for output buffer
> or error code if key hasn't been set.
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  crypto/dh.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/crypto/dh.c b/crypto/dh.c
> index 7cec0498..325a5dd 100644
> --- a/crypto/dh.c
> +++ b/crypto/dh.c
> @@ -148,7 +148,7 @@ static int dh_max_size(struct crypto_kpp *tfm)
>  {
>   struct dh_ctx *ctx = dh_get_ctx(tfm);
>  
> - return mpi_get_size(ctx->p);
> + return ctx->p ? mpi_get_size(ctx->p) : -EINVAL;
>  }

How about ENOKEY?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2 04/11] crypto: dh - fix dh_max_size

2017-05-22 Thread Herbert Xu 
On Wed, May 17, 2017 at 06:00:31PM +0300, Tudor Ambarus wrote:
> The function should return minimum size for output buffer
> or error code if key hasn't been set.
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  crypto/dh.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/crypto/dh.c b/crypto/dh.c
> index 7cec0498..325a5dd 100644
> --- a/crypto/dh.c
> +++ b/crypto/dh.c
> @@ -148,7 +148,7 @@ static int dh_max_size(struct crypto_kpp *tfm)
>  {
>   struct dh_ctx *ctx = dh_get_ctx(tfm);
>  
> - return mpi_get_size(ctx->p);
> + return ctx->p ? mpi_get_size(ctx->p) : -EINVAL;

How about ENOKEY?

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v2 08/11] crypto: testmgr - check err on akcipher maxsize

2017-05-22 Thread Herbert Xu 
On Wed, May 17, 2017 at 06:00:35PM +0300, Tudor Ambarus wrote:
> crypto_akcipher_maxsize() returns minimum length for output buffer
> or error code if key hasn't been set.
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  crypto/testmgr.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c
> index 6f5f3ed..87a4abd 100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -2150,6 +2150,11 @@ static int test_akcipher_one(struct crypto_akcipher 
> *tfm,
>  
>   err = -ENOMEM;
>   out_len_max = crypto_akcipher_maxsize(tfm);

Can this call be reached without a setkey or with a failed setkey?
If not we should not check for errors.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] crypto: qat: use pcie_flr instead of duplicating it

2017-05-22 Thread Herbert Xu 
On Tue, May 16, 2017 at 04:21:05PM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig 

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 v1] hw_random : omap3-rom-rng:- Handle return value of clk_prepare_enable

2017-05-22 Thread Herbert Xu 
On Mon, May 15, 2017 at 01:52:03PM +0530, Arvind Yadav wrote:
> Here, Clock enable can failed. So adding an error check for
> clk_prepare_enable.
> 
> Signed-off-by: Arvind Yadav 

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 v2 0/4] crypto: async crypto op fixes

2017-05-22 Thread Herbert Xu 
On Thu, May 18, 2017 at 04:29:22PM +0300, Gilad Ben-Yossef wrote:
> This patch set fixes various usage and documentation errors
> in waiting for async crypto op to complete which can result
> in data corruption.
> 
> Note: these were discovered in the process of working on a
> patch set that replaces these call sites and more with a
> generic implementation that will prevent these problems
> going forward. These are just the fix ups for current code.
> 
> Signed-off-by: Gilad Ben-Yossef 
> CC: sta...@vger.kernel.org
> CC: Eric Biggers 

Patches 1-3 applied.  Please fix patch 4 and resubmit.  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 0/9] crypto: add HMAC IPAD/OPAD constant

2017-05-22 Thread Herbert Xu 
On Fri, May 19, 2017 at 08:53:22AM +0200, Corentin Labbe wrote:
> Hello
> 
> Many HMAC users directly use directly 0x36/0x5c values.
> It's better with crypto to use a name instead of directly some crypto 
> constant.
> 
> Changes since v1:
> - Moved constant to include/crypto/hmac.h
> - Added  to includes
> 
> Corentin Labbe (9):
>   crypto: add hmac IPAD/OPAD constant
>   crypto: brcm - Use IPAD/OPAD constant
>   crypto: ixp4xx - Use IPAD/OPAD constant
>   crypto: marvell - Use IPAD/OPAD constant
>   crypto: mv_cesa - Use IPAD/OPAD constant
>   crypto: omap-sham - Use IPAD/OPAD constant
>   crypto: qat - Use IPAD/OPAD constant
>   crypto: mediatek - Use IPAD/OPAD constant
>   crypto: ccp - Use IPAD/OPAD constant

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v5 2/4] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver

2017-05-22 Thread Antoine Tenart 
Add support for Inside Secure SafeXcel EIP197 cryptographic engine,
which can be found on Marvell Armada 7k and 8k boards. This driver
currently implements: ecb(aes), cbc(aes), sha1, sha224, sha256 and
hmac(sah1) algorithms.

Two firmwares are needed for this engine to work. Their are mostly 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.

Signed-off-by: Antoine Tenart 
---
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/inside-secure/Makefile  |2 +
 drivers/crypto/inside-secure/safexcel.c|  930 +
 drivers/crypto/inside-secure/safexcel.h|  572 +
 drivers/crypto/inside-secure/safexcel_cipher.c |  556 +
 drivers/crypto/inside-secure/safexcel_hash.c   | 1045 
 drivers/crypto/inside-secure/safexcel_ring.c   |  157 
 8 files changed, 3280 insertions(+)
 create mode 100644 drivers/crypto/inside-secure/Makefile
 create mode 100644 drivers/crypto/inside-secure/safexcel.c
 create mode 100644 drivers/crypto/inside-secure/safexcel.h
 create mode 100644 drivers/crypto/inside-secure/safexcel_cipher.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_hash.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_ring.c

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index fb1e60f5002e..9cf41cc846bb 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -643,4 +643,21 @@ config CRYPTO_DEV_BCM_SPU
 
 source "drivers/crypto/stm32/Kconfig"
 
+config CRYPTO_DEV_SAFEXCEL
+   tristate "Inside Secure's SafeXcel cryptographic engine driver"
+   depends on HAS_DMA && OF
+   depends on (ARM64 && ARCH_MVEBU) || (COMPILE_TEST && 64BIT)
+   select CRYPTO_AES
+   select CRYPTO_BLKCIPHER
+   select CRYPTO_HASH
+   select CRYPTO_HMAC
+   select CRYPTO_SHA1
+   select CRYPTO_SHA256
+   select CRYPTO_SHA512
+   help
+ This driver interfaces with the SafeXcel EIP-197 cryptographic engine
+ designed by Inside Secure. Select this if you want to use CBC/ECB
+ chain mode, AES cipher mode and SHA1/SHA224/SHA256/SHA512 hash
+ algorithms.
+
 endif # CRYPTO_HW
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
index 463f33592d93..67572e4afaae 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -39,3 +39,4 @@ obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
 obj-$(CONFIG_CRYPTO_DEV_VIRTIO) += virtio/
 obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
 obj-$(CONFIG_CRYPTO_DEV_BCM_SPU) += bcm/
+obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += inside-secure/
diff --git a/drivers/crypto/inside-secure/Makefile 
b/drivers/crypto/inside-secure/Makefile
new file mode 100644
index ..302f07dde98c
--- /dev/null
+++ b/drivers/crypto/inside-secure/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_CRYPTO_DEV_SAFEXCEL) += crypto_safexcel.o
+crypto_safexcel-objs := safexcel.o safexcel_ring.o safexcel_cipher.o 
safexcel_hash.o
diff --git a/drivers/crypto/inside-secure/safexcel.c 
b/drivers/crypto/inside-secure/safexcel.c
new file mode 100644
index ..5485e925e18d
--- /dev/null
+++ b/drivers/crypto/inside-secure/safexcel.c
@@ -0,0 +1,930 @@
+/*
+ * Copyright (C) 2017 Marvell
+ *
+ * Antoine Tenart 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "safexcel.h"
+
+static u32 max_rings = EIP197_MAX_RINGS;
+module_param(max_rings, uint, 0644);
+MODULE_PARM_DESC(max_rings, "Maximum number of rings to use.");
+
+static void eip197_trc_cache_init(struct safexcel_crypto_priv *priv)
+{
+   u32 val, htable_offset;
+   int i;
+
+   /* Enable the record cache memory access */
+   val = readl(priv->base + EIP197_CS_RAM_CTRL);
+   val &= ~EIP197_TRC_ENABLE_MASK;
+   val |= EIP197_TRC_ENABLE_0;
+   writel(val, priv->base + EIP197_CS_RAM_CTRL);
+
+   /* Clear all ECC errors */
+   writel(0, priv->base + EIP197_TRC_ECCCTRL);
+
+   /*
+* Make sure the cache memory is accessible by taking record cache into
+* reset.
+*/
+   val = readl(priv->base + EIP197_TRC_PARAMS);
+   val |= EIP197_TRC_PARAMS_SW_RESET;
+   val &= ~EIP197_TRC_PARAMS_DATA_ACCESS;
+   writel(val, priv->base + EIP197_TRC_PARAMS);
+
+   /* Clear all records */
+   for (i = 0; i < EIP197_CS_RC_MAX; i++) {
+   u32 val, offset = EIP197_CLASSIFICATION_RAMS + i * 
EIP197_CS_RC_SIZE;
+
+   writel(EIP197_CS_RC_NEXT(EIP197_RC_NULL) |
+

[PATCH v5 1/4] Documentation/bindings: Document the SafeXel cryptographic engine driver

2017-05-22 Thread Antoine Tenart 
The Inside Secure Safexcel cryptographic engine is found on some Marvell
SoCs (7k/8k). Document the bindings used by its driver.

Signed-off-by: Antoine Tenart 
---
 .../bindings/crypto/inside-secure-safexcel.txt | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt

diff --git 
a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt 
b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
new file mode 100644
index ..37abbb2ca250
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
@@ -0,0 +1,29 @@
+Inside Secure SafeXcel cryptographic engine
+
+Required properties:
+- compatible: Should be "inside-secure,safexcel-eip197".
+- reg: Base physical address of the engine and length of memory mapped region.
+- interrupts: Interrupt numbers for the rings and engine.
+- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".
+
+Optional properties:
+- clocks: Reference to the crypto engine clock.
+- dma-mask: The address mask limitation. Defaults to 64.
+
+Example:
+
+   crypto: crypto@80 {
+   compatible = "inside-secure,safexcel-eip197";
+   reg = <0x80 0x20>;
+   interrupts = ,
+,
+,
+,
+,
+;
+   interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3",
+ "eip";
+   clocks = <_syscon0 1 26>;
+   dma-mask = <0xff 0x>;
+   status = "disabled";
+   };
-- 
2.9.4

[PATCH v3 0/5] Add support for the STM32F4 CRC32

2017-05-22 Thread Cosar Dindar 
This patch series add hardware CRC32 ("Ethernet") calculation support
for STMicroelectronics STM32F429.

Polynomial and key setting are not supported, key is fixed as 0x4C11DB7
and poly is 0x.

Module is tested on STM32F429-disco board with crypto testmgr using
cases within the key 0x.

Changes in v3:
Rearranged patch order to fix build test error.

Cosar Dindar (5):
  dt-bindings : Document the STM32F4 CRC32 binding
  crypto : stm32 - Add STM32F4 CRC32 support
  ARM: dts: stm32: Add CRC support to stm32f429
  ARM: dts: stm32: enable CRC32 on stm32429-disco board
  ARM: dts: stm32: enable CRC32 on stm32429i-eval board

 .../devicetree/bindings/crypto/st,stm32-crc.txt|  4 +-
 arch/arm/boot/dts/stm32429i-eval.dts   |  4 ++
 arch/arm/boot/dts/stm32f429-disco.dts  |  4 ++
 arch/arm/boot/dts/stm32f429.dtsi   |  7 +++
 drivers/crypto/stm32/stm32_crc32.c | 68 ++
 5 files changed, 75 insertions(+), 12 deletions(-)

-- 
2.7.4

Re: [PATCH v3 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver

2017-05-22 Thread Marc Zyngier 
Hi Antoine,

On 22/05/17 15:30, Antoine Tenart wrote:
> Hi Marc,
> 
> On Wed, May 03, 2017 at 05:36:38PM +0100, Marc Zyngier wrote:
>> On 24/04/17 08:54, Antoine Tenart wrote:
>>> +
>>> +   crypto: crypto@80 {
>>> +   compatible = "inside-secure,safexcel-eip197";
>>> +   reg = <0x80 0x20>;
>>> +   interrupts = >> IRQ_TYPE_LEVEL_HIGH)>,
>>
>> I'm puzzled. How can the interrupt can be both level *and* edge? That
>> doesn't make any sense.
> 
> I agree this looks odd. I took it from Russel's ICU mapping:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489040.html

This emails says:

ICU-irq => GIC-SPI-num Enable Edge/Level ICU-group
[...]
   24 =>  34 En Lv 0

which seems to clearly indicate Level (no Edge involved here).

> The driver does not use this interrupt (yet?). I'm not sure what is this
> interrupt exact configuration...

Surely the TRM would indicate this, wouldn't it?

> Do you want me to remove this from the documentation (and device trees)?

I'd rather you clarify it, if possible.

Thanks,

M.
-- 
Jazz is not dead. It just smells funny...

Re: [PATCH v3 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver

2017-05-22 Thread Antoine Tenart 
On Mon, May 22, 2017 at 03:48:30PM +0100, Marc Zyngier wrote:
> On 22/05/17 15:30, Antoine Tenart wrote:
> > On Wed, May 03, 2017 at 05:36:38PM +0100, Marc Zyngier wrote:
> >> On 24/04/17 08:54, Antoine Tenart wrote:
> >>> +
> >>> + crypto: crypto@80 {
> >>> + compatible = "inside-secure,safexcel-eip197";
> >>> + reg = <0x80 0x20>;
> >>> + interrupts =  >>> IRQ_TYPE_LEVEL_HIGH)>,
> >>
> >> I'm puzzled. How can the interrupt can be both level *and* edge? That
> >> doesn't make any sense.
> > 
> > I agree this looks odd. I took it from Russel's ICU mapping:
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489040.html
> 
> This emails says:
> 
> ICU-irq => GIC-SPI-num Enable Edge/Level ICU-group
> [...]
>24 =>  34 En Lv 0

It also says: 87 =>  34 En Lv 5, which is the IRQ I'm looking for.

Antoine.

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v3 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver

2017-05-22 Thread Antoine Tenart 
Hi Marc,

On Wed, May 03, 2017 at 05:36:38PM +0100, Marc Zyngier wrote:
> On 24/04/17 08:54, Antoine Tenart wrote:
> > +
> > +   crypto: crypto@80 {
> > +   compatible = "inside-secure,safexcel-eip197";
> > +   reg = <0x80 0x20>;
> > +   interrupts =  > IRQ_TYPE_LEVEL_HIGH)>,
> 
> I'm puzzled. How can the interrupt can be both level *and* edge? That
> doesn't make any sense.

I agree this looks odd. I took it from Russel's ICU mapping:
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-February/489040.html

The driver does not use this interrupt (yet?). I'm not sure what is this
interrupt exact configuration...

Do you want me to remove this from the documentation (and device trees)?

Thanks,
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH v3 1/5] dt-bindings : Document the STM32F4 CRC32 binding

2017-05-22 Thread Cosar Dindar 
Add device tree binding for STM32F4.

Signed-off-by: Cosar Dindar 
---
 Documentation/devicetree/bindings/crypto/st,stm32-crc.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt 
b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
index 3ba92a5..7b30f1e 100644
--- a/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
+++ b/Documentation/devicetree/bindings/crypto/st,stm32-crc.txt
@@ -1,7 +1,7 @@
 * STMicroelectronics STM32 CRC
 
 Required properties:
-- compatible: Should be "st,stm32f7-crc".
+- compatible: Can be either "st,stm32f7-crc" or "st,srm32f4-crc".
 - reg: The address and length of the peripheral registers space
 - clocks: The input clock of the CRC instance
 
@@ -10,7 +10,7 @@ Optional properties: none
 Example:
 
 crc: crc@40023000 {
-   compatible = "st,stm32f7-crc";
+   compatible = "st,stm32f7-crc", "st,stm32f4-crc";
reg = <0x40023000 0x400>;
clocks = < 0 12>;
 };
-- 
2.7.4

[PATCH v3 2/5] crypto : stm32 - Add STM32F4 CRC32 support

2017-05-22 Thread Cosar Dindar 
This patch adds CRC (CRC32 Crypto) support for STM32F4 series.

As an hardware limitation polynomial and key setting are not supported.
They are fixed as 0x4C11DB7 (poly) and 0x (key).
CRC32C Castagnoli algorithm is not used.

Signed-off-by: Cosar Dindar 
---
 drivers/crypto/stm32/stm32_crc32.c | 68 --
 1 file changed, 58 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/stm32/stm32_crc32.c 
b/drivers/crypto/stm32/stm32_crc32.c
index ec83b1e..12fbd98 100644
--- a/drivers/crypto/stm32/stm32_crc32.c
+++ b/drivers/crypto/stm32/stm32_crc32.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -39,6 +40,9 @@ struct stm32_crc {
struct clk   *clk;
u8   pending_data[sizeof(u32)];
size_t   nb_pending_bytes;
+   bool key_support;
+   bool poly_support;
+   bool reverse_support;
 };
 
 struct stm32_crc_list {
@@ -106,13 +110,31 @@ static int stm32_crc_init(struct shash_desc *desc)
}
spin_unlock_bh(_list.lock);
 
-   /* Reset, set key, poly and configure in bit reverse mode */
-   writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
-   writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
-   writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+   /* set key */
+   if (ctx->crc->key_support) {
+   writel(bitrev32(mctx->key), ctx->crc->regs + CRC_INIT);
+   } else if (mctx->key != CRC_INIT_DEFAULT) {
+   dev_err(ctx->crc->dev, "Unsupported key value! Should be: 
0x%x\n",
+   CRC_INIT_DEFAULT);
+   return -EINVAL;
+   }
+
+   /* set poly */
+   if (ctx->crc->poly_support)
+   writel(bitrev32(mctx->poly), ctx->crc->regs + CRC_POL);
+
+   /* reset and configure in bit reverse mode if supported */
+   if (ctx->crc->reverse_support)
+   writel(CRC_CR_RESET | CRC_CR_REVERSE, ctx->crc->regs + CRC_CR);
+   else
+   writel(CRC_CR_RESET, ctx->crc->regs + CRC_CR);
+
+   /* store partial result */
+   if (!ctx->crc->reverse_support)
+   ctx->partial = bitrev32(readl(crc->regs + CRC_DR));
+   else
+   ctx->partial = readl(ctx->crc->regs + CRC_DR);
 
-   /* Store partial result */
-   ctx->partial = readl(ctx->crc->regs + CRC_DR);
ctx->crc->nb_pending_bytes = 0;
 
return 0;
@@ -135,7 +157,12 @@ static int stm32_crc_update(struct shash_desc *desc, const 
u8 *d8,
 
if (crc->nb_pending_bytes == sizeof(u32)) {
/* Process completed pending data */
-   writel(*(u32 *)crc->pending_data, crc->regs + CRC_DR);
+   if (!ctx->crc->reverse_support)
+   writel(bitrev32(*(u32 *)crc->pending_data),
+  crc->regs + CRC_DR);
+   else
+   writel(*(u32 *)crc->pending_data,
+  crc->regs + CRC_DR);
crc->nb_pending_bytes = 0;
}
}
@@ -143,10 +170,16 @@ static int stm32_crc_update(struct shash_desc *desc, 
const u8 *d8,
d32 = (u32 *)d8;
for (i = 0; i < length >> 2; i++)
/* Process 32 bits data */
-   writel(*(d32++), crc->regs + CRC_DR);
+   if (!ctx->crc->reverse_support)
+   writel(bitrev32(*(d32++)), crc->regs + CRC_DR);
+   else
+   writel(*(d32++), crc->regs + CRC_DR);
 
/* Store partial result */
-   ctx->partial = readl(crc->regs + CRC_DR);
+   if (!ctx->crc->reverse_support)
+   ctx->partial = bitrev32(readl(crc->regs + CRC_DR));
+   else
+   ctx->partial = readl(crc->regs + CRC_DR);
 
/* Check for pending data (non 32 bits) */
length &= 3;
@@ -243,6 +276,7 @@ static int stm32_crc_probe(struct platform_device *pdev)
struct stm32_crc *crc;
struct resource *res;
int ret;
+   int algs_size;
 
crc = devm_kzalloc(dev, sizeof(*crc), GFP_KERNEL);
if (!crc)
@@ -269,13 +303,26 @@ static int stm32_crc_probe(struct platform_device *pdev)
return ret;
}
 
+   /* set key, poly and reverse support if device is of F7 series */
+   if (of_device_is_compatible(crc->dev->of_node, "st,stm32f7-crc")) {
+   crc->key_support = true;
+   crc->poly_support = true;
+   crc->reverse_support = true;
+   }
+
platform_set_drvdata(pdev, crc);
 
spin_lock(_list.lock);
list_add(>list, _list.dev_list);
spin_unlock(_list.lock);
 
-   ret = crypto_register_shashes(algs, ARRAY_SIZE(algs));
+   /* For F4 series only CRC32 algorithm will be used */
+   if

[PATCH v5 0/4] arm64: marvell: add cryptographic engine support for 7k/8k

2017-05-22 Thread Antoine Tenart 
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.12-rc1, and is available at:
https://github.com/atenart/linux  v4.12-rc1/7k8k-crypto
I can rebase if needed. Patches adding device tree nodes and modifying
the arm64 defconfig have been applied to the mvebu tree already.

I'd like to thank Ofer Heifetz and Igal Liberman who helped me to do
this driver by adding functionalities, optimizing functions and testing
(a lot).

Thanks,
Antoine

Since v4:
  - Added a dma-mask property and updated the default DMA mask to 64.
  - Replaced all  to .
  - Rebased on top of 4.12-rc1.

Since v3:
  - Updated to use the skcipher API instead of the ablkcipher one.
  - Added explicit zeroing of the keys.
  - Fixed the DMA mask.
  - Removed a few remaining phys_addr_t.

Since v2:
  - Used sha*_zero_message_hash definitions instead of custom ones.
  - Used memzero_explicit() instead of memset() to avoid leaks.
  - Misc cosmetic updates.

Since v1:
  - Fixed two compilation issues reported by Kbuild.
  - Removed all dma_to_phys() calls and used the dma addresses instead.
  - Added a call to dma_set_mask_and_coherent() before calling any DMA
API helper.
  - Removed some DMA free functions to avoid double-freeing.
  - Do not rely on sg_nents_for_len() to get the number of sg anymore.
  - Added a dedicated kmalloc'ed cache to use for dma_map_single().

Antoine Tenart (4):
  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 dma-mask in crypto nodes for 7k/8k

 .../bindings/crypto/inside-secure-safexcel.txt |   29 +
 MAINTAINERS|6 +
 .../boot/dts/marvell/armada-cp110-master.dtsi  |1 +
 .../arm64/boot/dts/marvell/armada-cp110-slave.dtsi |1 +
 drivers/crypto/Kconfig |   17 +
 drivers/crypto/Makefile|1 +
 drivers/crypto/inside-secure/Makefile  |2 +
 drivers/crypto/inside-secure/safexcel.c|  930 +
 drivers/crypto/inside-secure/safexcel.h|  572 +++
 drivers/crypto/inside-secure/safexcel_cipher.c |  556 +++
 drivers/crypto/inside-secure/safexcel_hash.c   | 1045 
 drivers/crypto/inside-secure/safexcel_ring.c   |  157 +++
 12 files changed, 3317 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
 create mode 100644 drivers/crypto/inside-secure/Makefile
 create mode 100644 drivers/crypto/inside-secure/safexcel.c
 create mode 100644 drivers/crypto/inside-secure/safexcel.h
 create mode 100644 drivers/crypto/inside-secure/safexcel_cipher.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_hash.c
 create mode 100644 drivers/crypto/inside-secure/safexcel_ring.c

-- 
2.9.4

[PATCH v5 3/4] MAINTAINERS: add a maintainer for the Inside Secure crypto driver

2017-05-22 Thread Antoine Tenart 
A new cryptographic engine driver was added in
drivers/crypto/inside-secure. Add myself as a maintainer for this
driver.

Signed-off-by: Antoine Tenart 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f7d568b8f133..1f2017604f16 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6602,6 +6602,12 @@ F:   Documentation/input/multi-touch-protocol.rst
 F: drivers/input/input-mt.c
 K: \b(ABS|SYN)_MT_
 
+INSIDE SECURE CRYPTO DRIVER
+M: Antoine Tenart 
+F: drivers/crypto/inside-secure/
+S: Maintained
+L: linux-crypto@vger.kernel.org
+
 INTEL ASoC BDW/HSW DRIVERS
 M: Jie Yang 
 L: alsa-de...@alsa-project.org (moderated for non-subscribers)
-- 
2.9.4

[PATCH] crypto: rng: Remove unused function __crypto_rng_cast()

2017-05-22 Thread Matthias Kaehlcke 
This fixes the following warning when building with clang:

crypto/rng.c:35:34: error: unused function '__crypto_rng_cast'
[-Werror,-Wunused-function]

Signed-off-by: Matthias Kaehlcke 
---
 crypto/rng.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/crypto/rng.c b/crypto/rng.c
index f46dac5288b9..5e8469244960 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -33,11 +33,6 @@ struct crypto_rng *crypto_default_rng;
 EXPORT_SYMBOL_GPL(crypto_default_rng);
 static int crypto_default_rng_refcnt;
 
-static inline struct crypto_rng *__crypto_rng_cast(struct crypto_tfm *tfm)
-{
-   return container_of(tfm, struct crypto_rng, base);
-}
-
 int crypto_rng_reset(struct crypto_rng *tfm, const u8 *seed, unsigned int slen)
 {
u8 *buf = NULL;
-- 
2.13.0.303.g4ebf302169-goog