date:20180109

Hi folks,

With the enormous help of people in the to and CCed lists I've gotten
the ccree driver to a point I believe it is ready to graduate out of
the staging tree:

- The code base has been reduced by something by 30% and is *much*
more  readable and manageable.
- The very few checkpatch warnings are all false positives (one due to
dt bindings going through the crypto tree, the others due to harmless
macro argument reuse)
and the few sparse output are equally benign.
- The driver follows the crypto API expected behavior as much as I can tell.
- Fixed all the bugs I could fine as a result of tcrypt tests.
- It works :-)

There are obviously more things todo, but I believe they are out of
scope for staging.

So, if you see something that still needs work, kindly let me know.
Alternatively, will you accept a patch moving it to drivers/crypto/?

Many 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] hw_random: mediatek: Setup default RNG quality

2018-01-09 Thread sean.wang

From: Sean Wang 

When hw_random device's quality is non-zero, it will automatically fill
the kernel's entropy pool at boot.  For the purpose, one conservative
quality value is being picked up as the default value.

Signed-off-by: Sean Wang 
---
 drivers/char/hw_random/mtk-rng.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/hw_random/mtk-rng.c b/drivers/char/hw_random/mtk-rng.c
index 8da7bcf..7f99cd5 100644
--- a/drivers/char/hw_random/mtk-rng.c
+++ b/drivers/char/hw_random/mtk-rng.c
@@ -135,6 +135,7 @@ static int mtk_rng_probe(struct platform_device *pdev)
 #endif
priv->rng.read = mtk_rng_read;
priv->rng.priv = (unsigned long)>dev;
+   priv->rng.quality = 900;
 
priv->clk = devm_clk_get(>dev, "rng");
if (IS_ERR(priv->clk)) {
-- 
2.7.4

[PATCH V8 1/5] crypto: Multi-buffer encryption infrastructure support

In this patch, the infrastructure needed to support multibuffer
encryption implementation is added:

a) Enhance mcryptd daemon to support skcipher requests.

b) Add multi-buffer mcryptd skcipher helper which presents the
   top-level algorithm as an skcipher.

b) Update configuration to include multi-buffer encryption build
support.

For an introduction to the multi-buffer implementation, please see
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 crypto/Kconfig   |  15 ++
 crypto/mcryptd.c | 475 +++
 include/crypto/mcryptd.h |  56 ++
 3 files changed, 546 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 9327fbf..66bd682 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1021,6 +1021,21 @@ config CRYPTO_AES_NI_INTEL
  ECB, CBC, LRW, PCBC, XTS. The 64 bit version has additional
  acceleration for CTR.
 
+config CRYPTO_AES_CBC_MB
+tristate "AES CBC algorithm (x86_64 Multi-Buffer, Experimental)"
+depends on X86 && 64BIT
+select CRYPTO_SIMD
+select CRYPTO_MCRYPTD
+help
+  AES CBC encryption implemented using multi-buffer technique.
+  This algorithm computes on multiple data lanes concurrently with
+  SIMD instructions for better throughput. It should only be used
+  when we expect many concurrent crypto requests to keep all the
+  data lanes filled to realize the performance benefit. If the data
+  lanes are unfilled, a flush operation will be initiated after some
+  delay to process the exisiting crypto jobs, adding some extra
+  latency to low load case.
+
 config CRYPTO_AES_SPARC64
tristate "AES cipher algorithms (SPARC64)"
depends on SPARC64
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index 2908382..ce502e2 100644
--- a/crypto/mcryptd.c
+++ b/crypto/mcryptd.c
@@ -269,6 +269,443 @@ static inline bool mcryptd_check_internal(struct rtattr 
**tb, u32 *type,
return false;
 }
 
+static int mcryptd_enqueue_skcipher_request(struct mcryptd_queue *queue,
+   struct crypto_async_request *request,
+   struct mcryptd_skcipher_request_ctx *rctx)
+{
+   int cpu, err;
+   struct mcryptd_cpu_queue *cpu_queue;
+
+   cpu = get_cpu();
+   cpu_queue = this_cpu_ptr(queue->cpu_queue);
+   rctx->tag.cpu = cpu;
+
+   err = crypto_enqueue_request(_queue->queue, request);
+   pr_debug("enqueue request: cpu %d cpu_queue %p request %p\n",
+   cpu, cpu_queue, request);
+   queue_work_on(cpu, kcrypto_wq, _queue->work);
+   put_cpu();
+
+   return err;
+}
+
+static int mcryptd_skcipher_setkey(struct crypto_skcipher *parent,
+   const u8 *key, unsigned int keylen)
+{
+   struct mcryptd_skcipher_ctx *ctx = crypto_skcipher_ctx(parent);
+   struct crypto_skcipher *child = ctx->child;
+   int err;
+
+   crypto_skcipher_clear_flags(child, CRYPTO_TFM_REQ_MASK);
+   crypto_skcipher_set_flags(child, crypto_skcipher_get_flags(parent) &
+   CRYPTO_TFM_REQ_MASK);
+   err = crypto_skcipher_setkey(child, key, keylen);
+   crypto_skcipher_set_flags(parent, crypto_skcipher_get_flags(child) &
+   CRYPTO_TFM_RES_MASK);
+   return err;
+}
+
+static void mcryptd_skcipher_complete(struct skcipher_request *req, int err)
+{
+   struct mcryptd_skcipher_request_ctx *rctx = skcipher_request_ctx(req);
+
+   local_bh_disable();
+   rctx->complete(>base, err);
+   local_bh_enable();
+}
+
+static void mcryptd_skcipher_encrypt(struct crypto_async_request *base,
+   int err)
+{
+   struct skcipher_request *req = skcipher_request_cast(base);
+   struct mcryptd_skcipher_request_ctx *rctx = skcipher_request_ctx(req);
+   struct crypto_skcipher *tfm = crypto_skcipher_reqtfm(req);
+   struct mcryptd_skcipher_ctx *ctx = crypto_skcipher_ctx(tfm);
+   struct crypto_skcipher *child = ctx->child;
+   struct skcipher_request subreq;
+
+   if (unlikely(err == -EINPROGRESS))
+   goto out;
+
+   /* set up the skcipher request to work on */
+   skcipher_request_set_tfm(, child);
+   skcipher_request_set_callback(,
+   CRYPTO_TFM_REQ_MAY_SLEEP, 0, 0);
+   skcipher_request_set_crypt(, req->src, req->dst,
+   req->cryptlen, req->iv);
+
+   /*
+* pass addr of descriptor stored in the request context
+* so that the callee can get to the request context
+*/
+

[PATCH V8 4/5] crypto: AES CBC by8 encryption

This patch introduces the assembly routine to do a by8 AES CBC
encryption in support of the AES CBC multi-buffer implementation.

It encrypts 8 data streams of the same key size simultaneously.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S | 775 
 1 file changed, 775 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S

diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S 
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
new file mode 100644
index 000..2130574
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
@@ -0,0 +1,775 @@
+/*
+ * AES CBC by8 multibuffer optimization (x86_64)
+ * This file implements 128/192/256 bit AES CBC encryption
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+ * James Guilford 
+ * Sean Gulley 
+ * Tim Chen 
+ * Megha Dey 
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+#include 
+
+/* stack size needs to be an odd multiple of 8 for alignment */
+
+#define AES_KEYSIZE_12816
+#define AES_KEYSIZE_19224
+#define AES_KEYSIZE_25632
+
+#define XMM_SAVE_SIZE  16*10
+#define GPR_SAVE_SIZE  8*9
+#define STACK_SIZE (XMM_SAVE_SIZE + GPR_SAVE_SIZE)
+
+#define GPR_SAVE_REG   %rsp
+#define GPR_SAVE_AREA  %rsp + XMM_SAVE_SIZE
+#define LEN_AREA_OFFSETXMM_SAVE_SIZE + 8*8
+#define LEN_AREA_REG   %rsp
+#define LEN_AREA   %rsp + XMM_SAVE_SIZE + 8*8
+
+#define IN_OFFSET  0
+#define OUT_OFFSET 8*8
+#define KEYS_OFFSET16*8
+#define IV_OFFSET  24*8
+
+
+#define IDX%rax
+#define TMP%rbx
+#define ARG%rdi
+#define LEN%rsi
+
+#define KEYS0  %r14
+#define KEYS1  %r15
+#define KEYS2  %rbp
+#define KEYS3  %rdx
+#define KEYS4  %rcx
+#define KEYS5  %r8
+#define KEYS6  %r9
+#define KEYS7  %r10
+
+#define IN0%r11
+#define IN2%r12
+#define IN4%r13
+#define IN6LEN
+
+#define XDATA0 %xmm0
+#define XDATA1 %xmm1
+#define XDATA2 %xmm2
+#define XDATA3 %xmm3
+#define XDATA4 %xmm4
+#define XDATA5 %xmm5
+#define XDATA6 %xmm6
+#define XDATA7 %xmm7
+
+#define XKEY0_3%xmm8
+#define XKEY1_4%xmm9
+#define XKEY2_5%xmm10
+#define XKEY3_6%xmm11
+#define XKEY4_7%xmm12
+#define XKEY5_8%xmm13
+#define XKEY6_9%xmm14
+#define XTMP   %xmm15
+
+#defineMOVDQ movdqu /* assume buffers not aligned */
+#define CONCAT(a, b)   a##b
+#define INPUT_REG_SUFX 1   /* IN */
+#define XDATA_REG_SUFX 2   /* XDAT */
+#define KEY_REG_SUFX   3   /* KEY */
+#define XMM_REG_SUFX   4   /* XMM */
+

[PATCH V8 5/5] crypto: AES CBC multi-buffer glue code

This patch introduces the multi-buffer job manager which is responsible
for submitting scatter-gather buffers from several AES CBC jobs
to the multi-buffer algorithm. The glue code interfaces with the
underlying algorithm that handles 8 data streams of AES CBC encryption
in parallel. AES key expansion and CBC decryption requests are performed
in a manner similar to the existing AESNI Intel glue driver.

The outline of the algorithm for AES CBC encryption requests is
sketched below:

Any driver requesting the crypto service will place an async crypto
request on the workqueue.  The multi-buffer crypto daemon will pull an
AES CBC encryption request from work queue and put each request in an
empty data lane for multi-buffer crypto computation.  When all the empty
lanes are filled, computation will commence on the jobs in parallel and
the job with the shortest remaining buffer will get completed and be
returned. To prevent prolonged stall, when no new jobs arrive, we will
flush workqueue of jobs after a maximum allowable delay has elapsed.

To accommodate the fragmented nature of scatter-gather, we will keep
submitting the next scatter-buffer fragment for a job for multi-buffer
computation until a job is completed and no more buffer fragments
remain. At that time we will pull a new job to fill the now empty data
slot. We check with the multibuffer scheduler to see if there are other
completed jobs to prevent extraneous delay in returning any completed
jobs.

This multi-buffer algorithm should be used for cases where we get at
least 8 streams of crypto jobs submitted at a reasonably high rate.
For low crypto job submission rate and low number of data streams, this
algorithm will not be beneficial. The reason is at low rate, we do not
fill out the data lanes before flushing the jobs instead of processing
them with all the data lanes full. We will miss the benefit of parallel
computation, and adding delay to the processing of the crypto job at the
same time.  Some tuning of the maximum latency parameter may be needed
to get the best performance.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/Makefile|   1 +
 arch/x86/crypto/aes-cbc-mb/Makefile |  22 +
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c | 698 
 3 files changed, 721 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c

diff --git a/arch/x86/crypto/Makefile b/arch/x86/crypto/Makefile
index 5f07333..3844f06 100644
--- a/arch/x86/crypto/Makefile
+++ b/arch/x86/crypto/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_CRYPTO_CRC32_PCLMUL) += crc32-pclmul.o
 obj-$(CONFIG_CRYPTO_SHA256_SSSE3) += sha256-ssse3.o
 obj-$(CONFIG_CRYPTO_SHA512_SSSE3) += sha512-ssse3.o
 obj-$(CONFIG_CRYPTO_CRCT10DIF_PCLMUL) += crct10dif-pclmul.o
+obj-$(CONFIG_CRYPTO_AES_CBC_MB) += aes-cbc-mb/
 obj-$(CONFIG_CRYPTO_POLY1305_X86_64) += poly1305-x86_64.o
 
 # These modules require assembler to support AVX.
diff --git a/arch/x86/crypto/aes-cbc-mb/Makefile 
b/arch/x86/crypto/aes-cbc-mb/Makefile
new file mode 100644
index 000..b642bd8
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/Makefile
@@ -0,0 +1,22 @@
+#
+# Arch-specific CryptoAPI modules.
+#
+
+avx_supported := $(call as-instr,vpxor %xmm0$(comma)%xmm0$(comma)%xmm0,yes,no)
+
+# we need decryption and key expansion routine symbols
+# if either AESNI_NI_INTEL or AES_CBC_MB is a module
+
+ifeq ($(CONFIG_CRYPTO_AES_NI_INTEL),m)
+   dec_support := ../aesni-intel_asm.o
+endif
+ifeq ($(CONFIG_CRYPTO_AES_CBC_MB),m)
+   dec_support := ../aesni-intel_asm.o
+endif
+
+ifeq ($(avx_supported),yes)
+   obj-$(CONFIG_CRYPTO_AES_CBC_MB) += aes-cbc-mb.o
+   aes-cbc-mb-y := $(dec_support) aes_cbc_mb.o aes_mb_mgr_init.o \
+   mb_mgr_inorder_x8_asm.o mb_mgr_ooo_x8_asm.o \
+   aes_cbc_enc_x8.o
+endif
diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c 
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
new file mode 100644
index 000..af09c4b
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
@@ -0,0 +1,698 @@
+/*
+ * Multi buffer AES CBC algorithm glue code
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+

[PATCH V8 3/5] crypto: AES CBC multi-buffer scheduler

This patch implements in-order scheduler for encrypting multiple buffers
in parallel supporting AES CBC encryption with key sizes of
128, 192 and 256 bits. It uses 8 data lanes by taking advantage of the
SIMD instructions with XMM registers.

The multibuffer manager and scheduler is mostly written in assembly and
the initialization support is written C. The AES CBC multibuffer crypto
driver support interfaces with the multibuffer manager and scheduler
to support AES CBC encryption in parallel. The scheduler supports
job submissions, job flushing and and job retrievals after completion.

The basic flow of usage of the CBC multibuffer scheduler is as follows:

- The caller allocates an aes_cbc_mb_mgr_inorder_x8 object
and initializes it once by calling aes_cbc_init_mb_mgr_inorder_x8().

- The aes_cbc_mb_mgr_inorder_x8 structure has an array of JOB_AES
objects. Allocation and scheduling of JOB_AES objects are managed
by the multibuffer scheduler support routines. The caller allocates
a JOB_AES using aes_cbc_get_next_job_inorder_x8().

- The returned JOB_AES must be filled in with parameters for CBC
encryption (eg: plaintext buffer, ciphertext buffer, key, iv, etc) and
submitted to the manager object using aes_cbc_submit_job_inorder_xx().

- If the oldest JOB_AES is completed during a call to
aes_cbc_submit_job_inorder_x8(), it is returned. Otherwise,
NULL is returned.

- A call to aes_cbc_flush_job_inorder_x8() always returns the
oldest job, unless the multibuffer manager is empty of jobs.

- A call to aes_cbc_get_completed_job_inorder_x8() returns
a completed job. This routine is useful to process completed
jobs instead of waiting for the flusher to engage.

- When a job is returned from submit or flush, the caller extracts
the useful data and returns it to the multibuffer manager implicitly
by the next call to aes_cbc_get_next_job_xx().

Jobs are always returned from submit or flush routines in the order they
were submitted (hence "inorder").A job allocated using
aes_cbc_get_next_job_inorder_x8() must be filled in and submitted before
another call. A job returned by aes_cbc_submit_job_inorder_x8() or
aes_cbc_flush_job_inorder_x8() is 'deallocated' upon the next call to
get a job structure. Calls to get_next_job() cannot fail. If all jobs
are allocated after a call to get_next_job(), the subsequent call to submit
always returns the oldest job in a completed state.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c   | 146 
 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 223 +++
 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 417 +
 3 files changed, 786 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S

diff --git a/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c 
b/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
new file mode 100644
index 000..2a2ce6c
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
@@ -0,0 +1,146 @@
+/*
+ * Initialization code for multi buffer AES CBC algorithm
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+ * James Guilford 
+ * Sean Gulley 
+ * Tim Chen 
+ * Megha Dey 
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS

[PATCH V8 2/5] crypto: AES CBC multi-buffer data structures

This patch introduces the data structures and prototypes of functions
needed for doing AES CBC encryption using multi-buffer. Included are
the structures of the multi-buffer AES CBC job, job scheduler in C and
data structure defines in x86 assembly code.

Originally-by: Chandramouli Narayanan 
Signed-off-by: Megha Dey 
Acked-by: Tim Chen 
---
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h|  97 +
 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132 
 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 271 +
 arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 126 
 4 files changed, 626 insertions(+)
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
 create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
 create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
 create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S

diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h 
b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
new file mode 100644
index 000..024586b
--- /dev/null
+++ b/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
@@ -0,0 +1,97 @@
+/*
+ * Header file for multi buffer AES CBC algorithm manager
+ * that deals with 8 buffers at a time
+ *
+ *
+ * This file is provided under a dual BSD/GPLv2 license.  When using or
+ * redistributing this file, you may do so under either license.
+ *
+ * GPL LICENSE SUMMARY
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * Contact Information:
+ * James Guilford 
+ * Sean Gulley 
+ * Tim Chen 
+ * Megha Dey 
+ *
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Intel Corporation.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * Neither the name of Intel Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ */
+#ifndef __AES_CBC_MB_CTX_H
+#define __AES_CBC_MB_CTX_H
+
+
+#include 
+
+#include "aes_cbc_mb_mgr.h"
+
+#define CBC_ENCRYPT0x01
+#define CBC_DECRYPT0x02
+#define CBC_START  0x04
+#define CBC_DONE   0x08
+
+#define CBC_CTX_STS_IDLE   0x00
+#define CBC_CTX_STS_PROCESSING 0x01
+#define CBC_CTX_STS_LAST   0x02
+#define CBC_CTX_STS_COMPLETE   0x04
+
+enum cbc_ctx_error {
+   CBC_CTX_ERROR_NONE   =  0,
+   CBC_CTX_ERROR_INVALID_FLAGS  = -1,
+   CBC_CTX_ERROR_ALREADY_PROCESSING = -2,
+   CBC_CTX_ERROR_ALREADY_COMPLETED  = -3,
+};
+
+#define cbc_ctx_init(ctx, n_bytes, op) \
+   do { \
+   (ctx)->flag = (op) | CBC_START; \
+   (ctx)->nbytes = (n_bytes); \
+   } while (0)
+
+/* AESNI routines to perform cbc decrypt and key expansion */
+
+asmlinkage void aesni_cbc_dec(struct crypto_aes_ctx *ctx, u8 *out,
+ const u8 *in, unsigned int len, u8 *iv);
+asmlinkage int aesni_set_key(struct crypto_aes_ctx *ctx, const u8 *in_key,
+unsigned int key_len);
+
+#endif /* __AES_CBC_MB_CTX_H */
diff --git a/arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h

[PATCH V8 0/5] crypto: AES CBC multibuffer implementation

In this patch series, we introduce AES CBC encryption that is parallelized
on x86_64 cpu with XMM registers. The multi-buffer technique encrypt 8
data streams in parallel with SIMD instructions. Decryption is handled as
in the existing AESNI Intel CBC implementation which can already
parallelize decryption even for a single data stream.

Please see the multi-buffer whitepaper for details of the technique:
http://www.intel.com/content/www/us/en/communications/communications-ia-multi-buffer-paper.html

It is important that any driver uses this algorithm properly for scenarios
where we have many data streams that can fill up the data lanes most of the
time. It shouldn't be used when only a single data stream is expected
mostly. Otherwise, we may incur extra delays when we have frequent gaps in
data lanes, causing us to wait till data come in to fill the data lanes
before initiating encryption. We may have to wait for flush operations to
commence when no new data come in after some wait time. However, we keep
this extra delay to a minimum by opportunistically flushing the unfinished
jobs if crypto daemon is the only active task running on a cpu.

By using this technique, we saw a throughput increase of up to 5.7x under
optimal conditions when we have fully loaded encryption jobs filling up all
the data lanes.

Change Log:
v8
1. Remove the notify_callback construct
2. Remove remaining irq_disabled check
3. Remove related tcrypt test as it is already merged

v7
1. Add the CRYPTO_ALG_ASYNC flag to the internal algorithm
2. Remove the irq_disabled check

v6
1. Move away from the compat naming scheme and update the names of the inner
and outer algorithm
2. Move wrapper code around synchronous internal algorithm from simd.c
to mcryptd.c

v5
1. Use an async implementation of the inner algorithm instead of sync and use
the latest skcipher interface instead of the older blkcipher interface.
(we have picked up this work after a while)

v4
1. Make the decrypt path also use ablkcpher walk.
http://lkml.iu.edu/hypermail/linux/kernel/1512.0/01807.html

v3
1. Use ablkcipher_walk helpers to walk the scatter gather list
and eliminated needs to modify blkcipher_walk for multibuffer cipher

v2
1. Update cpu feature check to make sure SSE is supported
2. Fix up unloading of aes-cbc-mb module to properly free memory

Megha Dey (5):
crypto: Multi-buffer encryption infrastructure support
crypto: AES CBC multi-buffer data structures
crypto: AES CBC multi-buffer scheduler
crypto: AES CBC by8 encryption
crypto: AES CBC multi-buffer glue code

arch/x86/crypto/Makefile | 1 +
arch/x86/crypto/aes-cbc-mb/Makefile| 22 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S| 775 +
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c| 698 +++
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h| 97 +++
arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h| 132
arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c | 146
arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S | 271 +++
arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S | 223 ++
arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S | 417 +++
arch/x86/crypto/aes-cbc-mb/reg_sizes.S | 126
crypto/Kconfig | 15 +
crypto/mcryptd.c | 475 +
include/crypto/mcryptd.h | 56 ++
14 files changed, 3454 insertions(+)
create mode 100644 arch/x86/crypto/aes-cbc-mb/Makefile
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_enc_x8.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb.c
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_ctx.h
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_cbc_mb_mgr.h
create mode 100644 arch/x86/crypto/aes-cbc-mb/aes_mb_mgr_init.c
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_datastruct.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_inorder_x8_asm.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/mb_mgr_ooo_x8_asm.S
create mode 100644 arch/x86/crypto/aes-cbc-mb/reg_sizes.S

--
1.9.1

Re: [PATCH V7 5/7] crypto: AES CBC multi-buffer glue code

On Thu, 2017-08-03 at 13:27 +0800, Herbert Xu wrote:
> On Tue, Jul 25, 2017 at 07:09:58PM -0700, Megha Dey wrote:
> >
> > +/* notify the caller of progress ; request still stays in queue */
> > +
> > +static void notify_callback(struct mcryptd_skcipher_request_ctx *rctx,
> > +   struct mcryptd_alg_cstate *cstate,
> > +   int err)
> > +{
> > +   struct skcipher_request *req = cast_mcryptd_ctx_to_req(rctx);
> > +
> > +   local_bh_disable();
> > +   rctx->complete(>base, err);
> > +   local_bh_enable();
> > +}
> 
> Please explain why you have this crazy construct that does async
> operations behind the crypto API's back while pretending to be sync
> by always returning zero?
> 
> Why is this even needed now that you have switched the underlying
> implementation to be async?

Hi Herbert,

In the next version, I have removed this construct. After giving it some
thought, I realise this is actually incorrect. Hopefully now, both the
outer and inner algorithm are async. 
> 
> > +   /* from mcryptd, we need to callback */
> > +   if (irqs_disabled())
> > +   rctx->complete(>base, err);
> > +   else {
> > +   local_bh_disable();
> > +   rctx->complete(>base, err);
> > +   local_bh_enable();
> > +   }
> 
> I complained about this the first time around and yet this crap is
> still there.

Sorry about that, will get rid of the context check in the next version.
> 
> Cheers,

[RFT PATCH] crypto: arm64 - implement SHA-512 using special instructions

2018-01-09 Thread Ard Biesheuvel

Implement the SHA-512 using the new special instructions that have
been introduced as an optional extension in ARMv8.2.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/crypto/Kconfig  |   6 ++
 arch/arm64/crypto/Makefile |   3 +
 arch/arm64/crypto/sha512-ce-core.S | 207 +
 arch/arm64/crypto/sha512-ce-glue.c | 119 +
 4 files changed, 335 insertions(+)
 create mode 100644 arch/arm64/crypto/sha512-ce-core.S
 create mode 100644 arch/arm64/crypto/sha512-ce-glue.c

diff --git a/arch/arm64/crypto/Kconfig b/arch/arm64/crypto/Kconfig
index 70c517aa4501..aad288f4b9de 100644
--- a/arch/arm64/crypto/Kconfig
+++ b/arch/arm64/crypto/Kconfig
@@ -29,6 +29,12 @@ config CRYPTO_SHA2_ARM64_CE
select CRYPTO_HASH
select CRYPTO_SHA256_ARM64
 
+config CRYPTO_SHA512_ARM64_CE
+   tristate "SHA-384/SHA-512 digest algorithm (ARMv8 Crypto Extensions)"
+   depends on KERNEL_MODE_NEON
+   select CRYPTO_HASH
+   select CRYPTO_SHA512_ARM64
+
 config CRYPTO_GHASH_ARM64_CE
tristate "GHASH/AES-GCM using ARMv8 Crypto Extensions"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm64/crypto/Makefile b/arch/arm64/crypto/Makefile
index b5edc5918c28..d7573d31d397 100644
--- a/arch/arm64/crypto/Makefile
+++ b/arch/arm64/crypto/Makefile
@@ -14,6 +14,9 @@ sha1-ce-y := sha1-ce-glue.o sha1-ce-core.o
 obj-$(CONFIG_CRYPTO_SHA2_ARM64_CE) += sha2-ce.o
 sha2-ce-y := sha2-ce-glue.o sha2-ce-core.o
 
+obj-$(CONFIG_CRYPTO_SHA512_ARM64_CE) += sha512-ce.o
+sha512-ce-y := sha512-ce-glue.o sha512-ce-core.o
+
 obj-$(CONFIG_CRYPTO_GHASH_ARM64_CE) += ghash-ce.o
 ghash-ce-y := ghash-ce-glue.o ghash-ce-core.o
 
diff --git a/arch/arm64/crypto/sha512-ce-core.S 
b/arch/arm64/crypto/sha512-ce-core.S
new file mode 100644
index ..6c562f8df0b0
--- /dev/null
+++ b/arch/arm64/crypto/sha512-ce-core.S
@@ -0,0 +1,207 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * sha512-ce-core.S - core SHA-384/SHA-512 transform using v8 Crypto Extensions
+ *
+ * Copyright (C) 2018 Linaro Ltd 
+ *
+ * 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 
+
+   //
+   // Temporary - for testing only. binutils has no support for these yet
+   //
+   .irp
b,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31
+   .set.Lq\b, \b
+   .set.Lv\b\().2d, \b
+   .endr
+
+   .macro  sha512h, rd, rn, rm
+   .inst   0xce608000 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
+   .endm
+
+   .macro  sha512h2, rd, rn, rm
+   .inst   0xce608400 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
+   .endm
+
+   .macro  sha512su0, rd, rn
+   .inst   0xcec08000 | .L\rd | (.L\rn << 5)
+   .endm
+
+   .macro  sha512su1, rd, rn, rm
+   .inst   0xce608800 | .L\rd | (.L\rn << 5) | (.L\rm << 16)
+   .endm
+
+   .text
+   .arch   armv8-a+crypto
+
+   /*
+* The SHA-512 round constants
+*/
+   .align  4
+.Lsha512_rcon:
+   .quad   0x428a2f98d728ae22, 0x7137449123ef65cd
+   .quad   0xb5c0fbcfec4d3b2f, 0xe9b5dba58189dbbc
+   .quad   0x3956c25bf348b538, 0x59f111f1b605d019
+   .quad   0x923f82a4af194f9b, 0xab1c5ed5da6d8118
+   .quad   0xd807aa98a3030242, 0x12835b0145706fbe
+   .quad   0x243185be4ee4b28c, 0x550c7dc3d5ffb4e2
+   .quad   0x72be5d74f27b896f, 0x80deb1fe3b1696b1
+   .quad   0x9bdc06a725c71235, 0xc19bf174cf692694
+   .quad   0xe49b69c19ef14ad2, 0xefbe4786384f25e3
+   .quad   0x0fc19dc68b8cd5b5, 0x240ca1cc77ac9c65
+   .quad   0x2de92c6f592b0275, 0x4a7484aa6ea6e483
+   .quad   0x5cb0a9dcbd41fbd4, 0x76f988da831153b5
+   .quad   0x983e5152ee66dfab, 0xa831c66d2db43210
+   .quad   0xb00327c898fb213f, 0xbf597fc7beef0ee4
+   .quad   0xc6e00bf33da88fc2, 0xd5a79147930aa725
+   .quad   0x06ca6351e003826f, 0x142929670a0e6e70
+   .quad   0x27b70a8546d22ffc, 0x2e1b21385c26c926
+   .quad   0x4d2c6dfc5ac42aed, 0x53380d139d95b3df
+   .quad   0x650a73548baf63de, 0x766a0abb3c77b2a8
+   .quad   0x81c2c92e47edaee6, 0x92722c851482353b
+   .quad   0xa2bfe8a14cf10364, 0xa81a664bbc423001
+   .quad   0xc24b8b70d0f89791, 0xc76c51a30654be30
+   .quad   0xd192e819d6ef5218, 0xd69906245565a910
+   .quad   0xf40e35855771202a, 0x106aa07032bbd1b8
+   .quad   0x19a4c116b8d2d0c8, 0x1e376c085141ab53
+   .quad   0x2748774cdf8eeb99, 0x34b0bcb5e19b48a8
+   .quad

[PATCH 1/2] crypto: exynos-rng - Add SPDX license identifier and correct module license

2018-01-09 Thread Krzysztof Kozlowski

Replace GPL license statement with SPDX GPL-2.0 license identifier and
correct the module license to GPLv2.

The license itself was a generic GPL because of copy-and-paste from old
drivers/char/hw_random/exynos-rng.c driver (on which this was based on).
However the module license indicated GPL-2.0 or later.  GPL-2.0 was
intended by author so fix up this mess.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/crypto/exynos-rng.c | 12 ++--
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/drivers/crypto/exynos-rng.c b/drivers/crypto/exynos-rng.c
index 451620b475a0..a2e91f94096f 100644
--- a/drivers/crypto/exynos-rng.c
+++ b/drivers/crypto/exynos-rng.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 /*
  * exynos-rng.c - Random Number Generator driver for the Exynos
  *
@@ -6,15 +7,6 @@
  * Loosely based on old driver from drivers/char/hw_random/exynos-rng.c:
  * Copyright (C) 2012 Samsung Electronics
  * Jonghwa Lee 
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation;
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
  */
 
 #include 
@@ -386,4 +378,4 @@ module_platform_driver(exynos_rng_driver);
 
 MODULE_DESCRIPTION("Exynos H/W Random Number Generator driver");
 MODULE_AUTHOR("Krzysztof Kozlowski ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
-- 
2.11.0

[PATCH 2/2] crypto: s5p-sss - Add SPDX license identifier

2018-01-09 Thread Krzysztof Kozlowski

Replace GPL license statement with SPDX GPL-2.0 license identifier.

Signed-off-by: Krzysztof Kozlowski 
---
 drivers/crypto/s5p-sss.c | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/drivers/crypto/s5p-sss.c b/drivers/crypto/s5p-sss.c
index 62830a43d959..188f44b7eb27 100644
--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -1,17 +1,13 @@
-/*
- * Cryptographic API.
- *
- * Support for Samsung S5PV210 and Exynos HW acceleration.
- *
- * Copyright (C) 2011 NetUP Inc. All rights reserved.
- * Copyright (c) 2017 Samsung Electronics Co., Ltd. All rights reserved.
- *
- * 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.
- *
- * Hash part based on omap-sham.c driver.
- */
+// SPDX-License-Identifier: GPL-2.0
+//
+// Cryptographic API.
+//
+// Support for Samsung S5PV210 and Exynos HW acceleration.
+//
+// Copyright (C) 2011 NetUP Inc. All rights reserved.
+// Copyright (c) 2017 Samsung Electronics Co., Ltd. All rights reserved.
+//
+// Hash part based on omap-sham.c driver.
 
 #include 
 #include 
-- 
2.11.0

[PATCH 2/5] staging: ccree: remove unneeded includes

Remove include files not needed for compilation.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_aead.c|  7 ---
 drivers/staging/ccree/cc_buffer_mgr.c  |  6 --
 drivers/staging/ccree/cc_cipher.c  |  4 
 drivers/staging/ccree/cc_driver.c  | 31 ---
 drivers/staging/ccree/cc_hash.c|  2 --
 drivers/staging/ccree/cc_ivgen.c   |  1 -
 drivers/staging/ccree/cc_pm.c  |  2 --
 drivers/staging/ccree/cc_request_mgr.c |  5 -
 8 files changed, 58 deletions(-)

diff --git a/drivers/staging/ccree/cc_aead.c b/drivers/staging/ccree/cc_aead.c
index da74423..265adff 100644
--- a/drivers/staging/ccree/cc_aead.c
+++ b/drivers/staging/ccree/cc_aead.c
@@ -3,18 +3,11 @@
 
 #include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include "cc_driver.h"
 #include "cc_buffer_mgr.h"
 #include "cc_aead.h"
diff --git a/drivers/staging/ccree/cc_buffer_mgr.c 
b/drivers/staging/ccree/cc_buffer_mgr.c
index 01c786c..14b2eab 100644
--- a/drivers/staging/ccree/cc_buffer_mgr.c
+++ b/drivers/staging/ccree/cc_buffer_mgr.c
@@ -1,17 +1,11 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
-#include 
-#include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
 
 #include "cc_buffer_mgr.h"
 #include "cc_lli_defs.h"
diff --git a/drivers/staging/ccree/cc_cipher.c 
b/drivers/staging/ccree/cc_cipher.c
index eca0578..8afdbc1 100644
--- a/drivers/staging/ccree/cc_cipher.c
+++ b/drivers/staging/ccree/cc_cipher.c
@@ -3,12 +3,8 @@
 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/ccree/cc_driver.c 
b/drivers/staging/ccree/cc_driver.c
index 98d491e..b49bc25 100644
--- a/drivers/staging/ccree/cc_driver.c
+++ b/drivers/staging/ccree/cc_driver.c
@@ -5,43 +5,12 @@
 #include 
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
-#include 
-
-/* cache.h required for L1_CACHE_ALIGN() and cache_line_size() */
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/staging/ccree/cc_hash.c b/drivers/staging/ccree/cc_hash.c
index 7c1645d..86f9ec7 100644
--- a/drivers/staging/ccree/cc_hash.c
+++ b/drivers/staging/ccree/cc_hash.c
@@ -3,10 +3,8 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/staging/ccree/cc_ivgen.c b/drivers/staging/ccree/cc_ivgen.c
index 43f70d4..25a3131 100644
--- a/drivers/staging/ccree/cc_ivgen.c
+++ b/drivers/staging/ccree/cc_ivgen.c
@@ -1,7 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
-#include 
 #include 
 #include "cc_driver.h"
 #include "cc_ivgen.h"
diff --git a/drivers/staging/ccree/cc_pm.c b/drivers/staging/ccree/cc_pm.c
index 1f5da86..c7d6b86 100644
--- a/drivers/staging/ccree/cc_pm.c
+++ b/drivers/staging/ccree/cc_pm.c
@@ -2,9 +2,7 @@
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include "cc_driver.h"
 #include "cc_buffer_mgr.h"
diff --git a/drivers/staging/ccree/cc_request_mgr.c 
b/drivers/staging/ccree/cc_request_mgr.c
index cbcfcc3..8372410 100644
--- a/drivers/staging/ccree/cc_request_mgr.c
+++ b/drivers/staging/ccree/cc_request_mgr.c
@@ -2,11 +2,6 @@
 /* Copyright (C) 2012-2018 ARM Limited or its affiliates. */
 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include "cc_driver.h"
 #include "cc_buffer_mgr.h"
 #include "cc_request_mgr.h"
-- 
2.7.4

[PATCH 1/5] staging: ccree: use a consistent file naming convention

The ccree driver source files were using an inconsistent
naming convention stemming from what the company was called
when they were added.

Move to a single consistent naming convention for better
code readability.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/Makefile   |  6 +++---
 drivers/staging/ccree/{ssi_aead.c => cc_aead.c}  | 12 ++--
 drivers/staging/ccree/{ssi_aead.h => cc_aead.h}  |  2 +-
 .../ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c}  |  8 
 .../ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h}  |  4 ++--
 drivers/staging/ccree/{ssi_cipher.c => cc_cipher.c}  |  8 
 drivers/staging/ccree/{ssi_cipher.h => cc_cipher.h}  |  6 +++---
 drivers/staging/ccree/cc_debugfs.c   |  2 +-
 drivers/staging/ccree/{ssi_driver.c => cc_driver.c}  | 20 ++--
 drivers/staging/ccree/{ssi_driver.h => cc_driver.h}  |  6 +++---
 drivers/staging/ccree/{ssi_fips.c => cc_fips.c}  |  4 ++--
 drivers/staging/ccree/{ssi_fips.h => cc_fips.h}  |  0
 drivers/staging/ccree/{ssi_hash.c => cc_hash.c}  | 10 +-
 drivers/staging/ccree/{ssi_hash.h => cc_hash.h}  |  4 ++--
 drivers/staging/ccree/{dx_host.h => cc_host_regs.h}  |  0
 drivers/staging/ccree/cc_hw_queue_defs.h |  2 +-
 drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c}| 10 +-
 drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h}|  0
 .../ccree/{dx_crys_kernel.h => cc_kernel_regs.h} |  0
 drivers/staging/ccree/{ssi_pm.c => cc_pm.c}  | 14 +++---
 drivers/staging/ccree/{ssi_pm.h => cc_pm.h}  |  4 ++--
 .../ccree/{ssi_request_mgr.c => cc_request_mgr.c}| 10 +-
 .../ccree/{ssi_request_mgr.h => cc_request_mgr.h}|  2 +-
 .../staging/ccree/{ssi_sram_mgr.c => cc_sram_mgr.c}  |  4 ++--
 .../staging/ccree/{ssi_sram_mgr.h => cc_sram_mgr.h}  |  0
 25 files changed, 69 insertions(+), 69 deletions(-)
 rename drivers/staging/ccree/{ssi_aead.c => cc_aead.c} (99%)
 rename drivers/staging/ccree/{ssi_aead.h => cc_aead.h} (99%)
 rename drivers/staging/ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c} (99%)
 rename drivers/staging/ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h} (97%)
 rename drivers/staging/ccree/{ssi_cipher.c => cc_cipher.c} (99%)
 rename drivers/staging/ccree/{ssi_cipher.h => cc_cipher.h} (95%)
 rename drivers/staging/ccree/{ssi_driver.c => cc_driver.c} (98%)
 rename drivers/staging/ccree/{ssi_driver.h => cc_driver.h} (98%)
 rename drivers/staging/ccree/{ssi_fips.c => cc_fips.c} (98%)
 rename drivers/staging/ccree/{ssi_fips.h => cc_fips.h} (100%)
 rename drivers/staging/ccree/{ssi_hash.c => cc_hash.c} (99%)
 rename drivers/staging/ccree/{ssi_hash.h => cc_hash.h} (98%)
 rename drivers/staging/ccree/{dx_host.h => cc_host_regs.h} (100%)
 rename drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c} (98%)
 rename drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h} (100%)
 rename drivers/staging/ccree/{dx_crys_kernel.h => cc_kernel_regs.h} (100%)
 rename drivers/staging/ccree/{ssi_pm.c => cc_pm.c} (93%)
 rename drivers/staging/ccree/{ssi_pm.h => cc_pm.h} (95%)
 rename drivers/staging/ccree/{ssi_request_mgr.c => cc_request_mgr.c} (99%)
 rename drivers/staging/ccree/{ssi_request_mgr.h => cc_request_mgr.h} (98%)
 rename drivers/staging/ccree/{ssi_sram_mgr.c => cc_sram_mgr.c} (98%)
 rename drivers/staging/ccree/{ssi_sram_mgr.h => cc_sram_mgr.h} (100%)

diff --git a/drivers/staging/ccree/Makefile b/drivers/staging/ccree/Makefile
index c107e25..bdc2797 100644
--- a/drivers/staging/ccree/Makefile
+++ b/drivers/staging/ccree/Makefile
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 obj-$(CONFIG_CRYPTO_DEV_CCREE) := ccree.o
-ccree-y := ssi_driver.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
-ccree-$(CONFIG_CRYPTO_FIPS) += ssi_fips.o
+ccree-y := cc_driver.o cc_buffer_mgr.o cc_request_mgr.o cc_cipher.o cc_hash.o 
cc_aead.o cc_ivgen.o cc_sram_mgr.o
+ccree-$(CONFIG_CRYPTO_FIPS) += cc_fips.o
 ccree-$(CONFIG_DEBUG_FS) += cc_debugfs.o
-ccree-$(CONFIG_PM) += ssi_pm.o
+ccree-$(CONFIG_PM) += cc_pm.o
diff --git a/drivers/staging/ccree/ssi_aead.c b/drivers/staging/ccree/cc_aead.c
similarity index 99%
rename from drivers/staging/ccree/ssi_aead.c
rename to drivers/staging/ccree/cc_aead.c
index 6f41a00..da74423 100644
--- a/drivers/staging/ccree/ssi_aead.c
+++ b/drivers/staging/ccree/cc_aead.c
@@ -15,12 +15,12 @@
 #include 
 #include 
 #include 
-#include "ssi_driver.h"
-#include "ssi_buffer_mgr.h"
-#include "ssi_aead.h"
-#include "ssi_request_mgr.h"
-#include "ssi_hash.h"
-#include "ssi_sram_mgr.h"
+#include "cc_driver.h"
+#include "cc_buffer_mgr.h"
+#include "cc_aead.h"
+#include "cc_request_mgr.h"
+#include "cc_hash.h"
+#include "cc_sram_mgr.h"
 
 #define template_aead  template_u.aead
 
diff --git a/drivers/staging/ccree/ssi_aead.h b/drivers/staging/ccree/cc_aead.h
similarity index 99%
rename from drivers/staging/ccree/ssi_aead.h
rename to

[PATCH 3/5] staging: ccree: add missing include

Add the missing include of include file with function declarations.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_debugfs.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/ccree/cc_debugfs.c 
b/drivers/staging/ccree/cc_debugfs.c
index f927a73..08f8db4 100644
--- a/drivers/staging/ccree/cc_debugfs.c
+++ b/drivers/staging/ccree/cc_debugfs.c
@@ -6,6 +6,7 @@
 #include 
 #include "cc_driver.h"
 #include "cc_crypto_ctx.h"
