Crypto Fixes for 4.11

2017-03-03 Thread Herbert Xu 
Hi Linus:

This push fixes the following issues:

- vmalloc stack regression in CCM.
- Build problem in CRC32 on ARM.
- Memory leak in cavium.
- Missing Kconfig dependencies in atmel and mediatek.
- XTS Regression on some platforms (s390 and ppc).
- Memory overrun in CCM test vector.


Please pull from

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


Ard Biesheuvel (3):
  crypto: ccm - move cbcmac input off the stack
  crypto: arm/crc32 - fix build error with outdated binutils
  crypto: arm/crc32 - add build time test for CRC instruction support

Colin Ian King (1):
  crypto: cavium - fix leak on curr if curr->head fails to be allocated

Geert Uytterhoeven (2):
  crypto: atmel - CRYPTO_DEV_ATMEL_TDES and CRYPTO_DEV_ATMEL_SHA should 
depend on HAS_DMA
  crypto: atmel - CRYPTO_DEV_MEDIATEK should depend on HAS_DMA

George Cherian (1):
  crypto: cavium - Fix couple of static checker errors

Herbert Xu (2):
  crypto: api - Add crypto_requires_off helper
  crypto: xts - Propagate NEED_FALLBACK bit

Laura Abbott (1):
  crypto: testmgr - Pad aes_ccm_enc_tv_template vector

Paulo Flabiano Smorigo (2):
  crypto: vmx - Use skcipher for cbc fallback
  crypto: vmx - Use skcipher for xts fallback

 arch/arm/crypto/Makefile |   12 ++-
 arch/arm/crypto/crc32-ce-core.S  |2 +-
 crypto/ccm.c |5 +--
 crypto/testmgr.h |2 +-
 crypto/xts.c |   14 
 drivers/crypto/Kconfig   |3 ++
 drivers/crypto/cavium/cpt/cptvf_main.c   |5 ++-
 drivers/crypto/cavium/cpt/cptvf_reqmanager.c |4 +--
 drivers/crypto/vmx/aes_cbc.c |   47 +-
 drivers/crypto/vmx/aes_xts.c |   32 +-
 include/crypto/algapi.h  |7 +++-
 11 files changed, 79 insertions(+), 54 deletions(-)

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

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

2017-03-03 Thread Brijesh Singh 

Hi Bjorn,

On 03/03/2017 02:33 PM, Bjorn Helgaas wrote:

On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:

This RFC series provides support for AMD's new Secure Encrypted Virtualization
(SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 [1].


What kernel version is this series based on?



This patch series is based off of the master branch of tip.
  Commit a27cb9e1b2b4 ("Merge branch 'WIP.sched/core'")
  Tom's RFC v4 patches (http://marc.info/?l=linux-mm=148725973013686=2)

Accidentally, I ended up rebasing SEV RFCv2 patches from updated SME v4 
instead of original SME v4. So you may need to apply patch [1]


[1] http://marc.info/?l=linux-mm=148857523132253=2

Optionally, I have posted the full git tree here [2]

[2] https://github.com/codomania/tip/branches

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

2017-03-03 Thread Tom Lendacky 

On 3/3/2017 2:42 PM, Bjorn Helgaas wrote:

On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:

From: Tom Lendacky 

The use of ioremap will force the setup data to be mapped decrypted even
though setup data is encrypted.  Switch to using memremap which will be
able to perform the proper mapping.


How should callers decide whether to use ioremap() or memremap()?

memremap() existed before SME and SEV, and this code is used even if
SME and SEV aren't supported, so the rationale for this change should
not need the decryption argument.


When SME or SEV is active an ioremap() will remove the encryption bit
from the pagetable entry when it is mapped.  This allows MMIO, which
doesn't support SME/SEV, to be performed successfully.  So my take is
that ioremap() should be used for MMIO and memremap() for pages in RAM.




Signed-off-by: Tom Lendacky 
---
 arch/x86/pci/common.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
index a4fdfa7..0b06670 100644
--- a/arch/x86/pci/common.c
+++ b/arch/x86/pci/common.c
@@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)

pa_data = boot_params.hdr.setup_data;
while (pa_data) {
-   data = ioremap(pa_data, sizeof(*rom));
+   data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);


I can't quite connect the dots here.  ioremap() on x86 would do
ioremap_nocache().  memremap(MEMREMAP_WB) would do arch_memremap_wb(),
which is ioremap_cache().  Is making a cacheable mapping the important
difference?


The memremap(MEMREMAP_WB) will actually check to see if it can perform
a __va(pa_data) in try_ram_remap() and then fallback to the
arch_memremap_wb().  So it's actually the __va() vs the ioremap_cache()
that is the difference.

Thanks,
Tom




if (!data)
return -ENOMEM;

@@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
}
}
pa_data = data->next;
-   iounmap(data);
+   memunmap(data);
}
set_dma_domain_ops(dev);
set_dev_domain_options(dev);

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-03 Thread Brijesh Singh 

Hi Boris,

On 03/03/2017 10:59 AM, Borislav Petkov wrote:

On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:

From: Tom Lendacky 

Update the CPU features to include identifying and reporting on the
Secure Encrypted Virtualization (SEV) feature.  SME is identified by
CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of
MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR).  Only show the SEV feature
as available if reported by CPUID and enabled by BIOS.

Signed-off-by: Tom Lendacky 
---
 arch/x86/include/asm/cpufeatures.h |1 +
 arch/x86/include/asm/msr-index.h   |2 ++
 arch/x86/kernel/cpu/amd.c  |   22 ++
 arch/x86/kernel/cpu/scattered.c|1 +
 4 files changed, 22 insertions(+), 4 deletions(-)


So this patchset is not really ontop of Tom's patchset because this
patch doesn't apply. The reason is, Tom did the SME bit this way:

https://lkml.kernel.org/r/20170216154236.19244.7580.st...@tlendack-t1.amdoffice.net

but it should've been in scattered.c.


diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
index cabda87..c3f58d9 100644
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -31,6 +31,7 @@ static const struct cpuid_bit cpuid_bits[] = {
{ X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
{ X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
{ X86_FEATURE_SME,  CPUID_EAX,  0, 0x801f, 0 },
+   { X86_FEATURE_SEV,  CPUID_EAX,  1, 0x801f, 0 },
{ 0, 0, 0, 0, 0 }


... and here it is in scattered.c, as it should be. So you've used an
older version of the patch, it seems.

Please sync with Tom to see whether he's reworked the v4 version of that
patch already. If yes, then you could send only the SME and SEV adding
patches as a reply to this message so that I can continue reviewing in
the meantime.



Just realized my error, I actually end up using Tom's recent updates to 
v4 instead of original v4. Here is the diff. If you have Tom's v4 
applied then apply this diff before applying SEV v2 version. Sorry about 
that.


Optionally, you also pull the complete tree from github [1].

[1] https://github.com/codomania/tip/tree/sev-rfc-v2


diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt

index 91c40fa..b91e2495 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2153,8 +2153,8 @@
mem_encrypt=on: Activate SME
mem_encrypt=off:Do not activate SME

-   Refer to the SME documentation for details on when
-   memory encryption can be activated.
+   Refer to Documentation/x86/amd-memory-encryption.txt
+   for details on when memory encryption can be activated.

mem_sleep_default=  [SUSPEND] Default system suspend mode:
s2idle  - Suspend-To-Idle
diff --git a/Documentation/x86/amd-memory-encryption.txt 
b/Documentation/x86/amd-memory-encryption.txt

index 0938e89..0b72ff2 100644
--- a/Documentation/x86/amd-memory-encryption.txt
+++ b/Documentation/x86/amd-memory-encryption.txt
@@ -7,9 +7,9 @@ DRAM.  SME can therefore be used to protect the contents 
of DRAM from physical

 attacks on the system.

 A page is encrypted when a page table entry has the encryption bit set 
(see

-below how to determine the position of the bit).  The encryption bit can be
-specified in the cr3 register, allowing the PGD table to be encrypted. Each
-successive level of page tables can also be encrypted.
+below on how to determine its position).  The encryption bit can be 
specified
+in the cr3 register, allowing the PGD table to be encrypted. Each 
successive

+level of page tables can also be encrypted.

 Support for SME can be determined through the CPUID instruction. The CPUID
 function 0x801f reports information related to SME:
@@ -17,13 +17,14 @@ function 0x801f reports information related to SME:
0x801f[eax]:
Bit[0] indicates support for SME
0x801f[ebx]:
-   Bit[5:0]  pagetable bit number used to activate memory
- encryption
-   Bit[11:6] reduction in physical address space, in bits, when
- memory encryption is enabled (this only affects system
- physical addresses, not guest physical addresses)
-
-If support for SME is present, MSR 0xc00100010 (SYS_CFG) can be used to
+   Bits[5:0]  pagetable bit number used to activate memory
+  encryption
+   Bits[11:6] reduction in physical address space, in bits, when
+  memory encryption is enabled (this only affects
+

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

2017-03-03 Thread Borislav Petkov 
On Fri, Mar 03, 2017 at 02:33:23PM -0600, Bjorn Helgaas wrote:
> On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> > This RFC series provides support for AMD's new Secure Encrypted 
> > Virtualization
> > (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 
> > [1].
> 
> What kernel version is this series based on?

Yeah, see that mail in [1]:

https://lkml.kernel.org/r/20170216154158.19244.66630.st...@tlendack-t1.amdoffice.net

"This patch series is based off of the master branch of tip.
  Commit a27cb9e1b2b4 ("Merge branch 'WIP.sched/core'")"

$ git describe a27cb9e1b2b4
v4.10-rc7-681-ga27cb9e1b2b4

So you need the SME pile first and then that SVE pile. But the first
patch needs refreshing as it is using a different base than the SME
pile. :-)

Tom, Brijesh, perhaps you guys could push a full tree somewhere - github
or so - for people to pull, in addition to the patchset on lkml.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

Re: [RFC PATCH v2 06/32] x86/pci: Use memremap when walking setup data

2017-03-03 Thread Bjorn Helgaas 
On Thu, Mar 02, 2017 at 10:13:10AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> The use of ioremap will force the setup data to be mapped decrypted even
> though setup data is encrypted.  Switch to using memremap which will be
> able to perform the proper mapping.

How should callers decide whether to use ioremap() or memremap()?

memremap() existed before SME and SEV, and this code is used even if
SME and SEV aren't supported, so the rationale for this change should
not need the decryption argument.

> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/pci/common.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index a4fdfa7..0b06670 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -691,7 +691,7 @@ int pcibios_add_device(struct pci_dev *dev)
>  
>   pa_data = boot_params.hdr.setup_data;
>   while (pa_data) {
> - data = ioremap(pa_data, sizeof(*rom));
> + data = memremap(pa_data, sizeof(*rom), MEMREMAP_WB);

I can't quite connect the dots here.  ioremap() on x86 would do
ioremap_nocache().  memremap(MEMREMAP_WB) would do arch_memremap_wb(),
which is ioremap_cache().  Is making a cacheable mapping the important
difference?

>   if (!data)
>   return -ENOMEM;
>  
> @@ -710,7 +710,7 @@ int pcibios_add_device(struct pci_dev *dev)
>   }
>   }
>   pa_data = data->next;
> - iounmap(data);
> + memunmap(data);
>   }
>   set_dma_domain_ops(dev);
>   set_dev_domain_options(dev);
>

Re: [RFC PATCH v2 00/32] x86: Secure Encrypted Virtualization (AMD)

2017-03-03 Thread Bjorn Helgaas 
On Thu, Mar 02, 2017 at 10:12:01AM -0500, Brijesh Singh wrote:
> This RFC series provides support for AMD's new Secure Encrypted Virtualization
> (SEV) feature. This RFC is build upon Secure Memory Encryption (SME) RFCv4 
> [1].

What kernel version is this series based on?

[RFC 1/7] soc/qman: export volatile dequeue related structs

2017-03-03 Thread Horia Geantă 
Since qman_volatile_dequeue() is already exported, move the related
structures into the public header too.

Signed-off-by: Horia Geantă 
---
 drivers/soc/fsl/qbman/qman_priv.h | 36 
 include/soc/fsl/qman.h| 36 
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman_priv.h 
b/drivers/soc/fsl/qbman/qman_priv.h
index 53685b59718e..64781eff6974 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -271,42 +271,6 @@ const struct qm_portal_config 
*qman_destroy_affine_portal(void);
  */
 int qman_query_fq(struct qman_fq *fq, struct qm_fqd *fqd);
 
-/*
- * For qman_volatile_dequeue(); Choose one PRECEDENCE. EXACT is optional. Use
- * NUMFRAMES(n) (6-bit) or NUMFRAMES_TILLEMPTY to fill in the frame-count. Use
- * FQID(n) to fill in the frame queue ID.
- */
-#define QM_VDQCR_PRECEDENCE_VDQCR  0x0
-#define QM_VDQCR_PRECEDENCE_SDQCR  0x8000
-#define QM_VDQCR_EXACT 0x4000
-#define QM_VDQCR_NUMFRAMES_MASK0x3f00
-#define QM_VDQCR_NUMFRAMES_SET(n)  (((n) & 0x3f) << 24)
-#define QM_VDQCR_NUMFRAMES_GET(n)  (((n) >> 24) & 0x3f)
-#define QM_VDQCR_NUMFRAMES_TILLEMPTY   QM_VDQCR_NUMFRAMES_SET(0)
-
-#define QMAN_VOLATILE_FLAG_WAIT 0x0001 /* wait if VDQCR is in 
use */
-#define QMAN_VOLATILE_FLAG_WAIT_INT  0x0002 /* if wait, interruptible? */
-#define QMAN_VOLATILE_FLAG_FINISH0x0004 /* wait till VDQCR completes */
-
-/*
- * qman_volatile_dequeue - Issue a volatile dequeue command
- * @fq: the frame queue object to dequeue from
- * @flags: a bit-mask of QMAN_VOLATILE_FLAG_*** options
- * @vdqcr: bit mask of QM_VDQCR_*** options, as per qm_dqrr_vdqcr_set()
- *
- * Attempts to lock access to the portal's VDQCR volatile dequeue 
functionality.
- * The function will block and sleep if QMAN_VOLATILE_FLAG_WAIT is specified 
and
- * the VDQCR is already in use, otherwise returns non-zero for failure. If
- * QMAN_VOLATILE_FLAG_FINISH is specified, the function will only return once
- * the VDQCR command has finished executing (ie. once the callback for the last
- * DQRR entry resulting from the VDQCR command has been called). If not using
- * the FINISH flag, completion can be determined either by detecting the
- * presence of the QM_DQRR_STAT_UNSCHEDULED and QM_DQRR_STAT_DQCR_EXPIRED bits
- * in the "stat" parameter passed to the FQ's dequeue callback, or by waiting
- * for the QMAN_FQ_STATE_VDQCR bit to disappear.
- */
-int qman_volatile_dequeue(struct qman_fq *fq, u32 flags, u32 vdqcr);
-
 int qman_alloc_fq_table(u32 num_fqids);
 
 /*   QMan s/w corenet portal, low-level i/face  */
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 3d4df74a96de..4de1ffcc8982 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -791,6 +791,23 @@ struct qman_cgr {
 #define QMAN_INITFQ_FLAG_SCHED  0x0001 /* schedule rather than park */
 #define QMAN_INITFQ_FLAG_LOCAL  0x0004 /* set dest portal */
 
+/*
+ * For qman_volatile_dequeue(); Choose one PRECEDENCE. EXACT is optional. Use
+ * NUMFRAMES(n) (6-bit) or NUMFRAMES_TILLEMPTY to fill in the frame-count. Use
+ * FQID(n) to fill in the frame queue ID.
+ */
+#define QM_VDQCR_PRECEDENCE_VDQCR  0x0
+#define QM_VDQCR_PRECEDENCE_SDQCR  0x8000
+#define QM_VDQCR_EXACT 0x4000
+#define QM_VDQCR_NUMFRAMES_MASK0x3f00
+#define QM_VDQCR_NUMFRAMES_SET(n)  (((n) & 0x3f) << 24)
+#define QM_VDQCR_NUMFRAMES_GET(n)  (((n) >> 24) & 0x3f)
+#define QM_VDQCR_NUMFRAMES_TILLEMPTY   QM_VDQCR_NUMFRAMES_SET(0)
+
+#define QMAN_VOLATILE_FLAG_WAIT 0x0001 /* wait if VDQCR is in 
use */
+#define QMAN_VOLATILE_FLAG_WAIT_INT  0x0002 /* if wait, interruptible? */
+#define QMAN_VOLATILE_FLAG_FINISH0x0004 /* wait till VDQCR completes */
+
/* Portal Management */
 /**
  * qman_p_irqsource_add - add processing sources to be interrupt-driven
@@ -963,6 +980,25 @@ int qman_retire_fq(struct qman_fq *fq, u32 *flags);
  */
 int qman_oos_fq(struct qman_fq *fq);
 
+/*
+ * qman_volatile_dequeue - Issue a volatile dequeue command
+ * @fq: the frame queue object to dequeue from
+ * @flags: a bit-mask of QMAN_VOLATILE_FLAG_*** options
+ * @vdqcr: bit mask of QM_VDQCR_*** options, as per qm_dqrr_vdqcr_set()
+ *
+ * Attempts to lock access to the portal's VDQCR volatile dequeue 
functionality.
+ * The function will block and sleep if QMAN_VOLATILE_FLAG_WAIT is specified 
and
+ * the VDQCR is already in use, otherwise returns non-zero for failure. If
+ * QMAN_VOLATILE_FLAG_FINISH is specified, the function will only return once
+ * the VDQCR command has finished executing (ie. once the callback for the last
+ * DQRR entry resulting from the VDQCR command has been called). If not using
+ * the FINISH flag, completion can be determined either by detecting

Re: [RFC PATCH v2 01/32] x86: Add the Secure Encrypted Virtualization CPU feature

2017-03-03 Thread Borislav Petkov 
On Thu, Mar 02, 2017 at 10:12:09AM -0500, Brijesh Singh wrote:
> From: Tom Lendacky 
> 
> Update the CPU features to include identifying and reporting on the
> Secure Encrypted Virtualization (SEV) feature.  SME is identified by
> CPUID 0x801f, but requires BIOS support to enable it (set bit 23 of
> MSR_K8_SYSCFG and set bit 0 of MSR_K7_HWCR).  Only show the SEV feature
> as available if reported by CPUID and enabled by BIOS.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/cpufeatures.h |1 +
>  arch/x86/include/asm/msr-index.h   |2 ++
>  arch/x86/kernel/cpu/amd.c  |   22 ++
>  arch/x86/kernel/cpu/scattered.c|1 +
>  4 files changed, 22 insertions(+), 4 deletions(-)

So this patchset is not really ontop of Tom's patchset because this
patch doesn't apply. The reason is, Tom did the SME bit this way:

https://lkml.kernel.org/r/20170216154236.19244.7580.st...@tlendack-t1.amdoffice.net

but it should've been in scattered.c.

> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index cabda87..c3f58d9 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -31,6 +31,7 @@ static const struct cpuid_bit cpuid_bits[] = {
>   { X86_FEATURE_CPB,  CPUID_EDX,  9, 0x8007, 0 },
>   { X86_FEATURE_PROC_FEEDBACK,CPUID_EDX, 11, 0x8007, 0 },
>   { X86_FEATURE_SME,  CPUID_EAX,  0, 0x801f, 0 },
> + { X86_FEATURE_SEV,  CPUID_EAX,  1, 0x801f, 0 },
>   { 0, 0, 0, 0, 0 }

... and here it is in scattered.c, as it should be. So you've used an
older version of the patch, it seems.

Please sync with Tom to see whether he's reworked the v4 version of that
patch already. If yes, then you could send only the SME and SEV adding
patches as a reply to this message so that I can continue reviewing in
the meantime.

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--

[RFC 4/7] soc/qman: add helper functions needed by caam/qi driver

2017-03-03 Thread Horia Geantă 
Add helper functions, macros, #defines for accessing / enabling
qman functionality from caam/qi driver, such that this driver
is not aware of the need for data conversion to big endian.
qman is updated to use these helpers internally.

Signed-off-by: Horia Geantă 
---
 drivers/soc/fsl/qbman/qman.c| 16 +--
 drivers/soc/fsl/qbman/qman_test_stash.c |  5 ++--
 include/soc/fsl/qman.h  | 47 +
 3 files changed, 56 insertions(+), 12 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 3d891db57ee6..7668ff53cd90 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -1764,16 +1764,15 @@ int qman_init_fq(struct qman_fq *fq, u32 flags, struct 
qm_mcc_initfq *opts)
if (fq_isclear(fq, QMAN_FQ_FLAG_TO_DCPORTAL)) {
dma_addr_t phys_fq;
 
-   mcc->initfq.we_mask |= cpu_to_be16(QM_INITFQ_WE_CONTEXTB);
-   mcc->initfq.fqd.context_b = cpu_to_be32(fq_to_tag(fq));
+   qm_initfq_setbits(>initfq, QM_INITFQ_WE_CONTEXTB);
+   qm_fqd_set_contextb(>initfq.fqd, fq_to_tag(fq));
/*
 *  and the physical address - NB, if the user wasn't trying to
 * set CONTEXTA, clear the stashing settings.
 */
if (!(be16_to_cpu(mcc->initfq.we_mask) &
  QM_INITFQ_WE_CONTEXTA)) {
-   mcc->initfq.we_mask |=
-   cpu_to_be16(QM_INITFQ_WE_CONTEXTA);
+   qm_initfq_setbits(>initfq, QM_INITFQ_WE_CONTEXTA);
memset(>initfq.fqd.context_a, 0,
sizeof(mcc->initfq.fqd.context_a));
} else {
@@ -1795,8 +1794,7 @@ int qman_init_fq(struct qman_fq *fq, u32 flags, struct 
qm_mcc_initfq *opts)
 
if (!(be16_to_cpu(mcc->initfq.we_mask) &
  QM_INITFQ_WE_DESTWQ)) {
-   mcc->initfq.we_mask |=
-   cpu_to_be16(QM_INITFQ_WE_DESTWQ);
+   qm_initfq_setbits(>initfq, QM_INITFQ_WE_DESTWQ);
wq = 4;
}
qm_fqd_set_destwq(>initfq.fqd, p->config->channel, wq);
@@ -1816,7 +1814,7 @@ int qman_init_fq(struct qman_fq *fq, u32 flags, struct 
qm_mcc_initfq *opts)
}
if (opts) {
if (be16_to_cpu(opts->we_mask) & QM_INITFQ_WE_FQCTRL) {
-   if (be16_to_cpu(opts->fqd.fq_ctrl) & QM_FQCTRL_CGE)
+   if (qm_fqd_isset_fqctrl(>fqd, QM_FQCTRL_CGE))
fq_set(fq, QMAN_FQ_STATE_CGR_EN);
else
fq_clear(fq, QMAN_FQ_STATE_CGR_EN);
@@ -2321,7 +2319,7 @@ int qman_create_cgr(struct qman_cgr *cgr, u32 flags,
 
qm_cgr_cscn_targ_set(_opts.cgr, PORTAL_IDX(p),
 be32_to_cpu(cgr_state.cgr.cscn_targ));
-   local_opts.we_mask |= cpu_to_be16(QM_CGR_WE_CSCN_TARG);
+   qm_initcgr_setbits(_opts, QM_CGR_WE_CSCN_TARG);
 
/* send init if flags indicate so */
if (flags & QMAN_CGR_FLAG_USE_INIT)
@@ -2840,7 +2838,7 @@ static int cgr_cleanup(u32 cgrid)
err = qman_query_fq(, );
if (WARN_ON(err))
return err;
-   if (be16_to_cpu(fqd.fq_ctrl) & QM_FQCTRL_CGE &&
+   if (qm_fqd_isset_fqctrl(, QM_FQCTRL_CGE) &&
fqd.cgid == cgrid) {
pr_err("CRGID 0x%x is being used by FQID 0x%x, 
CGR will be leaked\n",
   cgrid, fq.fqid);
diff --git a/drivers/soc/fsl/qbman/qman_test_stash.c 
b/drivers/soc/fsl/qbman/qman_test_stash.c
index e87b65403b67..d2bf453092d7 100644
--- a/drivers/soc/fsl/qbman/qman_test_stash.c
+++ b/drivers/soc/fsl/qbman/qman_test_stash.c
@@ -406,9 +406,8 @@ static int init_handler(void *h)
goto failed;
}
memset(, 0, sizeof(opts));
-   opts.we_mask = cpu_to_be16(QM_INITFQ_WE_FQCTRL |
-  QM_INITFQ_WE_CONTEXTA);
-   opts.fqd.fq_ctrl = cpu_to_be16(QM_FQCTRL_CTXASTASHING);
+   qm_initfq_setbits(, QM_INITFQ_WE_FQCTRL | QM_INITFQ_WE_CONTEXTA);
+   qm_fqd_set_fqctrl(, QM_FQCTRL_CTXASTASHING);
qm_fqd_set_stashing(, 0, STASH_DATA_CL, STASH_CTX_CL);
err = qman_init_fq(>rx, QMAN_INITFQ_FLAG_SCHED |
   QMAN_INITFQ_FLAG_LOCAL, );
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 0252c32f7421..fc133c658385 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -168,6 +168,12 @@ static inline void qm_fd_set_param(struct qm_fd *fd, enum 
qm_fd_format fmt,
 #define qm_fd_set_contig_big(fd, len) \

[RFC 3/7] soc/qman: export non-programmable FQD fields query

2017-03-03 Thread Horia Geantă 
Export qman_query_fq_np() function and related structures.
This will be needed in the caam/qi driver, where "queue empty"
condition will be decided based on the frm_cnt.

Signed-off-by: Horia Geantă 
---
 drivers/soc/fsl/qbman/qman.c  |  4 +--
 drivers/soc/fsl/qbman/qman_priv.h | 61 ---
 include/soc/fsl/qman.h| 68 +++
 3 files changed, 70 insertions(+), 63 deletions(-)

diff --git a/drivers/soc/fsl/qbman/qman.c b/drivers/soc/fsl/qbman/qman.c
index 6f509f68085e..3d891db57ee6 100644
--- a/drivers/soc/fsl/qbman/qman.c
+++ b/drivers/soc/fsl/qbman/qman.c
@@ -2019,8 +2019,7 @@ int qman_query_fq(struct qman_fq *fq, struct qm_fqd *fqd)
return ret;
 }
 
-static int qman_query_fq_np(struct qman_fq *fq,
-   struct qm_mcr_queryfq_np *np)
+int qman_query_fq_np(struct qman_fq *fq, struct qm_mcr_queryfq_np *np)
 {
union qm_mc_command *mcc;
union qm_mc_result *mcr;
@@ -2046,6 +2045,7 @@ static int qman_query_fq_np(struct qman_fq *fq,
put_affine_portal();
return ret;
 }
+EXPORT_SYMBOL(qman_query_fq_np);
 
 static int qman_query_cgr(struct qman_cgr *cgr,
  struct qm_mcr_querycgr *cgrd)
diff --git a/drivers/soc/fsl/qbman/qman_priv.h 
b/drivers/soc/fsl/qbman/qman_priv.h
index 64781eff6974..22725bdc6f15 100644
--- a/drivers/soc/fsl/qbman/qman_priv.h
+++ b/drivers/soc/fsl/qbman/qman_priv.h
@@ -89,67 +89,6 @@ static inline u64 qm_mcr_querycgr_a_get64(const struct 
qm_mcr_querycgr *q)
return ((u64)q->a_bcnt_hi << 32) | be32_to_cpu(q->a_bcnt_lo);
 }
 
-/* "Query FQ Non-Programmable Fields" */
-
-struct qm_mcr_queryfq_np {
-   u8 verb;
-   u8 result;
-   u8 __reserved1;
-   u8 state;   /* QM_MCR_NP_STATE_*** */
-   u32 fqd_link;   /* 24-bit, _res2[24-31] */
-   u16 odp_seq;/* 14-bit, _res3[14-15] */
-   u16 orp_nesn;   /* 14-bit, _res4[14-15] */
-   u16 orp_ea_hseq;/* 15-bit, _res5[15] */
-   u16 orp_ea_tseq;/* 15-bit, _res6[15] */
-   u32 orp_ea_hptr;/* 24-bit, _res7[24-31] */
-   u32 orp_ea_tptr;/* 24-bit, _res8[24-31] */
-   u32 pfdr_hptr;  /* 24-bit, _res9[24-31] */
-   u32 pfdr_tptr;  /* 24-bit, _res10[24-31] */
-   u8 __reserved2[5];
-   u8 is;  /* 1-bit, _res12[1-7] */
-   u16 ics_surp;
-   u32 byte_cnt;
-   u32 frm_cnt;/* 24-bit, _res13[24-31] */
-   u32 __reserved3;
-   u16 ra1_sfdr;   /* QM_MCR_NP_RA1_*** */
-   u16 ra2_sfdr;   /* QM_MCR_NP_RA2_*** */
-   u16 __reserved4;
-   u16 od1_sfdr;   /* QM_MCR_NP_OD1_*** */
-   u16 od2_sfdr;   /* QM_MCR_NP_OD2_*** */
-   u16 od3_sfdr;   /* QM_MCR_NP_OD3_*** */
-} __packed;
-
-#define QM_MCR_NP_STATE_FE 0x10
-#define QM_MCR_NP_STATE_R  0x08
-#define QM_MCR_NP_STATE_MASK   0x07/* Reads FQD::STATE; */
-#define QM_MCR_NP_STATE_OOS0x00
-#define QM_MCR_NP_STATE_RETIRED0x01
-#define QM_MCR_NP_STATE_TEN_SCHED  0x02
-#define QM_MCR_NP_STATE_TRU_SCHED  0x03
-#define QM_MCR_NP_STATE_PARKED 0x04
-#define QM_MCR_NP_STATE_ACTIVE 0x05
-#define QM_MCR_NP_PTR_MASK 0x07ff  /* for RA[12] & OD[123] */
-#define QM_MCR_NP_RA1_NRA(v)   (((v) >> 14) & 0x3) /* FQD::NRA */
-#define QM_MCR_NP_RA2_IT(v)(((v) >> 14) & 0x1) /* FQD::IT */
-#define QM_MCR_NP_OD1_NOD(v)   (((v) >> 14) & 0x3) /* FQD::NOD */
-#define QM_MCR_NP_OD3_NPC(v)   (((v) >> 14) & 0x3) /* FQD::NPC */
-
-enum qm_mcr_queryfq_np_masks {
-   qm_mcr_fqd_link_mask = BIT(24)-1,
-   qm_mcr_odp_seq_mask = BIT(14)-1,
-   qm_mcr_orp_nesn_mask = BIT(14)-1,
-   qm_mcr_orp_ea_hseq_mask = BIT(15)-1,
-   qm_mcr_orp_ea_tseq_mask = BIT(15)-1,
-   qm_mcr_orp_ea_hptr_mask = BIT(24)-1,
-   qm_mcr_orp_ea_tptr_mask = BIT(24)-1,
-   qm_mcr_pfdr_hptr_mask = BIT(24)-1,
-   qm_mcr_pfdr_tptr_mask = BIT(24)-1,
-   qm_mcr_is_mask = BIT(1)-1,
-   qm_mcr_frm_cnt_mask = BIT(24)-1,
-};
-#define qm_mcr_np_get(np, field) \
-   ((np)->field & (qm_mcr_##field##_mask))
-
 /* Congestion Groups */
 
 /*
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 10b549783ec5..0252c32f7421 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -811,6 +811,67 @@ struct qman_cgr {
 #define QMAN_VOLATILE_FLAG_WAIT_INT  0x0002 /* if wait, interruptible? */
 #define QMAN_VOLATILE_FLAG_FINISH0x0004 /* wait till VDQCR completes */
 
+/* "Query FQ Non-Programmable Fields" */
+struct qm_mcr_queryfq_np {
+   u8 verb;
+   u8 result;
+   u8 __reserved1;
+   u8 state;   /* QM_MCR_NP_STATE_*** */
+   u32 fqd_link;   /* 24-bit, _res2[24-31] */
+   u16 odp_seq;/*

[RFC 2/7] soc/qman: add dedicated channel ID for CAAM

2017-03-03 Thread Horia Geantă 
Add and export the ID of the channel serviced by the
CAAM (Cryptographic Acceleration and Assurance Module) DCP.

Signed-off-by: Horia Geantă 
---
 drivers/soc/fsl/qbman/qman_ccsr.c | 6 +-
 include/soc/fsl/qman.h| 3 +++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/fsl/qbman/qman_ccsr.c 
b/drivers/soc/fsl/qbman/qman_ccsr.c
index f4e6e70de259..90bc40c48675 100644
--- a/drivers/soc/fsl/qbman/qman_ccsr.c
+++ b/drivers/soc/fsl/qbman/qman_ccsr.c
@@ -34,6 +34,8 @@ u16 qman_ip_rev;
 EXPORT_SYMBOL(qman_ip_rev);
 u16 qm_channel_pool1 = QMAN_CHANNEL_POOL1;
 EXPORT_SYMBOL(qm_channel_pool1);
+u16 qm_channel_caam = QMAN_CHANNEL_CAAM;
+EXPORT_SYMBOL(qm_channel_caam);
 
 /* Register offsets */
 #define REG_QCSP_LIO_CFG(n)(0x + ((n) * 0x10))
@@ -720,8 +722,10 @@ static int fsl_qman_probe(struct platform_device *pdev)
return -ENODEV;
}
 
-   if ((qman_ip_rev & 0xff00) >= QMAN_REV30)
+   if ((qman_ip_rev & 0xff00) >= QMAN_REV30) {
qm_channel_pool1 = QMAN_CHANNEL_POOL1_REV3;
+   qm_channel_caam = QMAN_CHANNEL_CAAM_REV3;
+   }
 
ret = zero_priv_mem(dev, node, fqd_a, fqd_sz);
WARN_ON(ret);
diff --git a/include/soc/fsl/qman.h b/include/soc/fsl/qman.h
index 4de1ffcc8982..10b549783ec5 100644
--- a/include/soc/fsl/qman.h
+++ b/include/soc/fsl/qman.h
@@ -36,8 +36,11 @@
 /* Hardware constants */
 #define QM_CHANNEL_SWPORTAL0 0
 #define QMAN_CHANNEL_POOL1 0x21
+#define QMAN_CHANNEL_CAAM 0x80
 #define QMAN_CHANNEL_POOL1_REV3 0x401
+#define QMAN_CHANNEL_CAAM_REV3 0x840
 extern u16 qm_channel_pool1;
+extern u16 qm_channel_caam;
 
 /* Portal processing (interrupt) sources */
 #define QM_PIRQ_CSCI   0x0010  /* Congestion State Change */
-- 
2.4.4

[RFC 0/7] crypto: caam - add Queue Interface (QI) support

2017-03-03 Thread Horia Geantă 
The patchset adds support for CAAM Queue Interface (QI), the additional
interface (besides job ring) available for submitting jobs to the engine
on platforms having DPAA (Datapath Acceleration Architecture).

Patches 1-4 are QMan dependencies.
I would prefer to take them through the crypto tree,
but I am open to suggestions.

Patch 5 adds a missing double inclusion guard in desc_constr.h.

Patch 6 adds the caam/qi job submission backend.

Patch 7 adds algorithms (ablkcipher and authenc) that run on top
of caam/qi. For now, their priority is set lower than caam/jr.

Thanks,
Horia

Horia Geantă (7):
  soc/qman: export volatile dequeue related structs
  soc/qman: add dedicated channel ID for CAAM
  soc/qman: export non-programmable FQD fields query
  soc/qman: add helper functions needed by caam/qi driver
  crypto: caam - avoid double inclusion in desc_constr.h
  crypto: caam - add Queue Interface (QI) backend support
  crypto: caam/qi - add ablkcipher and authenc algorithms

 drivers/crypto/caam/Kconfig |   20 +-
 drivers/crypto/caam/Makefile|5 +
 drivers/crypto/caam/caamalg.c   |9 +-
 drivers/crypto/caam/caamalg_desc.c  |   77 +-
 drivers/crypto/caam/caamalg_desc.h  |   15 +-
 drivers/crypto/caam/caamalg_qi.c| 2387 +++
 drivers/crypto/caam/ctrl.c  |   58 +-
 drivers/crypto/caam/desc_constr.h   |5 +
 drivers/crypto/caam/intern.h|   24 +
 drivers/crypto/caam/qi.c|  805 +++
 drivers/crypto/caam/qi.h|  201 +++
 drivers/crypto/caam/sg_sw_qm.h  |  107 ++
 drivers/soc/fsl/qbman/qman.c|   20 +-
 drivers/soc/fsl/qbman/qman_ccsr.c   |6 +-
 drivers/soc/fsl/qbman/qman_priv.h   |   97 --
 drivers/soc/fsl/qbman/qman_test_stash.c |5 +-
 include/soc/fsl/qman.h  |  154 ++
 17 files changed, 3839 insertions(+), 156 deletions(-)
 create mode 100644 drivers/crypto/caam/caamalg_qi.c
 create mode 100644 drivers/crypto/caam/qi.c
 create mode 100644 drivers/crypto/caam/qi.h
 create mode 100644 drivers/crypto/caam/sg_sw_qm.h

-- 
2.4.4

[RFC 5/7] crypto: caam - avoid double inclusion in desc_constr.h

2017-03-03 Thread Horia Geantă 
Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/desc_constr.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/crypto/caam/desc_constr.h 
b/drivers/crypto/caam/desc_constr.h
index b9c8d98ef826..d8e83ca104e0 100644
--- a/drivers/crypto/caam/desc_constr.h
+++ b/drivers/crypto/caam/desc_constr.h
@@ -4,6 +4,9 @@
  * Copyright 2008-2012 Freescale Semiconductor, Inc.
  */
 
+#ifndef DESC_CONSTR_H
+#define DESC_CONSTR_H
+
 #include "desc.h"
 #include "regs.h"
 
@@ -491,3 +494,5 @@ static inline int desc_inline_query(unsigned int 
sd_base_len,
 
return (rem_bytes >= 0) ? 0 : -1;
 }
+
+#endif /* DESC_CONSTR_H */
-- 
2.4.4

[RFC 7/7] crypto: caam/qi - add ablkcipher and authenc algorithms

2017-03-03 Thread Horia Geantă 
Add support to submit ablkcipher and authenc algorithms
via the QI backend:
-ablkcipher:
cbc({aes,des,des3_ede})
ctr(aes), rfc3686(ctr(aes))
xts(aes)
-authenc:
authenc(hmac(md5),cbc({aes,des,des3_ede}))
authenc(hmac(sha*),cbc({aes,des,des3_ede}))

caam/qi being a new driver, let's wait some time to settle down without
interfering with existing caam/jr driver.
Accordingly, for now all caam/qi algorithms (caamalg_qi module) are
marked to be of lower priority than caam/jr ones (caamalg module).

Signed-off-by: Vakul Garg 
Signed-off-by: Alex Porosanu 
Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/Kconfig|   20 +-
 drivers/crypto/caam/Makefile   |1 +
 drivers/crypto/caam/caamalg.c  |9 +-
 drivers/crypto/caam/caamalg_desc.c |   77 +-
 drivers/crypto/caam/caamalg_desc.h |   15 +-
 drivers/crypto/caam/caamalg_qi.c   | 2387 
 drivers/crypto/caam/sg_sw_qm.h |  107 ++
 7 files changed, 2600 insertions(+), 16 deletions(-)
 create mode 100644 drivers/crypto/caam/caamalg_qi.c
 create mode 100644 drivers/crypto/caam/sg_sw_qm.h

diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index bc0d3569f8d9..e36aeacd7635 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -87,6 +87,23 @@ config CRYPTO_DEV_FSL_CAAM_CRYPTO_API
  To compile this as a module, choose M here: the module
  will be called caamalg.
 
+config CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI
+   tristate "Queue Interface as Crypto API backend"
+   depends on CRYPTO_DEV_FSL_CAAM_JR && FSL_DPAA && NET
+   default y
+   select CRYPTO_AUTHENC
+   select CRYPTO_BLKCIPHER
+   help
+ Selecting this will use CAAM Queue Interface (QI) for sending
+ & receiving crypto jobs to/from CAAM. This gives better performance
+ than job ring interface when the number of cores are more than the
+ number of job rings assigned to the kernel. The number of portals
+ assigned to the kernel should also be more than the number of
+ job rings.
+
+ To compile this as a module, choose M here: the module
+ will be called caamalg_qi.
+
 config CRYPTO_DEV_FSL_CAAM_AHASH_API
tristate "Register hash algorithm implementations with Crypto API"
depends on CRYPTO_DEV_FSL_CAAM_JR
@@ -136,4 +153,5 @@ config CRYPTO_DEV_FSL_CAAM_DEBUG
  information in the CAAM driver.
 
 config CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC
-   def_tristate CRYPTO_DEV_FSL_CAAM_CRYPTO_API
+   def_tristate (CRYPTO_DEV_FSL_CAAM_CRYPTO_API || \
+ CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI)
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 2e60e45c2bf1..9e2e98856b9b 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -8,6 +8,7 @@ endif
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI) += caamalg_qi.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC) += caamalg_desc.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
index 9bc80eb06934..398807d1b77e 100644
--- a/drivers/crypto/caam/caamalg.c
+++ b/drivers/crypto/caam/caamalg.c
@@ -266,8 +266,9 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
 
/* aead_encrypt shared descriptor */
desc = ctx->sh_desc_enc;
-   cnstr_shdsc_aead_encap(desc, >cdata, >adata, ctx->authsize,
-  is_rfc3686, nonce, ctx1_iv_off);
+   cnstr_shdsc_aead_encap(desc, >cdata, >adata, ivsize,
+  ctx->authsize, is_rfc3686, nonce, ctx1_iv_off,
+  false);
dma_sync_single_for_device(jrdev, ctx->sh_desc_enc_dma,
   desc_bytes(desc), DMA_TO_DEVICE);
 
@@ -299,7 +300,7 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
desc = ctx->sh_desc_dec;
cnstr_shdsc_aead_decap(desc, >cdata, >adata, ivsize,
   ctx->authsize, alg->caam.geniv, is_rfc3686,
-  nonce, ctx1_iv_off);
+  nonce, ctx1_iv_off, false);
dma_sync_single_for_device(jrdev, ctx->sh_desc_dec_dma,
   desc_bytes(desc), DMA_TO_DEVICE);
 
@@ -333,7 +334,7 @@ static int aead_set_sh_desc(struct crypto_aead *aead)
desc = ctx->sh_desc_enc;
cnstr_shdsc_aead_givencap(desc, >cdata, >adata, ivsize,
  ctx->authsize, is_rfc3686, nonce,
- ctx1_iv_off);
+ ctx1_iv_off, false);
dma_sync_single_for_device(jrdev,

[RFC 6/7] crypto: caam - add Queue Interface (QI) backend support

2017-03-03 Thread Horia Geantă 
CAAM engine supports two interfaces for crypto job submission:
-job ring interface - already existing caam/jr driver
-Queue Interface (QI) - caam/qi driver added in current patch

QI is present in CAAM engines found on DPAA platforms.
QI gets its I/O (frame descriptors) from QMan (Queue Manager) queues.

This patch adds a platform device for accessing CAAM's queue interface.
The requests are submitted to CAAM using one frame queue per
cryptographic context. Each crypto context has one shared descriptor.
This shared descriptor is attached to frame queue associated with
corresponding driver context using context_a.

The driver hides the mechanics of FQ creation, initialisation from its
applications. Each cryptographic context needs to be associated with
driver context which houses the FQ to be used to transport the job to
CAAM. The driver provides API for:
(a) Context creation
(b) Job submission
(c) Context deletion
(d) Congestion indication - whether path to/from CAAM is congested

The driver supports affining its context to a particular CPU.
This means that any responses from CAAM for the context in question
would arrive at the given CPU. This helps in implementing one CPU
per packet round trip in IPsec application.

The driver processes CAAM responses under NAPI contexts.
NAPI contexts are instantiated only on cores with affined portals since
only cores having their own portal can receive responses from DQRR.

The responses from CAAM for all cryptographic contexts ride on a fixed
set of FQs. We use one response FQ per portal owning core. The response
FQ is configured in each core's and thus portal's dedicated channel.
This gives the flexibility to direct CAAM's responses for a crypto
context on a given core.

Signed-off-by: Vakul Garg 
Signed-off-by: Alex Porosanu 
Signed-off-by: Horia Geantă 
---
 drivers/crypto/caam/Makefile |   4 +
 drivers/crypto/caam/ctrl.c   |  58 ++--
 drivers/crypto/caam/intern.h |  24 ++
 drivers/crypto/caam/qi.c | 805 +++
 drivers/crypto/caam/qi.h | 201 +++
 5 files changed, 1064 insertions(+), 28 deletions(-)
 create mode 100644 drivers/crypto/caam/qi.c
 create mode 100644 drivers/crypto/caam/qi.h

diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 6554742f357e..2e60e45c2bf1 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -16,3 +16,7 @@ obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
 caam-objs := ctrl.o
 caam_jr-objs := jr.o key_gen.o error.o
 caam_pkc-y := caampkc.o pkc_desc.o
+ifneq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI),)
+   ccflags-y += -DCONFIG_CAAM_QI
+   caam-objs += qi.o
+endif
diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 579f8263c479..9f91de315c30 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -18,6 +18,10 @@
 bool caam_little_end;
 EXPORT_SYMBOL(caam_little_end);
 
+#ifdef CONFIG_CAAM_QI
+#include "qi.h"
+#endif
+
 /*
  * i.MX targets tend to have clock control subsystems that can
  * enable/disable clocking to our device.
@@ -311,6 +315,11 @@ static int caam_remove(struct platform_device *pdev)
for (ring = 0; ring < ctrlpriv->total_jobrs; ring++)
of_device_unregister(ctrlpriv->jrpdev[ring]);
 
+#ifdef CONFIG_CAAM_QI
+   if (ctrlpriv->qidev)
+   caam_qi_shutdown(ctrlpriv->qidev);
+#endif
+
/* De-initialize RNG state handles initialized by this driver. */
if (ctrlpriv->rng4_sh_init)
deinstantiate_rng(ctrldev, ctrlpriv->rng4_sh_init);
@@ -401,23 +410,6 @@ int caam_get_era(void)
 }
 EXPORT_SYMBOL(caam_get_era);
 
-#ifdef CONFIG_DEBUG_FS
-static int caam_debugfs_u64_get(void *data, u64 *val)
-{
-   *val = caam64_to_cpu(*(u64 *)data);
-   return 0;
-}
-
-static int caam_debugfs_u32_get(void *data, u64 *val)
-{
-   *val = caam32_to_cpu(*(u32 *)data);
-   return 0;
-}
-
-DEFINE_SIMPLE_ATTRIBUTE(caam_fops_u32_ro, caam_debugfs_u32_get, NULL, 
"%llu\n");
-DEFINE_SIMPLE_ATTRIBUTE(caam_fops_u64_ro, caam_debugfs_u64_get, NULL, 
"%llu\n");
-#endif
-
 /* Probe routine for CAAM top (controller) level */
 static int caam_probe(struct platform_device *pdev)
 {
@@ -615,6 +607,17 @@ static int caam_probe(struct platform_device *pdev)
goto iounmap_ctrl;
}
 
+#ifdef CONFIG_DEBUG_FS
+   /*
+* FIXME: needs better naming distinction, as some amalgamation of
+* "caam" and nprop->full_name. The OF name isn't distinctive,
+* but does separate instances
+*/
+   perfmon = (struct caam_perfmon __force *)>perfmon;
+
+   ctrlpriv->dfs_root = debugfs_create_dir(dev_name(dev), NULL);
+   ctrlpriv->ctl = debugfs_create_dir("ctl", ctrlpriv->dfs_root);
+#endif
ring = 0;
ridx = 0;
ctrlpriv->total_jobrs = 0;
@@ -650,6 +653,13 @@ static int caam_probe(struct

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-03 Thread Nathan Royce 
Yup, when I disabled the s5p driver, xts DID show in the /proc/crypto list.

Heh, I was about to ask if it was something I should push towards
another maintainer for s5p stuff, but found you listed in that as
well.
If I am incorrect in that assumption, do let me know whom else I
should make aware of this issue.
Also let me know if you would like the rest of the kernel panic. Maybe
you already have enough to go on and don't need it.

Thanks for all that clarity.

On Fri, Mar 3, 2017 at 6:04 AM, Herbert Xu  wrote:
> On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote:
>> I do have ECB selected as well:
>> DM_CRYPT=y
>> CRYPTO_ECB=y
>> CRYPTO_XTS=y
>>
>> name : ecb(aes)
>> driver   : ecb-aes-s5p
>> module   : kernel
>> priority : 100
>> refcnt   : 1
>> selftest : passed
>> internal : no
>> type : ablkcipher
>> async: yes
>> blocksize: 16
>> min keysize  : 16
>> max keysize  : 32
>> ivsize   : 0
>> geniv: 
>> //still no "xts" can be found in the list
>
> Weird.  So you can't find any instances of xts in /proc/crypto
> at all? Even if the self-test fails it should still register an
> entry there...
>
> In any case, I think disabling the s5p driver should work at
> least.
>
> 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 v2 19/32] crypto: ccp: Introduce the AMD Secure Processor device

2017-03-03 Thread Andy Shevchenko 
On Thu, 2017-03-02 at 13:11 -0600, Brijesh Singh wrote:
> Hi Mark,
> 
> On 03/02/2017 11:39 AM, Mark Rutland wrote:
> > On Thu, Mar 02, 2017 at 10:16:15AM -0500, Brijesh Singh wrote:

> > > 
> > > +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
> > 
> > It looks like ccp-platform.c has morphed into sp-platform.c (judging
> > by
> > the compatible string and general shape of the code), and the
> > original
> > ccp-platform.c is no longer built.
> > 
> > Shouldn't ccp-platform.c be deleted by this patch?
> > 
> 
> Good catch. Both ccp-platform.c and ccp-pci.c should have been
> deleted 
> by this patch. I missed deleting it, will fix in next rev.

Don't forget to use -M -C when preparing / sending patches.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-03 Thread Herbert Xu 
On Fri, Mar 03, 2017 at 04:36:18AM -0600, Nathan Royce wrote:
> I do have ECB selected as well:
> DM_CRYPT=y
> CRYPTO_ECB=y
> CRYPTO_XTS=y
> 
> name : ecb(aes)
> driver   : ecb-aes-s5p
> module   : kernel
> priority : 100
> refcnt   : 1
> selftest : passed
> internal : no
> type : ablkcipher
> async: yes
> blocksize: 16
> min keysize  : 16
> max keysize  : 32
> ivsize   : 0
> geniv: 
> //still no "xts" can be found in the list

Weird.  So you can't find any instances of xts in /proc/crypto
at all? Even if the self-test fails it should still register an
entry there...

In any case, I think disabling the s5p driver should work at
least.

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

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-03 Thread Nathan Royce 
I do have ECB selected as well:
DM_CRYPT=y
CRYPTO_ECB=y
CRYPTO_XTS=y

name : ecb(aes)
driver   : ecb-aes-s5p
module   : kernel
priority : 100
refcnt   : 1
selftest : passed
internal : no
type : ablkcipher
async: yes
blocksize: 16
min keysize  : 16
max keysize  : 32
ivsize   : 0
geniv: 
//still no "xts" can be found in the list

I saw this about the regression that sounds similar to my issue,
except even when I built-in dm_crypt (no initramfs. just diving
straight into system), it still fails:
http://www.mail-archive.com/linux-crypto@vger.kernel.org/msg23748.html

On Fri, Mar 3, 2017 at 3:33 AM, Herbert Xu  wrote:
> On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote:
>> OK, I went ahead and enabled self tests
>> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
>> albeit with failures:
>> *
>> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
>> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
>> test 1 for xts(ecb-aes-s5p): ret=35
>> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
>> Error allocating crypto tfm
>> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
>> target to table
>> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
>> with key file '/dev/urandom': Invalid argument
>> *
>> (weird that it asked for the passphrase)
>>
>> But I do question whether the root issue is related to s5p... Maybe
>> there is a correlation in the warning, but to me it looks like the
>> issue is something else.
>
> I see.  Do you have ECB enabled in your config? The new XTS requires
> ECB to be present so that could be your problem.
>
> There is already a patch on its way to stable to add the Kconfig
> select on ECB.
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-03 Thread Herbert Xu 
On Fri, Mar 03, 2017 at 03:00:26AM -0600, Nathan Royce wrote:
> OK, I went ahead and enabled self tests
> "CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
> albeit with failures:
> *
> Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
> Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
> test 1 for xts(ecb-aes-s5p): ret=35
> Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
> Error allocating crypto tfm
> Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
> target to table
> Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
> with key file '/dev/urandom': Invalid argument
> *
> (weird that it asked for the passphrase)
> 
> But I do question whether the root issue is related to s5p... Maybe
> there is a correlation in the warning, but to me it looks like the
> issue is something else.

I see.  Do you have ECB enabled in your config? The new XTS requires
ECB to be present so that could be your problem.

There is already a patch on its way to stable to add the Kconfig
select on ECB.

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

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

2017-03-03 Thread Nathan Royce 
OK, I went ahead and enabled self tests
"CRYPTO_MANAGER_DISABLE_TESTS=n", and my system was able to boot,
albeit with failures:
*
Mar 02 23:14:38 server kernel: ---[ end trace 1c8a91f28cbcebf3 ]---
Mar 02 23:14:38 server kernel: alg: skcipher: encryption failed on
test 1 for xts(ecb-aes-s5p): ret=35
Mar 02 23:14:38 server kernel: device-mapper: table: 254:0: crypt:
Error allocating crypto tfm
Mar 02 23:14:38 server kernel: device-mapper: ioctl: error adding
target to table
Mar 02 23:14:39 server systemd-cryptsetup[234]: Failed to activate
with key file '/dev/urandom': Invalid argument
*
(weird that it asked for the passphrase)

But I do question whether the root issue is related to s5p... Maybe
there is a correlation in the warning, but to me it looks like the
issue is something else.
In my OP, I noted that the xts crypto isn't even found in /proc/crypto
in 4.10. I'd think it would at least be listed, even if it isn't used.
CBC is listed in /proc/crypto with kernel 4.9.13 and 4.10.1 (cbc-aes-s5p)
XTS is listed in /proc/crypto with kernel 4.9.13 but NOT 4.10.1

I should also add that I didn't include other tainted messages since
they followed the messages I first posted.
I was assuming that when the first issue would work, the others would
follow suit. I just didn't want to inundate with possible junk.
I still have the log file if you think it would be helpful to post the rest.

PS: I also noticed the bounce from my first mail submission because I
didn't enable plain-text for the e-mail (marked as spam because the
email contained html). I rectified that for this reply.

On Thu, Mar 2, 2017 at 10:02 PM, Herbert Xu  wrote:
> On Thu, Mar 02, 2017 at 05:35:30PM -0600, Nathan Royce wrote:
>> ARM ODroid XU4
>>
>> $ cat /proc/config.gz | gunzip | grep XTS
>> CONFIG_CRYPTO_XTS=y
>>
>> $ grep xts /proc/crypto
>> //4.9.13
>> name : xts(aes)
>> driver   : xts(aes-generic)
>> //4.10.1
>> 
>> //cbc can be found though
>>
>> CRYPTTAB:
>> cryptswap1 UUID= /dev/urandom
>> swap,offset=2048,cipher=aes-xts-plain64:sha512,size=512,nofail
>>
>> FSTAB:
>> /dev/mapper/cryptswap1 none swap sw 0 0
>>
>> Boot Log:
>> [   10.535985] [ cut here ]
>> [   10.539252] WARNING: CPU: 0 PID: 0 at crypto/skcipher.c:430
>> skcipher_walk_first+0x13c/0x14c
>> [   10.547542] Modules linked in: xor xor_neon aes_arm zlib_deflate
>> dm_crypt raid6_pq nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc
>> ip_tables x_tables
>> [   10.561716] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.10.1-dirty #1
>> [   10.568049] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
>> [   10.574171] [] (unwind_backtrace) from []
>> (show_stack+0x10/0x14)
>> [   10.581893] [] (show_stack) from []
>> (dump_stack+0x84/0x98)
>> [   10.589073] [] (dump_stack) from []
>> (__warn+0xe8/0x100)
>> [   10.595975] [] (__warn) from []
>> (warn_slowpath_null+0x20/0x28)
>> [   10.603546] [] (warn_slowpath_null) from []
>> (skcipher_walk_first+0x13c/0x14c)
>> [   10.612390] [] (skcipher_walk_first) from []
>> (skcipher_walk_virt+0x1c/0x38)
>> [   10.621056] [] (skcipher_walk_virt) from []
>> (post_crypt+0x38/0x1c4)
>> [   10.629022] [] (post_crypt) from []
>> (decrypt_done+0x4c/0x54)
>> [   10.636389] [] (decrypt_done) from []
>> (s5p_aes_complete+0x70/0xfc)
>> [   10.644274] [] (s5p_aes_complete) from []
>> (s5p_aes_interrupt+0x134/0x1a0)
>> [   10.652771] [] (s5p_aes_interrupt) from []
>> (__handle_irq_event_percpu+0x9c/0x124)
>
> This looks like a bug in the s5p driver.  It's calling the completion
> function straight from the IRQ handler, which is triggering the
> sanity check in skcipher_walk_first.
>
> The s5p driver needs to schedule a tasklet to call the completion
> function.
>
> Do you have crypto self-test enabled? If so it should've caught
> this at run-time.  Otherwise you can disable the s5p driver until
> it's fixed.
>
> Cheers,
> --
> Email: Herbert Xu 
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt