Re: [PATCH 5/7] x86, boot, LLVM: Use regparm=0 for memcpy and memset

[H. Peter Anvin]

On 03/17/17 05:08, Peter Zijlstra wrote:
> On Thu, Mar 16, 2017 at 05:15:18PM -0700, Michael Davidson wrote:
>> Use the standard regparm=0 calling convention for memcpy and
>> memset when building with clang.
>>
>> This is a work around for a long standing clang bug
>> (see https://llvm.org/bugs/show_bug.cgi?id=3997) where
>> clang always uses the standard regparm=0 calling convention
>> for any implcit calls to memcpy and memset that it generates
>> (eg for structure assignments and initialization) even if an
>> alternate calling convention such as regparm=3 has been specified.
> 
> Seriously, fix LLVM already.
> 

Yes, this is a real stinker, in no small part because once clang is
fixed to DTRT then this is actually broken...

-hpa

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Richard Henderson]

On 06/22/2017 09:48 AM, Logan Gunthorpe wrote:

Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.

For this, we simply use calls that chain two 32-bit operations.
(mostly because I don't really understand the alpha architecture.)


It's not difficult to provide this interface[*].  I believe the only reason I 
didn't do so from the beginning is that it wasn't used.




r~


* At least for systems other than Jensen, which cannot generate 64-bit I/O.  On 
the other hand, Jensen doesn't have PCI (EISA only), and so won't have any 
devices that care.

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Logan Gunthorpe]

On 6/22/2017 3:03 PM, Arnd Bergmann wrote:

Drivers that want a non-atomic variant should include either
include/linux/io-64-nonatomic-hi-lo.h or include/linux/io-64-nonatomic-lo-hi.h
depending on what they need. Drivers that require 64-bit I/O should
probably just depend on CONFIG_64BIT and maybe use readq/writeq.


Ok, I will work something like that up.

We'll still need a patch similar to patch 2 (less the non-atomic 
versions) seeing even CONFIG_GENERIC_IOMAP arches don't actually have a 
working ioread64/iowrite64 implementation.


Thanks,

Logan

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Arnd Bergmann]

On Thu, Jun 22, 2017 at 10:09 PM, Logan Gunthorpe  wrote:
> On 6/22/2017 2:08 PM, Alan Cox wrote:
>>
>> But this does not do the same thing as an ioread64 with regards to
>> atomicity or side effects on the device. The same is true of the other
>> hacks. You either have a real 64bit single read/write from MMIO space or
>> you don't. You can't fake it.
>
>
> Yes, I know. But is it not better than having every driver that wants to use
> these functions fake it themselves?

Drivers that want a non-atomic variant should include either
include/linux/io-64-nonatomic-hi-lo.h or include/linux/io-64-nonatomic-lo-hi.h
depending on what they need. Drivers that require 64-bit I/O should
probably just depend on CONFIG_64BIT and maybe use readq/writeq.

I see that there are exactly two drivers calling ioread64/iowrite64:
drivers/crypto/caam/ is architecture specific and
drivers/ntb/hw/intel/ntb_hw_intel.c already has a workaround that should
make it build on alpha.

Arnd

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

[Logan Gunthorpe]

On 6/22/2017 2:36 PM, Alan Cox wrote:

I think that makes sense for the platforms with that problem. I'm not
sure there are many that can't do it for mmio at least. 486SX can't do it
and I guess some ARM32 but I think almost everyone else can including
most 32bit x86.

What's more of a problem is a lot of platforms can do 64bit MMIO via
ioread/write64 but not 64bit port I/O, and it's not clear how you
represent that via an ioread/write API that abstracts it away.


In Patch 2, we call bad_io_access for anyone trying to do 64bit accesses 
on port I/O.


Logan

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

[Alan Cox]

On Thu, 22 Jun 2017 14:24:58 -0600
Logan Gunthorpe  wrote:

> On 6/22/2017 2:14 PM, Alan Cox wrote:
> > If a platform doesn't support 64bit I/O operations from the CPU then you
> > either need to use some kind of platform/architecture specific interface
> > if present or accept you don't have one.  
> 
> Yes, I understand that.
> 
> The thing is that every user that's currently using it right now is 
> patching in their own version that splits it on non-64bit systems.
> 
> > It's not safe to split it. Possibly for some use cases you could add an
> > ioread64_maysplit()  
> 
> I'm open to doing something like that.

I think that makes sense for the platforms with that problem. I'm not
sure there are many that can't do it for mmio at least. 486SX can't do it
and I guess some ARM32 but I think almost everyone else can including
most 32bit x86.

What's more of a problem is a lot of platforms can do 64bit MMIO via
ioread/write64 but not 64bit port I/O, and it's not clear how you
represent that via an ioread/write API that abstracts it away.

Alan

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

[Logan Gunthorpe]

On 6/22/2017 2:14 PM, Alan Cox wrote:

If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.


Yes, I understand that.

The thing is that every user that's currently using it right now is 
patching in their own version that splits it on non-64bit systems.



It's not safe to split it. Possibly for some use cases you could add an
ioread64_maysplit()


I'm open to doing something like that.


What btw is the actual ARM compiler warning ? Is the compiler also trying
to tell you it's a bad idea ?


It's just the compiler noting that you are mixing volatile and 
non-volatile pointers. Strangely some io{read|write}XX use volatile but 
most do not. But it's nothing crazy.


Logan

Re: [PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

[Alan Cox]

On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe  wrote:

> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks such as those at the top of
> 
> drivers/ntb/hw/intel/ntb_hw_intel.c
> 
> This patch adds fallback implementations for when CONFIG_64BIT and
> CONFIG_GENERIC_IOMAP are not set. These functions use two io32 based
> calls to complete the operation.
> 
> Note, we do not use the volatile keyword in these functions like the
> others in the same file. It is necessary to avoid a compiler warning
> on arm.

This is a really really bad idea as per the Alpha comment.

ioread64 and iowrite64 generate a single 64bit bus transaction. There is
hardware where mmio operations have side effects so simply using a pair
of 32bit operations blindly does not work (consider something as trivial
as reading a 64bit performance counter or incrementing pointer).

If a platform doesn't support 64bit I/O operations from the CPU then you
either need to use some kind of platform/architecture specific interface
if present or accept you don't have one.

It's not safe to split it. Possibly for some use cases you could add an

ioread64_maysplit()

but you cannot blindly break ioread64/write64() and expect it to
magically allow you to use drivers that depend upon it.

What btw is the actual ARM compiler warning ? Is the compiler also trying
to tell you it's a bad idea ?

Alan

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Logan Gunthorpe]

On 6/22/2017 2:08 PM, Alan Cox wrote:

But this does not do the same thing as an ioread64 with regards to
atomicity or side effects on the device. The same is true of the other
hacks. You either have a real 64bit single read/write from MMIO space or
you don't. You can't fake it.


Yes, I know. But is it not better than having every driver that wants to 
use these functions fake it themselves?


Logan

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Alan Cox]

On Thu, 22 Jun 2017 10:48:14 -0600
Logan Gunthorpe  wrote:

> Alpha implements its own io operation and doesn't use the
> common library. Thus to make ioread64 and iowrite64 globally
> available we need to add implementations for alpha.
> 
> For this, we simply use calls that chain two 32-bit operations.
> (mostly because I don't really understand the alpha architecture.)

But this does not do the same thing as an ioread64 with regards to
atomicity or side effects on the device. The same is true of the other
hacks. You either have a real 64bit single read/write from MMIO space or
you don't. You can't fake it.


Alan

Re: [PATCH 1/1] cavium: Add firmware for CNN55XX crypto driver.

[Kyle McMartin]

On Fri, Jun 16, 2017 at 07:52:26PM +0530, Srikanth Jampala wrote:
> This patchset adds the firmware for CNN55XX cryto driver,
> supports Symmetric crypto operations.
> 
> The version of the firmware is v07.
> 
> Signed-off-by: Srikanth Jampala 
> ---
>  WHENCE|   9 +
>  cnn55xx_se.fw | Bin 0 -> 27698 bytes

any chance i could convince you to put this in a cavium/ subdirectory?

--kyle

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Logan Gunthorpe]

On 6/22/2017 11:29 AM, Stephen  Bates wrote:

+#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))


Logan, thanks for taking this cleanup on. I think this should be iowrite64 not 
iowrite32?


Yup, good catch. Thanks. I'll fix it in a v2 of this series.

Logan

Re: [PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Stephen Bates]

> +#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))
 
Logan, thanks for taking this cleanup on. I think this should be iowrite64 not 
iowrite32?

Stephen

RE: [PATCH 5/7] ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks

[Jiang, Dave]

> -Original Message-
> From: linux-...@googlegroups.com [mailto:linux-...@googlegroups.com] On 
> Behalf Of Logan Gunthorpe
> Sent: Thursday, June 22, 2017 9:48 AM
> To: linux-ker...@vger.kernel.org; linux-a...@vger.kernel.org; 
> linux-...@googlegroups.com; linux-al...@vger.kernel.org; linuxppc-
> d...@lists.ozlabs.org; linux-crypto@vger.kernel.org; 
> dri-de...@lists.freedesktop.org
> Cc: Arnd Bergmann ; Greg Kroah-Hartman 
> ; Stephen Bates ;
> Logan Gunthorpe ; Jon Mason ; Jiang, 
> Dave ; Allen Hubbe
> 
> Subject: [PATCH 5/7] ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks
> 
> Now that ioread64 and iowrite64 are available generically we can
> remove the hack at the top of ntb_hw_intel.c that patches them in
> when they are not available.
> 
> Signed-off-by: Logan Gunthorpe 
> Cc: Jon Mason 
> Cc: Dave Jiang 
> Cc: Allen Hubbe 

Thanks for doing this Logan. 

Acked-by: Dave Jiang 

> ---
>  drivers/ntb/hw/intel/ntb_hw_intel.c | 30 --
>  1 file changed, 30 deletions(-)
> 
> diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
> b/drivers/ntb/hw/intel/ntb_hw_intel.c
> index c00238491673..56221d540c2b 100644
> --- a/drivers/ntb/hw/intel/ntb_hw_intel.c
> +++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
> @@ -153,35 +153,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
>  static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 
> ppd);
>  static int xeon_init_isr(struct intel_ntb_dev *ndev);
> 
> -#ifndef ioread64
> -#ifdef readq
> -#define ioread64 readq
> -#else
> -#define ioread64 _ioread64
> -static inline u64 _ioread64(void __iomem *mmio)
> -{
> - u64 low, high;
> -
> - low = ioread32(mmio);
> - high = ioread32(mmio + sizeof(u32));
> - return low | (high << 32);
> -}
> -#endif
> -#endif
> -
> -#ifndef iowrite64
> -#ifdef writeq
> -#define iowrite64 writeq
> -#else
> -#define iowrite64 _iowrite64
> -static inline void _iowrite64(u64 val, void __iomem *mmio)
> -{
> - iowrite32(val, mmio);
> - iowrite32(val >> 32, mmio + sizeof(u32));
> -}
> -#endif
> -#endif
> -
>  static inline int pdev_is_atom(struct pci_dev *pdev)
>  {
>   switch (pdev->device) {
> @@ -3008,4 +2979,3 @@ static void __exit intel_ntb_pci_driver_exit(void)
>   debugfs_remove_recursive(debugfs_dir);
>  }
>  module_exit(intel_ntb_pci_driver_exit);
> -
> --
> 2.11.0
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-ntb" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-ntb+unsubscr...@googlegroups.com.
> To post to this group, send email to linux-...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/linux-ntb/20170622164817.25515-6-
> logang%40deltatee.com.
> For more options, visit https://groups.google.com/d/optout.

Re: [PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

[Gary R Hook]

On 06/22/2017 12:15 AM, Stephan Müller wrote:

Am Donnerstag, 22. Juni 2017, 00:48:01 CEST schrieb Gary R Hook:

Hi Gary,


Thanks, Stephen. Good catch(es). I will re-work this, but it looks like 
my changes should wait
until after the patch set posted by Brijesh (Introduce AMD Secure 
Processor device).


Please ignore these for now.





Wire up the v3 CCP as a cipher provider.

Signed-off-by: Gary R Hook 
---
 drivers/crypto/ccp/Makefile  |1
 drivers/crypto/ccp/ccp-crypto-main.c |   21 ++
 drivers/crypto/ccp/ccp-crypto-rsa.c  |  286
++ drivers/crypto/ccp/ccp-crypto.h  |
31 
 drivers/crypto/ccp/ccp-debugfs.c |1
 drivers/crypto/ccp/ccp-dev.c |1
 drivers/crypto/ccp/ccp-ops.c |2
 include/linux/ccp.h  |1
 8 files changed, 341 insertions(+), 3 deletions(-)
 create mode 100644 drivers/crypto/ccp/ccp-crypto-rsa.c

diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 59493fd3a751..439bc2fcb464 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -15,4 +15,5 @@ ccp-crypto-objs := ccp-crypto-main.o \
  ccp-crypto-aes-xts.o \
  ccp-crypto-aes-galois.o \
  ccp-crypto-des3.o \
+ccp-crypto-rsa.o \
  ccp-crypto-sha.o
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c
b/drivers/crypto/ccp/ccp-crypto-main.c index 8dccbddabef1..dd7d00c680e7
100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 

 #include "ccp-crypto.h"

@@ -37,10 +38,15 @@
 module_param(des3_disable, uint, 0444);
 MODULE_PARM_DESC(des3_disable, "Disable use of 3DES - any non-zero value");

+static unsigned int rsa_disable;
+module_param(rsa_disable, uint, 0444);
+MODULE_PARM_DESC(rsa_disable, "Disable use of RSA - any non-zero value");
+
 /* List heads for the supported algorithms */
 static LIST_HEAD(hash_algs);
 static LIST_HEAD(cipher_algs);
 static LIST_HEAD(aead_algs);
+static LIST_HEAD(akcipher_algs);

 /* For any tfm, requests for that tfm must be returned on the order
  * received.  With multiple queues available, the CCP can process more
@@ -358,6 +364,14 @@ static int ccp_register_algs(void)
   return ret;
   }

+ if (!rsa_disable) {
+ ret = ccp_register_rsa_algs(_algs);
+ if (ret) {
+ rsa_disable = 1;
+ return ret;
+ }
+ }
+
   return 0;
 }

@@ -366,6 +380,7 @@ static void ccp_unregister_algs(void)
   struct ccp_crypto_ahash_alg *ahash_alg, *ahash_tmp;
   struct ccp_crypto_ablkcipher_alg *ablk_alg, *ablk_tmp;
   struct ccp_crypto_aead *aead_alg, *aead_tmp;
+ struct ccp_crypto_akcipher_alg *akc_alg, *akc_tmp;

   list_for_each_entry_safe(ahash_alg, ahash_tmp, _algs, entry) {
   crypto_unregister_ahash(_alg->alg);
@@ -384,6 +399,12 @@ static void ccp_unregister_algs(void)
   list_del(_alg->entry);
   kfree(aead_alg);
   }
+
+ list_for_each_entry_safe(akc_alg, akc_tmp, _algs, entry) {
+ crypto_unregister_akcipher(_alg->alg);
+ list_del(_alg->entry);
+ kfree(akc_alg);
+ }
 }

 static int ccp_crypto_init(void)
diff --git a/drivers/crypto/ccp/ccp-crypto-rsa.c
b/drivers/crypto/ccp/ccp-crypto-rsa.c new file mode 100644
index ..4a2a71463594
--- /dev/null
+++ b/drivers/crypto/ccp/ccp-crypto-rsa.c
@@ -0,0 +1,286 @@
+/*
+ * AMD Cryptographic Coprocessor (CCP) RSA crypto API support
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Gary R Hook 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ccp-crypto.h"
+
+static inline struct akcipher_request *akcipher_request_cast(
+ struct crypto_async_request *req)
+{
+ return container_of(req, struct akcipher_request, base);
+}
+
+static int ccp_rsa_complete(struct crypto_async_request *async_req, int
ret) +{
+ struct akcipher_request *req = akcipher_request_cast(async_req);
+ struct ccp_rsa_req_ctx *rctx = akcipher_request_ctx(req);
+
+ if (!ret)
+ req->dst_len = rctx->cmd.u.rsa.key_size >> 3;
+
+ ret = 0;
+
+ return ret;
+}
+
+static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm)
+{
+ return CCP_RSA_MAXMOD;
+}
+
+static int ccp_rsa_crypt(struct akcipher_request *req, bool encrypt)
+{
+ struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
+ struct ccp_ctx *ctx = akcipher_tfm_ctx(tfm);
+ struct ccp_rsa_req_ctx *rctx = akcipher_request_ctx(req);
+ int ret = 0;
+
+ 

[PATCH 2/7] iomap: implement ioread64 and iowrite64

[Logan Gunthorpe]

Currently, ioread64 and iowrite64 are not impleminted in the generic
iomap implementation. The prototypes are defined if CONFIG_64BIT is set
but there is no actual implementation.

Seeing the functions are not universally available, they are unusable
for driver developers. This leads to ugly hacks such as those at
the top of

drivers/ntb/hw/intel/ntb_hw_intel.c

This patch adds generic implementations for these functions. We add
the obvious version if readq/writeq are implemented and fall back
to using two io32 calls in cases that don't provide direct 64bit
accesses. Thus making the functions universally available to
configurations with CONFIG_GENERIC_IOMAP=y.

For any pio accesses, the 64bit operations remain unsupported and
simply call bad_io_access in cases readq would be called.

Signed-off-by: Logan Gunthorpe 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman 
Cc: Arnd Bergmann 
Cc: Suresh Warrier 
Cc: Nicholas Piggin 
---
 arch/powerpc/include/asm/io.h |  2 ++
 include/asm-generic/iomap.h   |  4 ---
 lib/iomap.c   | 62 +++
 3 files changed, 64 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/include/asm/io.h b/arch/powerpc/include/asm/io.h
index 422f99cf9924..11a83667d2c3 100644
--- a/arch/powerpc/include/asm/io.h
+++ b/arch/powerpc/include/asm/io.h
@@ -788,8 +788,10 @@ extern void __iounmap_at(void *ea, unsigned long size);
 
 #define mmio_read16be(addr)readw_be(addr)
 #define mmio_read32be(addr)readl_be(addr)
+#define mmio_read64be(addr)readq_be(addr)
 #define mmio_write16be(val, addr)  writew_be(val, addr)
 #define mmio_write32be(val, addr)  writel_be(val, addr)
+#define mmio_write64be(val, addr)  writeq_be(val, addr)
 #define mmio_insb(addr, dst, count)readsb(addr, dst, count)
 #define mmio_insw(addr, dst, count)readsw(addr, dst, count)
 #define mmio_insl(addr, dst, count)readsl(addr, dst, count)
diff --git a/include/asm-generic/iomap.h b/include/asm-generic/iomap.h
index 650fede33c25..43ec4ea9f6f9 100644
--- a/include/asm-generic/iomap.h
+++ b/include/asm-generic/iomap.h
@@ -30,20 +30,16 @@ extern unsigned int ioread16(void __iomem *);
 extern unsigned int ioread16be(void __iomem *);
 extern unsigned int ioread32(void __iomem *);
 extern unsigned int ioread32be(void __iomem *);
-#ifdef CONFIG_64BIT
 extern u64 ioread64(void __iomem *);
 extern u64 ioread64be(void __iomem *);
-#endif
 
 extern void iowrite8(u8, void __iomem *);
 extern void iowrite16(u16, void __iomem *);
 extern void iowrite16be(u16, void __iomem *);
 extern void iowrite32(u32, void __iomem *);
 extern void iowrite32be(u32, void __iomem *);
-#ifdef CONFIG_64BIT
 extern void iowrite64(u64, void __iomem *);
 extern void iowrite64be(u64, void __iomem *);
-#endif
 
 /*
  * "string" versions of the above. Note that they
diff --git a/lib/iomap.c b/lib/iomap.c
index fc3dcb4b238e..e38e036cb52f 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -66,6 +66,7 @@ static void bad_io_access(unsigned long port, const char 
*access)
 #ifndef mmio_read16be
 #define mmio_read16be(addr) be16_to_cpu(__raw_readw(addr))
 #define mmio_read32be(addr) be32_to_cpu(__raw_readl(addr))
+#define mmio_read64be(addr) be64_to_cpu(__raw_readq(addr))
 #endif
 
 unsigned int ioread8(void __iomem *addr)
@@ -93,11 +94,45 @@ unsigned int ioread32be(void __iomem *addr)
IO_COND(addr, return pio_read32be(port), return mmio_read32be(addr));
return 0x;
 }
+
+#ifdef readq
+u64 ioread64(void __iomem *addr)
+{
+   IO_COND(addr, bad_io_access(port, "ioread64"), return readq(addr));
+   return 0xLL;
+}
+u64 ioread64be(void __iomem *addr)
+{
+   IO_COND(addr, bad_io_access(port, "ioread64be"),
+   return mmio_read64be(addr));
+   return 0xLL;
+}
+#else
+u64 ioread64(void __iomem *addr)
+{
+   u64 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+   return low | (high << 32);
+}
+u64 ioread64be(void __iomem *addr)
+{
+   u64 low, high;
+
+   low = ioread32be(addr + sizeof(u32));
+   high = ioread32be(addr);
+   return low | (high << 32);
+}
+#endif
+
 EXPORT_SYMBOL(ioread8);
 EXPORT_SYMBOL(ioread16);
 EXPORT_SYMBOL(ioread16be);
 EXPORT_SYMBOL(ioread32);
 EXPORT_SYMBOL(ioread32be);
+EXPORT_SYMBOL(ioread64);
+EXPORT_SYMBOL(ioread64be);
 
 #ifndef pio_write16be
 #define pio_write16be(val,port) outw(swab16(val),port)
@@ -107,6 +142,7 @@ EXPORT_SYMBOL(ioread32be);
 #ifndef mmio_write16be
 #define mmio_write16be(val,port) __raw_writew(be16_to_cpu(val),port)
 #define mmio_write32be(val,port) __raw_writel(be32_to_cpu(val),port)
+#define mmio_write64be(val,port) __raw_writeq(be64_to_cpu(val),port)
 #endif
 
 void iowrite8(u8 val, void __iomem *addr)
@@ -129,11 

[PATCH 5/7] ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks

[Logan Gunthorpe]

Now that ioread64 and iowrite64 are available generically we can
remove the hack at the top of ntb_hw_intel.c that patches them in
when they are not available.

Signed-off-by: Logan Gunthorpe 
Cc: Jon Mason 
Cc: Dave Jiang 
Cc: Allen Hubbe 
---
 drivers/ntb/hw/intel/ntb_hw_intel.c | 30 --
 1 file changed, 30 deletions(-)

diff --git a/drivers/ntb/hw/intel/ntb_hw_intel.c 
b/drivers/ntb/hw/intel/ntb_hw_intel.c
index c00238491673..56221d540c2b 100644
--- a/drivers/ntb/hw/intel/ntb_hw_intel.c
+++ b/drivers/ntb/hw/intel/ntb_hw_intel.c
@@ -153,35 +153,6 @@ MODULE_PARM_DESC(xeon_b2b_dsd_bar5_addr32,
 static inline enum ntb_topo xeon_ppd_topo(struct intel_ntb_dev *ndev, u8 ppd);
 static int xeon_init_isr(struct intel_ntb_dev *ndev);
 
-#ifndef ioread64
-#ifdef readq
-#define ioread64 readq
-#else
-#define ioread64 _ioread64
-static inline u64 _ioread64(void __iomem *mmio)
-{
-   u64 low, high;
-
-   low = ioread32(mmio);
-   high = ioread32(mmio + sizeof(u32));
-   return low | (high << 32);
-}
-#endif
-#endif
-
-#ifndef iowrite64
-#ifdef writeq
-#define iowrite64 writeq
-#else
-#define iowrite64 _iowrite64
-static inline void _iowrite64(u64 val, void __iomem *mmio)
-{
-   iowrite32(val, mmio);
-   iowrite32(val >> 32, mmio + sizeof(u32));
-}
-#endif
-#endif
-
 static inline int pdev_is_atom(struct pci_dev *pdev)
 {
switch (pdev->device) {
@@ -3008,4 +2979,3 @@ static void __exit intel_ntb_pci_driver_exit(void)
debugfs_remove_recursive(debugfs_dir);
 }
 module_exit(intel_ntb_pci_driver_exit);
-
-- 
2.11.0

[PATCH 6/7] drm/tilcdc: clean up ifdef hacks around iowrite64

[Logan Gunthorpe]

Now that we can expect iowrite64 to always exist the hack is no longer
necessary so we just call iowrite64 directly.

Signed-off-by: Logan Gunthorpe 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: David Airlie 
---
 drivers/gpu/drm/tilcdc/tilcdc_regs.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index e9ce725698a9..0b901405f30a 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -133,13 +133,7 @@ static inline void tilcdc_write64(struct drm_device *dev, 
u32 reg, u64 data)
struct tilcdc_drm_private *priv = dev->dev_private;
void __iomem *addr = priv->mmio + reg;
 
-#ifdef iowrite64
iowrite64(data, addr);
-#else
-   __iowmb();
-   /* This compiles to strd (=64-bit write) on ARM7 */
-   *(u64 __force *)addr = __cpu_to_le64(data);
-#endif
 }
 
 static inline u32 tilcdc_read(struct drm_device *dev, u32 reg)
-- 
2.11.0

[PATCH 4/7] alpha: provide ioread64 and iowrite64 implementations

[Logan Gunthorpe]

Alpha implements its own io operation and doesn't use the
common library. Thus to make ioread64 and iowrite64 globally
available we need to add implementations for alpha.

For this, we simply use calls that chain two 32-bit operations.
(mostly because I don't really understand the alpha architecture.)

Signed-off-by: Logan Gunthorpe 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
---
 arch/alpha/include/asm/io.h |  2 ++
 arch/alpha/kernel/io.c  | 18 ++
 2 files changed, 20 insertions(+)

diff --git a/arch/alpha/include/asm/io.h b/arch/alpha/include/asm/io.h
index ff4049155c84..15588092c062 100644
--- a/arch/alpha/include/asm/io.h
+++ b/arch/alpha/include/asm/io.h
@@ -493,8 +493,10 @@ extern inline void writeq(u64 b, volatile void __iomem 
*addr)
 
 #define ioread16be(p) be16_to_cpu(ioread16(p))
 #define ioread32be(p) be32_to_cpu(ioread32(p))
+#define ioread64be(p) be64_to_cpu(ioread64(p))
 #define iowrite16be(v,p) iowrite16(cpu_to_be16(v), (p))
 #define iowrite32be(v,p) iowrite32(cpu_to_be32(v), (p))
+#define iowrite64be(v,p) iowrite32(cpu_to_be64(v), (p))
 
 #define inb_p  inb
 #define inw_p  inw
diff --git a/arch/alpha/kernel/io.c b/arch/alpha/kernel/io.c
index 19c5875ab398..8c28026f7849 100644
--- a/arch/alpha/kernel/io.c
+++ b/arch/alpha/kernel/io.c
@@ -59,6 +59,24 @@ EXPORT_SYMBOL(iowrite8);
 EXPORT_SYMBOL(iowrite16);
 EXPORT_SYMBOL(iowrite32);
 
+u64 ioread64(void __iomem *addr)
+{
+   u64 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+   return low | (high << 32);
+}
+
+void iowrite64(u64 val, void __iomem *addr)
+{
+   iowrite32(val, addr);
+   iowrite32(val >> 32, addr + sizeof(u32));
+}
+
+EXPORT_SYMBOL(ioread64);
+EXPORT_SYMBOL(iowrite64);
+
 u8 inb(unsigned long port)
 {
return ioread8(ioport_map(port, 1));
-- 
2.11.0

[PATCH 0/7] cleanup issues with io{read|write}64

[Logan Gunthorpe]

Hi,

Presently, the 64bit IO functions are not very usable in drivers because
they are not universally available in all architectures. This leads to
a bunch of hacks in the kernel to work around this. (See the last 3
patches in this series.) As part of my switchtec_ntb submission which
added another one of these warts, Greg asked me to look into fixing
it[1].

So this patchset attempts to solve this issue by filling in the missing
implementations in iomap.c and io.h. After that, the alpha architecture is
the only one I found that also needed a fix for this. Finally, this
patchset removes the hacks that have accumulated in the kernel,
thus far, for working around this.

This set is based off of v4.12-rc6.

Thanks,

Logan

[1] https://marc.info/?l=linux-kernel=149774601910663=2

Logan Gunthorpe (7):
  drm/tilcdc: don't use volatile with iowrite64
  iomap: implement ioread64 and iowrite64
  asm-generic/io.h: make ioread64 and iowrite64 universally available
  alpha: provide ioread64 and iowrite64 implementations
  ntb: ntb_hw_intel: remove ioread64 and iowrite64 hacks
  drm/tilcdc: clean up ifdef hacks around iowrite64
  crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

 arch/alpha/include/asm/io.h  |  2 ++
 arch/alpha/kernel/io.c   | 18 +++
 arch/powerpc/include/asm/io.h|  2 ++
 drivers/crypto/caam/regs.h   | 29 -
 drivers/gpu/drm/tilcdc/tilcdc_regs.h |  8 +
 drivers/ntb/hw/intel/ntb_hw_intel.c  | 30 -
 include/asm-generic/io.h | 54 ---
 include/asm-generic/iomap.h  |  4 ---
 lib/iomap.c  | 62 
 9 files changed, 127 insertions(+), 82 deletions(-)

--
2.11.0

[PATCH 7/7] crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64

[Logan Gunthorpe]

Now that ioread64 and iowrite64 are always available we don't
need the ugly ifdefs to change their implementation when they
are not.

Signed-off-by: Logan Gunthorpe 
Cc: "Horia Geantă" 
Cc: Dan Douglass 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 drivers/crypto/caam/regs.h | 29 -
 1 file changed, 29 deletions(-)

diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h
index 84d2f838a063..26fc19dd0c39 100644
--- a/drivers/crypto/caam/regs.h
+++ b/drivers/crypto/caam/regs.h
@@ -134,7 +134,6 @@ static inline void clrsetbits_32(void __iomem *reg, u32 
clear, u32 set)
  *base + 0x : least-significant 32 bits
  *base + 0x0004 : most-significant 32 bits
  */
-#ifdef CONFIG_64BIT
 static inline void wr_reg64(void __iomem *reg, u64 data)
 {
if (caam_little_end)
@@ -151,34 +150,6 @@ static inline u64 rd_reg64(void __iomem *reg)
return ioread64be(reg);
 }
 
-#else /* CONFIG_64BIT */
-static inline void wr_reg64(void __iomem *reg, u64 data)
-{
-#ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
-   if (caam_little_end) {
-   wr_reg32((u32 __iomem *)(reg) + 1, data >> 32);
-   wr_reg32((u32 __iomem *)(reg), data);
-   } else
-#endif
-   {
-   wr_reg32((u32 __iomem *)(reg), data >> 32);
-   wr_reg32((u32 __iomem *)(reg) + 1, data);
-   }
-}
-
-static inline u64 rd_reg64(void __iomem *reg)
-{
-#ifndef CONFIG_CRYPTO_DEV_FSL_CAAM_IMX
-   if (caam_little_end)
-   return ((u64)rd_reg32((u32 __iomem *)(reg) + 1) << 32 |
-   (u64)rd_reg32((u32 __iomem *)(reg)));
-   else
-#endif
-   return ((u64)rd_reg32((u32 __iomem *)(reg)) << 32 |
-   (u64)rd_reg32((u32 __iomem *)(reg) + 1));
-}
-#endif /* CONFIG_64BIT  */
-
 #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
 #ifdef CONFIG_SOC_IMX7D
 #define cpu_to_caam_dma(value) \
-- 
2.11.0

[PATCH 3/7] asm-generic/io.h: make ioread64 and iowrite64 universally available

[Logan Gunthorpe]

Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
universally available, it makes them unusable for driver developers.
This leads to ugly hacks such as those at the top of

drivers/ntb/hw/intel/ntb_hw_intel.c

This patch adds fallback implementations for when CONFIG_64BIT and
CONFIG_GENERIC_IOMAP are not set. These functions use two io32 based
calls to complete the operation.

Note, we do not use the volatile keyword in these functions like the
others in the same file. It is necessary to avoid a compiler warning
on arm.

Signed-off-by: Logan Gunthorpe 
Cc: Arnd Bergmann 
---
 include/asm-generic/io.h | 54 +---
 1 file changed, 42 insertions(+), 12 deletions(-)

diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015eb3403..817edaa3da78 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -585,15 +585,24 @@ static inline u32 ioread32(const volatile void __iomem 
*addr)
 }
 #endif
 
-#ifdef CONFIG_64BIT
 #ifndef ioread64
 #define ioread64 ioread64
-static inline u64 ioread64(const volatile void __iomem *addr)
+#ifdef readq
+static inline u64 ioread64(const void __iomem *addr)
 {
return readq(addr);
 }
+#else
+static inline u64 ioread64(const void __iomem *addr)
+{
+   u64 low, high;
+
+   low = ioread32(addr);
+   high = ioread32(addr + sizeof(u32));
+   return low | (high << 32);
+}
+#endif
 #endif
-#endif /* CONFIG_64BIT */
 
 #ifndef iowrite8
 #define iowrite8 iowrite8
@@ -619,15 +628,21 @@ static inline void iowrite32(u32 value, volatile void 
__iomem *addr)
 }
 #endif
 
-#ifdef CONFIG_64BIT
 #ifndef iowrite64
 #define iowrite64 iowrite64
-static inline void iowrite64(u64 value, volatile void __iomem *addr)
+#ifdef writeq
+static inline void iowrite64(u64 value, void __iomem *addr)
 {
writeq(value, addr);
 }
+#else
+static inline void iowrite64(u64 value, void __iomem *addr)
+{
+   iowrite32(value, addr);
+   iowrite32(value >> 32, addr + sizeof(u32));
+}
+#endif
 #endif
-#endif /* CONFIG_64BIT */
 
 #ifndef ioread16be
 #define ioread16be ioread16be
@@ -645,15 +660,24 @@ static inline u32 ioread32be(const volatile void __iomem 
*addr)
 }
 #endif
 
-#ifdef CONFIG_64BIT
 #ifndef ioread64be
 #define ioread64be ioread64be
-static inline u64 ioread64be(const volatile void __iomem *addr)
+#ifdef readq
+static inline u64 ioread64be(const void __iomem *addr)
 {
return swab64(readq(addr));
 }
+#else
+static inline u64 ioread64be(const void __iomem *addr)
+{
+   u64 low, high;
+
+   low = ioread32be(addr + sizeof(u32));
+   high = ioread32be(addr);
+   return low | (high << 32);
+}
+#endif
 #endif
-#endif /* CONFIG_64BIT */
 
 #ifndef iowrite16be
 #define iowrite16be iowrite16be
@@ -671,15 +695,21 @@ static inline void iowrite32be(u32 value, volatile void 
__iomem *addr)
 }
 #endif
 
-#ifdef CONFIG_64BIT
 #ifndef iowrite64be
 #define iowrite64be iowrite64be
-static inline void iowrite64be(u64 value, volatile void __iomem *addr)
+#ifdef writeq
+static inline void iowrite64be(u64 value, void __iomem *addr)
 {
writeq(swab64(value), addr);
 }
+#else
+static inline void iowrite64be(u64 value, void __iomem *addr)
+{
+   iowrite32be(value >> 32, addr);
+   iowrite32be(value, addr + sizeof(u32));
+}
+#endif
 #endif
-#endif /* CONFIG_64BIT */
 
 #ifndef ioread8_rep
 #define ioread8_rep ioread8_rep
-- 
2.11.0

[PATCH 1/7] drm/tilcdc: don't use volatile with iowrite64

[Logan Gunthorpe]

This is a prep patch for adding a universal iowrite64.

The patch is to prevent compiler warnings when we add iowrite64 that
would occur because there is an unnecessary volatile in this driver.

Signed-off-by: Logan Gunthorpe 
Cc: Jyri Sarha 
Cc: Tomi Valkeinen 
Cc: David Airlie 
---
 drivers/gpu/drm/tilcdc/tilcdc_regs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/tilcdc/tilcdc_regs.h 
b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
index 9d528c0a67a4..e9ce725698a9 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_regs.h
+++ b/drivers/gpu/drm/tilcdc/tilcdc_regs.h
@@ -131,14 +131,14 @@ static inline void tilcdc_write(struct drm_device *dev, 
u32 reg, u32 data)
 static inline void tilcdc_write64(struct drm_device *dev, u32 reg, u64 data)
 {
struct tilcdc_drm_private *priv = dev->dev_private;
-   volatile void __iomem *addr = priv->mmio + reg;
+   void __iomem *addr = priv->mmio + reg;
 
 #ifdef iowrite64
iowrite64(data, addr);
 #else
__iowmb();
/* This compiles to strd (=64-bit write) on ARM7 */
-   *(volatile u64 __force *)addr = __cpu_to_le64(data);
+   *(u64 __force *)addr = __cpu_to_le64(data);
 #endif
 }
 
-- 
2.11.0

Re: [PATCH 4/4] crypto: ccp - Expand RSA support for a v5 ccp

[Tom Lendacky]

On 6/21/2017 5:48 PM, Gary R Hook wrote:

A V5 device can accommodate larger keys, as well as read the keys
directly from memory instead of requiring them to be in a local
storage block.


The previous patch already reads them from memory so just the first
part of this sentence is needed.




Signed-off-by: Gary R Hook 
---
  drivers/crypto/ccp/ccp-crypto-rsa.c |5 -
  drivers/crypto/ccp/ccp-crypto.h |1 +
  drivers/crypto/ccp/ccp-dev-v3.c |1 +
  drivers/crypto/ccp/ccp-dev-v5.c |2 ++
  drivers/crypto/ccp/ccp-dev.h|2 ++
  drivers/crypto/ccp/ccp-ops.c|3 ++-
  6 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-crypto-rsa.c 
b/drivers/crypto/ccp/ccp-crypto-rsa.c
index 4a2a71463594..93e6b00ce34d 100644
--- a/drivers/crypto/ccp/ccp-crypto-rsa.c
+++ b/drivers/crypto/ccp/ccp-crypto-rsa.c
@@ -43,7 +43,10 @@ static int ccp_rsa_complete(struct crypto_async_request 
*async_req, int ret)
  
  static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm)

  {
-   return CCP_RSA_MAXMOD;
+   if (ccp_version() > CCP_VERSION(3, 0))
+   return CCP5_RSA_MAXMOD;
+   else
+   return CCP_RSA_MAXMOD;


The ccp_check_key_length() function in this file has a hardcoded 4096
that should be changed to use vdata value.

Thanks,
Tom


  }
  
  static int ccp_rsa_crypt(struct akcipher_request *req, bool encrypt)

diff --git a/drivers/crypto/ccp/ccp-crypto.h b/drivers/crypto/ccp/ccp-crypto.h
index 5d592ecc9af5..40598894113b 100644
--- a/drivers/crypto/ccp/ccp-crypto.h
+++ b/drivers/crypto/ccp/ccp-crypto.h
@@ -255,6 +255,7 @@ struct ccp_rsa_req_ctx {
  };
  
  #define	CCP_RSA_MAXMOD	(4 * 1024 / 8)

+#defineCCP5_RSA_MAXMOD (16 * 1024 / 8)
  
  /* Common Context Structure */

  struct ccp_ctx {
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 367c2e30656f..9b159b0a891e 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -592,4 +592,5 @@ static void ccp_destroy(struct ccp_device *ccp)
.perform = _actions,
.bar = 2,
.offset = 0x2,
+   .rsamax = CCP_RSA_MAX_WIDTH,
  };
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 632518efd685..6043552322fd 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -1115,6 +1115,7 @@ static void ccp5other_config(struct ccp_device *ccp)
.perform = _actions,
.bar = 2,
.offset = 0x0,
+   .rsamax = CCP5_RSA_MAX_WIDTH,
  };
  
  const struct ccp_vdata ccpv5b = {

@@ -1124,4 +1125,5 @@ static void ccp5other_config(struct ccp_device *ccp)
.perform = _actions,
.bar = 2,
.offset = 0x0,
+   .rsamax = CCP5_RSA_MAX_WIDTH,
  };
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index a70154ac7405..8242cf54d90f 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -200,6 +200,7 @@
  #define CCP_SHA_SB_COUNT  1
  
  #define CCP_RSA_MAX_WIDTH		4096

+#define CCP5_RSA_MAX_WIDTH 16384
  
  #define CCP_PASSTHRU_BLOCKSIZE		256

  #define CCP_PASSTHRU_MASKSIZE 32
@@ -677,6 +678,7 @@ struct ccp_vdata {
const struct ccp_actions *perform;
const unsigned int bar;
const unsigned int offset;
+   const unsigned int rsamax;
  };
  
  extern const struct ccp_vdata ccpv3;

diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index 2cdd15a92178..ea5e4ede1eed 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1737,7 +1737,8 @@ static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
unsigned int key_size_bytes;
int ret;
  
-	if (rsa->key_size > CCP_RSA_MAX_WIDTH)

+   /* Check against the maximum allowable size, in bits */
+   if (rsa->key_size > cmd_q->ccp->vdata->rsamax)
return -EINVAL;
  
  	if (!rsa->exp || !rsa->mod || !rsa->src || !rsa->dst)

Re: [PATCH v2] of: update ePAPR references to point to Devicetree Specification

[Rob Herring]

On Thu, Jun 22, 2017 at 09:15:39AM -0700, frowand.l...@gmail.com wrote:
> From: Frank Rowand 
> 
> The Devicetree Specification has superseded the ePAPR as the
> base specification for bindings.  Update files in Documentation
> to reference the new document.
> 
> First reference to ePAPR in Documentation/devicetree/bindings/arm/cci.txt
> is generic, remove it.
> 
> Some files are not updated because there is no hypervisor chapter
> in the Devicetree Specification:
>Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
>Documenation/virtual/kvm/api.txt
>Documenation/virtual/kvm/ppc-pv.txt
> 
> Signed-off-by: Frank Rowand 
> ---
> 
> changes from v1:
>- remove boilerplat ePAPR reference from cci.txt
> 
>  Documentation/devicetree/bindings/arm/cci.txt | 15 
> ---
>  Documentation/devicetree/bindings/arm/cpus.txt| 13 +++--
>  Documentation/devicetree/bindings/arm/idle-states.txt |  4 ++--
>  Documentation/devicetree/bindings/arm/l2c2x0.txt  |  4 ++--
>  Documentation/devicetree/bindings/arm/topology.txt|  4 ++--
>  Documentation/devicetree/bindings/bus/simple-pm-bus.txt   |  2 +-
>  Documentation/devicetree/bindings/chosen.txt  |  3 ++-
>  Documentation/devicetree/bindings/common-properties.txt   |  2 +-
>  Documentation/devicetree/bindings/crypto/fsl-sec4.txt |  4 ++--
>  Documentation/devicetree/bindings/crypto/fsl-sec6.txt |  4 ++--
>  .../devicetree/bindings/interrupt-controller/open-pic.txt |  5 ++---
>  Documentation/devicetree/bindings/net/ethernet.txt|  9 ++---
>  Documentation/devicetree/bindings/powerpc/fsl/cpus.txt|  6 +++---
>  Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt |  2 +-
>  .../devicetree/bindings/powerpc/fsl/srio-rmu.txt  |  4 ++--
>  Documentation/devicetree/bindings/powerpc/fsl/srio.txt|  3 ++-
>  Documentation/devicetree/booting-without-of.txt   |  2 +-
>  Documentation/devicetree/usage-model.txt  |  2 +-
>  Documentation/xtensa/mmu.txt  |  6 +++---
>  19 files changed, 46 insertions(+), 48 deletions(-)

Applied.

Re: [PATCH 3/4] crypto: ccp - Add support for RSA on the CCP

[Tom Lendacky]

On 6/21/2017 5:48 PM, Gary R Hook wrote:

Wire up the v3 CCP as a cipher provider.


The V5 support will be invoked through this also.  Maybe something like:

Wire up the CCP as an RSA cipher provider.



Signed-off-by: Gary R Hook 
---
  drivers/crypto/ccp/Makefile  |1
  drivers/crypto/ccp/ccp-crypto-main.c |   21 ++
  drivers/crypto/ccp/ccp-crypto-rsa.c  |  286 ++
  drivers/crypto/ccp/ccp-crypto.h  |   31 
  drivers/crypto/ccp/ccp-debugfs.c |1
  drivers/crypto/ccp/ccp-dev.c |1
  drivers/crypto/ccp/ccp-ops.c |2
  include/linux/ccp.h  |1
  8 files changed, 341 insertions(+), 3 deletions(-)
  create mode 100644 drivers/crypto/ccp/ccp-crypto-rsa.c

diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 59493fd3a751..439bc2fcb464 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -15,4 +15,5 @@ ccp-crypto-objs := ccp-crypto-main.o \
   ccp-crypto-aes-xts.o \
   ccp-crypto-aes-galois.o \
   ccp-crypto-des3.o \
+  ccp-crypto-rsa.o \
   ccp-crypto-sha.o
diff --git a/drivers/crypto/ccp/ccp-crypto-main.c 
b/drivers/crypto/ccp/ccp-crypto-main.c
index 8dccbddabef1..dd7d00c680e7 100644
--- a/drivers/crypto/ccp/ccp-crypto-main.c
+++ b/drivers/crypto/ccp/ccp-crypto-main.c
@@ -17,6 +17,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "ccp-crypto.h"
  
@@ -37,10 +38,15 @@

  module_param(des3_disable, uint, 0444);
  MODULE_PARM_DESC(des3_disable, "Disable use of 3DES - any non-zero value");
  
+static unsigned int rsa_disable;

+module_param(rsa_disable, uint, 0444);
+MODULE_PARM_DESC(rsa_disable, "Disable use of RSA - any non-zero value");
+
  /* List heads for the supported algorithms */
  static LIST_HEAD(hash_algs);
  static LIST_HEAD(cipher_algs);
  static LIST_HEAD(aead_algs);
+static LIST_HEAD(akcipher_algs);
  
  /* For any tfm, requests for that tfm must be returned on the order

   * received.  With multiple queues available, the CCP can process more
@@ -358,6 +364,14 @@ static int ccp_register_algs(void)
return ret;
}
  
+	if (!rsa_disable) {

+   ret = ccp_register_rsa_algs(_algs);
+   if (ret) {
+   rsa_disable = 1;


Not sure what this does...  The return of the error code will cause the
init to fail and unregister everything. This path won't be taken again
to make use of the change in value.


+   return ret;
+   }
+   }
+
return 0;
  }
  
@@ -366,6 +380,7 @@ static void ccp_unregister_algs(void)

struct ccp_crypto_ahash_alg *ahash_alg, *ahash_tmp;
struct ccp_crypto_ablkcipher_alg *ablk_alg, *ablk_tmp;
struct ccp_crypto_aead *aead_alg, *aead_tmp;
+   struct ccp_crypto_akcipher_alg *akc_alg, *akc_tmp;
  
  	list_for_each_entry_safe(ahash_alg, ahash_tmp, _algs, entry) {

crypto_unregister_ahash(_alg->alg);
@@ -384,6 +399,12 @@ static void ccp_unregister_algs(void)
list_del(_alg->entry);
kfree(aead_alg);
}
+
+   list_for_each_entry_safe(akc_alg, akc_tmp, _algs, entry) {
+   crypto_unregister_akcipher(_alg->alg);
+   list_del(_alg->entry);
+   kfree(akc_alg);
+   }
  }
  
  static int ccp_crypto_init(void)

diff --git a/drivers/crypto/ccp/ccp-crypto-rsa.c 
b/drivers/crypto/ccp/ccp-crypto-rsa.c
new file mode 100644
index ..4a2a71463594
--- /dev/null
+++ b/drivers/crypto/ccp/ccp-crypto-rsa.c
@@ -0,0 +1,286 @@
+/*
+ * AMD Cryptographic Coprocessor (CCP) RSA crypto API support
+ *
+ * Copyright (C) 2016 Advanced Micro Devices, Inc.
+ *
+ * Author: Gary R Hook 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ccp-crypto.h"
+
+static inline struct akcipher_request *akcipher_request_cast(
+   struct crypto_async_request *req)
+{
+   return container_of(req, struct akcipher_request, base);
+}
+
+static int ccp_rsa_complete(struct crypto_async_request *async_req, int ret)
+{
+   struct akcipher_request *req = akcipher_request_cast(async_req);
+   struct ccp_rsa_req_ctx *rctx = akcipher_request_ctx(req);
+
+   if (!ret)
+   req->dst_len = rctx->cmd.u.rsa.key_size >> 3;
+
+   ret = 0;
+
+   return ret;


This seems odd.  You should probably make this similar to the other CCP
complete functions:

if (ret)
return ret;

req->dst_len = ...

return 0;


+}
+
+static unsigned int ccp_rsa_maxsize(struct crypto_akcipher *tfm)
+{
+   return 

Re: [PATCH] of: update ePAPR references to point to Devicetree Specification

[Rob Herring]

On Mon, Jun 19, 2017 at 03:23:41AM -0700, Frank Rowand wrote:
> On 06/18/17 07:05, Rob Herring wrote:
> > On Tue, Jun 13, 2017 at 07:49:04PM -0700, frowand.l...@gmail.com wrote:
> >> From: Frank Rowand 
> >>
> >> The Devicetree Specification has superseded the ePAPR as the
> >> base specification for bindings.  Update files in Documentation
> >> to reference the new document.
> >>
> >> Some files are not updated because there is no hypervisor chapter
> >> in the Devicetree Specification:
> >>Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt
> >>Documenation/virtual/kvm/api.txt
> >>Documenation/virtual/kvm/ppc-pv.txt

> >> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt 
> >> b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
> >> index f8cd2397aa04..d63ab1dec16d 100644
> >> --- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
> >> +++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
> >> @@ -3,10 +3,10 @@ Power Architecture CPU Binding
> >>  Copyright 2013 Freescale Semiconductor Inc.
> >>  
> >>  Power Architecture CPUs in Freescale SOCs are represented in device trees 
> >> as
> >> -per the definition in ePAPR.
> >> +per the definition in the Devicetree Specification.
> > 
> > Are we sure we didn't remove any PPC specifics that apply here?
> 
> I don't see any.
> 
> Table 3.7.1 "General Properties of CPU nodes" was slightly
> re-ordered, but the same properties are listed in both documents.
> 
> I don't think that the boot requirements removal impacts this
> file.
> 
> Am I missing something?

No, I just wanted to make sure. So I guess there's just that one minor 
thing to drop.

Rob

Re: [PATCH 1/4] crypto: ccp - Fix base RSA function for version 5 CCPs

[Tom Lendacky]

On 6/21/2017 5:47 PM, Gary R Hook wrote:

Version 5 devices have requirements for buffer lengths, as well as
parameter format (e.g. bits vs. bytes). Fix the base CCP driver
code to meet requirements all supported versions.

Signed-off-by: Gary R Hook 
---
  drivers/crypto/ccp/ccp-dev-v5.c |   10 ++--
  drivers/crypto/ccp/ccp-ops.c|   95 ---
  2 files changed, 64 insertions(+), 41 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index b10d2d2075cb..632518efd685 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -469,7 +469,7 @@ static int ccp5_perform_rsa(struct ccp_op *op)
CCP5_CMD_PROT() = 0;
  
  	function.raw = 0;

-   CCP_RSA_SIZE() = op->u.rsa.mod_size >> 3;
+   CCP_RSA_SIZE() = (op->u.rsa.mod_size + 7) >> 3;
CCP5_CMD_FUNCTION() = function.raw;
  
  	CCP5_CMD_LEN() = op->u.rsa.input_len;

@@ -484,10 +484,10 @@ static int ccp5_perform_rsa(struct ccp_op *op)
CCP5_CMD_DST_HI() = ccp_addr_hi(>dst.u.dma);
CCP5_CMD_DST_MEM() = CCP_MEMTYPE_SYSTEM;
  
-	/* Exponent is in LSB memory */

-   CCP5_CMD_KEY_LO() = op->sb_key * LSB_ITEM_SIZE;
-   CCP5_CMD_KEY_HI() = 0;
-   CCP5_CMD_KEY_MEM() = CCP_MEMTYPE_SB;
+   /* Key (Exponent) is in external memory */
+   CCP5_CMD_KEY_LO() = ccp_addr_lo(>exp.u.dma);
+   CCP5_CMD_KEY_HI() = ccp_addr_hi(>exp.u.dma);
+   CCP5_CMD_KEY_MEM() = CCP_MEMTYPE_SYSTEM;
  
  	return ccp5_do_cmd(, op->cmd_q);

  }
diff --git a/drivers/crypto/ccp/ccp-ops.c b/drivers/crypto/ccp/ccp-ops.c
index c0dfdacbdff5..11155e52c52c 100644
--- a/drivers/crypto/ccp/ccp-ops.c
+++ b/drivers/crypto/ccp/ccp-ops.c
@@ -1731,10 +1731,10 @@ static int ccp_run_sha_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
  static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd)
  {
struct ccp_rsa_engine *rsa = >u.rsa;
-   struct ccp_dm_workarea exp, src;
-   struct ccp_data dst;
+   struct ccp_dm_workarea exp, src, dst;
struct ccp_op op;
unsigned int sb_count, i_len, o_len;
+   unsigned int key_size_bytes;
int ret;
  
  	if (rsa->key_size > CCP_RSA_MAX_WIDTH)

@@ -1743,31 +1743,41 @@ static int ccp_run_rsa_cmd(struct ccp_cmd_queue *cmd_q, 
struct ccp_cmd *cmd)
if (!rsa->exp || !rsa->mod || !rsa->src || !rsa->dst)
return -EINVAL;
  
-	/* The RSA modulus must precede the message being acted upon, so

-* it must be copied to a DMA area where the message and the
-* modulus can be concatenated.  Therefore the input buffer
-* length required is twice the output buffer length (which
-* must be a multiple of 256-bits).
-*/
-   o_len = ((rsa->key_size + 255) / 256) * 32;
-   i_len = o_len * 2;
-
-   sb_count = o_len / CCP_SB_BYTES;
-
memset(, 0, sizeof(op));
op.cmd_q = cmd_q;
-   op.jobid = ccp_gen_jobid(cmd_q->ccp);
-   op.sb_key = cmd_q->ccp->vdata->perform->sballoc(cmd_q, sb_count);
+   op.jobid = CCP_NEW_JOBID(cmd_q->ccp);


This change isn't related to RSA support, should be a separate patch.

  
-	if (!op.sb_key)

-   return -EIO;
+   /* Compute o_len, i_len in bytes. */
+   if (cmd_q->ccp->vdata->version < CCP_VERSION(5, 0)) {
+   /* The RSA modulus must precede the message being acted upon, so
+* it must be copied to a DMA area where the message and the
+* modulus can be concatenated.  Therefore the input buffer
+* length required is twice the output buffer length (which
+* must be a multiple of 256-bits). sb_count is the
+* number of storage block slots required for the modulus
+*/
+   key_size_bytes = (rsa->key_size + 7) >> 3; > +  o_len 
= ((rsa->key_size + 255) / 256) * CCP_SB_BYTES;


This calculation shouldn't change the "32" to CCP_SB_BYTES.  This is
purely to get the 256-bit alignment.


+   i_len = key_size_bytes * 2;


This violates the comment above, key_size_bytes is byte aligned vs the
256-bit/8-byte alignment required.  i_len should stay as o_len * 2.
Should key_size_bytes be moved down and set to o_len for this path?


+
+   sb_count = o_len / CCP_SB_BYTES;
+
+   op.sb_key = cmd_q->ccp->vdata->perform->sballoc(cmd_q,
+   sb_count);
+   if (!op.sb_key)
+   return -EIO;
+   } else {
+   /* A version 5 device allows a modulus size that will not fit
+* in the LSB, so the command will transfer it from memory.
+* But more importantly, the buffer sizes must be a multiple
+* of 32 bytes; rounding up may be required.
+*/
+   key_size_bytes = 32 * ((rsa->key_size + 255) / 

Re: [PATCH v2 1/7] staging: ccree: fix hash import/export

[Dan Carpenter]

On Thu, Jun 22, 2017 at 04:36:55PM +0300, Gilad Ben-Yossef wrote:
>  static int ssi_ahash_export(struct ahash_request *req, void *out)
>  {
>   struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
>   struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
> + struct device *dev = >drvdata->plat_dev->dev;
> + struct ahash_req_ctx *state = ahash_request_ctx(req);
> + u8 *curr_buff = state->buff_index ? state->buff1 : state->buff0;
> + u32 curr_buff_cnt = state->buff_index ? state->buff1_cnt :
> + state->buff0_cnt;
> + const u32 tmp = CC_EXPORT_MAGIC;
> +
> + CHECK_AND_RETURN_UPON_FIPS_ERROR();
>  
> - return ssi_hash_export(ctx, out);
> + memcpy(out, , sizeof(u32));
> + out += sizeof(u32);
> +
> + dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
> + ctx->inter_digestsize, DMA_BIDIRECTIONAL);
> + memcpy(out, state->digest_buff, ctx->inter_digestsize);
> + out += ctx->inter_digestsize;
> +
> + if (state->digest_bytes_len_dma_addr) {
> + dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
> + HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
> + memcpy(out, state->digest_bytes_len, HASH_LEN_SIZE);
> + }
> + out += HASH_LEN_SIZE;

I'm sorry to ask this question now instead of on my first review.  I was
waiting for my other computer to get ready so I could look up how this
is called.  But now that I've looked at it, I'm still not sure how this
is called.

Anyway, my question is, is out zeroed memory?  Should we have something
like:
} else {
memset(out, 0, HASH_LEN_SIZE);
}
out += HASH_LEN_SIZE;

The ->import() function has a similar snippet.

regards,
dan carpenter

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

[Radu Solea]

On Jo, 2017-06-22 at 15:53 +0800, Herbert Xu wrote:
> On Thu, Jun 22, 2017 at 05:03:44AM +, Radu Solea wrote:
> > 
> > I'm adding cacheline_aligned to iv and result. That is done so
> > hash, iv and result never share a cache line.
> Yes but you're doing it in crypto/gcm.c which isn't even used by
> caam AFAIK.
> 
> Cheers,

My bad, I need to put this in context better. First, I saw this issue
with CAAM, but it has the potential to impact any implementation that
tries to access those fields through DMA. 

CAAM has a number of variations one of them is called CAAM LP, it
doesn't support GCM but it can offload ctr(aes). Which it tries to do,
but because of how this memory is allocated, when the CPU writes
result, the cache mechanism overwrites hash and iv with whatever was
there before the offload happened. This is not the only problem, DMA
writing two fields on the same cacheline is likely to cause issues too:

from https://www.kernel.org/doc/Documentation/DMA-API.txt
Memory coherency operates at a granularity called the cache
line width.  In order for memory mapped by this API to operate
correctly, the mapped region must begin exactly on a cache line
boundary and end exactly on one (to prevent two separately mapped
regions from sharing a single cache line).  Since the cache line size
may not be known at compile time, the API will not enforce this
requirement.  Therefore, it is recommended that driver writers who
don't take special care to determine the cache line size at run time
only map virtual regions that begin and end on page boundaries (which
are guaranteed also to be cache line boundaries).

There are two ways of fixing this AFAIK: the first is adding
cacheline_aligned so those fields don't fall into the same cacheline.
The second is to kzalloc hash and iv separately. kmalloc should honor
ARCH_DMA_MINALIGN which would make this issue go away. 

Cheers,
Radu.

Re: [PATCH] staging: ccree: fix coding style error

[Gilad Ben-Yossef]

On Tue, Jun 20, 2017 at 5:51 PM, Jhih-Ming Huang  wrote:
>
> Hi,
>
> This patch fix all coding style error in driver/staging/ccree/ssi_aead.c.

For patches 1-6:

Acked-by: Gilad Ben-Yossef 

Thanks you,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH V2] staging: ccree: - style fix, spaces and tabs

[Gilad Ben-Yossef]

On Sat, Jun 17, 2017 at 5:44 AM, Derek Robson  wrote:
> Changed code indent to be tabs across whole driver
> Found using checkpatch
>
> Signed-off-by: Derek Robson 
>
> V1 had vague subject.

Acked-by: Gilad Ben-Yossef 

Thanks you,
Gilad




-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[PATCH v2 1/7] staging: ccree: fix hash import/export

[Gilad Ben-Yossef]

Hash import and export was saving and restoring the wrong context
and therefore disabled. Fix it by restoring intermediate digest
and additional state needed.

The hash and mac transform now pass testmgr partial hash tests.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 140 +++
 drivers/staging/ccree/ssi_hash.h |   2 +
 2 files changed, 98 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index ed1c672..c39e3be 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -976,22 +976,6 @@ static int ssi_hash_init(struct ahash_req_ctx *state, 
struct ssi_hash_ctx *ctx)
return 0;
 }
 
-#ifdef EXPORT_FIXED
-static int ssi_hash_export(struct ssi_hash_ctx *ctx, void *out)
-{
-   CHECK_AND_RETURN_UPON_FIPS_ERROR();
-   memcpy(out, ctx, sizeof(struct ssi_hash_ctx));
-   return 0;
-}
-
-static int ssi_hash_import(struct ssi_hash_ctx *ctx, const void *in)
-{
-   CHECK_AND_RETURN_UPON_FIPS_ERROR();
-   memcpy(ctx, in, sizeof(struct ssi_hash_ctx));
-   return 0;
-}
-#endif
-
 static int ssi_hash_setkey(void *hash,
   const u8 *key,
   unsigned int keylen,
@@ -1782,23 +1766,104 @@ static int ssi_ahash_init(struct ahash_request *req)
return ssi_hash_init(state, ctx);
 }
 
-#ifdef EXPORT_FIXED
 static int ssi_ahash_export(struct ahash_request *req, void *out)
 {
struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
+   struct device *dev = >drvdata->plat_dev->dev;
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   u8 *curr_buff = state->buff_index ? state->buff1 : state->buff0;
+   u32 curr_buff_cnt = state->buff_index ? state->buff1_cnt :
+   state->buff0_cnt;
+   const u32 tmp = CC_EXPORT_MAGIC;
+
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-   return ssi_hash_export(ctx, out);
+   memcpy(out, , sizeof(u32));
+   out += sizeof(u32);
+
+   dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
+   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   memcpy(out, state->digest_buff, ctx->inter_digestsize);
+   out += ctx->inter_digestsize;
+
+   if (state->digest_bytes_len_dma_addr) {
+   dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
+   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+   memcpy(out, state->digest_bytes_len, HASH_LEN_SIZE);
+   }
+   out += HASH_LEN_SIZE;
+
+   memcpy(out, _buff_cnt, sizeof(u32));
+   out += sizeof(u32);
+
+   memcpy(out, curr_buff, curr_buff_cnt);
+
+   /* No sync for device ineeded since we did not change the data,
+* we only copy it
+*/
+
+   return 0;
 }
 
 static int ssi_ahash_import(struct ahash_request *req, const void *in)
 {
struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
+   struct device *dev = >drvdata->plat_dev->dev;
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   u32 tmp;
+   int rc;
+
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-   return ssi_hash_import(ctx, in);
+   memcpy(, in, sizeof(u32));
+   if (tmp != CC_EXPORT_MAGIC) {
+   rc = -EINVAL;
+   goto out;
+   }
+   in += sizeof(u32);
+
+   rc = ssi_hash_init(state, ctx);
+   if (rc)
+   goto out;
+
+   dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
+   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   memcpy(state->digest_buff, in, ctx->inter_digestsize);
+   in += ctx->inter_digestsize;
+
+   if (state->digest_bytes_len_dma_addr) {
+   dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
+   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+   memcpy(state->digest_bytes_len, in, HASH_LEN_SIZE);
+   }
+   in += HASH_LEN_SIZE;
+
+   dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
+  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+
+   if (state->digest_bytes_len_dma_addr)
+   dma_sync_single_for_device(dev,
+  state->digest_bytes_len_dma_addr,
+  HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+
+   state->buff_index = 0;
+
+   /* Sanity check the data as much as possible */
+   memcpy(, in, sizeof(u32));
+   if (tmp > SSI_MAX_HASH_BLCK_SIZE) {
+   rc = -EINVAL;
+   goto out;
+   }
+   in += sizeof(u32);
+
+   state->buff0_cnt = tmp;
+   memcpy(state->buff0, in, state->buff0_cnt);
+
+out:
+   return rc;
 }

[PATCH v2 0/7] staging: ccree: bug fixes and TODO items for 4.13

[Gilad Ben-Yossef]

An assortment of bug fixes and staging TODO items.
Highlights includes the driver passing crypto testmgr boot tests
and support of multiple HW revs. without build time changes.

CC: Dan Carpenter 

Changes from v1:
- Rebased on top of latest patches sent to mailing
  list but not yet marged for same driver.
- Address Dan Carpenter style review comments
- Fix clk de-init being called on clk init failure
  error path pointed out by Dan Carpenter.

Gilad Ben-Yossef (7):
  staging: ccree: fix hash import/export
  staging: ccree: register setkey for none hash macs
  staging: ccree: add support for older HW revisions
  staging: ccree: remove unused function
  staging: ccree: add clock management support
  staging: ccree: add DT bus coherency detection
  staging: ccree: use signal safe completion wait

 drivers/staging/ccree/Kconfig|   7 +-
 drivers/staging/ccree/Makefile   |   2 +-
 drivers/staging/ccree/cc_crypto_ctx.h|  16 --
 drivers/staging/ccree/cc_hw_queue_defs.h |  14 +-
 drivers/staging/ccree/cc_regs.h  |   7 +-
 drivers/staging/ccree/dx_crys_kernel.h   |   1 +
 drivers/staging/ccree/dx_host.h  |   3 +
 drivers/staging/ccree/dx_reg_common.h|   2 -
 drivers/staging/ccree/ssi_aead.c |  36 ++-
 drivers/staging/ccree/ssi_buffer_mgr.c   |  37 +--
 drivers/staging/ccree/ssi_cipher.c   |  27 +-
 drivers/staging/ccree/ssi_config.h   |  20 --
 drivers/staging/ccree/ssi_driver.c   | 167 +---
 drivers/staging/ccree/ssi_driver.h   |  32 ++-
 drivers/staging/ccree/ssi_fips_ll.c  |  59 +++--
 drivers/staging/ccree/ssi_hash.c | 441 ++-
 drivers/staging/ccree/ssi_hash.h |  12 +-
 drivers/staging/ccree/ssi_pm.c   |  13 +-
 drivers/staging/ccree/ssi_pm_ext.c   |  60 -
 drivers/staging/ccree/ssi_pm_ext.h   |  33 ---
 drivers/staging/ccree/ssi_request_mgr.c  |  22 +-
 drivers/staging/ccree/ssi_sram_mgr.c |  15 +-
 22 files changed, 561 insertions(+), 465 deletions(-)
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.c
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.h

-- 
2.1.4

[PATCH v2 3/7] staging: ccree: add support for older HW revisions

[Gilad Ben-Yossef]

Add support for the older CryptoCell 710 and 630P hardware revisions.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig|   7 +-
 drivers/staging/ccree/cc_crypto_ctx.h|  16 ---
 drivers/staging/ccree/cc_hw_queue_defs.h |   2 +-
 drivers/staging/ccree/cc_regs.h  |   7 +-
 drivers/staging/ccree/dx_crys_kernel.h   |   1 +
 drivers/staging/ccree/dx_host.h  |   3 +
 drivers/staging/ccree/dx_reg_common.h|   2 -
 drivers/staging/ccree/ssi_aead.c |  36 +++--
 drivers/staging/ccree/ssi_cipher.c   |  27 +++-
 drivers/staging/ccree/ssi_config.h   |   2 +-
 drivers/staging/ccree/ssi_driver.c   | 115 ++-
 drivers/staging/ccree/ssi_driver.h   |  25 +++-
 drivers/staging/ccree/ssi_fips_ll.c  |  59 
 drivers/staging/ccree/ssi_hash.c | 234 +--
 drivers/staging/ccree/ssi_hash.h |  10 +-
 drivers/staging/ccree/ssi_request_mgr.c  |  19 ++-
 drivers/staging/ccree/ssi_sram_mgr.c |  15 +-
 17 files changed, 349 insertions(+), 231 deletions(-)

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 4be87f5..f1e75e8 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -19,9 +19,10 @@ config CRYPTO_DEV_CCREE
select CRYPTO_XTS
help
  Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
- C7xx. Currently only the CryptoCell 712 REE is supported.
- Choose this if you wish to use hardware acceleration of
- cryptographic operations on the system REE.
+ C7xx. Currently the REE interface of the CryptoCell 712,
+ 710 and 630p are supported. Choose this if you wish to use
+ hardware acceleration of cryptographic operations on the
+ system REE.
  If unsure say Y.
 
 config CCREE_FIPS_SUPPORT
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 591f6fd..1542aa7 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -19,17 +19,6 @@
 
 #include 
 
-/* context size */
-#ifndef CC_CTX_SIZE_LOG2
-#if (CC_SUPPORT_SHA > 256)
-#define CC_CTX_SIZE_LOG2 8
-#else
-#define CC_CTX_SIZE_LOG2 7
-#endif
-#endif
-#define CC_CTX_SIZE BIT(CC_CTX_SIZE_LOG2)
-#define CC_DRV_CTX_SIZE_WORDS (CC_CTX_SIZE >> 2)
-
 #define CC_DRV_DES_IV_SIZE 8
 #define CC_DRV_DES_BLOCK_SIZE 8
 
@@ -72,13 +61,8 @@
 #define CC_SHA384_BLOCK_SIZE 128
 #define CC_SHA512_BLOCK_SIZE 128
 
-#if (CC_SUPPORT_SHA > 256)
 #define CC_DIGEST_SIZE_MAX CC_SHA512_DIGEST_SIZE
 #define CC_HASH_BLOCK_SIZE_MAX CC_SHA512_BLOCK_SIZE /*1024b*/
-#else /* Only up to SHA256 */
-#define CC_DIGEST_SIZE_MAX CC_SHA256_DIGEST_SIZE
-#define CC_HASH_BLOCK_SIZE_MAX CC_SHA256_BLOCK_SIZE /*512b*/
-#endif
 
 #define CC_HMAC_BLOCK_SIZE_MAX CC_HASH_BLOCK_SIZE_MAX
 
diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index aaa56c8..c730c3c 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -220,7 +220,7 @@ static inline void hw_desc_init(struct cc_hw_desc *pdesc)
  *
  * @pdesc: pointer HW descriptor struct
  */
-static inline void set_queue_last_ind(struct cc_hw_desc *pdesc)
+static inline void set_queue_last_ind_bit(struct cc_hw_desc *pdesc)
 {
pdesc->word[3] |= FIELD_PREP(WORD3_QUEUE_LAST_IND, 1);
 }
diff --git a/drivers/staging/ccree/cc_regs.h b/drivers/staging/ccree/cc_regs.h
index 4a893a6..62ace81 100644
--- a/drivers/staging/ccree/cc_regs.h
+++ b/drivers/staging/ccree/cc_regs.h
@@ -25,12 +25,9 @@
 
 #include 
 
-#define AXIM_MON_BASE_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP)
-#define AXIM_MON_COMP_VALUE GENMASK(DX_AXIM_MON_COMP_VALUE_BIT_SIZE + \
-   DX_AXIM_MON_COMP_VALUE_BIT_SHIFT, \
-   DX_AXIM_MON_COMP_VALUE_BIT_SHIFT)
+#define AXIM_MON_BASE_712_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP)
+#define AXIM_MON_BASE_630_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP8)
 
-#define AXIM_MON_BASE_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP)
 #define AXIM_MON_COMP_VALUE GENMASK(DX_AXIM_MON_COMP_VALUE_BIT_SIZE + \
DX_AXIM_MON_COMP_VALUE_BIT_SHIFT, \
DX_AXIM_MON_COMP_VALUE_BIT_SHIFT)
diff --git a/drivers/staging/ccree/dx_crys_kernel.h 
b/drivers/staging/ccree/dx_crys_kernel.h
index 2196030..0d1d01e 100644
--- a/drivers/staging/ccree/dx_crys_kernel.h
+++ b/drivers/staging/ccree/dx_crys_kernel.h
@@ -131,6 +131,7 @@
 #define DX_AXIM_MON_INFLIGHTLAST_VALUE_BIT_SHIFT   0x0UL
 #define DX_AXIM_MON_INFLIGHTLAST_VALUE_BIT_SIZE0x8UL
 #define DX_AXIM_MON_COMP_REG_OFFSET0xB80UL
+#define DX_AXIM_MON_COMP8_REG_OFFSET   0xBA0UL
 #define DX_AXIM_MON_COMP_VALUE_BIT_SHIFT   0x0UL
 #define DX_AXIM_MON_COMP_VALUE_BIT_SIZE0x10UL
 #define DX_AXIM_MON_ERR_REG_OFFSET 0xBC4UL
diff --git a/drivers/staging/ccree/dx_host.h 

[PATCH v2 6/7] staging: ccree: add DT bus coherency detection

[Gilad Ben-Yossef]

The ccree driver has build time configurable support
to work on top of coherent (e.g. ACP) vs. none coherent bus
connections. Turn it to run-time configurable option
based on device tree.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 37 ++
 drivers/staging/ccree/ssi_config.h | 20 --
 drivers/staging/ccree/ssi_driver.c | 12 ---
 drivers/staging/ccree/ssi_driver.h |  3 +++
 4 files changed, 32 insertions(+), 40 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 88ebda8..4373d1d 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -627,6 +627,7 @@ void ssi_buffer_mgr_unmap_aead_request(
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
unsigned int hw_iv_size = areq_ctx->hw_iv_size;
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
+   struct ssi_drvdata *drvdata = dev_get_drvdata(dev);
u32 dummy;
bool chained;
u32 size_to_unmap = 0;
@@ -700,8 +701,8 @@ void ssi_buffer_mgr_unmap_aead_request(
dma_unmap_sg(dev, req->dst, 
ssi_buffer_mgr_get_sgl_nents(req->dst,size_to_unmap,,),
DMA_BIDIRECTIONAL);
}
-#if DX_HAS_ACP
-   if ((areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
+   if (drvdata->coherent &&
+   (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
likely(req->src == req->dst))
{
u32 size_to_skip = req->assoclen;
@@ -716,7 +717,6 @@ void ssi_buffer_mgr_unmap_aead_request(
size_to_skip+ req->cryptlen - areq_ctx->req_authsize,
size_to_skip+ req->cryptlen, SSI_SG_FROM_BUF);
}
-#endif
 }
 
 static inline int ssi_buffer_mgr_get_aead_icv_nents(
@@ -981,20 +981,24 @@ static inline int ssi_buffer_mgr_prepare_aead_data_mlli(
 * MAC verification upon request completion
 */
if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
-#if !DX_HAS_ACP
-   /* In ACP platform we already copying ICV
-* for any INPLACE-DECRYPT operation, hence
+   if (!drvdata->coherent) {
+   /* In coherent platforms (e.g. ACP)
+* already copying ICV for any
+* INPLACE-DECRYPT operation, hence
 * we must neglect this code.
 */
-   u32 size_to_skip = req->assoclen;
-   if (areq_ctx->is_gcm4543) {
-   size_to_skip += crypto_aead_ivsize(tfm);
+   u32 skip = req->assoclen;
+
+   if (areq_ctx->is_gcm4543)
+   skip += crypto_aead_ivsize(tfm);
+
+   ssi_buffer_mgr_copy_scatterlist_portion(
+   areq_ctx->backup_mac, req->src,
+   (skip + req->cryptlen -
+areq_ctx->req_authsize),
+   skip + req->cryptlen,
+   SSI_SG_TO_BUF);
}
-   ssi_buffer_mgr_copy_scatterlist_portion(
-   areq_ctx->backup_mac, req->src,
-   size_to_skip+ req->cryptlen - 
areq_ctx->req_authsize,
-   size_to_skip+ req->cryptlen, 
SSI_SG_TO_BUF);
-#endif
areq_ctx->icv_virt_addr = areq_ctx->backup_mac;
} else {
areq_ctx->icv_virt_addr = areq_ctx->mac_buf;
@@ -1281,8 +1285,8 @@ int ssi_buffer_mgr_map_aead_request(
mlli_params->curr_pool = NULL;
sg_data.num_of_buffers = 0;
 
-#if DX_HAS_ACP
-   if ((areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
+   if (drvdata->coherent &&
+   (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
likely(req->src == req->dst))
{
u32 size_to_skip = req->assoclen;
@@ -1297,7 +1301,6 @@ int ssi_buffer_mgr_map_aead_request(
size_to_skip+ req->cryptlen - areq_ctx->req_authsize,
size_to_skip+ req->cryptlen, SSI_SG_TO_BUF);
}
-#endif
 
/* cacluate the size for cipher remove ICV in decrypt*/
areq_ctx->cryptlen = (areq_ctx->gen_ctx.op_type ==
diff --git a/drivers/staging/ccree/ssi_config.h 
b/drivers/staging/ccree/ssi_config.h

[PATCH v2 5/7] staging: ccree: add clock management support

[Gilad Ben-Yossef]

Some SoC which implement CryptoCell have a dedicated clock
tied to it, some do not. Implement clock support if exists
based on device tree data and tie power management to it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile |  2 +-
 drivers/staging/ccree/ssi_driver.c | 40 +
 drivers/staging/ccree/ssi_driver.h |  4 +++
 drivers/staging/ccree/ssi_pm.c | 13 +
 drivers/staging/ccree/ssi_pm_ext.c | 60 --
 drivers/staging/ccree/ssi_pm_ext.h | 33 -
 6 files changed, 47 insertions(+), 105 deletions(-)
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.c
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.h

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 44f3e3e..318c2b3 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o
 ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 131bfc4..2e251a4 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ssi_config.h"
 #include "ssi_driver.h"
@@ -269,6 +270,7 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
hw_rev = (struct cc_hw_data *)dev_id->data;
new_drvdata->hw_rev_name = hw_rev->name;
new_drvdata->hw_rev = hw_rev->rev;
+   new_drvdata->clk = of_clk_get(np, 0);
 
if (hw_rev->rev >= CC_HW_REV_712) {
new_drvdata->hash_len_sz = HASH_LEN_SIZE_712;
@@ -338,6 +340,10 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 
new_drvdata->plat_dev = plat_dev;
 
+   rc = cc_clk_on(new_drvdata);
+   if (rc)
+   goto init_cc_res_err;
+
if(new_drvdata->plat_dev->dev.dma_mask == NULL)
{
new_drvdata->plat_dev->dev.dma_mask = & 
new_drvdata->plat_dev->dev.coherent_dma_mask;
@@ -504,14 +510,11 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
ssi_sysfs_fini();
 #endif
 
-   /* Mask all interrupts */
-   WRITE_REGISTER(drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, HOST_IMR),
-   0x);
+   fini_cc_regs(drvdata);
+   cc_clk_off(drvdata);
free_irq(drvdata->res_irq->start, drvdata);
drvdata->res_irq = NULL;
 
-   fini_cc_regs(drvdata);
-
if (drvdata->cc_base != NULL) {
iounmap(drvdata->cc_base);
release_mem_region(drvdata->res_mem->start,
@@ -524,6 +527,33 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
dev_set_drvdata(_dev->dev, NULL);
 }
 
+int cc_clk_on(struct ssi_drvdata *drvdata)
+{
+   struct clk *clk = drvdata->clk;
+   int rc;
+
+   if (IS_ERR(clk))
+   /* Not all devices have a clock associated with CCREE  */
+   return 0;
+
+   rc = clk_prepare_enable(clk);
+   if (rc)
+   return rc;
+
+   return 0;
+}
+
+void cc_clk_off(struct ssi_drvdata *drvdata)
+{
+   struct clk *clk = drvdata->clk;
+
+   if (IS_ERR(clk))
+   /* Not all devices have a clock associated with CCREE */
+   return;
+
+   clk_disable_unprepare(clk);
+}
+
 static int ccree_probe(struct platform_device *plat_dev)
 {
int rc;
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 3c27fd8..a9333892 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Registers definitions from shared/hw/ree_include */
 #include "dx_reg_base_host.h"
@@ -156,6 +157,7 @@ struct ssi_drvdata {
enum cc_hw_rev hw_rev;
u32 hash_len_sz;
u32 axim_mon_offset;
+   struct clk *clk;
 };
 
 struct ssi_crypto_alg {
@@ -201,6 +203,8 @@ void dump_byte_array(const char *name, const u8 *the_array, 
unsigned long size);
 
 int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe);
 void fini_cc_regs(struct ssi_drvdata *drvdata);
+int cc_clk_on(struct ssi_drvdata *drvdata);
+void cc_clk_off(struct ssi_drvdata *drvdata);
 
 static inline void set_queue_last_ind(struct ssi_drvdata *drvdata,
  struct cc_hw_desc *pdesc)
diff --git a/drivers/staging/ccree/ssi_pm.c b/drivers/staging/ccree/ssi_pm.c
index 5bfbdd0..67ae1dc 100644
--- a/drivers/staging/ccree/ssi_pm.c
+++ 

[PATCH v2 4/7] staging: ccree: remove unused function

[Gilad Ben-Yossef]

The function set_ack_last was not used anywhere. Remove it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_hw_queue_defs.h | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index c730c3c..ac0eb97 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -226,18 +226,6 @@ static inline void set_queue_last_ind_bit(struct 
cc_hw_desc *pdesc)
 }
 
 /*
- * Signs the end of HW descriptors flow by asking for completion ack,
- * and release the HW engines
- *
- * @pdesc: pointer HW descriptor struct
- */
-static inline void set_ack_last(struct cc_hw_desc *pdesc)
-{
-   pdesc->word[3] |= FIELD_PREP(WORD3_QUEUE_LAST_IND, 1);
-   pdesc->word[4] |= FIELD_PREP(WORD4_ACK_NEEDED, 1);
-}
-
-/*
  * Set the DIN field of a HW descriptors
  *
  * @pdesc: pointer HW descriptor struct
-- 
2.1.4

[PATCH v2 2/7] staging: ccree: register setkey for none hash macs

[Gilad Ben-Yossef]

Fix a bug where the transformation init code did
not register a setkey method for none hash based MACs.

Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support").

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 83 
 1 file changed, 42 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index c39e3be..f52e1af 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1874,8 +1874,8 @@ static int ssi_ahash_setkey(struct crypto_ahash *ahash,
 struct ssi_hash_template {
char name[CRYPTO_MAX_ALG_NAME];
char driver_name[CRYPTO_MAX_ALG_NAME];
-   char hmac_name[CRYPTO_MAX_ALG_NAME];
-   char hmac_driver_name[CRYPTO_MAX_ALG_NAME];
+   char mac_name[CRYPTO_MAX_ALG_NAME];
+   char mac_driver_name[CRYPTO_MAX_ALG_NAME];
unsigned int blocksize;
bool synchronize;
struct ahash_alg template_ahash;
@@ -1894,8 +1894,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha1",
.driver_name = "sha1-dx",
-   .hmac_name = "hmac(sha1)",
-   .hmac_driver_name = "hmac-sha1-dx",
+   .mac_name = "hmac(sha1)",
+   .mac_driver_name = "hmac-sha1-dx",
.blocksize = SHA1_BLOCK_SIZE,
.synchronize = false,
.template_ahash = {
@@ -1919,8 +1919,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha256",
.driver_name = "sha256-dx",
-   .hmac_name = "hmac(sha256)",
-   .hmac_driver_name = "hmac-sha256-dx",
+   .mac_name = "hmac(sha256)",
+   .mac_driver_name = "hmac-sha256-dx",
.blocksize = SHA256_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1943,8 +1943,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha224",
.driver_name = "sha224-dx",
-   .hmac_name = "hmac(sha224)",
-   .hmac_driver_name = "hmac-sha224-dx",
+   .mac_name = "hmac(sha224)",
+   .mac_driver_name = "hmac-sha224-dx",
.blocksize = SHA224_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1968,8 +1968,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha384",
.driver_name = "sha384-dx",
-   .hmac_name = "hmac(sha384)",
-   .hmac_driver_name = "hmac-sha384-dx",
+   .mac_name = "hmac(sha384)",
+   .mac_driver_name = "hmac-sha384-dx",
.blocksize = SHA384_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1992,8 +1992,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha512",
.driver_name = "sha512-dx",
-   .hmac_name = "hmac(sha512)",
-   .hmac_driver_name = "hmac-sha512-dx",
+   .mac_name = "hmac(sha512)",
+   .mac_driver_name = "hmac-sha512-dx",
.blocksize = SHA512_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2017,8 +2017,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "md5",
.driver_name = "md5-dx",
-   .hmac_name = "hmac(md5)",
-   .hmac_driver_name = "hmac-md5-dx",
+   .mac_name = "hmac(md5)",
+   .mac_driver_name = "hmac-md5-dx",
.blocksize = MD5_HMAC_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2039,8 +2039,8 @@ static struct ssi_hash_template driver_hash[] = {
.inter_digestsize = MD5_DIGEST_SIZE,
},
{
-   .name = "xcbc(aes)",
-   .driver_name = "xcbc-aes-dx",
+   .mac_name = "xcbc(aes)",
+   .mac_driver_name = "xcbc-aes-dx",
.blocksize = AES_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2062,8 +2062,8 @@ static struct ssi_hash_template driver_hash[] = {
},
 #if SSI_CC_HAS_CMAC
{
-   .name = "cmac(aes)",
-   .driver_name = "cmac-aes-dx",
+   .mac_name = "cmac(aes)",
+   .mac_driver_name = "cmac-aes-dx",
.blocksize = AES_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2106,9 +2106,9 @@ ssi_hash_create_alg(struct ssi_hash_template *template, 
bool keyed)
 
if (keyed) {
snprintf(alg->cra_name, CRYPTO_MAX_ALG_NAME, "%s",
-

[PATCH v2 7/7] staging: ccree: use signal safe completion wait

[Gilad Ben-Yossef]

We were waiting for a completion notification of HW DMA
operation using an interruptible wait which can result
in data corruption if a signal interrupted us while
DMA was not yet completed.

Fix this by moving to uninterrupted wait.

Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW driver").

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_request_mgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index cffc8de..87f5ab6 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -382,7 +382,8 @@ int send_request(
/* Wait upon sequence completion.
 *  Return "0" -Operation done successfully.
 */
-   return wait_for_completion_interruptible(_req->seq_compl);
+   wait_for_completion(_req->seq_compl);
+   return 0;
} else {
/* Operation still in process */
return -EINPROGRESS;
-- 
2.1.4

Re: [PATCH 6/7] staging: ccree: add DT bus coherency detection

[Gilad Ben-Yossef]

On Thu, Jun 22, 2017 at 12:04 PM, Dan Carpenter
 wrote:
> On Thu, Jun 22, 2017 at 10:07:52AM +0300, Gilad Ben-Yossef wrote:
>> The ccree driver has build time configurable support
>> to work on top of coherent (e.g. ACP) vs. none coherent bus
>> connections. Turn it to run-time configurable option
>> based on device tree.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>> ---
>>  drivers/staging/ccree/ssi_buffer_mgr.c | 37 
>> ++
>>  drivers/staging/ccree/ssi_config.h | 20 --
>>  drivers/staging/ccree/ssi_driver.c | 14 +
>>  drivers/staging/ccree/ssi_driver.h |  3 +++
>>  4 files changed, 33 insertions(+), 41 deletions(-)
>>
>> diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
>> b/drivers/staging/ccree/ssi_buffer_mgr.c
>> index 88ebda8..75810dc 100644
>> --- a/drivers/staging/ccree/ssi_buffer_mgr.c
>> +++ b/drivers/staging/ccree/ssi_buffer_mgr.c
>> @@ -627,6 +627,9 @@ void ssi_buffer_mgr_unmap_aead_request(
>>   struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
>>   unsigned int hw_iv_size = areq_ctx->hw_iv_size;
>>   struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>> + struct ssi_drvdata *drvdata =
>> + (struct ssi_drvdata *)dev_get_drvdata(dev);
>
> The cast is not needed.
>
>> +
>
> Don't put a blank in the middle of the declaration block.
>
>>   u32 dummy;
>>   bool chained;
>>   u32 size_to_unmap = 0;

Will fix.

>
> [ snip ]
>
>> @@ -981,20 +983,22 @@ static inline int 
>> ssi_buffer_mgr_prepare_aead_data_mlli(
>>* MAC verification upon request completion
>>*/
>>   if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
>> -#if !DX_HAS_ACP
>> - /* In ACP platform we already copying ICV
>> -  * for any INPLACE-DECRYPT operation, hence
>> + if (!drvdata->coherent) {
>> + /* In coherent platforms (e.g. ACP)
>> +  * already copying ICV for any
>> +  * INPLACE-DECRYPT operation, hence
>>* we must neglect this code.
>>*/
>> - u32 size_to_skip = req->assoclen;
>> - if (areq_ctx->is_gcm4543) {
>> - size_to_skip += 
>> crypto_aead_ivsize(tfm);
>> + u32 skip = req->assoclen;
>> +
>> + if (areq_ctx->is_gcm4543)
>> + skip += 
>> crypto_aead_ivsize(tfm);
>> +
>> + 
>> ssi_buffer_mgr_copy_scatterlist_portion(
>> +areq_ctx->backup_mac, req->src,
>> +(skip + req->cryptlen - areq_ctx->req_authsize),
>> +skip + req->cryptlen, SSI_SG_TO_BUF);
>
>
> Indenting is messed up.

Sigh... having a function with a name as long as
ssi_buffer_mgr_copy_scatterlist_portion()
with such a deep indentation level is what is really messed up (but
that is for another patch
to fix).

I will indent it more sanely.
>
>>   }
>> - ssi_buffer_mgr_copy_scatterlist_portion(
>> - areq_ctx->backup_mac, req->src,
>> - size_to_skip+ req->cryptlen - 
>> areq_ctx->req_authsize,
>> - size_to_skip+ req->cryptlen, 
>> SSI_SG_TO_BUF);
>> -#endif
>>   areq_ctx->icv_virt_addr = areq_ctx->backup_mac;
>>   } else {
>>   areq_ctx->icv_virt_addr = areq_ctx->mac_buf;
>
> [ snip ]
>
>> @@ -533,7 +539,7 @@ int cc_clk_on(struct ssi_drvdata *drvdata)
>>   struct clk *clk = drvdata->clk;
>>
>>   if (IS_ERR(clk))
>> - /* No all devices have a clock associated with CCREE */
>> + /* Not all devices have a clock associated with CCREE */
>
> This is not related.  Do unrelated things in different patches.  This
> typo was introduced in an earlier patch.  There are a couple ways in git
> to edit previous patches.

Yes, this was not intended.


>
>>   goto out;
>>
>>   rc = clk_prepare_enable(clk);
>
> regards,
> dan carpenter

Thanks for your time and great review comments!

Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 5/7] staging: ccree: add clock management support

[Gilad Ben-Yossef]

On Thu, Jun 22, 2017 at 11:58 AM, Dan Carpenter
 wrote:
> On Thu, Jun 22, 2017 at 10:07:51AM +0300, Gilad Ben-Yossef wrote:
>> +int cc_clk_on(struct ssi_drvdata *drvdata)
>> +{
>> + int rc = 0;
>> + struct clk *clk = drvdata->clk;
>> +
>> + if (IS_ERR(clk))
>> + /* No all devices have a clock associated with CCREE */
>> + goto out;
>
> Ugh...  I hate this.  The "goto out;" here is a waste of time
> do-nothing-goto that returns diretly.  It's equivalent to "return 0;".
> Is that intended?  Even with the comment, it's not clear...
>
> People think do nothing gotos are a great idea but from reviewing tons
> and tons of real life errors, I can assure you that in real life (as
> opposed to theory) they don't prevent any future bugs and only introduce
> "forgot to set the error code" bugs.

I see your point and the code is indeed clearer this way.

Will fix.

Thanks,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[PATCH] crypto: qat - avoid an uninitialized variable warning

[Arnd Bergmann]

After commit 9e442aa6a753 ("x86: remove DMA_ERROR_CODE"), the inlining
decisions in the qat driver changed slightly, introducing a new false-positive
warning:

drivers/crypto/qat/qat_common/qat_algs.c: In function 
'qat_alg_sgl_to_bufl.isra.6':
include/linux/dma-mapping.h:228:2: error: 'sz_out' may be used uninitialized in 
this function [-Werror=maybe-uninitialized]
drivers/crypto/qat/qat_common/qat_algs.c:676:9: note: 'sz_out' was declared here

The patch that introduced this is correct, so let's just avoid the
warning in this driver by rearranging the unwinding after an error
to make it more obvious to the compiler what is going on.

The problem here is the 'if (unlikely(dma_mapping_error(dev, blp)))'
check, in which the 'unlikely' causes gcc to forget what it knew about
the state of the variables. Cleaning up the dma state in the reverse
order it was created means we can simplify the logic so it doesn't have
to know about that state, and also makes it easier to understand.

Cc: Christoph Hellwig 
Signed-off-by: Arnd Bergmann 
---
 drivers/crypto/qat/qat_common/qat_algs.c | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/crypto/qat/qat_common/qat_algs.c 
b/drivers/crypto/qat/qat_common/qat_algs.c
index 5b5efcc52cb5..baffae817259 100644
--- a/drivers/crypto/qat/qat_common/qat_algs.c
+++ b/drivers/crypto/qat/qat_common/qat_algs.c
@@ -686,7 +686,7 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance 
*inst,
 
blp = dma_map_single(dev, bufl, sz, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, blp)))
-   goto err;
+   goto err_in;
 
for_each_sg(sgl, sg, n, i) {
int y = sg_nctr;
@@ -699,7 +699,7 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance 
*inst,
  DMA_BIDIRECTIONAL);
bufl->bufers[y].len = sg->length;
if (unlikely(dma_mapping_error(dev, bufl->bufers[y].addr)))
-   goto err;
+   goto err_in;
sg_nctr++;
}
bufl->num_bufs = sg_nctr;
@@ -717,10 +717,10 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance 
*inst,
buflout = kzalloc_node(sz_out, GFP_ATOMIC,
   dev_to_node(_DEV(inst->accel_dev)));
if (unlikely(!buflout))
-   goto err;
+   goto err_in;
bloutp = dma_map_single(dev, buflout, sz_out, DMA_TO_DEVICE);
if (unlikely(dma_mapping_error(dev, bloutp)))
-   goto err;
+   goto err_out;
bufers = buflout->bufers;
for_each_sg(sglout, sg, n, i) {
int y = sg_nctr;
@@ -732,7 +732,7 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance 
*inst,
sg->length,
DMA_BIDIRECTIONAL);
if (unlikely(dma_mapping_error(dev, bufers[y].addr)))
-   goto err;
+   goto err_out;
bufers[y].len = sg->length;
sg_nctr++;
}
@@ -747,9 +747,20 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance 
*inst,
qat_req->buf.sz_out = 0;
}
return 0;
-err:
-   dev_err(dev, "Failed to map buf for dma\n");
-   sg_nctr = 0;
+
+err_out:
+   n = sg_nents(sglout);
+   for (i = 0; i < n; i++)
+   if (!dma_mapping_error(dev, buflout->bufers[i].addr))
+   dma_unmap_single(dev, buflout->bufers[i].addr,
+buflout->bufers[i].len,
+DMA_BIDIRECTIONAL);
+   if (!dma_mapping_error(dev, bloutp))
+   dma_unmap_single(dev, bloutp, sz_out, DMA_TO_DEVICE);
+   kfree(buflout);
+
+err_in:
+   n = sg_nents(sgl);
for (i = 0; i < n; i++)
if (!dma_mapping_error(dev, bufl->bufers[i].addr))
dma_unmap_single(dev, bufl->bufers[i].addr,
@@ -759,17 +770,8 @@ static int qat_alg_sgl_to_bufl(struct qat_crypto_instance 
*inst,
if (!dma_mapping_error(dev, blp))
dma_unmap_single(dev, blp, sz, DMA_TO_DEVICE);
kfree(bufl);
-   if (sgl != sglout && buflout) {
-   n = sg_nents(sglout);
-   for (i = 0; i < n; i++)
-   if (!dma_mapping_error(dev, buflout->bufers[i].addr))
-   dma_unmap_single(dev, buflout->bufers[i].addr,
-buflout->bufers[i].len,
-DMA_BIDIRECTIONAL);
-   if (!dma_mapping_error(dev, bloutp))
-

Re: Regarding Porting of hardware cryptography to Linux kernel

[Marek Vasut]

On 06/22/2017 01:50 PM, sagar khadgi wrote:
> Hi Marek,

Hi,

> I am having one microcontroller which has AES, HMAC, SHA, DES, RSA, DSA,
> ECDSA cryptographic services. I want to port it to Linux Kernal so that
> I can access them through OpenSSL from user space.
> 
> I am new to Linux. Can you please provide me any document or link for
> porting the hardware cryptography to Linux kernel.

Try https://www.kernel.org/doc/html/v4.11/crypto/index.html

unless you provide further details about your hardware, it's hard to
help you more.

> Thanking you in advance.
> 
> Regards,
> Sagar


-- 
Best regards,
Marek Vasut

[PATCH 1/3] crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup

[Brijesh Singh]

Update pci and platform files to use devres interface to allocate the PCI
and iomap resources. Also add helper functions to consolicate module init,
exit and power mangagement code duplication.

Signed-off-by: Brijesh Singh 
---
 drivers/crypto/ccp/ccp-dev-v3.c   |   8 +++
 drivers/crypto/ccp/ccp-dev.c  |  61 
 drivers/crypto/ccp/ccp-dev.h  |   6 ++
 drivers/crypto/ccp/ccp-pci.c  | 114 +-
 drivers/crypto/ccp/ccp-platform.c |  56 ++-
 5 files changed, 107 insertions(+), 138 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 367c2e3..1cae5a3 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -586,6 +586,14 @@ static const struct ccp_actions ccp3_actions = {
.irqhandler = ccp_irq_handler,
 };
 
+const struct ccp_vdata ccpv3_platform = {
+   .version = CCP_VERSION(3, 0),
+   .setup = NULL,
+   .perform = _actions,
+   .bar = 2,
+   .offset = 0,
+};
+
 const struct ccp_vdata ccpv3 = {
.version = CCP_VERSION(3, 0),
.setup = NULL,
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 2506b50..ce35e43 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -538,8 +538,69 @@ bool ccp_queues_suspended(struct ccp_device *ccp)
 
return ccp->cmd_q_count == suspended;
 }
+
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state)
+{
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>cmd_lock, flags);
+
+   ccp->suspending = 1;
+
+   /* Wake all the queue kthreads to prepare for suspend */
+   for (i = 0; i < ccp->cmd_q_count; i++)
+   wake_up_process(ccp->cmd_q[i].kthread);
+
+   spin_unlock_irqrestore(>cmd_lock, flags);
+
+   /* Wait for all queue kthreads to say they're done */
+   while (!ccp_queues_suspended(ccp))
+   wait_event_interruptible(ccp->suspend_queue,
+ccp_queues_suspended(ccp));
+
+   return 0;
+}
+
+int ccp_dev_resume(struct ccp_device *ccp)
+{
+   unsigned long flags;
+   unsigned int i;
+
+   spin_lock_irqsave(>cmd_lock, flags);
+
+   ccp->suspending = 0;
+
+   /* Wake up all the kthreads */
+   for (i = 0; i < ccp->cmd_q_count; i++) {
+   ccp->cmd_q[i].suspended = 0;
+   wake_up_process(ccp->cmd_q[i].kthread);
+   }
+
+   spin_unlock_irqrestore(>cmd_lock, flags);
+
+   return 0;
+}
 #endif
 
+int ccp_dev_init(struct ccp_device *ccp)
+{
+   if (ccp->vdata->setup)
+   ccp->vdata->setup(ccp);
+
+   ccp->io_regs = ccp->io_map + ccp->vdata->offset;
+
+   return ccp->vdata->perform->init(ccp);
+}
+
+void ccp_dev_destroy(struct ccp_device *ccp)
+{
+   if (!ccp)
+   return;
+
+   ccp->vdata->perform->destroy(ccp);
+}
+
 static int __init ccp_mod_init(void)
 {
 #ifdef CONFIG_X86
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index a70154a..df2e76e 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -652,6 +652,11 @@ void ccp_dmaengine_unregister(struct ccp_device *ccp);
 void ccp5_debugfs_setup(struct ccp_device *ccp);
 void ccp5_debugfs_destroy(void);
 
+int ccp_dev_init(struct ccp_device *ccp);
+void ccp_dev_destroy(struct ccp_device *ccp);
+int ccp_dev_suspend(struct ccp_device *ccp, pm_message_t state);
+int ccp_dev_resume(struct ccp_device *ccp);
+
 /* Structure for computation functions that are device-specific */
 struct ccp_actions {
int (*aes)(struct ccp_op *);
@@ -679,6 +684,7 @@ struct ccp_vdata {
const unsigned int offset;
 };
 
+extern const struct ccp_vdata ccpv3_platform;
 extern const struct ccp_vdata ccpv3;
 extern const struct ccp_vdata ccpv5a;
 extern const struct ccp_vdata ccpv5b;
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index e880d4cf4..490ad0a 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -150,28 +150,13 @@ static void ccp_free_irqs(struct ccp_device *ccp)
ccp->irq = 0;
 }
 
-static int ccp_find_mmio_area(struct ccp_device *ccp)
-{
-   struct device *dev = ccp->dev;
-   struct pci_dev *pdev = to_pci_dev(dev);
-   resource_size_t io_len;
-   unsigned long io_flags;
-
-   io_flags = pci_resource_flags(pdev, ccp->vdata->bar);
-   io_len = pci_resource_len(pdev, ccp->vdata->bar);
-   if ((io_flags & IORESOURCE_MEM) &&
-   (io_len >= (ccp->vdata->offset + 0x800)))
-   return ccp->vdata->bar;
-
-   return -EIO;
-}
-
 static int ccp_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
 {
struct ccp_device *ccp;
struct ccp_pci *ccp_pci;
struct device *dev = >dev;
-   unsigned int bar;
+   void __iomem * const *iomap_table;
+   int bar_mask;
 

[PATCH 3/3] crypto: cpp - Abstract interrupt registeration

[Brijesh Singh]

The CCP and PSP devices part of AMD Secure Procesor may share the same
interrupt. Hence we expand the SP device to register a common interrupt
handler and provide functions to CCP and PSP devices to register their
interrupt callback which will be invoked upon interrupt.

Signed-off-by: Brijesh Singh 
---
 drivers/crypto/ccp/ccp-dev-v3.c   |   6 +--
 drivers/crypto/ccp/ccp-dev-v5.c   |   7 ++-
 drivers/crypto/ccp/ccp-dev.c  |   3 +-
 drivers/crypto/ccp/ccp-dev.h  |   2 -
 drivers/crypto/ccp/ccp-pci.c  | 103 +++-
 drivers/crypto/ccp/ccp-platform.c |  57 ++--
 drivers/crypto/ccp/sp-dev.c   | 107 ++
 drivers/crypto/ccp/sp-dev.h   |  17 +-
 8 files changed, 187 insertions(+), 115 deletions(-)

diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 57179034..695fde8 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -453,7 +453,7 @@ static int ccp_init(struct ccp_device *ccp)
iowrite32(ccp->qim, ccp->io_regs + IRQ_STATUS_REG);
 
/* Request an irq */
-   ret = ccp->get_irq(ccp);
+   ret = sp_request_ccp_irq(ccp->sp, ccp_irq_handler, ccp->name, ccp);
if (ret) {
dev_err(dev, "unable to allocate an IRQ\n");
goto e_pool;
@@ -510,7 +510,7 @@ static int ccp_init(struct ccp_device *ccp)
if (ccp->cmd_q[i].kthread)
kthread_stop(ccp->cmd_q[i].kthread);
 
-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);
 
 e_pool:
for (i = 0; i < ccp->cmd_q_count; i++)
@@ -549,7 +549,7 @@ static void ccp_destroy(struct ccp_device *ccp)
if (ccp->cmd_q[i].kthread)
kthread_stop(ccp->cmd_q[i].kthread);
 
-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);
 
for (i = 0; i < ccp->cmd_q_count; i++)
dma_pool_destroy(ccp->cmd_q[i].dma_pool);
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 8ed2b37..b0391f0 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -880,7 +880,7 @@ static int ccp5_init(struct ccp_device *ccp)
 
dev_dbg(dev, "Requesting an IRQ...\n");
/* Request an irq */
-   ret = ccp->get_irq(ccp);
+   ret = sp_request_ccp_irq(ccp->sp, ccp5_irq_handler, ccp->name, ccp);
if (ret) {
dev_err(dev, "unable to allocate an IRQ\n");
goto e_pool;
@@ -986,7 +986,7 @@ static int ccp5_init(struct ccp_device *ccp)
kthread_stop(ccp->cmd_q[i].kthread);
 
 e_irq:
-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);
 
 e_pool:
for (i = 0; i < ccp->cmd_q_count; i++)
@@ -1036,7 +1036,7 @@ static void ccp5_destroy(struct ccp_device *ccp)
if (ccp->cmd_q[i].kthread)
kthread_stop(ccp->cmd_q[i].kthread);
 
-   ccp->free_irq(ccp);
+   sp_free_ccp_irq(ccp->sp, ccp);
 
for (i = 0; i < ccp->cmd_q_count; i++) {
cmd_q = >cmd_q[i];
@@ -1105,7 +1105,6 @@ static const struct ccp_actions ccp5_actions = {
.init = ccp5_init,
.destroy = ccp5_destroy,
.get_free_slots = ccp5_get_free_slots,
-   .irqhandler = ccp5_irq_handler,
 };
 
 const struct ccp_vdata ccpv5a = {
diff --git a/drivers/crypto/ccp/ccp-dev.c b/drivers/crypto/ccp/ccp-dev.c
index 8a1674a..7c751bf 100644
--- a/drivers/crypto/ccp/ccp-dev.c
+++ b/drivers/crypto/ccp/ccp-dev.c
@@ -599,8 +599,7 @@ int ccp_dev_init(struct sp_device *sp)
goto e_err;
}
 
-   ccp->get_irq = sp->get_irq;
-   ccp->free_irq = sp->free_irq;
+   ccp->use_tasklet = sp->use_tasklet;
 
ccp->io_regs = sp->io_map + ccp->vdata->offset;
if (ccp->vdata->setup)
diff --git a/drivers/crypto/ccp/ccp-dev.h b/drivers/crypto/ccp/ccp-dev.h
index ca44821..193f309 100644
--- a/drivers/crypto/ccp/ccp-dev.h
+++ b/drivers/crypto/ccp/ccp-dev.h
@@ -351,8 +351,6 @@ struct ccp_device {
/* Bus specific device information
 */
void *dev_specific;
-   int (*get_irq)(struct ccp_device *ccp);
-   void (*free_irq)(struct ccp_device *ccp);
unsigned int qim;
unsigned int irq;
bool use_tasklet;
diff --git a/drivers/crypto/ccp/ccp-pci.c b/drivers/crypto/ccp/ccp-pci.c
index 7eab3c6..f6b9858 100644
--- a/drivers/crypto/ccp/ccp-pci.c
+++ b/drivers/crypto/ccp/ccp-pci.c
@@ -28,67 +28,37 @@
 
 #define MSIX_VECTORS   2
 
-struct ccp_msix {
-   u32 vector;
-   char name[16];
-};
-
 struct ccp_pci {
int msix_count;
-   struct ccp_msix msix[MSIX_VECTORS];
+   struct msix_entry msix_entry[MSIX_VECTORS];
 };
 
-static int ccp_get_msix_irqs(struct ccp_device *ccp)
+static int ccp_get_msix_irqs(struct sp_device *sp)
 {
-   struct sp_device *sp = ccp->sp;
struct 

[PATCH 2/3] crypto: ccp - Introduce the AMD Secure Processor device

[Brijesh Singh]

The CCP device is part of the AMD Secure Processor. In order to expand
the usage of the AMD Secure Processor, create a framework that allows
functional components of the AMD Secure Processor to be initialized and
handled appropriately.

Signed-off-by: Brijesh Singh 
---
 drivers/crypto/Kconfig|  10 +-
 drivers/crypto/ccp/Kconfig|  43 ++---
 drivers/crypto/ccp/Makefile   |   6 +-
 drivers/crypto/ccp/ccp-dev-v3.c   |   5 +-
 drivers/crypto/ccp/ccp-dev-v5.c   |   5 +-
 drivers/crypto/ccp/ccp-dev.c  | 106 +---
 drivers/crypto/ccp/ccp-dev.h  |  21 +---
 drivers/crypto/ccp/ccp-pci.c  |  81 ++--
 drivers/crypto/ccp/ccp-platform.c |  70 --
 drivers/crypto/ccp/sp-dev.c   | 198 ++
 drivers/crypto/ccp/sp-dev.h   | 120 +++
 include/linux/ccp.h   |   3 +-
 12 files changed, 493 insertions(+), 175 deletions(-)
 create mode 100644 drivers/crypto/ccp/sp-dev.c
 create mode 100644 drivers/crypto/ccp/sp-dev.h

diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 0528a62..418f991 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -512,14 +512,14 @@ config CRYPTO_DEV_ATMEL_SHA
  To compile this driver as a module, choose M here: the module
  will be called atmel-sha.
 
-config CRYPTO_DEV_CCP
-   bool "Support for AMD Cryptographic Coprocessor"
+config CRYPTO_DEV_SP
+   bool "Support for AMD Secure Processor"
depends on ((X86 && PCI) || (ARM64 && (OF_ADDRESS || ACPI))) && 
HAS_IOMEM
help
- The AMD Cryptographic Coprocessor provides hardware offload support
- for encryption, hashing and related operations.
+ The AMD Secure Processor provides hardware offload support for memory
+ encryption in virtualization and cryptographic hashing and related 
operations.
 
-if CRYPTO_DEV_CCP
+if CRYPTO_DEV_SP
source "drivers/crypto/ccp/Kconfig"
 endif
 
diff --git a/drivers/crypto/ccp/Kconfig b/drivers/crypto/ccp/Kconfig
index 2238f77..bc08f03 100644
--- a/drivers/crypto/ccp/Kconfig
+++ b/drivers/crypto/ccp/Kconfig
@@ -1,26 +1,37 @@
-config CRYPTO_DEV_CCP_DD
-   tristate "Cryptographic Coprocessor device driver"
-   depends on CRYPTO_DEV_CCP
-   default m
-   select HW_RANDOM
-   select DMA_ENGINE
-   select DMADEVICES
-   select CRYPTO_SHA1
-   select CRYPTO_SHA256
-   help
- Provides the interface to use the AMD Cryptographic Coprocessor
- which can be used to offload encryption operations such as SHA,
- AES and more. If you choose 'M' here, this module will be called
- ccp.
-
 config CRYPTO_DEV_CCP_CRYPTO
tristate "Encryption and hashing offload support"
-   depends on CRYPTO_DEV_CCP_DD
+   depends on CRYPTO_DEV_SP_DD
default m
select CRYPTO_HASH
select CRYPTO_BLKCIPHER
select CRYPTO_AUTHENC
+   select CRYPTO_DEV_CCP
help
  Support for using the cryptographic API with the AMD Cryptographic
  Coprocessor. This module supports offload of SHA and AES algorithms.
  If you choose 'M' here, this module will be called ccp_crypto.
+
+config CRYPTO_DEV_SP_DD
+   tristate "Secure Processor device driver"
+   depends on CRYPTO_DEV_SP
+   default m
+   help
+ Provides the interface to use the AMD Secure Processor. The
+ AMD Secure Processor support the Platform Security Processor (PSP)
+ and Cryptographic Coprocessor (CCP). If you choose 'M' here, this
+ module will be called ccp.
+
+if CRYPTO_DEV_SP_DD
+config CRYPTO_DEV_CCP
+   bool "Cryptographic Coprocessor interface"
+   default y
+   select HW_RANDOM
+   select DMA_ENGINE
+   select DMADEVICES
+   select CRYPTO_SHA1
+   select CRYPTO_SHA256
+   help
+ Provides the interface to use the AMD Cryptographic Coprocessor
+ which can be used to offload encryption operations such as SHA,
+ AES and more.
+endif
diff --git a/drivers/crypto/ccp/Makefile b/drivers/crypto/ccp/Makefile
index 59493fd..ea42888 100644
--- a/drivers/crypto/ccp/Makefile
+++ b/drivers/crypto/ccp/Makefile
@@ -1,9 +1,9 @@
-obj-$(CONFIG_CRYPTO_DEV_CCP_DD) += ccp.o
-ccp-objs := ccp-dev.o \
+obj-$(CONFIG_CRYPTO_DEV_SP_DD) += ccp.o
+ccp-objs  := sp-dev.o ccp-platform.o
+ccp-$(CONFIG_CRYPTO_DEV_CCP) += ccp-dev.o \
ccp-ops.o \
ccp-dev-v3.o \
ccp-dev-v5.o \
-   ccp-platform.o \
ccp-dmaengine.o \
ccp-debugfs.o
 ccp-$(CONFIG_PCI) += ccp-pci.o
diff --git a/drivers/crypto/ccp/ccp-dev-v3.c b/drivers/crypto/ccp/ccp-dev-v3.c
index 1cae5a3..57179034 100644
--- a/drivers/crypto/ccp/ccp-dev-v3.c
+++ b/drivers/crypto/ccp/ccp-dev-v3.c
@@ -359,8 +359,7 @@ static void ccp_irq_bh(unsigned long data)
 
 static irqreturn_t ccp_irq_handler(int irq, void 

[PATCH 0/3] Introduce AMD Secure Processor device

[Brijesh Singh]

CCP device (drivers/crypto/ccp/ccp.ko) is part of AMD Secure Processor,
which is not dedicated solely to crypto. The AMD Secure Processor includes
CCP and PSP (Platform Secure Processor) devices.

This patch series adds a framework that allows functional component of the
AMD Secure Processor to be initialized and handled appropriately. The series
does not makes any logic modification into CCP - it refactors the code to
integerate CCP into AMD secure processor framework.

Brijesh Singh (3):
  crypto: ccp - Use devres interface to allocate PCI/iomap and cleanup
  crypto: ccp - Introduce the AMD Secure Processor device
  crypto: cpp - Abstract interrupt registeration

 drivers/crypto/Kconfig|  10 +-
 drivers/crypto/ccp/Kconfig|  43 --
 drivers/crypto/ccp/Makefile   |   6 +-
 drivers/crypto/ccp/ccp-dev-v3.c   |  17 ++-
 drivers/crypto/ccp/ccp-dev-v5.c   |  12 +-
 drivers/crypto/ccp/ccp-dev.c  | 124 ++--
 drivers/crypto/ccp/ccp-dev.h  |  19 +--
 drivers/crypto/ccp/ccp-pci.c  | 264 -
 drivers/crypto/ccp/ccp-platform.c | 165 -
 drivers/crypto/ccp/sp-dev.c   | 305 ++
 drivers/crypto/ccp/sp-dev.h   | 133 +
 include/linux/ccp.h   |   3 +-
 12 files changed, 730 insertions(+), 371 deletions(-)
 create mode 100644 drivers/crypto/ccp/sp-dev.c
 create mode 100644 drivers/crypto/ccp/sp-dev.h

-- 
2.9.4

[RFC PATCH] crypto: ecdh: fix concurrency on ecdh_ctx

[Tudor Ambarus]

ecdh_ctx contained static allocated data for the shared secret,
for the public and private key.

When talking about shared secret and public key, they were
doomed to concurrency issues because they could be shared by
multiple crypto requests. The requests were generating specific
data to the same zone of memory without any protection.

The private key was subject to concurrency problems because
multiple setkey calls could fight to memcpy to the same zone
of memory.

Shared secret and public key concurrency is fixed by allocating
memory on heap for each request. In the end, the shared secret
and public key are computed for each request, there is no reason
to use shared memory.

Private key concurrency is fixed by allocating memory on heap
for each setkey call, by memcopying the parsed/generated private
key to the heap and by making the private key pointer from
ecdh_ctx to point to the newly allocated data.

On all systems running Linux, loads from and stores to pointers
are atomic, that is, if a store to a pointer occurs at the same
time as a load from that same pointer, the load will return either
the initial value or the value stored, never some bitwise mashup
of the two.

With this, the private key will always point to a valid key,
but to what setkey call it belongs, is the responsibility of the
caller, as it is now in all crypto framework.

Signed-off-by: Tudor Ambarus 
---
 crypto/ecc.h  |  2 --
 crypto/ecdh.c | 93 ++-
 2 files changed, 67 insertions(+), 28 deletions(-)

diff --git a/crypto/ecc.h b/crypto/ecc.h
index e4fd449..b35855b 100644
--- a/crypto/ecc.h
+++ b/crypto/ecc.h
@@ -26,8 +26,6 @@
 #ifndef _CRYPTO_ECC_H
 #define _CRYPTO_ECC_H
 
-#define ECC_MAX_DIGITS 4 /* 256 */
-
 #define ECC_DIGITS_TO_BYTES_SHIFT 3
 
 /**
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 61c7708..30d954d 100644
--- a/crypto/ecdh.c
+++ b/crypto/ecdh.c
@@ -19,9 +19,7 @@
 struct ecdh_ctx {
unsigned int curve_id;
unsigned int ndigits;
-   u64 private_key[ECC_MAX_DIGITS];
-   u64 public_key[2 * ECC_MAX_DIGITS];
-   u64 shared_secret[ECC_MAX_DIGITS];
+   const u64 *private_key;
 };
 
 static inline struct ecdh_ctx *ecdh_get_ctx(struct crypto_kpp *tfm)
@@ -38,13 +36,31 @@ static unsigned int ecdh_supported_curve(unsigned int 
curve_id)
}
 }
 
+static int ecdh_gen_privkey(struct ecdh_ctx *ctx, u64 *private_key)
+{
+   int ret;
+
+   ret = ecc_gen_privkey(ctx->curve_id, ctx->ndigits, private_key);
+   if (ret) {
+   kzfree(private_key);
+   return ret;
+   }
+
+   ctx->private_key = private_key;
+   return 0;
+}
+
 static int ecdh_set_secret(struct crypto_kpp *tfm, const void *buf,
   unsigned int len)
 {
struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
+   u64 *private_key;
struct ecdh params;
unsigned int ndigits;
 
+   /* clear the old private key, if any */
+   kzfree(ctx->private_key);
+
if (crypto_ecdh_decode_key(buf, len, ) < 0)
return -EINVAL;
 
@@ -52,59 +68,82 @@ static int ecdh_set_secret(struct crypto_kpp *tfm, const 
void *buf,
if (!ndigits)
return -EINVAL;
 
+   private_key = kzalloc(ndigits << ECC_DIGITS_TO_BYTES_SHIFT, GFP_KERNEL);
+   if (!private_key)
+   return -ENOMEM;
+
ctx->curve_id = params.curve_id;
ctx->ndigits = ndigits;
 
if (!params.key || !params.key_size)
-   return ecc_gen_privkey(ctx->curve_id, ctx->ndigits,
-  ctx->private_key);
+   return ecdh_gen_privkey(ctx, private_key);
 
if (ecc_is_key_valid(ctx->curve_id, ctx->ndigits,
-(const u64 *)params.key, params.key_size) < 0)
+(const u64 *)params.key, params.key_size) < 0) {
+   kzfree(private_key);
return -EINVAL;
+   }
 
-   memcpy(ctx->private_key, params.key, params.key_size);
+   memcpy(private_key, params.key, params.key_size);
+   ctx->private_key = private_key;
 
return 0;
 }
 
 static int ecdh_compute_value(struct kpp_request *req)
 {
-   int ret = 0;
struct crypto_kpp *tfm = crypto_kpp_reqtfm(req);
struct ecdh_ctx *ctx = ecdh_get_ctx(tfm);
-   size_t copied, nbytes;
+   u64 *public_key;
+   u64 *shared_secret = NULL;
+   size_t copied, nbytes, public_key_sz;
void *buf;
+   int ret = -ENOMEM;
 
nbytes = ctx->ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+   /* Public part is a point thus it has both coordinates */
+   public_key_sz = 2 * nbytes;
+
+   public_key = kmalloc(public_key_sz, GFP_KERNEL);
+   if (!public_key)
+   return -ENOMEM;
 
if (req->src) {
-   copied = sg_copy_to_buffer(req->src, 1, ctx->public_key,
-  

Re: [PATCH 6/7] staging: ccree: add DT bus coherency detection

[Dan Carpenter]

On Thu, Jun 22, 2017 at 10:07:52AM +0300, Gilad Ben-Yossef wrote:
> The ccree driver has build time configurable support
> to work on top of coherent (e.g. ACP) vs. none coherent bus
> connections. Turn it to run-time configurable option
> based on device tree.
> 
> Signed-off-by: Gilad Ben-Yossef 
> ---
>  drivers/staging/ccree/ssi_buffer_mgr.c | 37 
> ++
>  drivers/staging/ccree/ssi_config.h | 20 --
>  drivers/staging/ccree/ssi_driver.c | 14 +
>  drivers/staging/ccree/ssi_driver.h |  3 +++
>  4 files changed, 33 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
> b/drivers/staging/ccree/ssi_buffer_mgr.c
> index 88ebda8..75810dc 100644
> --- a/drivers/staging/ccree/ssi_buffer_mgr.c
> +++ b/drivers/staging/ccree/ssi_buffer_mgr.c
> @@ -627,6 +627,9 @@ void ssi_buffer_mgr_unmap_aead_request(
>   struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
>   unsigned int hw_iv_size = areq_ctx->hw_iv_size;
>   struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> + struct ssi_drvdata *drvdata =
> + (struct ssi_drvdata *)dev_get_drvdata(dev);

The cast is not needed.

> +

Don't put a blank in the middle of the declaration block.

>   u32 dummy;
>   bool chained;
>   u32 size_to_unmap = 0;

[ snip ]

> @@ -981,20 +983,22 @@ static inline int ssi_buffer_mgr_prepare_aead_data_mlli(
>* MAC verification upon request completion
>*/
>   if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
> -#if !DX_HAS_ACP
> - /* In ACP platform we already copying ICV
> -  * for any INPLACE-DECRYPT operation, hence
> + if (!drvdata->coherent) {
> + /* In coherent platforms (e.g. ACP)
> +  * already copying ICV for any
> +  * INPLACE-DECRYPT operation, hence
>* we must neglect this code.
>*/
> - u32 size_to_skip = req->assoclen;
> - if (areq_ctx->is_gcm4543) {
> - size_to_skip += crypto_aead_ivsize(tfm);
> + u32 skip = req->assoclen;
> +
> + if (areq_ctx->is_gcm4543)
> + skip += crypto_aead_ivsize(tfm);
> +
> + ssi_buffer_mgr_copy_scatterlist_portion(
> +areq_ctx->backup_mac, req->src,
> +(skip + req->cryptlen - areq_ctx->req_authsize),
> +skip + req->cryptlen, SSI_SG_TO_BUF);


Indenting is messed up.

>   }
> - ssi_buffer_mgr_copy_scatterlist_portion(
> - areq_ctx->backup_mac, req->src,
> - size_to_skip+ req->cryptlen - 
> areq_ctx->req_authsize,
> - size_to_skip+ req->cryptlen, 
> SSI_SG_TO_BUF);
> -#endif
>   areq_ctx->icv_virt_addr = areq_ctx->backup_mac;
>   } else {
>   areq_ctx->icv_virt_addr = areq_ctx->mac_buf;

[ snip ]

> @@ -533,7 +539,7 @@ int cc_clk_on(struct ssi_drvdata *drvdata)
>   struct clk *clk = drvdata->clk;
>  
>   if (IS_ERR(clk))
> - /* No all devices have a clock associated with CCREE */
> + /* Not all devices have a clock associated with CCREE */

This is not related.  Do unrelated things in different patches.  This
typo was introduced in an earlier patch.  There are a couple ways in git
to edit previous patches.

>   goto out;
>  
>   rc = clk_prepare_enable(clk);

regards,
dan carpenter

Re: [PATCH] crypto: ccp - Release locks before returning

[Herbert Xu]

On Mon, Jun 19, 2017 at 12:31:17PM -0500, Gary R Hook wrote:
> krobot warning: make sure that all error return paths release locks.
> 
> Signed-off-by: Gary R Hook 

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: cavium/nitrox - dma_mapping_error() returns bool

[Herbert Xu]

On Mon, Jun 19, 2017 at 01:51:25PM +0300, Dan Carpenter wrote:
> We want to return negative error codes here, but we're accidentally
> propogating the "true" return from dma_mapping_error().
> 
> Fixes: 14fa93cdcd9b ("crypto: cavium - Add support for CNN55XX adapters.")
> Signed-off-by: Dan Carpenter 

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 2/2] crypto: caam - fix gfp allocation flags (part II)

[Herbert Xu]

On Mon, Jun 19, 2017 at 11:44:46AM +0300, Horia Geantă wrote:
> This is the 2nd part of fixing the usage of GFP_KERNEL for memory
> allocations, taking care off all the places that haven't caused a real
> problem / failure.
> Again, the issue being fixed is that GFP_KERNEL should be used only when
> MAY_SLEEP flag is set, i.e. MAY_BACKLOG flag usage is orthogonal.
> 
> Signed-off-by: Horia Geantă 

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 1/2] crypto: caam - fix gfp allocation flags (part I)

[Herbert Xu]

On Mon, Jun 19, 2017 at 11:44:45AM +0300, Horia Geantă wrote:
> Changes in the SW cts (ciphertext stealing) code in
> commit 0605c41cc53ca ("crypto: cts - Convert to skcipher")
> revealed a problem in the CAAM driver:
> when cts(cbc(aes)) is executed and cts runs in SW,
> cbc(aes) is offloaded in CAAM; cts encrypts the last block
> in atomic context and CAAM incorrectly decides to use GFP_KERNEL
> for memory allocation.
> 
> Fix this by allowing GFP_KERNEL (sleeping) only when MAY_SLEEP flag is
> set, i.e. remove MAY_BACKLOG flag.
> 
> We split the fix in two parts - first is sent to -stable, while the
> second is not (since there is no known failure case).
> 
> Link: http://lkml.kernel.org/g/20170602122446.2427-1-da...@sigma-star.at
> Cc:  # 4.8+
> Reported-by: David Gstir 
> Signed-off-by: Horia Geantă 

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: fix typo in docs

[Herbert Xu]

On Sun, Jun 18, 2017 at 11:53:41PM -0700, Benjamin Peterson wrote:
> Signed-off-by: Benjamin Peterson 

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 1/1] crypto:drbg- Fixes panic in wait_for_completion call.

[Herbert Xu]

On Mon, Jun 12, 2017 at 12:00:49PM +0530, Harsh Jain wrote:
> Hi Herbert,
> 
> Since It's a panic BUG.  Can we push this fix to stable kernel releases?

I have added it to crypto with a stable CC.

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

Re: [PATCH 5/7] staging: ccree: add clock management support

[Dan Carpenter]

On Thu, Jun 22, 2017 at 10:07:51AM +0300, Gilad Ben-Yossef wrote:
> +int cc_clk_on(struct ssi_drvdata *drvdata)
> +{
> + int rc = 0;
> + struct clk *clk = drvdata->clk;
> +
> + if (IS_ERR(clk))
> + /* No all devices have a clock associated with CCREE */
> + goto out;

Ugh...  I hate this.  The "goto out;" here is a waste of time
do-nothing-goto that returns diretly.  It's equivalent to "return 0;".
Is that intended?  Even with the comment, it's not clear...

People think do nothing gotos are a great idea but from reviewing tons
and tons of real life errors, I can assure you that in real life (as
opposed to theory) they don't prevent any future bugs and only introduce
"forgot to set the error code" bugs.

The indenting is messed up and multi-line indents get curly braces.

> +
> + rc = clk_prepare_enable(clk);
> + if (rc) {
> + SSI_LOG_ERR("error enabling clock\n");
> + clk_disable_unprepare(clk);

Don't unprepare something that hasn't been prepared.

> + }
> +
> +out:
> + return rc;
> +}

int cc_clk_on(struct ssi_drvdata *drvdata)
{
struct clk *clk = drvdata->clk;
int rc;

if (IS_ERR(clk)) {
/* Not all devices have a clock associated with CCREE */
return 0;
}

rc = clk_prepare_enable(clk);
if (rc)
return rc;

return 0;
}

regards,
dan carpenter

Re: [PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

[Gilad Ben-Yossef]

On Thu, Jun 22, 2017 at 11:28 AM, Dan Carpenter
 wrote:
> On Thu, Jun 22, 2017 at 10:14:08AM +0300, Gilad Ben-Yossef wrote:
>> On Thu, Jun 22, 2017 at 10:07 AM, Gilad Ben-Yossef  
>> wrote:
>> > An assortment of bug fixes and staging TODO items.
>> > Highlights includes the driver passing crypto testmgr boot tests
>> > and support of multiple HW revs. without build time changes.
>> >
>> > Gilad Ben-Yossef (7):
>> >   staging: ccree: fix hash import/export
>> >   staging: ccree: register setkey for none hash macs
>> >   staging: ccree: add support for older HW revisions
>> >   staging: ccree: remove unused function
>> >   staging: ccree: add clock management support
>> >   staging: ccree: add DT bus coherency detection
>> >   staging: ccree: use signal safe completion wait
>>
>> One additional note: the patch set is on top of the current staging-next 
>> which
>> is d06838de4a015c7c4844ad3fcf63ad5e2c17b234 so it will conflict with
>> the coding style clean up patches from Jhin-Ming if you take them.
>>
>> If you wish me to merge this patch set on top those just let me know.
>>
>
> Yes.  Those are fine and will be merged most likely.  It's strictly
> first in, first out.

Sure. I'll send an updated patch on top of those then.

Thanks,
Gilad


-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

[Dan Carpenter]

On Thu, Jun 22, 2017 at 10:14:08AM +0300, Gilad Ben-Yossef wrote:
> On Thu, Jun 22, 2017 at 10:07 AM, Gilad Ben-Yossef  
> wrote:
> > An assortment of bug fixes and staging TODO items.
> > Highlights includes the driver passing crypto testmgr boot tests
> > and support of multiple HW revs. without build time changes.
> >
> > Gilad Ben-Yossef (7):
> >   staging: ccree: fix hash import/export
> >   staging: ccree: register setkey for none hash macs
> >   staging: ccree: add support for older HW revisions
> >   staging: ccree: remove unused function
> >   staging: ccree: add clock management support
> >   staging: ccree: add DT bus coherency detection
> >   staging: ccree: use signal safe completion wait
> 
> One additional note: the patch set is on top of the current staging-next which
> is d06838de4a015c7c4844ad3fcf63ad5e2c17b234 so it will conflict with
> the coding style clean up patches from Jhin-Ming if you take them.
> 
> If you wish me to merge this patch set on top those just let me know.
> 

Yes.  Those are fine and will be merged most likely.  It's strictly
first in, first out.

regards,
dan carpenter

Re: XFRM Stats

[Herbert Xu]

Raj Ammanur  wrote:
> oops yes, completely forgot the lifetime stats. Thanks Herbert.
> 
> I will check this out, but after a rekey, are the stats still preserved?

No those stats are per-state.  So your best bet would be to get this
feature added to your user-space key manager, and get it to read out
the final stats before deleting the SA.

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

Re: [RFC PATCH] gcm - fix setkey cache coherence issues

[Herbert Xu]

On Thu, Jun 22, 2017 at 05:03:44AM +, Radu Solea wrote:
> I'm adding cacheline_aligned to iv and result. That is done so hash, iv 
> and result never share a cache line.

Yes but you're doing it in crypto/gcm.c which isn't even used by
caam AFAIK.

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

Re: [PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

[Gilad Ben-Yossef]

On Thu, Jun 22, 2017 at 10:07 AM, Gilad Ben-Yossef  wrote:
> An assortment of bug fixes and staging TODO items.
> Highlights includes the driver passing crypto testmgr boot tests
> and support of multiple HW revs. without build time changes.
>
> Gilad Ben-Yossef (7):
>   staging: ccree: fix hash import/export
>   staging: ccree: register setkey for none hash macs
>   staging: ccree: add support for older HW revisions
>   staging: ccree: remove unused function
>   staging: ccree: add clock management support
>   staging: ccree: add DT bus coherency detection
>   staging: ccree: use signal safe completion wait

One additional note: the patch set is on top of the current staging-next which
is d06838de4a015c7c4844ad3fcf63ad5e2c17b234 so it will conflict with
the coding style clean up patches from Jhin-Ming if you take them.

If you wish me to merge this patch set on top those just let me know.

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[PATCH 4/7] staging: ccree: remove unused function

[Gilad Ben-Yossef]

The function set_ack_last was not used anywhere. Remove it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_hw_queue_defs.h | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index c730c3c..ac0eb97 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -226,18 +226,6 @@ static inline void set_queue_last_ind_bit(struct 
cc_hw_desc *pdesc)
 }
 
 /*
- * Signs the end of HW descriptors flow by asking for completion ack,
- * and release the HW engines
- *
- * @pdesc: pointer HW descriptor struct
- */
-static inline void set_ack_last(struct cc_hw_desc *pdesc)
-{
-   pdesc->word[3] |= FIELD_PREP(WORD3_QUEUE_LAST_IND, 1);
-   pdesc->word[4] |= FIELD_PREP(WORD4_ACK_NEEDED, 1);
-}
-
-/*
  * Set the DIN field of a HW descriptors
  *
  * @pdesc: pointer HW descriptor struct
-- 
2.1.4

[PATCH 2/7] staging: ccree: register setkey for none hash macs

[Gilad Ben-Yossef]

Fix a bug where the transformation init code did
not register a setkey method for none hash based MACs.

Fixes commit 50cfbbb7e627 ("staging: ccree: add ahash support").

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 83 
 1 file changed, 42 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index c39e3be..f52e1af 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -1874,8 +1874,8 @@ static int ssi_ahash_setkey(struct crypto_ahash *ahash,
 struct ssi_hash_template {
char name[CRYPTO_MAX_ALG_NAME];
char driver_name[CRYPTO_MAX_ALG_NAME];
-   char hmac_name[CRYPTO_MAX_ALG_NAME];
-   char hmac_driver_name[CRYPTO_MAX_ALG_NAME];
+   char mac_name[CRYPTO_MAX_ALG_NAME];
+   char mac_driver_name[CRYPTO_MAX_ALG_NAME];
unsigned int blocksize;
bool synchronize;
struct ahash_alg template_ahash;
@@ -1894,8 +1894,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha1",
.driver_name = "sha1-dx",
-   .hmac_name = "hmac(sha1)",
-   .hmac_driver_name = "hmac-sha1-dx",
+   .mac_name = "hmac(sha1)",
+   .mac_driver_name = "hmac-sha1-dx",
.blocksize = SHA1_BLOCK_SIZE,
.synchronize = false,
.template_ahash = {
@@ -1919,8 +1919,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha256",
.driver_name = "sha256-dx",
-   .hmac_name = "hmac(sha256)",
-   .hmac_driver_name = "hmac-sha256-dx",
+   .mac_name = "hmac(sha256)",
+   .mac_driver_name = "hmac-sha256-dx",
.blocksize = SHA256_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1943,8 +1943,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha224",
.driver_name = "sha224-dx",
-   .hmac_name = "hmac(sha224)",
-   .hmac_driver_name = "hmac-sha224-dx",
+   .mac_name = "hmac(sha224)",
+   .mac_driver_name = "hmac-sha224-dx",
.blocksize = SHA224_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1968,8 +1968,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha384",
.driver_name = "sha384-dx",
-   .hmac_name = "hmac(sha384)",
-   .hmac_driver_name = "hmac-sha384-dx",
+   .mac_name = "hmac(sha384)",
+   .mac_driver_name = "hmac-sha384-dx",
.blocksize = SHA384_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -1992,8 +1992,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "sha512",
.driver_name = "sha512-dx",
-   .hmac_name = "hmac(sha512)",
-   .hmac_driver_name = "hmac-sha512-dx",
+   .mac_name = "hmac(sha512)",
+   .mac_driver_name = "hmac-sha512-dx",
.blocksize = SHA512_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2017,8 +2017,8 @@ static struct ssi_hash_template driver_hash[] = {
{
.name = "md5",
.driver_name = "md5-dx",
-   .hmac_name = "hmac(md5)",
-   .hmac_driver_name = "hmac-md5-dx",
+   .mac_name = "hmac(md5)",
+   .mac_driver_name = "hmac-md5-dx",
.blocksize = MD5_HMAC_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2039,8 +2039,8 @@ static struct ssi_hash_template driver_hash[] = {
.inter_digestsize = MD5_DIGEST_SIZE,
},
{
-   .name = "xcbc(aes)",
-   .driver_name = "xcbc-aes-dx",
+   .mac_name = "xcbc(aes)",
+   .mac_driver_name = "xcbc-aes-dx",
.blocksize = AES_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2062,8 +2062,8 @@ static struct ssi_hash_template driver_hash[] = {
},
 #if SSI_CC_HAS_CMAC
{
-   .name = "cmac(aes)",
-   .driver_name = "cmac-aes-dx",
+   .mac_name = "cmac(aes)",
+   .mac_driver_name = "cmac-aes-dx",
.blocksize = AES_BLOCK_SIZE,
.template_ahash = {
.init = ssi_ahash_init,
@@ -2106,9 +2106,9 @@ ssi_hash_create_alg(struct ssi_hash_template *template, 
bool keyed)
 
if (keyed) {
snprintf(alg->cra_name, CRYPTO_MAX_ALG_NAME, "%s",
-

[PATCH 3/7] staging: ccree: add support for older HW revisions

[Gilad Ben-Yossef]

Add support for the older CryptoCell 710 and 630P hardware revisions.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Kconfig|   7 +-
 drivers/staging/ccree/cc_crypto_ctx.h|  16 ---
 drivers/staging/ccree/cc_hw_queue_defs.h |   2 +-
 drivers/staging/ccree/cc_regs.h  |   7 +-
 drivers/staging/ccree/dx_crys_kernel.h   |   1 +
 drivers/staging/ccree/dx_host.h  |   3 +
 drivers/staging/ccree/dx_reg_common.h|   2 -
 drivers/staging/ccree/ssi_aead.c |  36 +++--
 drivers/staging/ccree/ssi_cipher.c   |  27 +++-
 drivers/staging/ccree/ssi_config.h   |   2 +-
 drivers/staging/ccree/ssi_driver.c   | 115 ++-
 drivers/staging/ccree/ssi_driver.h   |  25 +++-
 drivers/staging/ccree/ssi_fips_ll.c  |  59 
 drivers/staging/ccree/ssi_hash.c | 234 +--
 drivers/staging/ccree/ssi_hash.h |  10 +-
 drivers/staging/ccree/ssi_request_mgr.c  |  19 ++-
 drivers/staging/ccree/ssi_sram_mgr.c |  15 +-
 17 files changed, 349 insertions(+), 231 deletions(-)

diff --git a/drivers/staging/ccree/Kconfig b/drivers/staging/ccree/Kconfig
index 4be87f5..f1e75e8 100644
--- a/drivers/staging/ccree/Kconfig
+++ b/drivers/staging/ccree/Kconfig
@@ -19,9 +19,10 @@ config CRYPTO_DEV_CCREE
select CRYPTO_XTS
help
  Say 'Y' to enable a driver for the Arm TrustZone CryptoCell 
- C7xx. Currently only the CryptoCell 712 REE is supported.
- Choose this if you wish to use hardware acceleration of
- cryptographic operations on the system REE.
+ C7xx. Currently the REE interface of the CryptoCell 712,
+ 710 and 630p are supported. Choose this if you wish to use
+ hardware acceleration of cryptographic operations on the
+ system REE.
  If unsure say Y.
 
 config CCREE_FIPS_SUPPORT
diff --git a/drivers/staging/ccree/cc_crypto_ctx.h 
b/drivers/staging/ccree/cc_crypto_ctx.h
index 591f6fd..1542aa7 100644
--- a/drivers/staging/ccree/cc_crypto_ctx.h
+++ b/drivers/staging/ccree/cc_crypto_ctx.h
@@ -19,17 +19,6 @@
 
 #include 
 
-/* context size */
-#ifndef CC_CTX_SIZE_LOG2
-#if (CC_SUPPORT_SHA > 256)
-#define CC_CTX_SIZE_LOG2 8
-#else
-#define CC_CTX_SIZE_LOG2 7
-#endif
-#endif
-#define CC_CTX_SIZE BIT(CC_CTX_SIZE_LOG2)
-#define CC_DRV_CTX_SIZE_WORDS (CC_CTX_SIZE >> 2)
-
 #define CC_DRV_DES_IV_SIZE 8
 #define CC_DRV_DES_BLOCK_SIZE 8
 
@@ -72,13 +61,8 @@
 #define CC_SHA384_BLOCK_SIZE 128
 #define CC_SHA512_BLOCK_SIZE 128
 
-#if (CC_SUPPORT_SHA > 256)
 #define CC_DIGEST_SIZE_MAX CC_SHA512_DIGEST_SIZE
 #define CC_HASH_BLOCK_SIZE_MAX CC_SHA512_BLOCK_SIZE /*1024b*/
-#else /* Only up to SHA256 */
-#define CC_DIGEST_SIZE_MAX CC_SHA256_DIGEST_SIZE
-#define CC_HASH_BLOCK_SIZE_MAX CC_SHA256_BLOCK_SIZE /*512b*/
-#endif
 
 #define CC_HMAC_BLOCK_SIZE_MAX CC_HASH_BLOCK_SIZE_MAX
 
diff --git a/drivers/staging/ccree/cc_hw_queue_defs.h 
b/drivers/staging/ccree/cc_hw_queue_defs.h
index aaa56c8..c730c3c 100644
--- a/drivers/staging/ccree/cc_hw_queue_defs.h
+++ b/drivers/staging/ccree/cc_hw_queue_defs.h
@@ -220,7 +220,7 @@ static inline void hw_desc_init(struct cc_hw_desc *pdesc)
  *
  * @pdesc: pointer HW descriptor struct
  */
-static inline void set_queue_last_ind(struct cc_hw_desc *pdesc)
+static inline void set_queue_last_ind_bit(struct cc_hw_desc *pdesc)
 {
pdesc->word[3] |= FIELD_PREP(WORD3_QUEUE_LAST_IND, 1);
 }
diff --git a/drivers/staging/ccree/cc_regs.h b/drivers/staging/ccree/cc_regs.h
index 4a893a6..62ace81 100644
--- a/drivers/staging/ccree/cc_regs.h
+++ b/drivers/staging/ccree/cc_regs.h
@@ -25,12 +25,9 @@
 
 #include 
 
-#define AXIM_MON_BASE_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP)
-#define AXIM_MON_COMP_VALUE GENMASK(DX_AXIM_MON_COMP_VALUE_BIT_SIZE + \
-   DX_AXIM_MON_COMP_VALUE_BIT_SHIFT, \
-   DX_AXIM_MON_COMP_VALUE_BIT_SHIFT)
+#define AXIM_MON_BASE_712_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP)
+#define AXIM_MON_BASE_630_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP8)
 
-#define AXIM_MON_BASE_OFFSET CC_REG_OFFSET(CRY_KERNEL, AXIM_MON_COMP)
 #define AXIM_MON_COMP_VALUE GENMASK(DX_AXIM_MON_COMP_VALUE_BIT_SIZE + \
DX_AXIM_MON_COMP_VALUE_BIT_SHIFT, \
DX_AXIM_MON_COMP_VALUE_BIT_SHIFT)
diff --git a/drivers/staging/ccree/dx_crys_kernel.h 
b/drivers/staging/ccree/dx_crys_kernel.h
index 2196030..0d1d01e 100644
--- a/drivers/staging/ccree/dx_crys_kernel.h
+++ b/drivers/staging/ccree/dx_crys_kernel.h
@@ -131,6 +131,7 @@
 #define DX_AXIM_MON_INFLIGHTLAST_VALUE_BIT_SHIFT   0x0UL
 #define DX_AXIM_MON_INFLIGHTLAST_VALUE_BIT_SIZE0x8UL
 #define DX_AXIM_MON_COMP_REG_OFFSET0xB80UL
+#define DX_AXIM_MON_COMP8_REG_OFFSET   0xBA0UL
 #define DX_AXIM_MON_COMP_VALUE_BIT_SHIFT   0x0UL
 #define DX_AXIM_MON_COMP_VALUE_BIT_SIZE0x10UL
 #define DX_AXIM_MON_ERR_REG_OFFSET 0xBC4UL
diff --git a/drivers/staging/ccree/dx_host.h 

[PATCH 6/7] staging: ccree: add DT bus coherency detection

[Gilad Ben-Yossef]

The ccree driver has build time configurable support
to work on top of coherent (e.g. ACP) vs. none coherent bus
connections. Turn it to run-time configurable option
based on device tree.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_buffer_mgr.c | 37 ++
 drivers/staging/ccree/ssi_config.h | 20 --
 drivers/staging/ccree/ssi_driver.c | 14 +
 drivers/staging/ccree/ssi_driver.h |  3 +++
 4 files changed, 33 insertions(+), 41 deletions(-)

diff --git a/drivers/staging/ccree/ssi_buffer_mgr.c 
b/drivers/staging/ccree/ssi_buffer_mgr.c
index 88ebda8..75810dc 100644
--- a/drivers/staging/ccree/ssi_buffer_mgr.c
+++ b/drivers/staging/ccree/ssi_buffer_mgr.c
@@ -627,6 +627,9 @@ void ssi_buffer_mgr_unmap_aead_request(
struct aead_req_ctx *areq_ctx = aead_request_ctx(req);
unsigned int hw_iv_size = areq_ctx->hw_iv_size;
struct crypto_aead *tfm = crypto_aead_reqtfm(req);
+   struct ssi_drvdata *drvdata =
+   (struct ssi_drvdata *)dev_get_drvdata(dev);
+
u32 dummy;
bool chained;
u32 size_to_unmap = 0;
@@ -700,8 +703,8 @@ void ssi_buffer_mgr_unmap_aead_request(
dma_unmap_sg(dev, req->dst, 
ssi_buffer_mgr_get_sgl_nents(req->dst,size_to_unmap,,),
DMA_BIDIRECTIONAL);
}
-#if DX_HAS_ACP
-   if ((areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
+   if (drvdata->coherent &&
+   (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
likely(req->src == req->dst))
{
u32 size_to_skip = req->assoclen;
@@ -716,7 +719,6 @@ void ssi_buffer_mgr_unmap_aead_request(
size_to_skip+ req->cryptlen - areq_ctx->req_authsize,
size_to_skip+ req->cryptlen, SSI_SG_FROM_BUF);
}
-#endif
 }
 
 static inline int ssi_buffer_mgr_get_aead_icv_nents(
@@ -981,20 +983,22 @@ static inline int ssi_buffer_mgr_prepare_aead_data_mlli(
 * MAC verification upon request completion
 */
if (direct == DRV_CRYPTO_DIRECTION_DECRYPT) {
-#if !DX_HAS_ACP
-   /* In ACP platform we already copying ICV
-* for any INPLACE-DECRYPT operation, hence
+   if (!drvdata->coherent) {
+   /* In coherent platforms (e.g. ACP)
+* already copying ICV for any
+* INPLACE-DECRYPT operation, hence
 * we must neglect this code.
 */
-   u32 size_to_skip = req->assoclen;
-   if (areq_ctx->is_gcm4543) {
-   size_to_skip += crypto_aead_ivsize(tfm);
+   u32 skip = req->assoclen;
+
+   if (areq_ctx->is_gcm4543)
+   skip += crypto_aead_ivsize(tfm);
+
+   ssi_buffer_mgr_copy_scatterlist_portion(
+areq_ctx->backup_mac, req->src,
+(skip + req->cryptlen - areq_ctx->req_authsize),
+skip + req->cryptlen, SSI_SG_TO_BUF);
}
-   ssi_buffer_mgr_copy_scatterlist_portion(
-   areq_ctx->backup_mac, req->src,
-   size_to_skip+ req->cryptlen - 
areq_ctx->req_authsize,
-   size_to_skip+ req->cryptlen, 
SSI_SG_TO_BUF);
-#endif
areq_ctx->icv_virt_addr = areq_ctx->backup_mac;
} else {
areq_ctx->icv_virt_addr = areq_ctx->mac_buf;
@@ -1281,8 +1285,8 @@ int ssi_buffer_mgr_map_aead_request(
mlli_params->curr_pool = NULL;
sg_data.num_of_buffers = 0;
 
-#if DX_HAS_ACP
-   if ((areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
+   if (drvdata->coherent &&
+   (areq_ctx->gen_ctx.op_type == DRV_CRYPTO_DIRECTION_DECRYPT) &&
likely(req->src == req->dst))
{
u32 size_to_skip = req->assoclen;
@@ -1297,7 +1301,6 @@ int ssi_buffer_mgr_map_aead_request(
size_to_skip+ req->cryptlen - areq_ctx->req_authsize,
size_to_skip+ req->cryptlen, SSI_SG_TO_BUF);
}
-#endif
 
/* cacluate the size for cipher remove ICV in decrypt*/
areq_ctx->cryptlen = (areq_ctx->gen_ctx.op_type ==
diff --git a/drivers/staging/ccree/ssi_config.h 
b/drivers/staging/ccree/ssi_config.h
index 2484a06..ff7597c 100644
--- a/drivers/staging/ccree/ssi_config.h
+++ b/drivers/staging/ccree/ssi_config.h
@@ -23,7 +23,6 @@
 
 #include 
 
-//#define DISABLE_COHERENT_DMA_OPS
 //#define 

[PATCH 7/7] staging: ccree: use signal safe completion wait

[Gilad Ben-Yossef]

We were waiting for a completion notification of HW DMA
operation using an interruptible wait which can result
in data corruption if a signal interrupted us while
DMA was not yet completed.

Fix this by moving to uninterrupted wait.

Fixes: abefd6741d ("staging: ccree: introduce CryptoCell HW driver").

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_request_mgr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
b/drivers/staging/ccree/ssi_request_mgr.c
index cffc8de..87f5ab6 100644
--- a/drivers/staging/ccree/ssi_request_mgr.c
+++ b/drivers/staging/ccree/ssi_request_mgr.c
@@ -382,7 +382,8 @@ int send_request(
/* Wait upon sequence completion.
 *  Return "0" -Operation done successfully.
 */
-   return wait_for_completion_interruptible(_req->seq_compl);
+   wait_for_completion(_req->seq_compl);
+   return 0;
} else {
/* Operation still in process */
return -EINPROGRESS;
-- 
2.1.4

[PATCH 5/7] staging: ccree: add clock management support

[Gilad Ben-Yossef]

Some SoC which implement CryptoCell have a dedicated clock
tied to it, some do not. Implement clock support if exists
based on device tree data and tie power management to it.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile |  2 +-
 drivers/staging/ccree/ssi_driver.c | 43 +++
 drivers/staging/ccree/ssi_driver.h |  4 +++
 drivers/staging/ccree/ssi_pm.c | 13 +
 drivers/staging/ccree/ssi_pm_ext.c | 60 --
 drivers/staging/ccree/ssi_pm_ext.h | 33 -
 6 files changed, 50 insertions(+), 105 deletions(-)
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.c
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.h

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index 44f3e3e..318c2b3 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,3 +1,3 @@
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o 
ssi_pm_ext.o
+ccree-y := ssi_driver.o ssi_sysfs.o ssi_buffer_mgr.o ssi_request_mgr.o 
ssi_cipher.o ssi_hash.o ssi_aead.o ssi_ivgen.o ssi_sram_mgr.o ssi_pm.o
 ccree-$(CCREE_FIPS_SUPPORT) += ssi_fips.o ssi_fips_ll.o ssi_fips_ext.o 
ssi_fips_local.o
diff --git a/drivers/staging/ccree/ssi_driver.c 
b/drivers/staging/ccree/ssi_driver.c
index 5a62b4f..f1275a6 100644
--- a/drivers/staging/ccree/ssi_driver.c
+++ b/drivers/staging/ccree/ssi_driver.c
@@ -57,6 +57,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "ssi_config.h"
 #include "ssi_driver.h"
@@ -269,6 +270,7 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
hw_rev = (struct cc_hw_data *)dev_id->data;
new_drvdata->hw_rev_name = hw_rev->name;
new_drvdata->hw_rev = hw_rev->rev;
+   new_drvdata->clk = of_clk_get(np, 0);
 
if (hw_rev->rev >= CC_HW_REV_712) {
new_drvdata->hash_len_sz = HASH_LEN_SIZE_712;
@@ -338,6 +340,10 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
 
new_drvdata->plat_dev = plat_dev;
 
+   rc = cc_clk_on(new_drvdata);
+   if (rc)
+   goto init_cc_res_err;
+
if(new_drvdata->plat_dev->dev.dma_mask == NULL)
{
new_drvdata->plat_dev->dev.dma_mask = & 
new_drvdata->plat_dev->dev.coherent_dma_mask;
@@ -504,14 +510,11 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
ssi_sysfs_fini();
 #endif
 
-   /* Mask all interrupts */
-   WRITE_REGISTER(drvdata->cc_base + CC_REG_OFFSET(HOST_RGF, HOST_IMR),
-   0x);
+   fini_cc_regs(drvdata);
+   cc_clk_off(drvdata);
free_irq(drvdata->res_irq->start, drvdata);
drvdata->res_irq = NULL;
 
-   fini_cc_regs(drvdata);
-
if (drvdata->cc_base != NULL) {
iounmap(drvdata->cc_base);
release_mem_region(drvdata->res_mem->start,
@@ -524,6 +527,36 @@ static void cleanup_cc_resources(struct platform_device 
*plat_dev)
dev_set_drvdata(_dev->dev, NULL);
 }
 
+int cc_clk_on(struct ssi_drvdata *drvdata)
+{
+   int rc = 0;
+   struct clk *clk = drvdata->clk;
+
+   if (IS_ERR(clk))
+   /* No all devices have a clock associated with CCREE */
+   goto out;
+
+   rc = clk_prepare_enable(clk);
+   if (rc) {
+   SSI_LOG_ERR("error enabling clock\n");
+   clk_disable_unprepare(clk);
+   }
+
+out:
+   return rc;
+}
+
+void cc_clk_off(struct ssi_drvdata *drvdata)
+{
+   struct clk *clk = drvdata->clk;
+
+   if (IS_ERR(clk))
+   /* No all devices have a clock associated with CCREE */
+   return;
+
+   clk_disable_unprepare(clk);
+}
+
 static int ccree_probe(struct platform_device *plat_dev)
 {
int rc;
diff --git a/drivers/staging/ccree/ssi_driver.h 
b/drivers/staging/ccree/ssi_driver.h
index 52ac43c..a59df59 100644
--- a/drivers/staging/ccree/ssi_driver.h
+++ b/drivers/staging/ccree/ssi_driver.h
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Registers definitions from shared/hw/ree_include */
 #include "dx_reg_base_host.h"
@@ -156,6 +157,7 @@ struct ssi_drvdata {
enum cc_hw_rev hw_rev;
u32 hash_len_sz;
u32 axim_mon_offset;
+   struct clk *clk;
 };
 
 struct ssi_crypto_alg {
@@ -201,6 +203,8 @@ void dump_byte_array(const char *name, const u8 *the_array, 
unsigned long size);
 
 int init_cc_regs(struct ssi_drvdata *drvdata, bool is_probe);
 void fini_cc_regs(struct ssi_drvdata *drvdata);
+int cc_clk_on(struct ssi_drvdata *drvdata);
+void cc_clk_off(struct ssi_drvdata *drvdata);
 
 static inline void set_queue_last_ind(struct ssi_drvdata *drvdata,
  struct cc_hw_desc *pdesc)
diff --git a/drivers/staging/ccree/ssi_pm.c 

[PATCH 1/7] staging: ccree: fix hash import/export

[Gilad Ben-Yossef]

Hash import and export was saving and restoring the wrong context
and therefore disabled. Fix it by restoring intermediate digest
and additional state needed.

The hash and mac transform now pass testmgr partial hash tests.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/ssi_hash.c | 140 +++
 drivers/staging/ccree/ssi_hash.h |   2 +
 2 files changed, 98 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index ed1c672..c39e3be 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drivers/staging/ccree/ssi_hash.c
@@ -976,22 +976,6 @@ static int ssi_hash_init(struct ahash_req_ctx *state, 
struct ssi_hash_ctx *ctx)
return 0;
 }
 
-#ifdef EXPORT_FIXED
-static int ssi_hash_export(struct ssi_hash_ctx *ctx, void *out)
-{
-   CHECK_AND_RETURN_UPON_FIPS_ERROR();
-   memcpy(out, ctx, sizeof(struct ssi_hash_ctx));
-   return 0;
-}
-
-static int ssi_hash_import(struct ssi_hash_ctx *ctx, const void *in)
-{
-   CHECK_AND_RETURN_UPON_FIPS_ERROR();
-   memcpy(ctx, in, sizeof(struct ssi_hash_ctx));
-   return 0;
-}
-#endif
-
 static int ssi_hash_setkey(void *hash,
   const u8 *key,
   unsigned int keylen,
@@ -1782,23 +1766,104 @@ static int ssi_ahash_init(struct ahash_request *req)
return ssi_hash_init(state, ctx);
 }
 
-#ifdef EXPORT_FIXED
 static int ssi_ahash_export(struct ahash_request *req, void *out)
 {
struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
+   struct device *dev = >drvdata->plat_dev->dev;
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   u8 *curr_buff = state->buff_index ? state->buff1 : state->buff0;
+   u32 curr_buff_cnt = state->buff_index ? state->buff1_cnt :
+   state->buff0_cnt;
+   const u32 tmp = CC_EXPORT_MAGIC;
+
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-   return ssi_hash_export(ctx, out);
+   memcpy(out, , sizeof(u32));
+   out += sizeof(u32);
+
+   dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
+   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   memcpy(out, state->digest_buff, ctx->inter_digestsize);
+   out += ctx->inter_digestsize;
+
+   if (state->digest_bytes_len_dma_addr) {
+   dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
+   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+   memcpy(out, state->digest_bytes_len, HASH_LEN_SIZE);
+   }
+   out += HASH_LEN_SIZE;
+
+   memcpy(out, _buff_cnt, sizeof(u32));
+   out += sizeof(u32);
+
+   memcpy(out, curr_buff, curr_buff_cnt);
+
+   /* No sync for device ineeded since we did not change the data,
+* we only copy it
+*/
+
+   return 0;
 }
 
 static int ssi_ahash_import(struct ahash_request *req, const void *in)
 {
struct crypto_ahash *ahash = crypto_ahash_reqtfm(req);
struct ssi_hash_ctx *ctx = crypto_ahash_ctx(ahash);
+   struct device *dev = >drvdata->plat_dev->dev;
+   struct ahash_req_ctx *state = ahash_request_ctx(req);
+   u32 tmp;
+   int rc;
+
+   CHECK_AND_RETURN_UPON_FIPS_ERROR();
 
-   return ssi_hash_import(ctx, in);
+   memcpy(, in, sizeof(u32));
+   if (tmp != CC_EXPORT_MAGIC) {
+   rc = -EINVAL;
+   goto out;
+   }
+   in += sizeof(u32);
+
+   rc = ssi_hash_init(state, ctx);
+   if (rc)
+   goto out;
+
+   dma_sync_single_for_cpu(dev, state->digest_buff_dma_addr,
+   ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+   memcpy(state->digest_buff, in, ctx->inter_digestsize);
+   in += ctx->inter_digestsize;
+
+   if (state->digest_bytes_len_dma_addr) {
+   dma_sync_single_for_cpu(dev, state->digest_bytes_len_dma_addr,
+   HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+   memcpy(state->digest_bytes_len, in, HASH_LEN_SIZE);
+   }
+   in += HASH_LEN_SIZE;
+
+   dma_sync_single_for_device(dev, state->digest_buff_dma_addr,
+  ctx->inter_digestsize, DMA_BIDIRECTIONAL);
+
+   if (state->digest_bytes_len_dma_addr)
+   dma_sync_single_for_device(dev,
+  state->digest_bytes_len_dma_addr,
+  HASH_LEN_SIZE, DMA_BIDIRECTIONAL);
+
+   state->buff_index = 0;
+
+   /* Sanity check the data as much as possible */
+   memcpy(, in, sizeof(u32));
+   if (tmp > SSI_MAX_HASH_BLCK_SIZE) {
+   rc = -EINVAL;
+   goto out;
+   }
+   in += sizeof(u32);
+
+   state->buff0_cnt = tmp;
+   memcpy(state->buff0, in, state->buff0_cnt);
+
+out:
+   return rc;
 }

[PATCH 0/7] staging: ccree: bug fixes and TODO items for 4.13

[Gilad Ben-Yossef]

An assortment of bug fixes and staging TODO items.
Highlights includes the driver passing crypto testmgr boot tests
and support of multiple HW revs. without build time changes.

Gilad Ben-Yossef (7):
  staging: ccree: fix hash import/export
  staging: ccree: register setkey for none hash macs
  staging: ccree: add support for older HW revisions
  staging: ccree: remove unused function
  staging: ccree: add clock management support
  staging: ccree: add DT bus coherency detection
  staging: ccree: use signal safe completion wait

 drivers/staging/ccree/Kconfig|   7 +-
 drivers/staging/ccree/Makefile   |   2 +-
 drivers/staging/ccree/cc_crypto_ctx.h|  16 --
 drivers/staging/ccree/cc_hw_queue_defs.h |  14 +-
 drivers/staging/ccree/cc_regs.h  |   7 +-
 drivers/staging/ccree/dx_crys_kernel.h   |   1 +
 drivers/staging/ccree/dx_host.h  |   3 +
 drivers/staging/ccree/dx_reg_common.h|   2 -
 drivers/staging/ccree/ssi_aead.c |  36 ++-
 drivers/staging/ccree/ssi_buffer_mgr.c   |  37 +--
 drivers/staging/ccree/ssi_cipher.c   |  27 +-
 drivers/staging/ccree/ssi_config.h   |  20 --
 drivers/staging/ccree/ssi_driver.c   | 170 +---
 drivers/staging/ccree/ssi_driver.h   |  32 ++-
 drivers/staging/ccree/ssi_fips_ll.c  |  59 +++--
 drivers/staging/ccree/ssi_hash.c | 441 ++-
 drivers/staging/ccree/ssi_hash.h |  12 +-
 drivers/staging/ccree/ssi_pm.c   |  13 +-
 drivers/staging/ccree/ssi_pm_ext.c   |  60 -
 drivers/staging/ccree/ssi_pm_ext.h   |  33 ---
 drivers/staging/ccree/ssi_request_mgr.c  |  22 +-
 drivers/staging/ccree/ssi_sram_mgr.c |  15 +-
 22 files changed, 564 insertions(+), 465 deletions(-)
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.c
 delete mode 100644 drivers/staging/ccree/ssi_pm_ext.h

-- 
2.1.4