+#include "cc_debugfs.h"
 
 struct cc_debugfs_ctx {
struct dentry *dir;
-- 
2.7.4

Re: [PATCH V4 2/2] ARM: dts: imx7s: add snvs rtc clock

2018-01-09 Thread Dong Aisheng

On Tue, Jan 09, 2018 at 05:52:06PM +0800, Anson Huang wrote:
> Add i.MX7 SNVS RTC clock.
> 
> Signed-off-by: Anson Huang 

Acked-by: Dong Aisheng 

Regards
Dong Aisheng

[PATCH 4/5] staging: ccree: make stub function static inline

The debugfs interface defines stub function if debugfs is not
enabled, which were missing the 'static inline' qualifiers causing
sparse warnings.

Signed-off-by: Gilad Ben-Yossef 
---
 drivers/staging/ccree/cc_debugfs.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/ccree/cc_debugfs.h 
b/drivers/staging/ccree/cc_debugfs.h
index 354ec17..5b5320e 100644
--- a/drivers/staging/ccree/cc_debugfs.h
+++ b/drivers/staging/ccree/cc_debugfs.h
@@ -13,19 +13,19 @@ void cc_debugfs_fini(struct cc_drvdata *drvdata);
 
 #else
 
-int cc_debugfs_global_init(void)
+static inline int cc_debugfs_global_init(void)
 {
return 0;
 }
 
-void cc_debugfs_global_fini(void) {}
+static inline void cc_debugfs_global_fini(void) {}
 
-int cc_debugfs_init(struct cc_drvdata *drvdata)
+static inline int cc_debugfs_init(struct cc_drvdata *drvdata)
 {
return 0;
 }
 
-void cc_debugfs_fini(struct cc_drvdata *drvdata) {}
+static inline void cc_debugfs_fini(struct cc_drvdata *drvdata) {}
 
 #endif
 
-- 
2.7.4

[PATCH 5/5] staging: ccree: dma mask is type u64

The dma mask var was defined as dma_addr_t but should be
u64. This showed as a sparse warning when building for 32 bit.
Fix it by changing type to u64 and drop the cast.

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

diff --git a/drivers/staging/ccree/cc_driver.c 
b/drivers/staging/ccree/cc_driver.c
index b49bc25..6682d9d 100644
--- a/drivers/staging/ccree/cc_driver.c
+++ b/drivers/staging/ccree/cc_driver.c
@@ -156,7 +156,7 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
struct device *dev = _dev->dev;
struct device_node *np = dev->of_node;
u32 signature_val;
-   dma_addr_t dma_mask;
+   u64 dma_mask;
int rc = 0;
 
new_drvdata = devm_kzalloc(dev, sizeof(*new_drvdata), GFP_KERNEL);
@@ -205,7 +205,7 @@ static int init_cc_resources(struct platform_device 
*plat_dev)
if (!plat_dev->dev.dma_mask)
plat_dev->dev.dma_mask = _dev->dev.coherent_dma_mask;
 
-   dma_mask = (dma_addr_t)(DMA_BIT_MASK(DMA_BIT_MASK_LEN));
+   dma_mask = DMA_BIT_MASK(DMA_BIT_MASK_LEN);
while (dma_mask > 0x7fffUL) {
if (dma_supported(_dev->dev, dma_mask)) {
rc = dma_set_coherent_mask(_dev->dev, dma_mask);
-- 
2.7.4

[PATCH 0/5] more cleanups

File name consistency renames, include files diet and address
some sparse warnings.

Gilad Ben-Yossef (5):
  staging: ccree: use a consistent file naming convention
  staging: ccree: remove unneeded includes
  staging: ccree: add missing include
  staging: ccree: make stub function static inline
  staging: ccree: dma mask is type u64

 drivers/staging/ccree/Makefile |  6 +--
 drivers/staging/ccree/{ssi_aead.c => cc_aead.c}| 19 +++-
 drivers/staging/ccree/{ssi_aead.h => cc_aead.h}|  2 +-
 .../ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c}| 14 ++
 .../ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h}|  4 +-
 .../staging/ccree/{ssi_cipher.c => cc_cipher.c}| 12 ++---
 .../staging/ccree/{ssi_cipher.h => cc_cipher.h}|  6 +--
 drivers/staging/ccree/cc_debugfs.c |  3 +-
 drivers/staging/ccree/cc_debugfs.h |  8 ++--
 .../staging/ccree/{ssi_driver.c => cc_driver.c}| 55 +-
 .../staging/ccree/{ssi_driver.h => cc_driver.h}|  6 +--
 drivers/staging/ccree/{ssi_fips.c => cc_fips.c}|  4 +-
 drivers/staging/ccree/{ssi_fips.h => cc_fips.h}|  0
 drivers/staging/ccree/{ssi_hash.c => cc_hash.c}| 12 ++---
 drivers/staging/ccree/{ssi_hash.h => cc_hash.h}|  4 +-
 .../staging/ccree/{dx_host.h => cc_host_regs.h}|  0
 drivers/staging/ccree/cc_hw_queue_defs.h   |  2 +-
 drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c}  | 11 ++---
 drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h}  |  0
 .../ccree/{dx_crys_kernel.h => cc_kernel_regs.h}   |  0
 drivers/staging/ccree/{ssi_pm.c => cc_pm.c}| 16 +++
 drivers/staging/ccree/{ssi_pm.h => cc_pm.h}|  4 +-
 .../ccree/{ssi_request_mgr.c => cc_request_mgr.c}  | 15 ++
 .../ccree/{ssi_request_mgr.h => cc_request_mgr.h}  |  2 +-
 .../ccree/{ssi_sram_mgr.c => cc_sram_mgr.c}|  4 +-
 .../ccree/{ssi_sram_mgr.h => cc_sram_mgr.h}|  0
 26 files changed, 76 insertions(+), 133 deletions(-)
 rename drivers/staging/ccree/{ssi_aead.c => cc_aead.c} (99%)
 rename drivers/staging/ccree/{ssi_aead.h => cc_aead.h} (99%)
 rename drivers/staging/ccree/{ssi_buffer_mgr.c => cc_buffer_mgr.c} (99%)
 rename drivers/staging/ccree/{ssi_buffer_mgr.h => cc_buffer_mgr.h} (97%)
 rename drivers/staging/ccree/{ssi_cipher.c => cc_cipher.c} (99%)
 rename drivers/staging/ccree/{ssi_cipher.h => cc_cipher.h} (95%)
 rename drivers/staging/ccree/{ssi_driver.c => cc_driver.c} (90%)
 rename drivers/staging/ccree/{ssi_driver.h => cc_driver.h} (98%)
 rename drivers/staging/ccree/{ssi_fips.c => cc_fips.c} (98%)
 rename drivers/staging/ccree/{ssi_fips.h => cc_fips.h} (100%)
 rename drivers/staging/ccree/{ssi_hash.c => cc_hash.c} (99%)
 rename drivers/staging/ccree/{ssi_hash.h => cc_hash.h} (98%)
 rename drivers/staging/ccree/{dx_host.h => cc_host_regs.h} (100%)
 rename drivers/staging/ccree/{ssi_ivgen.c => cc_ivgen.c} (97%)
 rename drivers/staging/ccree/{ssi_ivgen.h => cc_ivgen.h} (100%)
 rename drivers/staging/ccree/{dx_crys_kernel.h => cc_kernel_regs.h} (100%)
 rename drivers/staging/ccree/{ssi_pm.c => cc_pm.c} (91%)
 rename drivers/staging/ccree/{ssi_pm.h => cc_pm.h} (95%)
 rename drivers/staging/ccree/{ssi_request_mgr.c => cc_request_mgr.c} (98%)
 rename drivers/staging/ccree/{ssi_request_mgr.h => cc_request_mgr.h} (98%)
 rename drivers/staging/ccree/{ssi_sram_mgr.c => cc_sram_mgr.c} (98%)
 rename drivers/staging/ccree/{ssi_sram_mgr.h => cc_sram_mgr.h} (100%)

-- 
2.7.4

[PATCH V4 1/2] clk: imx: imx7d: add the snvs clock

According to the i.MX7D Reference Manual,
SNVS block has a clock gate, accessing SNVS block
would need this clock gate to be enabled, add it
into clock tree so that SNVS module driver can
operate this clock gate.

Signed-off-by: Anson Huang 
Acked-by: Dong Aisheng 
Reviewed-by: Fabio Estevam 
---
 drivers/clk/imx/clk-imx7d.c | 1 +
 include/dt-bindings/clock/imx7d-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..f34f1ec 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -795,6 +795,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = 
imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 
0x4130, 0);
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", 
"dram_alt_post_div", base + 0x4130, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base 
+ 0x4230, 0);
+   clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 
0x4250, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", 
"usb_hsic_post_div", base + 0x4420, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", 
"ahb_root_clk", base + 0x4480, 0);
clks[IMX7D_PCIE_CTRL_ROOT_CLK] = imx_clk_gate4("pcie_ctrl_root_clk", 
"pcie_ctrl_post_div", base + 0x4600, 0);
diff --git a/include/dt-bindings/clock/imx7d-clock.h 
b/include/dt-bindings/clock/imx7d-clock.h
index e2f99ae..dc51904 100644
--- a/include/dt-bindings/clock/imx7d-clock.h
+++ b/include/dt-bindings/clock/imx7d-clock.h
@@ -452,5 +452,6 @@
 #define IMX7D_OCOTP_CLK439
 #define IMX7D_NAND_RAWNAND_CLK 440
 #define IMX7D_NAND_USDHC_BUS_RAWNAND_CLK 441
-#define IMX7D_CLK_END  442
+#define IMX7D_SNVS_CLK 442
+#define IMX7D_CLK_END  443
 #endif /* __DT_BINDINGS_CLOCK_IMX7D_H */
-- 
1.9.1

RE: [PATCH V3 1/2] clk: imx: imx7d: add the snvs clock



Best Regards!
Anson Huang


> -Original Message-
> From: Dong Aisheng [mailto:donga...@gmail.com]
> Sent: 2018-01-09 5:44 PM
> To: Anson Huang 
> Cc: Horia Geantă ; Aymen Sghaier
> ; herb...@gondor.apana.org.au;
> da...@davemloft.net; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ; li...@armlinux.org.uk;
> mturque...@baylibre.com; sb...@codeaurora.org; Adriana Reus
> ; ste...@agner.ch; linux-crypto@vger.kernel.org;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org; dl-linux-imx  i...@nxp.com>
> Subject: Re: [PATCH V3 1/2] clk: imx: imx7d: add the snvs clock
> 
> On Tue, Jan 09, 2018 at 05:20:50PM +0800, Anson Huang wrote:
> > According to the i.MX7D Reference Manual, SNVS block has a clock gate,
> > accessing SNVS block would need this clock gate to be enabled, add it
> > into clock tree so that SNVS module driver can operate this clock
> > gate.
> >
> > Signed-off-by: Anson Huang 
> 
> You missed the last round review tags.
> 
> Regards
> Dong Aisheng


Thanks for reminder, already sent out a V4 patch set to add tags.

Anson.

[PATCH V4 2/2] ARM: dts: imx7s: add snvs rtc clock

Add i.MX7 SNVS RTC clock.

Signed-off-by: Anson Huang 
---
change since v3:
add optional for clocks in binding doc statement.
 Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 17 +
 arch/arm/boot/dts/imx7s.dtsi  |  2 ++
 2 files changed, 19 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt 
b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index 76aec8a..3c1f3a2 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -415,12 +415,27 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
value type: 
Definition: LP register offset. default it is 0x34.
 
+   - clocks
+  Usage: optional, required if SNVS LP RTC requires explicit
+  enablement of clocks
+  Value type: 
+  Definition:  a clock specifier describing the clock required for
+  enabling and disabling SNVS LP RTC.
+
+   - clock-names
+  Usage: optional, required if SNVS LP RTC requires explicit
+  enablement of clocks
+  Value type: 
+  Definition: clock name string should be "snvs-rtc".
+
 EXAMPLE
sec_mon_rtc_lp@1 {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
interrupts = <93 2>;
regmap = <>;
offset = <0x34>;
+   clocks = < IMX7D_SNVS_CLK>;
+   clock-names = "snvs-rtc";
};
 
 =
@@ -543,6 +558,8 @@ FULL EXAMPLE
regmap = <_mon>;
offset = <0x34>;
interrupts = <93 2>;
+   clocks = < IMX7D_SNVS_CLK>;
+   clock-names = "snvs-rtc";
};
 
snvs-pwrkey@020cc000 {
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 9aa2bb9..02baf42 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -551,6 +551,8 @@
offset = <0x34>;
interrupts = ,
 ;
+   clocks = < IMX7D_SNVS_CLK>;
+   clock-names = "snvs-rtc";
};
 
snvs_poweroff: snvs-poweroff {
-- 
1.9.1

RE: [PATCH V3 2/2] ARM: dts: imx7s: add snvs rtc clock



Best Regards!
Anson Huang


> -Original Message-
> From: Dong Aisheng [mailto:donga...@gmail.com]
> Sent: 2018-01-09 5:47 PM
> To: Anson Huang 
> Cc: Horia Geantă ; Aymen Sghaier
> ; herb...@gondor.apana.org.au;
> da...@davemloft.net; robh...@kernel.org; mark.rutl...@arm.com;
> shawn...@kernel.org; ker...@pengutronix.de; Fabio Estevam
> ; li...@armlinux.org.uk;
> mturque...@baylibre.com; sb...@codeaurora.org; Adriana Reus
> ; ste...@agner.ch; linux-crypto@vger.kernel.org;
> devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-...@vger.kernel.org; dl-linux-imx  i...@nxp.com>
> Subject: Re: [PATCH V3 2/2] ARM: dts: imx7s: add snvs rtc clock
> 
> On Tue, Jan 09, 2018 at 05:20:51PM +0800, Anson Huang wrote:
> > Add i.MX7 SNVS RTC clock.
> >
> > Signed-off-by: Anson Huang 
> > ---
> > changes since v2:
> > improve the binding doc statement about clocks.
> >  Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 15
> +++
> >  arch/arm/boot/dts/imx7s.dtsi  |  2 ++
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > index 76aec8a..7329f29 100644
> > --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> > @@ -415,12 +415,25 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP)
> RTC Node
> > value type: 
> > Definition: LP register offset. default it is 0x34.
> >
> > +   - clocks
> > +  Usage: required if SNVS LP RTC requires explicit enablement of clocks
> > +  Value type: 
> > +  Definition:  a clock specifier describing the clock required for
> > +  enabling and disabling SNVS LP RTC.
> > +
> 
> This clock seem optional.
> Should we indicate it here explicitly?

Will add a optional in usage.


> 
> BTW, i thought we probably could update poweroff and key as well at the same
> time since device tree changes can go separately.
> Does it make sense?

I think this patch set is only for RTC case since snvs-rtc driver already 
handle the clock.
But for poweroff and powerkey, their drivers are NOT handling clocks currently, 
we
can add them when driver ready to handle clocks. Should be in another patch set 
later.

Anson.

> 
> Regards
> Dong Aisheng
> 
> > +   - clock-names
> > +  Usage: required if SNVS LP RTC requires explicit enablement of clocks
> > +  Value type: 
> > +  Definition: clock name string should be "snvs-rtc".
> > +
> >  EXAMPLE
> > sec_mon_rtc_lp@1 {
> > compatible = "fsl,sec-v4.0-mon-rtc-lp";
> > interrupts = <93 2>;
> > regmap = <>;
> > offset = <0x34>;
> > +   clocks = < IMX7D_SNVS_CLK>;
> > +   clock-names = "snvs-rtc";
> > };
> >
> >
> 
> =
> > @@ -543,6 +556,8 @@ FULL EXAMPLE
> > regmap = <_mon>;
> > offset = <0x34>;
> > interrupts = <93 2>;
> > +   clocks = < IMX7D_SNVS_CLK>;
> > +   clock-names = "snvs-rtc";
> > };
> >
> > snvs-pwrkey@020cc000 {
> > diff --git a/arch/arm/boot/dts/imx7s.dtsi
> > b/arch/arm/boot/dts/imx7s.dtsi index 9aa2bb9..02baf42 100644
> > --- a/arch/arm/boot/dts/imx7s.dtsi
> > +++ b/arch/arm/boot/dts/imx7s.dtsi
> > @@ -551,6 +551,8 @@
> > offset = <0x34>;
> > interrupts =  IRQ_TYPE_LEVEL_HIGH>,
> >   IRQ_TYPE_LEVEL_HIGH>;
> > +   clocks = < IMX7D_SNVS_CLK>;
> > +   clock-names = "snvs-rtc";
> > };
> >
> > snvs_poweroff: snvs-poweroff {
> > --
> > 1.9.1
> >

Re: Hang loading omap_rng on MacchiatoBin with 4.15-rc7

2018-01-09 Thread Riku Voipio

On 9 January 2018 at 11:47, Ard Biesheuvel  wrote:
> On 9 January 2018 at 08:31, Riku Voipio  wrote:
>> Hi,
>>
>> Loading omap_rng module on McBin causes hangup (in about 9/10 times).
>> Looking at /proc/interrupts it seems the interrupt starts running like
>> crazy, and after a while the whole system is unresponsive. This with
>> Debian kernel (everything possible as modules) and EFI as bootloader.
>> The EFI firmware appears[1] to use the rng unit to provide a seed for
>> KASRL, I wonder if the driver needs to depend less on the state left
>> by firmware, or the firmware needs to de-initialize the RNG before
>> booting.
>>
> ...
>>  87:  0  0  0  0  ICU.f21e  95
>> Level f276.trng
>>  88:2532580  0  0  0  ICU.f41e  95
>> Level f476.trng
> ...
>
> My original code had
>
> gMarvellTokenSpaceGuid.PcdEip76TrngBaseAddress|0xF276
>
> which means the interrupt storm is being caused by the /other/ RNG,
> not the one UEFI uses.
>
> Could you please check whether your UEFI source is still using the
> same base address?

Good catch. Looks like it is:

https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/marvell-armada-wip-variables/Platforms/Marvell/Armada/Armada.dsc.inc#L374

Riku

Re: Hang loading omap_rng on MacchiatoBin with 4.15-rc7

2018-01-09 Thread Ard Biesheuvel

On 9 January 2018 at 08:31, Riku Voipio  wrote:
> Hi,
>
> Loading omap_rng module on McBin causes hangup (in about 9/10 times).
> Looking at /proc/interrupts it seems the interrupt starts running like
> crazy, and after a while the whole system is unresponsive. This with
> Debian kernel (everything possible as modules) and EFI as bootloader.
> The EFI firmware appears[1] to use the rng unit to provide a seed for
> KASRL, I wonder if the driver needs to depend less on the state left
> by firmware, or the firmware needs to de-initialize the RNG before
> booting.
>
...
>  87:  0  0  0  0  ICU.f21e  95
> Level f276.trng
>  88:2532580  0  0  0  ICU.f41e  95
> Level f476.trng
...

My original code had

gMarvellTokenSpaceGuid.PcdEip76TrngBaseAddress|0xF276

which means the interrupt storm is being caused by the /other/ RNG,
not the one UEFI uses.

Could you please check whether your UEFI source is still using the
same base address?

Re: [PATCH V3 2/2] ARM: dts: imx7s: add snvs rtc clock

2018-01-09 Thread Dong Aisheng

On Tue, Jan 09, 2018 at 05:20:51PM +0800, Anson Huang wrote:
> Add i.MX7 SNVS RTC clock.
> 
> Signed-off-by: Anson Huang 
> ---
> changes since v2:
>   improve the binding doc statement about clocks.
>  Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 15 +++
>  arch/arm/boot/dts/imx7s.dtsi  |  2 ++
>  2 files changed, 17 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt 
> b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> index 76aec8a..7329f29 100644
> --- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> +++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
> @@ -415,12 +415,25 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC 
> Node
>   value type: 
>   Definition: LP register offset. default it is 0x34.
>  
> +   - clocks
> +  Usage: required if SNVS LP RTC requires explicit enablement of clocks
> +  Value type: 
> +  Definition:  a clock specifier describing the clock required for
> +  enabling and disabling SNVS LP RTC.
> +

This clock seem optional.
Should we indicate it here explicitly?

BTW, i thought we probably could update poweroff and key as well at
the same time since device tree changes can go separately.
Does it make sense?

Regards
Dong Aisheng

> +   - clock-names
> +  Usage: required if SNVS LP RTC requires explicit enablement of clocks
> +  Value type: 
> +  Definition: clock name string should be "snvs-rtc".
> +
>  EXAMPLE
>   sec_mon_rtc_lp@1 {
>   compatible = "fsl,sec-v4.0-mon-rtc-lp";
>   interrupts = <93 2>;
>   regmap = <>;
>   offset = <0x34>;
> + clocks = < IMX7D_SNVS_CLK>;
> + clock-names = "snvs-rtc";
>   };
>  
>  =
> @@ -543,6 +556,8 @@ FULL EXAMPLE
>   regmap = <_mon>;
>   offset = <0x34>;
>   interrupts = <93 2>;
> + clocks = < IMX7D_SNVS_CLK>;
> + clock-names = "snvs-rtc";
>   };
>  
>   snvs-pwrkey@020cc000 {
> diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
> index 9aa2bb9..02baf42 100644
> --- a/arch/arm/boot/dts/imx7s.dtsi
> +++ b/arch/arm/boot/dts/imx7s.dtsi
> @@ -551,6 +551,8 @@
>   offset = <0x34>;
>   interrupts =  IRQ_TYPE_LEVEL_HIGH>,
> IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < IMX7D_SNVS_CLK>;
> + clock-names = "snvs-rtc";
>   };
>  
>   snvs_poweroff: snvs-poweroff {
> -- 
> 1.9.1
>

Re: [PATCH V3 1/2] clk: imx: imx7d: add the snvs clock

2018-01-09 Thread Dong Aisheng

On Tue, Jan 09, 2018 at 05:20:50PM +0800, Anson Huang wrote:
> According to the i.MX7D Reference Manual,
> SNVS block has a clock gate, accessing SNVS block
> would need this clock gate to be enabled, add it
> into clock tree so that SNVS module driver can
> operate this clock gate.
> 
> Signed-off-by: Anson Huang 

You missed the last round review tags.

Regards
Dong Aisheng

[PATCH V3 2/2] ARM: dts: imx7s: add snvs rtc clock

Add i.MX7 SNVS RTC clock.

Signed-off-by: Anson Huang 
---
changes since v2:
improve the binding doc statement about clocks.
 Documentation/devicetree/bindings/crypto/fsl-sec4.txt | 15 +++
 arch/arm/boot/dts/imx7s.dtsi  |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt 
b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index 76aec8a..7329f29 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -415,12 +415,25 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
value type: 
Definition: LP register offset. default it is 0x34.
 
+   - clocks
+  Usage: required if SNVS LP RTC requires explicit enablement of clocks
+  Value type: 
+  Definition:  a clock specifier describing the clock required for
+  enabling and disabling SNVS LP RTC.
+
+   - clock-names
+  Usage: required if SNVS LP RTC requires explicit enablement of clocks
+  Value type: 
+  Definition: clock name string should be "snvs-rtc".
+
 EXAMPLE
sec_mon_rtc_lp@1 {
compatible = "fsl,sec-v4.0-mon-rtc-lp";
interrupts = <93 2>;
regmap = <>;
offset = <0x34>;
+   clocks = < IMX7D_SNVS_CLK>;
+   clock-names = "snvs-rtc";
};
 
 =
@@ -543,6 +556,8 @@ FULL EXAMPLE
regmap = <_mon>;
offset = <0x34>;
interrupts = <93 2>;
+   clocks = < IMX7D_SNVS_CLK>;
+   clock-names = "snvs-rtc";
};
 
snvs-pwrkey@020cc000 {
diff --git a/arch/arm/boot/dts/imx7s.dtsi b/arch/arm/boot/dts/imx7s.dtsi
index 9aa2bb9..02baf42 100644
--- a/arch/arm/boot/dts/imx7s.dtsi
+++ b/arch/arm/boot/dts/imx7s.dtsi
@@ -551,6 +551,8 @@
offset = <0x34>;
interrupts = ,
 ;
+   clocks = < IMX7D_SNVS_CLK>;
+   clock-names = "snvs-rtc";
};
 
snvs_poweroff: snvs-poweroff {
-- 
1.9.1

[PATCH V3 1/2] clk: imx: imx7d: add the snvs clock

According to the i.MX7D Reference Manual,
SNVS block has a clock gate, accessing SNVS block
would need this clock gate to be enabled, add it
into clock tree so that SNVS module driver can
operate this clock gate.

Signed-off-by: Anson Huang 
---
 drivers/clk/imx/clk-imx7d.c | 1 +
 include/dt-bindings/clock/imx7d-clock.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/imx/clk-imx7d.c b/drivers/clk/imx/clk-imx7d.c
index 80dc211..f34f1ec 100644
--- a/drivers/clk/imx/clk-imx7d.c
+++ b/drivers/clk/imx/clk-imx7d.c
@@ -795,6 +795,7 @@ static void __init imx7d_clocks_init(struct device_node 
*ccm_node)
clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] = 
imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div", base + 
0x4130, 0);
clks[IMX7D_DRAM_ALT_ROOT_CLK] = imx_clk_gate4("dram_alt_root_clk", 
"dram_alt_post_div", base + 0x4130, 0);
clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk", "ipg_root_clk", base 
+ 0x4230, 0);
+   clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk", base + 
0x4250, 0);
clks[IMX7D_USB_HSIC_ROOT_CLK] = imx_clk_gate4("usb_hsic_root_clk", 
"usb_hsic_post_div", base + 0x4420, 0);
clks[IMX7D_SDMA_CORE_CLK] = imx_clk_gate4("sdma_root_clk", 
"ahb_root_clk", base + 0x4480, 0);
clks[IMX7D_PCIE_CTRL_ROOT_CLK] = imx_clk_gate4("pcie_ctrl_root_clk", 
"pcie_ctrl_post_div", base + 0x4600, 0);
diff --git a/include/dt-bindings/clock/imx7d-clock.h 
b/include/dt-bindings/clock/imx7d-clock.h
index e2f99ae..dc51904 100644
--- a/include/dt-bindings/clock/imx7d-clock.h
+++ b/include/dt-bindings/clock/imx7d-clock.h
@@ -452,5 +452,6 @@
 #define IMX7D_OCOTP_CLK439
 #define IMX7D_NAND_RAWNAND_CLK 440
 #define IMX7D_NAND_USDHC_BUS_RAWNAND_CLK 441
-#define IMX7D_CLK_END  442
+#define IMX7D_SNVS_CLK 442
+#define IMX7D_CLK_END  443
 #endif /* __DT_BINDINGS_CLOCK_IMX7D_H */
-- 
1.9.1

Re: Hang loading omap_rng on MacchiatoBin with 4.15-rc7

2018-01-09 Thread Riku Voipio

On 9 January 2018 at 11:21, Gregory CLEMENT
 wrote:
> Hi Riku,
>
>  On mar., janv. 09 2018, Riku Voipio  wrote:
>
>> Hi,
>>
>> Loading omap_rng module on McBin causes hangup (in about 9/10 times).
>> Looking at /proc/interrupts it seems the interrupt starts running like
>> crazy, and after a while the whole system is unresponsive. This with
>> Debian kernel (everything possible as modules) and EFI as bootloader.
>> The EFI firmware appears[1] to use the rng unit to provide a seed for
>> KASRL, I wonder if the driver needs to depend less on the state left
>> by firmware, or the firmware needs to de-initialize the RNG before
>> booting.
>
> I do not have a board with an EFI bootloader, so that may explain why I
> didn't managed to reproduce your issue. I really would prefer to make
> the driver less depend to the bootloader than the firmware de-initialize
> the RNG before booting. However both things could be done independently.
>
> I can have a look on the driver but as I don't have the configuration I
> may ask you to test it for me.

Sure, I'll be happy to test.

>>
>> root@debian:~# cat /proc/interrupts
>>CPU0   CPU1   CPU2   CPU3
>>   1:  0  0  0  0 GICv2  25 Level vgic
>>   3:   1268   1983   1175   1139 GICv2  30 Level
>>   arch_timer
>>   4:  0  0  0  0 GICv2  27 Level
>>   kvm guest timer
>>   7:   1956  0  0  0 GICv2  51 Level 
>> ttyS0
>>   9:   4472  0307  0 GICv2  48 Level mmc0
>>  18:  0  0  0  0  pMSI 4096 Edge
>>f040.xor
>>  19:  0  0  0  0  pMSI 6144 Edge
>>f042.xor
>>  20:  0  0  0  0  pMSI 8192 Edge
>>f044.xor
>>  21:  0  0  0  0  pMSI 10240 Edge
>> f046.xor
>>  22:  0  0  0  0  pMSI 12288 Edge
>> f26a.xor
>>  23:  0  0  0  0  pMSI 14336 Edge
>> f26c.xor
>>  24:  0  0  0  0  pMSI 16384 Edge
>> f46a.xor
>>  25:  0  0  0  0  pMSI 18432 Edge
>> f46c.xor
>>  26:  0  0  0  0
>> f03f0100.interrupt-controller  17 Level arm-pmu
>>  27:  0  0  0  0  ICU.f21e  22
>> Level armada8k-pcie, PCIe PME, aerdrv
>>  72: 13  0  0  0  ICU.f41e  40
>> Level eth2
>>  73:  0 10  0  0  ICU.f41e  44
>> Level eth2
>>  74:  0  0 29  0  ICU.f41e  48
>> Level eth2
>>  75:  0  0  0 45  ICU.f41e  52
>> Level eth2
>>  76: 36  0  0 55  ICU.f41e  56
>> Level eth2
>>  78:440  0 42  0  ICU.f21e  27
>> Level mmc1
>>  79:  0  0  0  0  ICU.f41e  77
>> Level f4284000.rtc
>>  80:  0  0  0  0  ICU.f21e 120
>> Level mv64xxx_i2c
>>  81:  0  0  0  0  ICU.f21e 121
>> Level mv64xxx_i2c
>>  82:  0  0  0  0  ICU.f21e 106
>> Level xhci-hcd:usb1
>>  83:  0  0  0  0  ICU.f21e 105
>> Level xhci-hcd:usb3
>>  84:  0  0  0  0  ICU.f41e 106
>> Level xhci-hcd:usb5
>>  85:  0  0  0  0  ICU.f21e 107
>> Level ahci[f254.sata]
>>  86:268  0  0  0  ICU.f41e 107
>> Level ahci[f454.sata]
>> IPI0:  2254   2458   1876   1844   Rescheduling 
>> interrupts
>> IPI1:   110107299165   Function call 
>> interrupts
>> IPI2: 0  0  0  0   CPU stop interrupts
>> IPI3: 0  0  0  0   CPU stop (for
>> crash dump) interrupts
>> IPI4: 0  0  0  0   Timer broadcast
>> interrupts
>> IPI5: 1  0  0  0   IRQ work interrupts
>> IPI6: 0  0  0  0   CPU wake-up interrupts
>> Err:  0
>> root@debian:~# modprobe omap_rng
>> root@debian:~# cat /proc/interrupts
>>CPU0   CPU1   CPU2   CPU3
>>   1:  0  0  0  0 GICv2  25 Level vgic
>>   3:   1795   2736   1663   1620 GICv2  30 Level
>>   arch_timer
>>   4:  0  0  0  0 GICv2  27 Level
>>   kvm guest timer
>>   7:   2183  0  0  0

RE: [PATCH V2 2/2] ARM: dts: imx7s: add snvs rtc clock