* [RFC PATCH 2/2] crypto: arm/aes - add CCM driver using ARMv8 Crypto Extensions
From: Ard Biesheuvel @ 2017-01-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483991849-32448-1-git-send-email-ard.biesheuvel@linaro.org>
This is a straight port of the arm64 driver that implements AES
in CCM mode using the ARMv8 Crypto Extensions instructions. It
is ~13x faster than the generic CCM code using scalar AES.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/crypto/Kconfig | 8 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/aes-ce-ccm-core.S | 234 +++++++++++++
arch/arm/crypto/aes-ce-ccm-glue.c | 360 ++++++++++++++++++++
4 files changed, 604 insertions(+)
diff --git a/arch/arm/crypto/Kconfig b/arch/arm/crypto/Kconfig
index f1de658c3c8f..f933cae8d76b 100644
--- a/arch/arm/crypto/Kconfig
+++ b/arch/arm/crypto/Kconfig
@@ -92,6 +92,14 @@ config CRYPTO_AES_ARM_CE
Use an implementation of AES in CBC, CTR and XTS modes that uses
ARMv8 Crypto Extensions
+config CRYPTO_AES_ARM_CE_CCM
+ tristate "AES in CCM mode using ARMv8 Crypto Extensions"
+ depends on KERNEL_MODE_NEON && m
+ select CRYPTO_ALGAPI
+ select CRYPTO_AES
+ select CRYPTO_AEAD
+ select CRYPTO_CCM
+
config CRYPTO_GHASH_ARM_CE
tristate "PMULL-accelerated GHASH using ARMv8 Crypto Extensions"
depends on KERNEL_MODE_NEON
diff --git a/arch/arm/crypto/Makefile b/arch/arm/crypto/Makefile
index 6eda6ffafea9..1b4f3a5f918c 100644
--- a/arch/arm/crypto/Makefile
+++ b/arch/arm/crypto/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_CRYPTO_SHA512_ARM) += sha512-arm.o
obj-$(CONFIG_CRYPTO_CHACHA20_NEON) += chacha20-neon.o
ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE) += aes-arm-ce.o
+ce-obj-$(CONFIG_CRYPTO_AES_ARM_CE_CCM) += aes-ce-ccm.o
ce-obj-$(CONFIG_CRYPTO_SHA1_ARM_CE) += sha1-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_SHA2_ARM_CE) += sha2-arm-ce.o
ce-obj-$(CONFIG_CRYPTO_GHASH_ARM_CE) += ghash-arm-ce.o
@@ -38,6 +39,7 @@ sha512-arm-y := sha512-core.o sha512-glue.o $(sha512-arm-neon-y)
sha1-arm-ce-y := sha1-ce-core.o sha1-ce-glue.o
sha2-arm-ce-y := sha2-ce-core.o sha2-ce-glue.o
aes-arm-ce-y := aes-ce-core.o aes-ce-glue.o
+aes-ce-ccm-y := aes-ce-ccm-core.o aes-ce-ccm-glue.o
ghash-arm-ce-y := ghash-ce-core.o ghash-ce-glue.o
crct10dif-arm-ce-y := crct10dif-ce-core.o crct10dif-ce-glue.o
crc32-arm-ce-y:= crc32-ce-core.o crc32-ce-glue.o
diff --git a/arch/arm/crypto/aes-ce-ccm-core.S b/arch/arm/crypto/aes-ce-ccm-core.S
new file mode 100644
index 000000000000..6eefb7dea77e
--- /dev/null
+++ b/arch/arm/crypto/aes-ce-ccm-core.S
@@ -0,0 +1,234 @@
+/*
+ * aesce-ccm-core.S - AES-CCM transform for ARMv8 with Crypto Extensions
+ *
+ * Copyright (C) 2013 - 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
+ * 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 <linux/linkage.h>
+#include <asm/assembler.h>
+
+ .text
+ .arch armv7-a
+ .fpu crypto-neon-fp-armv8
+
+ /*
+ * void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
+ * u32 *macp, u8 const rk[], u32 rounds);
+ */
+ENTRY(ce_aes_ccm_auth_data)
+ push {r4-r8, lr}
+ ldrd r4, r5, [sp, #24]
+ ldr r8, [r3] /* leftover from prev round? */
+ vld1.8 {q0}, [r0] /* load mac */
+ teq r8, #0
+ beq 1f
+ sub r8, r8, #16
+ veor q1, q1, q1
+0: ldrb r7, [r1], #1 /* get 1 byte of input */
+ subs r2, r2, #1
+ add r8, r8, #1
+ vmov.8 d2[0], r7
+ vext.8 q1, q1, q1, #1 /* rotate in the input bytes */
+ beq 8f /* out of input? */
+ teq r8, #0
+ bne 0b
+ veor q0, q0, q1
+1: vld1.32 {q3}, [r4] /* load first round key */
+ cmp r5, #12 /* which key size? */
+ add r6, r4, #16
+ sub r7, r5, #2 /* modified # of rounds */
+ bmi 2f
+ bne 5f
+ vmov q5, q3
+ b 4f
+2: vmov q4, q3
+ vld1.32 {q5}, [r6]! /* load 2nd round key */
+3: aese.8 q0, q4
+ aesmc.8 q0, q0
+4: vld1.32 {q3}, [r6]! /* load next round key */
+ aese.8 q0, q5
+ aesmc.8 q0, q0
+5: vld1.32 {q4}, [r6]! /* load next round key */
+ subs r7, r7, #3
+ aese.8 q0, q3
+ aesmc.8 q0, q0
+ vld1.32 {q5}, [r6]! /* load next round key */
+ bpl 3b
+ aese.8 q0, q4
+ subs r2, r2, #16 /* last data? */
+ veor q0, q0, q5 /* final round */
+ bmi 6f
+ vld1.8 {q1}, [r1]! /* load next input block */
+ veor q0, q0, q1 /* xor with mac */
+ bne 1b
+6: vst1.8 {q0}, [r0] /* store mac */
+ beq 10f
+ adds r2, r2, #16
+ beq 10f
+ mov r8, r2
+7: ldrb r7, [r1], #1
+ vmov r6, d0[0]
+ eor r6, r6, r7
+ strb r6, [r0], #1
+ subs r2, r2, #1
+ beq 10f
+ vext.8 q0, q0, q0, #1 /* rotate out the mac bytes */
+ b 7b
+8: mov r7, r8
+ add r8, r8, #16
+9: vext.8 q1, q1, q1, #1
+ adds r7, r7, #1
+ bne 9b
+ veor q0, q0, q1
+ vst1.8 {q0}, [r0]
+10: str r8, [r3]
+ pop {r4-r8, pc}
+ENDPROC(ce_aes_ccm_auth_data)
+
+ /*
+ * void ce_aes_ccm_final(u8 mac[], u8 const ctr[], u8 const rk[],
+ * u32 rounds);
+ */
+ENTRY(ce_aes_ccm_final)
+ vld1.32 {q3}, [r2]! /* load first round key */
+ vld1.8 {q0}, [r0] /* load mac */
+ cmp r3, #12 /* which key size? */
+ sub r3, r3, #2 /* modified # of rounds */
+ vld1.8 {q1}, [r1] /* load 1st ctriv */
+ bmi 0f
+ bne 3f
+ vmov q5, q3
+ b 2f
+0: vmov q4, q3
+1: vld1.32 {q5}, [r2]! /* load next round key */
+ aese.8 q0, q4
+ aesmc.8 q0, q0
+ aese.8 q1, q4
+ aesmc.8 q1, q1
+2: vld1.32 {q3}, [r2]! /* load next round key */
+ aese.8 q0, q5
+ aesmc.8 q0, q0
+ aese.8 q1, q5
+ aesmc.8 q1, q1
+3: vld1.32 {q4}, [r2]! /* load next round key */
+ subs r3, r3, #3
+ aese.8 q0, q3
+ aesmc.8 q0, q0
+ aese.8 q1, q3
+ aesmc.8 q1, q1
+ bpl 1b
+ aese.8 q0, q4
+ aese.8 q1, q4
+ /* final round key cancels out */
+ veor q0, q0, q1 /* en-/decrypt the mac */
+ vst1.8 {q0}, [r0] /* store result */
+ bx lr
+ENDPROC(ce_aes_ccm_final)
+
+ .macro aes_ccm_do_crypt, enc
+ push {r4-r10, lr}
+ ldrd r4, r5, [sp, #32]
+ ldr r6, [sp, #40]
+
+ ldr r8, [r6, #12] /* load lower ctr */
+ vld1.8 {q0}, [r5] /* load mac */
+#ifndef CONFIG_CPU_BIG_ENDIAN
+ rev r8, r8 /* keep swabbed ctr in reg */
+#endif
+0: /* outer loop */
+ vld1.8 {q1}, [r6] /* load upper ctr */
+ add r8, r8, #1
+ rev r9, r8
+ cmp r4, #12 /* which key size? */
+ sub r7, r4, #2 /* get modified # of rounds */
+ vmov.32 d3[1], r9 /* no carry in lower ctr */
+ vld1.8 {q3}, [r3] /* load first round key */
+ add r10, r3, #16
+ bmi 1f
+ bne 4f
+ vmov q5, q3
+ b 3f
+1: vmov q4, q3
+ vld1.32 {q5}, [r10]! /* load 2nd round key */
+2: /* inner loop: 3 rounds, 2x interleaved */
+ aese.8 q0, q4
+ aesmc.8 q0, q0
+ aese.8 q1, q4
+ aesmc.8 q1, q1
+3: vld1.32 {q3}, [r10]! /* load next round key */
+ aese.8 q0, q5
+ aesmc.8 q0, q0
+ aese.8 q1, q5
+ aesmc.8 q1, q1
+4: vld1.32 {q4}, [r10]! /* load next round key */
+ subs r7, r7, #3
+ aese.8 q0, q3
+ aesmc.8 q0, q0
+ aese.8 q1, q3
+ aesmc.8 q1, q1
+ vld1.32 {q5}, [r10]! /* load next round key */
+ bpl 2b
+ aese.8 q0, q4
+ aese.8 q1, q4
+ subs r2, r2, #16
+ bmi 6f /* partial block? */
+ vld1.8 {q2}, [r1]! /* load next input block */
+ .if \enc == 1
+ veor q2, q2, q5 /* final round enc+mac */
+ veor q1, q1, q2 /* xor with crypted ctr */
+ .else
+ veor q2, q2, q1 /* xor with crypted ctr */
+ veor q1, q2, q5 /* final round enc */
+ .endif
+ veor q0, q0, q2 /* xor mac with pt ^ rk[last] */
+ vst1.8 {q1}, [r0]! /* write output block */
+ bne 0b
+#ifndef CONFIG_CPU_BIG_ENDIAN
+ rev r8, r8
+#endif
+ vst1.8 {q0}, [r5] /* store mac */
+ str r8, [r6, #12] /* store lsb end of ctr (BE) */
+5: pop {r4-r10, pc}
+
+6: veor q0, q0, q5 /* final round mac */
+ veor q1, q1, q5 /* final round enc */
+ vst1.8 {q0}, [r5] /* store mac */
+ add r2, r2, #16 /* process partial tail block */
+7: ldrb r9, [r1], #1 /* get 1 byte of input */
+ vmov.u8 r6, d2[0] /* get top crypted ctr byte */
+ vmov.u8 r7, d0[0] /* get top mac byte */
+ .if \enc == 1
+ eor r7, r7, r9
+ eor r9, r9, r6
+ .else
+ eor r9, r9, r6
+ eor r7, r7, r9
+ .endif
+ strb r9, [r0], #1 /* store out byte */
+ strb r7, [r5], #1 /* store mac byte */
+ subs r2, r2, #1
+ beq 5b
+ vext.8 q0, q0, q0, #1 /* shift out mac byte */
+ vext.8 q1, q1, q1, #1 /* shift out ctr byte */
+ b 7b
+ .endm
+
+ /*
+ * void ce_aes_ccm_encrypt(u8 out[], u8 const in[], u32 cbytes,
+ * u8 const rk[], u32 rounds, u8 mac[],
+ * u8 ctr[]);
+ * void ce_aes_ccm_decrypt(u8 out[], u8 const in[], u32 cbytes,
+ * u8 const rk[], u32 rounds, u8 mac[],
+ * u8 ctr[]);
+ */
+ENTRY(ce_aes_ccm_encrypt)
+ aes_ccm_do_crypt 1
+ENDPROC(ce_aes_ccm_encrypt)
+
+ENTRY(ce_aes_ccm_decrypt)
+ aes_ccm_do_crypt 0
+ENDPROC(ce_aes_ccm_decrypt)
diff --git a/arch/arm/crypto/aes-ce-ccm-glue.c b/arch/arm/crypto/aes-ce-ccm-glue.c
new file mode 100644
index 000000000000..137ff7dded6b
--- /dev/null
+++ b/arch/arm/crypto/aes-ce-ccm-glue.c
@@ -0,0 +1,360 @@
+/*
+ * aes-ccm-glue.c - AES-CCM transform for ARMv8 with Crypto Extensions
+ *
+ * Copyright (C) 2013 - 2017 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
+ * 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 <asm/neon.h>
+#include <asm/unaligned.h>
+#include <crypto/aes.h>
+#include <crypto/scatterwalk.h>
+#include <crypto/internal/aead.h>
+#include <crypto/internal/skcipher.h>
+#include <linux/module.h>
+
+struct crypto_aes_ccm_ctx {
+ struct crypto_aes_ctx key;
+ struct crypto_aead *fallback;
+};
+
+asmlinkage void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes,
+ u32 *macp, u32 const rk[], u32 rounds);
+
+asmlinkage void ce_aes_ccm_encrypt(u8 out[], u8 const in[], u32 cbytes,
+ u32 const rk[], u32 rounds, u8 mac[],
+ u8 ctr[]);
+
+asmlinkage void ce_aes_ccm_decrypt(u8 out[], u8 const in[], u32 cbytes,
+ u32 const rk[], u32 rounds, u8 mac[],
+ u8 ctr[]);
+
+asmlinkage void ce_aes_ccm_final(u8 mac[], u8 const ctr[], u32 const rk[],
+ u32 rounds);
+
+static int num_rounds(struct crypto_aes_ccm_ctx *ctx)
+{
+ /*
+ * # of rounds specified by AES:
+ * 128 bit key 10 rounds
+ * 192 bit key 12 rounds
+ * 256 bit key 14 rounds
+ * => n byte key => 6 + (n/4) rounds
+ */
+ return 6 + ctx->key.key_length / 4;
+}
+
+static int ccm_setkey(struct crypto_aead *tfm, const u8 *in_key,
+ unsigned int key_len)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(tfm);
+ int ret;
+
+ ret = crypto_aes_expand_key(&ctx->key, in_key, key_len);
+ if (ret) {
+ tfm->base.crt_flags |= CRYPTO_TFM_RES_BAD_KEY_LEN;
+ return ret;
+ }
+
+ ret = crypto_aead_setkey(ctx->fallback, in_key, key_len);
+ if (ret) {
+ tfm->base.crt_flags |= (ctx->fallback->base.crt_flags &
+ CRYPTO_TFM_RES_BAD_KEY_LEN);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int ccm_setauthsize(struct crypto_aead *tfm, unsigned int authsize)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(tfm);
+
+ if ((authsize & 1) || authsize < 4)
+ return -EINVAL;
+
+ return crypto_aead_setauthsize(ctx->fallback, authsize);
+}
+
+static int ccm_init_mac(struct aead_request *req, u8 maciv[], u32 msglen)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ __be32 *n = (__be32 *)&maciv[AES_BLOCK_SIZE - 8];
+ u32 l = req->iv[0] + 1;
+
+ /* verify that CCM dimension 'L' is set correctly in the IV */
+ if (l < 2 || l > 8)
+ return -EINVAL;
+
+ /* verify that msglen can in fact be represented in L bytes */
+ if (l < 4 && msglen >> (8 * l))
+ return -EOVERFLOW;
+
+ /*
+ * Even if the CCM spec allows L values of up to 8, the Linux cryptoapi
+ * uses a u32 type to represent msglen so the top 4 bytes are always 0.
+ */
+ n[0] = 0;
+ n[1] = cpu_to_be32(msglen);
+
+ memcpy(maciv, req->iv, AES_BLOCK_SIZE - l);
+
+ /*
+ * Meaning of byte 0 according to CCM spec (RFC 3610/NIST 800-38C)
+ * - bits 0..2 : max # of bytes required to represent msglen, minus 1
+ * (already set by caller)
+ * - bits 3..5 : size of auth tag (1 => 4 bytes, 2 => 6 bytes, etc)
+ * - bit 6 : indicates presence of authenticate-only data
+ */
+ maciv[0] |= (crypto_aead_authsize(aead) - 2) << 2;
+ if (req->assoclen)
+ maciv[0] |= 0x40;
+
+ memset(&req->iv[AES_BLOCK_SIZE - l], 0, l);
+ return 0;
+}
+
+static void ccm_calculate_auth_mac(struct aead_request *req, u8 mac[])
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ struct __packed { __be16 l; __be32 h; u16 len; } ltag;
+ struct scatter_walk walk;
+ u32 len = req->assoclen;
+ u32 macp = 0;
+
+ /* prepend the AAD with a length tag */
+ if (len < 0xff00) {
+ ltag.l = cpu_to_be16(len);
+ ltag.len = 2;
+ } else {
+ ltag.l = cpu_to_be16(0xfffe);
+ put_unaligned_be32(len, <ag.h);
+ ltag.len = 6;
+ }
+
+ ce_aes_ccm_auth_data(mac, (u8 *)<ag, ltag.len, &macp,
+ ctx->key.key_enc, num_rounds(ctx));
+ scatterwalk_start(&walk, req->src);
+
+ do {
+ u32 n = scatterwalk_clamp(&walk, len);
+ u8 *p;
+
+ if (!n) {
+ scatterwalk_start(&walk, sg_next(walk.sg));
+ n = scatterwalk_clamp(&walk, len);
+ }
+ p = scatterwalk_map(&walk);
+ ce_aes_ccm_auth_data(mac, p, n, &macp, ctx->key.key_enc,
+ num_rounds(ctx));
+ len -= n;
+
+ scatterwalk_unmap(p);
+ scatterwalk_advance(&walk, n);
+ scatterwalk_done(&walk, 0, len);
+ } while (len);
+}
+
+static int ccm_encrypt(struct aead_request *req)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ struct skcipher_walk walk;
+ u8 __aligned(8) mac[AES_BLOCK_SIZE];
+ u8 buf[AES_BLOCK_SIZE];
+ u32 len = req->cryptlen;
+ int err;
+
+ if (in_irq()) {
+ struct aead_request *fallback_req;
+
+ fallback_req = aead_request_alloc(ctx->fallback, GFP_ATOMIC);
+ if (!fallback_req)
+ return -ENOMEM;
+
+ aead_request_set_ad(fallback_req, req->assoclen);
+ aead_request_set_crypt(fallback_req, req->src, req->dst,
+ req->cryptlen, req->iv);
+
+ err = crypto_aead_encrypt(fallback_req);
+ aead_request_free(fallback_req);
+ return err;
+ }
+
+ err = ccm_init_mac(req, mac, len);
+ if (err)
+ return err;
+
+ kernel_neon_begin();
+
+ if (req->assoclen)
+ ccm_calculate_auth_mac(req, mac);
+
+ /* preserve the original iv for the final round */
+ memcpy(buf, req->iv, AES_BLOCK_SIZE);
+
+ err = skcipher_walk_aead_encrypt(&walk, req, true);
+
+ while (walk.nbytes) {
+ u32 tail = walk.nbytes % AES_BLOCK_SIZE;
+
+ if (walk.nbytes == walk.total)
+ tail = 0;
+
+ ce_aes_ccm_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
+ walk.nbytes - tail, ctx->key.key_enc,
+ num_rounds(ctx), mac, walk.iv);
+
+ err = skcipher_walk_done(&walk, tail);
+ }
+ if (!err)
+ ce_aes_ccm_final(mac, buf, ctx->key.key_enc, num_rounds(ctx));
+
+ kernel_neon_end();
+
+ if (err)
+ return err;
+
+ /* copy authtag to end of dst */
+ scatterwalk_map_and_copy(mac, req->dst, req->assoclen + req->cryptlen,
+ crypto_aead_authsize(aead), 1);
+
+ return 0;
+}
+
+static int ccm_decrypt(struct aead_request *req)
+{
+ struct crypto_aead *aead = crypto_aead_reqtfm(req);
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ unsigned int authsize = crypto_aead_authsize(aead);
+ struct skcipher_walk walk;
+ u8 __aligned(8) mac[AES_BLOCK_SIZE];
+ u8 buf[AES_BLOCK_SIZE];
+ u32 len = req->cryptlen - authsize;
+ int err;
+
+ if (in_irq()) {
+ struct aead_request *fallback_req;
+
+ fallback_req = aead_request_alloc(ctx->fallback, GFP_ATOMIC);
+ if (!fallback_req)
+ return -ENOMEM;
+
+ aead_request_set_ad(fallback_req, req->assoclen);
+ aead_request_set_crypt(fallback_req, req->src, req->dst,
+ req->cryptlen, req->iv);
+
+ err = crypto_aead_decrypt(fallback_req);
+ aead_request_free(fallback_req);
+ return err;
+ }
+
+ err = ccm_init_mac(req, mac, len);
+ if (err)
+ return err;
+
+ kernel_neon_begin();
+
+ if (req->assoclen)
+ ccm_calculate_auth_mac(req, mac);
+
+ /* preserve the original iv for the final round */
+ memcpy(buf, req->iv, AES_BLOCK_SIZE);
+
+ err = skcipher_walk_aead_decrypt(&walk, req, true);
+
+ while (walk.nbytes) {
+ u32 tail = walk.nbytes % AES_BLOCK_SIZE;
+
+ if (walk.nbytes == walk.total)
+ tail = 0;
+
+ ce_aes_ccm_decrypt(walk.dst.virt.addr, walk.src.virt.addr,
+ walk.nbytes - tail, ctx->key.key_enc,
+ num_rounds(ctx), mac, walk.iv);
+
+ err = skcipher_walk_done(&walk, tail);
+ }
+ if (!err)
+ ce_aes_ccm_final(mac, buf, ctx->key.key_enc, num_rounds(ctx));
+
+ kernel_neon_end();
+
+ if (err)
+ return err;
+
+ /* compare calculated auth tag with the stored one */
+ scatterwalk_map_and_copy(buf, req->src,
+ req->assoclen + req->cryptlen - authsize,
+ authsize, 0);
+
+ if (crypto_memneq(mac, buf, authsize))
+ return -EBADMSG;
+ return 0;
+}
+
+static int ccm_init(struct crypto_aead *aead)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+ struct crypto_aead *tfm;
+
+ tfm = crypto_alloc_aead("ccm(aes)", 0,
+ CRYPTO_ALG_ASYNC | CRYPTO_ALG_NEED_FALLBACK);
+
+ if (IS_ERR(tfm))
+ return PTR_ERR(tfm);
+
+ ctx->fallback = tfm;
+ return 0;
+}
+
+static void ccm_exit(struct crypto_aead *aead)
+{
+ struct crypto_aes_ccm_ctx *ctx = crypto_aead_ctx(aead);
+
+ crypto_free_aead(ctx->fallback);
+}
+
+static struct aead_alg ccm_aes_alg = {
+ .base.cra_name = "ccm(aes)",
+ .base.cra_driver_name = "ccm-aes-ce",
+ .base.cra_priority = 300,
+ .base.cra_blocksize = 1,
+ .base.cra_ctxsize = sizeof(struct crypto_aes_ccm_ctx),
+ .base.cra_module = THIS_MODULE,
+ .base.cra_flags = CRYPTO_ALG_NEED_FALLBACK,
+
+ .ivsize = AES_BLOCK_SIZE,
+ .chunksize = AES_BLOCK_SIZE,
+ .maxauthsize = AES_BLOCK_SIZE,
+ .setkey = ccm_setkey,
+ .setauthsize = ccm_setauthsize,
+ .encrypt = ccm_encrypt,
+ .decrypt = ccm_decrypt,
+ .init = ccm_init,
+ .exit = ccm_exit,
+};
+
+static int __init aes_mod_init(void)
+{
+ if (!(elf_hwcap2 & HWCAP2_AES))
+ return -ENODEV;
+ return crypto_register_aead(&ccm_aes_alg);
+}
+
+static void __exit aes_mod_exit(void)
+{
+ crypto_unregister_aead(&ccm_aes_alg);
+}
+
+module_init(aes_mod_init);
+module_exit(aes_mod_exit);
+
+MODULE_DESCRIPTION("Synchronous AES in CCM mode using ARMv8 Crypto Extensions");
+MODULE_AUTHOR("Ard Biesheuvel <ard.biesheuvel@linaro.org>");
+MODULE_LICENSE("GPL v2");
+MODULE_ALIAS_CRYPTO("ccm(aes)");
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 1/2] ARM: vfp - allow kernel mode NEON in softirq context
From: Ard Biesheuvel @ 2017-01-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483991849-32448-1-git-send-email-ard.biesheuvel@linaro.org>
This updates the kernel mode NEON handling to allow the NEON to be used
in softirq context as well as process context. This involves disabling
softirq processing when the NEON is used in kernel mode in process context,
and dealing with the situation where 'current' is not the owner of the
userland context that is present in the NEON register file when the NEON
is enabled in kernel mode.
The rationale for this change is that the NEON is shared with the ARMv8
Crypto Extensions (which are also defined for the AArch32 execution state),
which can give a huge performance boost (15x) to use cases like mac80211
CCMP processing, which executes in softirq context.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm/vfp/vfpmodule.c | 22 ++++++++++++++------
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/arch/arm/vfp/vfpmodule.c b/arch/arm/vfp/vfpmodule.c
index 569d5a650a4a..814752811537 100644
--- a/arch/arm/vfp/vfpmodule.c
+++ b/arch/arm/vfp/vfpmodule.c
@@ -690,26 +690,33 @@ void kernel_neon_begin(void)
u32 fpexc;
/*
- * Kernel mode NEON is only allowed outside of interrupt context
+ * Kernel mode NEON is only allowed outside of hardirq context
* with preemption disabled. This will make sure that the kernel
* mode NEON register contents never need to be preserved.
*/
- BUG_ON(in_interrupt());
+ BUG_ON(in_irq());
cpu = get_cpu();
+ /*
+ * Disable softirq processing while the NEON is used by the kernel in
+ * process context. This ensures that only a single kernel mode NEON
+ * state is live at any given time.
+ */
+ if (!in_serving_softirq())
+ local_bh_disable();
+
fpexc = fmrx(FPEXC) | FPEXC_EN;
fmxr(FPEXC, fpexc);
/*
- * Save the userland NEON/VFP state. Under UP,
- * the owner could be a task other than 'current'
+ * Save the userland NEON/VFP state. Under UP, or when executing in
+ * softirq context, the owner could be a task other than 'current'
*/
if (vfp_state_in_hw(cpu, thread))
vfp_save_state(&thread->vfpstate, fpexc);
-#ifndef CONFIG_SMP
else if (vfp_current_hw_state[cpu] != NULL)
vfp_save_state(vfp_current_hw_state[cpu], fpexc);
-#endif
+
vfp_current_hw_state[cpu] = NULL;
}
EXPORT_SYMBOL(kernel_neon_begin);
@@ -718,7 +725,10 @@ void kernel_neon_end(void)
{
/* Disable the NEON/VFP unit. */
fmxr(FPEXC, fmrx(FPEXC) & ~FPEXC_EN);
+ if (!in_serving_softirq())
+ local_bh_enable();
put_cpu();
+
}
EXPORT_SYMBOL(kernel_neon_end);
--
2.7.4
^ permalink raw reply related
* [RFC PATCH 0/2] ARM: kernel mode NEON in softirq context
From: Ard Biesheuvel @ 2017-01-09 19:57 UTC (permalink / raw)
To: linux-arm-kernel
Patch #1 in this series adds support for using the NEON in kernel mode
while executing in softirq context. By allowing this, subsystems that
perform non-trivial crypto in softirq context (such as CCMP in the
mac80211 layer) can use algorithms such as the AES-CCM driver in
patch #2, which is 13x faster than the generic CCM driver.
Ard Biesheuvel (2):
ARM: vfp - allow kernel mode NEON in softirq context
crypto: arm/aes - add CCM driver using ARMv8 Crypto Extensions
arch/arm/crypto/Kconfig | 8 +
arch/arm/crypto/Makefile | 2 +
arch/arm/crypto/aes-ce-ccm-core.S | 234 +++++++++++++
arch/arm/crypto/aes-ce-ccm-glue.c | 360 ++++++++++++++++++++
arch/arm/vfp/vfpmodule.c | 22 +-
5 files changed, 620 insertions(+), 6 deletions(-)
create mode 100644 arch/arm/crypto/aes-ce-ccm-core.S
create mode 100644 arch/arm/crypto/aes-ce-ccm-glue.c
--
2.7.4
^ permalink raw reply
* [RESEND] spi: davinci: Allow device tree devices to use DMA
From: Mark Brown @ 2017-01-09 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483673177-31516-1-git-send-email-david@lechnology.com>
On Thu, Jan 05, 2017 at 09:26:17PM -0600, David Lechner wrote:
> This allows SPI devices specified in a device tree to use DMA when the
> master controller.
> Since device tree is supposed to only describe the hardware, adding such
> a configuration option to device tree would not be acceptable. So, this
> is the best we can do for now to get SPI devices working with DMA.
> Unfortunately, this excludes the possibility of using one SPI device with
> DMA and one without on the same master.
Why would you ever want to do that? What would ever make sense about
not using DMA if it's available and the transfer is suitably large, or
conversely why would one want to force DMA even if PIO would be more
performant?
> When I originally submitted this patch, there was some discussion as to whether
> dspi->dma_rx should be changed to return an error rather than being null.
> However, I prefer it the way it is and don't see a compelling reason to change
> it.
I don't know what the above comment means, sorry (and don't recall
having seen any earlier versions of this).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170109/ce442c16/attachment.sig>
^ permalink raw reply
* [PATCH 5/5] ARM: dts: keystone-k2e: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2E SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
index 9d1d8a64d10e..c5983418c42c 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2e", "ti,keystone";
model = "Texas Instruments Keystone 2 Edison SoC";
@@ -94,6 +96,17 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2e-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 4/5] ARM: dts: keystone-k2l: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2L SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index b58015737a35..4fa368f9ba52 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2l", "ti,keystone";
model = "Texas Instruments Keystone 2 Lamarr SoC";
@@ -216,6 +218,20 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2l-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 3/5] ARM: dts: keystone-k2hk: Add PSC reset controller node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module contains specific
memory-mapped registers that can be used to perform reset
management using specific bits for the DSPs available on the
SoC. The PSC is defined using a syscon node, and the reset
functionality is defined using a child syscon reset controller
node.
Add this syscon reset controller node as well as the reset
control data for the resets it supports for the 66AK2H SoCs.
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index e0780f111537..a833db72fc61 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -8,6 +8,8 @@
* published by the Free Software Foundation.
*/
+#include <dt-bindings/reset/ti-syscon.h>
+
/ {
compatible = "ti,k2hk", "ti,keystone";
model = "Texas Instruments Keystone 2 Kepler/Hawking SoC";
@@ -58,6 +60,24 @@
};
};
+ psc: power-sleep-controller at 02350000 {
+ pscrst: psc-reset-controller {
+ compatible = "ti,k2hk-pscrst", "ti,syscon-reset";
+ #reset-cells = <1>;
+
+ ti,reset-bits = <
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 8 0xa40 8 0x840 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 1: dsp1 */
+ 0xa44 8 0xa44 8 0x844 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 2: dsp2 */
+ 0xa48 8 0xa48 8 0x848 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 3: dsp3 */
+ 0xa4c 8 0xa4c 8 0x84c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 4: dsp4 */
+ 0xa50 8 0xa50 8 0x850 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 5: dsp5 */
+ 0xa54 8 0xa54 8 0x854 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 6: dsp6 */
+ 0xa58 8 0xa58 8 0x858 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 7: dsp7 */
+ >;
+ };
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH 2/5] ARM: dts: keystone: Add PSC node
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Power Sleep Controller (PSC) module is responsible
for the power and clock management for each of the peripherals
present on the SoC. Represent this as a syscon node so that
multiple users can leverage it for various functionalities.
Signed-off-by: Suman Anna <s-anna@ti.com>
[afd at ti.com: add simple-mfd compatible]
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
---
arch/arm/boot/dts/keystone.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 02708ba2d4f4..ec203d0a673d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -83,6 +83,11 @@
reg = <0x02310000 0x200>;
};
+ psc: power-sleep-controller at 02350000 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0x02350000 0x1000>;
+ };
+
devctrl: device-state-control at 02620000 {
compatible = "ti,keystone-devctrl", "syscon";
reg = <0x02620000 0x1000>;
--
2.10.2
^ permalink raw reply related
* [PATCH 1/5] ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109194358.27271-1-s-anna@ti.com>
The Keystone 2 family of SoCs will use various Reset Controller
drivers for managing the resets of remote processor devices like
DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option
by default to enable the Reset framework.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-keystone/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 24bd64dabdfc..554357035f30 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -4,6 +4,7 @@ config ARCH_KEYSTONE
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
select KEYSTONE_TIMER
+ select ARCH_HAS_RESET_CONTROLLER
select ARM_ERRATA_798181 if SMP
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
--
2.10.2
^ permalink raw reply related
* [PATCH 0/5] Reset Controller Nodes for TI Keystone platforms
From: Suman Anna @ 2017-01-09 19:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi Santosh,
This patch adds the reset controller nodes and the corresponding
reset data for TI Keystone 66AK2H, 66AK2L and 66AK2E SoCs. These
resets are for the DSPs on these SoCs, and are the last dependencies
before the keystone remoteproc driver can be added.
All these SoCs will use the ti-syscon-reset driver which is already
part of mainline kernel. The bindings for the same can be found in
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt file.
Note that the other Keystone 66AK2G SoC will use a different TI-SCI
based reset driver, so will be submitted separately once the TI-SCI
dependencies make it into mainline.
Patches are based on top of 4.10-rc1 plus the MSM-RAM DT node series
that you have already picked up. Patch 1 enable the Reset Framework
for Keystone platforms, and remaining patches add the required DT
nodes.
regards
Suman
Suman Anna (5):
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
ARM: dts: keystone: Add PSC node
ARM: dts: keystone-k2hk: Add PSC reset controller node
ARM: dts: keystone-k2l: Add PSC reset controller node
ARM: dts: keystone-k2e: Add PSC reset controller node
arch/arm/boot/dts/keystone-k2e.dtsi | 13 +++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 16 ++++++++++++++++
arch/arm/boot/dts/keystone.dtsi | 5 +++++
arch/arm/mach-keystone/Kconfig | 1 +
5 files changed, 55 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH 4/4] watchdog: coh901327_wdt: Use dev variable instead of pdev->dev
From: Linus Walleij @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-4-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Use a local dev variable instead of dereferencing pdev->dev several
> times in the probe function to make the code easier to read.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170109193328.GO2630@atomide.com>
On 01/09/2017 11:33 AM, Tony Lindgren wrote:
> * Sarangdhar Joshi <spjoshi@codeaurora.org> [170105 14:01]:
>> The function wkup_m3_rproc_boot_thread waits for asynchronous
>> firmware loading to parse the resource table before calling
>> rproc_boot(). However, as the resource table parsing has been
>> moved to rproc_boot(), there's no need to wait for the
>> asynchronous firmware loading completion. So, drop this.
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Tested-by: Suman Anna <s-anna@ti.com>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>> ---
>>
>> This patch seems to be doing an independent clean up now. Hence
>> removing it from the series.
>>
>> Changes from v2:
>>
>> * Updated the subject line as per Suman's comment
>
> FYI, I already have v2 applied with subject:
>
> "soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread"
Oh great. Thanks a lot Tony.
Regards,
Sarang
>
> Tony
>
>
>> drivers/soc/ti/wkup_m3_ipc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
>> index 8823cc8..8bfa44b 100644
>> --- a/drivers/soc/ti/wkup_m3_ipc.c
>> +++ b/drivers/soc/ti/wkup_m3_ipc.c
>> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>> struct device *dev = m3_ipc->dev;
>> int ret;
>>
>> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
>> -
>> init_completion(&m3_ipc->sync_complete);
>>
>> ret = rproc_boot(m3_ipc->rproc);
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/6] arm64: dts: apq8016-sbc: add support to hdmi audio via adv7533
From: Stephen Boyd @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483536902-21450-3-git-send-email-srinivas.kandagatla@linaro.org>
On 01/04, Srinivas Kandagatla wrote:
> diff --git a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> index 08bd5eb..5ab277f 100644
> --- a/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> +++ b/arch/arm64/boot/dts/qcom/apq8016-sbc.dtsi
> @@ -85,6 +85,7 @@
> pinctrl-names = "default","sleep";
> pinctrl-0 = <&adv7533_int_active &adv7533_switch_active>;
> pinctrl-1 = <&adv7533_int_suspend &adv7533_switch_suspend>;
> + #sound-dai-cells = <1>;
>
> ports {
> #address-cells = <1>;
> @@ -285,6 +286,15 @@
> qcom,audio-routing =
> "AMIC2", "MIC BIAS Internal2",
> "AMIC3", "MIC BIAS External1";
> + external-dai-link at 0 {
> + link-name = "ADV7533";
> + cpu { /* QUAT */
> + sound-dai = <&lpass MI2S_QUATERNARY>;
> + };
> + codec {
> + sound-dai = <&adv_bridge 0>;
> + };
> + };
>
> internal-codec-playback-dai-link at 0 { /* I2S - Internal codec */
> link-name = "WCD";
The spacing is weird here. Did the internal-codec get added
without tabs before?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 3/4] watchdog: coh901327_wdt: Use devm_ioremap_resource to map resources
From: Linus Walleij @ 2017-01-09 19:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-3-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Map resources using devm_ioremap_resource() to simplify error handling.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 2/4] watchdog: coh901327_wdt: Keep clock enabled after loading driver
From: Linus Walleij @ 2017-01-09 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-2-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Enabling the clock before accessing chip registers and disabling it
> afterwards does not really make sense and only adds complexity to
> the driver. In addition to that, a comment int the driver suggests
> that it does not serve a useful purpose either.
>
> "The watchdog block is of course always clocked, the
> clk_enable()/clk_disable() calls are mainly for performing reference
> counting higher up in the clock hierarchy."
>
> Just keep the clock enabled instead.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/4] watchdog: coh901327_wdt: Simplify error handling in probe function
From: Linus Walleij @ 2017-01-09 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483500343-27113-1-git-send-email-linux@roeck-us.net>
On Wed, Jan 4, 2017 at 4:25 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> Checking if there is no error followed by a goto if there is one is
> confusing. Reverse the logic.
>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Tony Lindgren @ 2017-01-09 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483653615-24378-1-git-send-email-spjoshi@codeaurora.org>
* Sarangdhar Joshi <spjoshi@codeaurora.org> [170105 14:01]:
> The function wkup_m3_rproc_boot_thread waits for asynchronous
> firmware loading to parse the resource table before calling
> rproc_boot(). However, as the resource table parsing has been
> moved to rproc_boot(), there's no need to wait for the
> asynchronous firmware loading completion. So, drop this.
>
> CC: Dave Gerlach <d-gerlach@ti.com>
> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> Tested-by: Suman Anna <s-anna@ti.com>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> ---
>
> This patch seems to be doing an independent clean up now. Hence
> removing it from the series.
>
> Changes from v2:
>
> * Updated the subject line as per Suman's comment
FYI, I already have v2 applied with subject:
"soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread"
Tony
> drivers/soc/ti/wkup_m3_ipc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
> index 8823cc8..8bfa44b 100644
> --- a/drivers/soc/ti/wkup_m3_ipc.c
> +++ b/drivers/soc/ti/wkup_m3_ipc.c
> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
> struct device *dev = m3_ipc->dev;
> int ret;
>
> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
> -
> init_completion(&m3_ipc->sync_complete);
>
> ret = rproc_boot(m3_ipc->rproc);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH v4 1/9] clk: stm32f4: Update DT bindings documentation
From: Stephen Boyd @ 2017-01-09 19:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ccd14adb-9d10-ae9e-de6d-565418421968@st.com>
On 01/09, Alexandre Torgue wrote:
> Hi Stephen,
>
> On 12/22/2016 01:10 AM, Stephen Boyd wrote:
> >On 12/13, gabriel.fernandez at st.com wrote:
> >>From: Gabriel Fernandez <gabriel.fernandez@st.com>
> >>
> >>Creation of dt include file for specific stm32f4 clocks.
> >>These specific clocks are not derived from system clock (SYSCLOCK)
> >>We should use index 1 to use these clocks in DT.
> >>e.g. <&rcc 1 CLK_LSI>
> >>
> >>Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
> >>Acked-by: Rob Herring <robh@kernel.org>
> >>---
> >
> >Applied to clk-stm32f4 and merged into clk-next.
> >
>
> I'm preparing pull request branch for STM32 DT part. This patch is
> also requested to build correctly DT patches. Do you know how could
> we synchronize our pull request ?
>
clk-stm32f4 is stable and not going to be rebased, so you're good
to base patches on it and send it off to arm-soc if the arm-soc
maintainers agree to it. You can also base off an earlier part of
the branch if you only need this first patch for example.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2.1 1/4] ARM: dts: davinci: da850: VPIF: add node and muxing
From: Kevin Hilman @ 2017-01-09 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f3cdadf0-b0e9-9956-145a-9cc22024f6f9@ti.com>
Sekhar Nori <nsekhar@ti.com> writes:
> Hi Kevin,
>
> On Thursday 08 December 2016 05:44 AM, Kevin Hilman wrote:
>> Add VPIF node an pins to da850 and enable on boards. VPIF has two input
>> channels described using the standard DT ports and enpoints.
>>
>> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
>> ---
>> v2 -> v2.1: moved ports from SoC .dtsi to board .dts files.
>>
>> arch/arm/boot/dts/da850-evm.dts | 20 ++++++++++++++++++++
>> arch/arm/boot/dts/da850-lcdk.dts | 13 +++++++++++++
>> arch/arm/boot/dts/da850.dtsi | 27 ++++++++++++++++++++++++++-
>> 3 files changed, 59 insertions(+), 1 deletion(-)
>
> Can you split this patch to keep the SoC addition separate from board
> updates. Separating support addition for EVM and LCDK will be good also.
I don't understand why that matters, but OK.
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index f79e1b91c680..5f0b40510b2b 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>
>> @@ -399,7 +410,21 @@
>> <&edma0 0 1>;
>> dma-names = "tx", "rx";
>> };
>> +
>> + vpif: video at 217000 {
>> + compatible = "ti,da850-vpif";
>> + reg = <0x217000 0x1000>;
>> + interrupts = <92>;
>> + status = "disabled";
>> +
>> + /* VPIF capture port */
>> + port {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + };
>> + };
>
> Can you add this node just above mmc1? I am trying to keep the nodes
> sorted in the order of unit address instead of new ones getting added at
> the end. Unfortunately, it was not strictly enforced and we have many
> breakages. But lets add the new ones where they will eventually end up.
OK.
Kevin
^ permalink raw reply
* [PATCH] Documentation: dt: reset: Revise typos in TI syscon reset example
From: Suman Anna @ 2017-01-09 19:28 UTC (permalink / raw)
To: linux-arm-kernel
Fix couple of typos in the example given in the TI syscon reset
binding. The ti,reset-bits used for DSP0 are corrected to match
the values that will be used in the actual DT node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
Hi Philipp,
This is the Documentation part fix that goes along with
the ti-syscon-reset fix that you have on your next branch.
I will be submitting the DT nodes very soon
regards
Suman
Documentation/devicetree/bindings/reset/ti-syscon-reset.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
index 164c7f34c451..21ba739b162e 100644
--- a/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
+++ b/Documentation/devicetree/bindings/reset/ti-syscon-reset.txt
@@ -63,7 +63,7 @@ Example:
--------
The following example demonstrates a syscon node, the reset controller node
using the syscon node, and a consumer (a DSP device) on the TI Keystone 2
-Edison SoC.
+66AK2E SoC.
/ {
soc {
@@ -71,13 +71,13 @@ Edison SoC.
compatible = "syscon", "simple-mfd";
reg = <0x02350000 0x1000>;
- pscrst: psc-reset {
+ pscrst: psc-reset-controller {
compatible = "ti,k2e-pscrst", "ti,syscon-reset";
#reset-cells = <1>;
ti,reset-bits = <
- 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_SET|DEASSERT_CLEAR|STATUS_SET) /* 0: pcrst-dsp0 */
- 0xa40 5 0xa44 3 0 0 (ASSERT_SET|DEASSERT_CLEAR|STATUS_NONE) /* 1: pcrst-example */
+ 0xa3c 8 0xa3c 8 0x83c 8 (ASSERT_CLEAR | DEASSERT_SET | STATUS_CLEAR) /* 0: dsp0 */
+ 0xa40 5 0xa44 3 0 0 (ASSERT_SET | DEASSERT_CLEAR | STATUS_NONE) /* 1: example */
>;
};
};
--
2.10.2
^ permalink raw reply related
* [RFC PATCH 1/5] regulator: Extend the power-management APIs
From: Mark Brown @ 2017-01-09 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480687036-5037-2-git-send-email-boris.brezillon@free-electrons.com>
On Fri, Dec 02, 2016 at 02:57:12PM +0100, Boris Brezillon wrote:
> The idea to solve #2 is to allow runtime changes. Since this kind of
> change is likely to have an impact on the whole system, we require the
> board to explicitly state that runtime changes are allowed (using a DT
> property).
> Allowing runtime changes, may also be a problem if devices are not
> suspended in the correct order: a device using a regulator should be
> suspended before the regulator itself, otherwise we may change the
> regulator state while it's still being used.
> Hopefully, this problem will be solved with the work done on device
> dependency description.
I'm not sure that adding an extra property is going to help with the
problems here - the system already has to provide explicit support for
setting the suspend configuration so that should be enough. However it
*is* a bit more than just making sure that the device suspend ordering
is good (though that's definitely part of it), there will be things
kicked off by hardware signalling without software knowing about it.
Anything that doesn't affect a hardware supported runtime state probably
needs to be split off and handled separately as that's the much more
risky bit, moving changing of suspend mode earlier isn't going to cause
too much grief, that patch should just be split out and can probably
just go straight in.
> + * This function should be called from the regulator driver ->suspend() hook
> + * and after the platform has called regulator_suspend_begin() to properly set
> + * the rdev->suspend.target field.
Requring these functions to be called from every single driver seems
like we're doing something wrong - if we're going to do this we should
find some way to loop over all regulators and apply any unapplied
changes. Batching things up at the end of suspend would also mean that
we'd be able to minimise the chances that we get the ordering wrong.
For the target bit... we should be able to find some way to figure out
what kind of suspend we're doing without the platform being involved, a
callback from the PM core would be helpful here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170109/6ac2c655/attachment.sig>
^ permalink raw reply
* [PATCH v2] arm64: dts: rockchip: add "rockchip, grf" property for RK3399 PMUCRU/CRU
From: Doug Anderson @ 2017-01-09 18:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483945344-3125-1-git-send-email-zhengxing@rock-chips.com>
Hi,
On Sun, Jan 8, 2017 at 11:02 PM, Xing Zheng <zhengxing@rock-chips.com> wrote:
> The structure rockchip_clk_provider needs to refer the GRF regmap
> in somewhere, if the CRU node has not "rockchip,grf" property,
> calling syscon_regmap_lookup_by_phandle will return an invalid GRF
> regmap, and the MUXGRF type clock will be not supported.
>
> Therefore, we need to add them.
>
> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
> ---
>
> Changes in v2:
> - referring pmugrf for PMUGRU
> - fix the typo "invaild" in COMMIT message
>
> arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
This looks sane to me, but before you land it you need to first send
up a (separate) patch that adjusts:
Documentation/devicetree/bindings/clock/rockchip,rk3399-cru.txt
...it would also be sorta nice if you included an a patch in your
series that actually uses this new functionality.
-Doug
^ permalink raw reply
* [PATCH v2 4/4] dmaengine: pl330: Don't require irq-safe runtime PM
From: Krzysztof Kozlowski @ 2017-01-09 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483970598-6191-5-git-send-email-m.szyprowski@samsung.com>
On Mon, Jan 09, 2017 at 03:03:18PM +0100, Marek Szyprowski wrote:
> This patch replaces irq-safe runtime PM with non-irq-safe version based on
> the new approach. Existing, irq-safe runtime PM implementation for PL330 was
> not bringing much benefits of its own - only clocks were enabled/disabled.
>
> Till now non-irq-safe runtime PM implementation was only possible by calling
> pm_runtime_get/put functions from alloc/free_chan_resources. All other DMA
> engine API functions cannot be called from a context, which permits sleeping.
> Such implementation, in practice would result in keeping DMA controller's
> device active almost all the time, because most of the slave device drivers
> (DMA engine clients) acquire DMA channel in their probe() function and
> released it during driver removal.
>
> This patch provides a new, different approach. It is based on an observation
> that there can be only one slave device using each DMA channel. PL330 hardware
> always has dedicated channels for each peripheral device. Using recently
> introduced device dependencies (links) infrastructure one can ensure proper
> runtime PM state of PL330 DMA controller basing on the runtime PM state of
> the slave device.
>
> In this approach in pl330_alloc_chan_resources() function a new dependency
> is being created between PL330 DMA controller device (as a supplier) and
> given slave device (as a consumer). This way PL330 DMA controller device
> runtime active counter is increased when the slave device is resumed and
> decreased the same time when given slave device is put to suspend. This way
> it has been ensured to keep PL330 DMA controller runtime active if there is
> an active used of any of its DMA channels. Slave device pointer is initially
> stored in per-channel data in of_dma_xlate callback. This is similar to what
> has been already implemented in Exynos IOMMU driver in commit 2f5f44f205cc95
> ("iommu/exynos: Use device dependency links to control runtime pm").
>
> If slave device doesn't implement runtime PM or keeps device runtime active
> all the time, then PL330 DMA controller will be runtime active all the time
> when channel is being allocated. The goal is however to have runtime PM
> added to all devices in the system, because it lets respective power
> domains to be turned off, what gives the best results in terms of power
> saving.
>
> If one requests memory-to-memory channel, runtime active counter is
> increased unconditionally. This might be a drawback of this approach, but
> PL330 is not really used for memory-to-memory operations due to poor
> performance in such operations compared to the CPU.
>
> Introducing non-irq-safe runtime power management finally allows to turn off
> audio power domain on Exynos5 SoCs.
>
> Removal of irq-safe runtime PM is based on the revert of the following
> commits:
> 1. "dmaengine: pl330: fix runtime pm support" commit
> 5c9e6c2b2ba3ec3a442e2fb5b4286498f8b4dcb7
> 2. "dmaengine: pl330: Fix hang on dmaengine_terminate_all on certain boards"
> commit 81cc6edc08705ac0146fe6ac14a0982a31ce6f3d
> 3. "ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12"
> commit ae43b3289186480f81c78bb63d788a85a3631f47
Checkpatch will complain here. I think following standard pattern of
'commit XYZ ("abc")' makes sense.
Beside that, one not important remark below.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/dma/pl330.c | 124 ++++++++++++++++++++++++++--------------------------
> 1 file changed, 61 insertions(+), 63 deletions(-)
>
> diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> index 9c72f535739c..2cffbb44b09e 100644
> --- a/drivers/dma/pl330.c
> +++ b/drivers/dma/pl330.c
> @@ -268,9 +268,6 @@ enum pl330_byteswap {
>
> #define NR_DEFAULT_DESC 16
>
> -/* Delay for runtime PM autosuspend, ms */
> -#define PL330_AUTOSUSPEND_DELAY 20
> -
> /* Populated by the PL330 core driver for DMA API driver's info */
> struct pl330_config {
> u32 periph_id;
> @@ -449,8 +446,8 @@ struct dma_pl330_chan {
> bool cyclic;
>
> /* for runtime pm tracking */
> - bool active;
> struct device *slave;
> + struct device_link *slave_link;
> };
>
> struct pl330_dmac {
> @@ -2016,7 +2013,6 @@ static void pl330_tasklet(unsigned long data)
> struct dma_pl330_chan *pch = (struct dma_pl330_chan *)data;
> struct dma_pl330_desc *desc, *_dt;
> unsigned long flags;
> - bool power_down = false;
>
> spin_lock_irqsave(&pch->lock, flags);
>
> @@ -2031,18 +2027,10 @@ static void pl330_tasklet(unsigned long data)
> /* Try to submit a req imm. next to the last completed cookie */
> fill_queue(pch);
>
> - if (list_empty(&pch->work_list)) {
> - spin_lock(&pch->thread->dmac->lock);
> - _stop(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - power_down = true;
> - pch->active = false;
> - } else {
> - /* Make sure the PL330 Channel thread is active */
> - spin_lock(&pch->thread->dmac->lock);
> - _start(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - }
> + /* Make sure the PL330 Channel thread is active */
> + spin_lock(&pch->thread->dmac->lock);
> + _start(pch->thread);
> + spin_unlock(&pch->thread->dmac->lock);
>
> while (!list_empty(&pch->completed_list)) {
> struct dmaengine_desc_callback cb;
> @@ -2055,13 +2043,6 @@ static void pl330_tasklet(unsigned long data)
> if (pch->cyclic) {
> desc->status = PREP;
> list_move_tail(&desc->node, &pch->work_list);
> - if (power_down) {
> - pch->active = true;
> - spin_lock(&pch->thread->dmac->lock);
> - _start(pch->thread);
> - spin_unlock(&pch->thread->dmac->lock);
> - power_down = false;
> - }
> } else {
> desc->status = FREE;
> list_move_tail(&desc->node, &pch->dmac->desc_pool);
> @@ -2076,12 +2057,6 @@ static void pl330_tasklet(unsigned long data)
> }
> }
> spin_unlock_irqrestore(&pch->lock, flags);
> -
> - /* If work list empty, power down */
> - if (power_down) {
> - pm_runtime_mark_last_busy(pch->dmac->ddma.dev);
> - pm_runtime_put_autosuspend(pch->dmac->ddma.dev);
> - }
> }
>
> bool pl330_filter(struct dma_chan *chan, void *param)
> @@ -2125,11 +2100,52 @@ static struct dma_chan *of_dma_pl330_xlate(struct of_phandle_args *dma_spec,
> return dma_get_slave_channel(&pl330->peripherals[chan_id].chan);
> }
>
> +static int pl330_add_slave_link(struct pl330_dmac *pl330,
> + struct dma_pl330_chan *pch)
> +{
> + struct device_link *link;
> + int i;
> +
> + if (pch->slave_link)
> + return 0;
> +
> + link = device_link_add(pch->slave, pl330->ddma.dev,
> + DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE);
Align the arguments with open parenthesis?
Anyway, nice job!
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c35bd06d-f012-1289-e765-02dc26b87e27@gmail.com>
On 09/01/17 19:45, Matthias Brugger wrote:
>
>
> On 09/01/17 12:29, Hans Verkuil wrote:
>> Hi Rick,
>>
>> On 01/06/2017 03:34 AM, Rick Chang wrote:
>>> Hi Hans,
>>>
>>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you
>>> have
>>> any idea about this patch series? Should we wait for [2] or we could
>>> merge
>>> the source code and dt-binding first?
>>
>> Looking at [2] I noticed that the last comment was July 4th. What is
>> the reason
>> it hasn't been merged yet?
>>
>> If I know [2] will be merged for 4.11, then I am fine with merging
>> this media
>> patch series. The dependency of this patch on [2] is something Mauro
>> can handle.
>>
>> If [2] is not merged for 4.11, then I think it is better to wait until
>> it is
>> merged.
>>
>
> I can't take [2] because there is no scpsys in the dts present. It seems
> that it got never posted.
>
> Rick can you please follow-up with James and provide a patch which adds
> a scpsys node to the mt2701.dtsi?
>
Ah I forgot, dts patches should go through my tree, so Hans please don't
merge this patch. Bindings should go through your branch though.
Thanks,
Matthias
^ permalink raw reply
* [PATCH v6 3/3] arm: dts: mt2701: Add node for Mediatek JPEG Decoder
From: Matthias Brugger @ 2017-01-09 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <974d20f3-5133-0869-2a35-c1617bec5d6e@xs4all.nl>
On 09/01/17 12:29, Hans Verkuil wrote:
> Hi Rick,
>
> On 01/06/2017 03:34 AM, Rick Chang wrote:
>> Hi Hans,
>>
>> The dependence on [1] has been merged in 4.10, but [2] has not.Do you have
>> any idea about this patch series? Should we wait for [2] or we could merge
>> the source code and dt-binding first?
>
> Looking at [2] I noticed that the last comment was July 4th. What is the reason
> it hasn't been merged yet?
>
> If I know [2] will be merged for 4.11, then I am fine with merging this media
> patch series. The dependency of this patch on [2] is something Mauro can handle.
>
> If [2] is not merged for 4.11, then I think it is better to wait until it is
> merged.
>
I can't take [2] because there is no scpsys in the dts present. It seems
that it got never posted.
Rick can you please follow-up with James and provide a patch which adds
a scpsys node to the mt2701.dtsi?
Thanks,
Matthias
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox