* [PATCH 1/1] mfd: Remove unused variable using Coccinelle
From: Shyam Saini @ 2016-10-10 1:36 UTC (permalink / raw)
To: linux-arm-kernel
The variable err is initialized but never used otherwise.
The semantic patch that makes this change is as follows:
// <smpl>
@@
type T;
identifier i;
constant C;
@@
(
extern T i;
|
- T i;
<+... when != i
- i = C;
...+>
)
// </smpl>
Signed-off-by: Shyam Saini <mayhs11saini@gmail.com>
---
drivers/mfd/ab3100-core.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/mfd/ab3100-core.c b/drivers/mfd/ab3100-core.c
index 6a5a988..3ebb2f0 100644
--- a/drivers/mfd/ab3100-core.c
+++ b/drivers/mfd/ab3100-core.c
@@ -584,8 +584,6 @@ static struct dentry *ab3100_set_reg_file;
static void ab3100_setup_debugfs(struct ab3100 *ab3100)
{
- int err;
-
ab3100_dir = debugfs_create_dir("ab3100", NULL);
if (!ab3100_dir)
goto exit_no_debugfs;
@@ -594,7 +592,6 @@ static void ab3100_setup_debugfs(struct ab3100 *ab3100)
S_IRUGO, ab3100_dir, ab3100,
&ab3100_registers_fops);
if (!ab3100_reg_file) {
- err = -ENOMEM;
goto exit_destroy_dir;
}
@@ -604,7 +601,6 @@ static void ab3100_setup_debugfs(struct ab3100 *ab3100)
S_IWUSR, ab3100_dir, &ab3100_get_priv,
&ab3100_get_set_reg_fops);
if (!ab3100_get_reg_file) {
- err = -ENOMEM;
goto exit_destroy_reg;
}
@@ -614,7 +610,6 @@ static void ab3100_setup_debugfs(struct ab3100 *ab3100)
S_IWUSR, ab3100_dir, &ab3100_set_priv,
&ab3100_get_set_reg_fops);
if (!ab3100_set_reg_file) {
- err = -ENOMEM;
goto exit_destroy_get_reg;
}
return;
--
2.7.4
^ permalink raw reply related
* [PATCH 8/8] pinctrl: aspeed-g5: Add mux configuration for all pins
From: Rob Herring @ 2016-10-10 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a17175fdeaf1656afa307a180a4ab4953d4ad19c.1474986045.git-series.andrew@aj.id.au>
On Wed, Sep 28, 2016 at 12:20:20AM +0930, Andrew Jeffery wrote:
> The patch introducing the g5 pinctrl driver implemented a smattering of
> pins to flesh out the implementation of the core and provide bare-bones
> support for some OpenPOWER platforms and the AST2500 evaluation board.
> Now, update the bindings document to reflect the complete functionality
> and implement the necessary pin configuration tables in the driver.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/pinctrl/pinctrl-aspeed.txt | 17 +-
Acked-by: Rob Herring <robh@kernel.org>
> drivers/pinctrl/aspeed/pinctrl-aspeed-g5.c | 1476 ++++++-
> drivers/pinctrl/aspeed/pinctrl-aspeed.h | 1 +-
> 3 files changed, 1487 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH 2/2] arm: futex: Use asm-generic/futex.h instead of redefining the entire header
From: Joel Porquet @ 2016-10-10 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010000308.13212-1-joel@porquet.org>
"asm-generic/futex.h" was refactored and now allows arch ports to only
define arch-specific macros instead of redefining the entire header
file.
This patch adapts "asm/futex.h" for ARM by only defining the macros
required by the generic header (ie __futex_atomic_op_inuser() and
__futex_atomic_cmpxchg_inatomic()).
Compiled (SMP and !SMP) and booted on QEMU with a minimal busybox-based
system.
Signed-off-by: Joel Porquet <joel@porquet.org>
---
arch/arm/include/asm/futex.h | 203 ++++++++++++++++++-------------------------
1 file changed, 84 insertions(+), 119 deletions(-)
diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
index 6795368..d3db562 100644
--- a/arch/arm/include/asm/futex.h
+++ b/arch/arm/include/asm/futex.h
@@ -39,41 +39,30 @@
: "r" (uaddr), "r" (oparg), "Ir" (-EFAULT) \
: "cc", "memory"); \
uaccess_restore(__ua_flags); \
+ smp_mb(); \
})
-static inline int
-futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
- u32 oldval, u32 newval)
-{
- unsigned int __ua_flags;
- int ret;
- u32 val;
-
- if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
- return -EFAULT;
-
- smp_mb();
- /* Prefetching cannot fault */
- prefetchw(uaddr);
- __ua_flags = uaccess_save_and_enable();
- __asm__ __volatile__("@futex_atomic_cmpxchg_inatomic\n"
- "1: ldrex %1, [%4]\n"
- " teq %1, %2\n"
- " ite eq @ explicit IT needed for the 2b label\n"
- "2: strexeq %0, %3, [%4]\n"
- " movne %0, #0\n"
- " teq %0, #0\n"
- " bne 1b\n"
- __futex_atomic_ex_table("%5")
- : "=&r" (ret), "=&r" (val)
- : "r" (oldval), "r" (newval), "r" (uaddr), "Ir" (-EFAULT)
- : "cc", "memory");
- uaccess_restore(__ua_flags);
- smp_mb();
-
- *uval = val;
- return ret;
-}
+#define __futex_atomic_cmpxchg_op(ret, val, uaddr, oldval, newval) \
+({ \
+ unsigned int __ua_flags; \
+ smp_mb(); \
+ prefetchw(uaddr); \
+ __ua_flags = uaccess_save_and_enable(); \
+ __asm__ __volatile__( \
+ "1: ldrex %1, [%4]\n" \
+ " teq %1, %2\n" \
+ " ite eq @ explicit IT needed for the 2b label\n" \
+ "2: strexeq %0, %3, [%4]\n" \
+ " movne %0, #0\n" \
+ " teq %0, #0\n" \
+ " bne 1b\n" \
+ __futex_atomic_ex_table("%5") \
+ : "=&r" (ret), "=&r" (val) \
+ : "r" (oldval), "r" (newval), "r" (uaddr), "Ir" (-EFAULT) \
+ : "cc", "memory"); \
+ uaccess_restore(__ua_flags); \
+ smp_mb(); \
+})
#else /* !SMP, we can work around lack of atomic ops by disabling preemption */
@@ -82,7 +71,9 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
#define __futex_atomic_op(insn, ret, oldval, tmp, uaddr, oparg) \
({ \
- unsigned int __ua_flags = uaccess_save_and_enable(); \
+ unsigned int __ua_flags; \
+ preempt_disable(); \
+ __ua_flags = uaccess_save_and_enable(); \
__asm__ __volatile__( \
"1: " TUSER(ldr) " %1, [%3]\n" \
" " insn "\n" \
@@ -93,98 +84,72 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
: "r" (uaddr), "r" (oparg), "Ir" (-EFAULT) \
: "cc", "memory"); \
uaccess_restore(__ua_flags); \
+ preempt_disable(); \
})
-static inline int
-futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
- u32 oldval, u32 newval)
-{
- unsigned int __ua_flags;
- int ret = 0;
- u32 val;
-
- if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
- return -EFAULT;
-
- preempt_disable();
- __ua_flags = uaccess_save_and_enable();
- __asm__ __volatile__("@futex_atomic_cmpxchg_inatomic\n"
- "1: " TUSER(ldr) " %1, [%4]\n"
- " teq %1, %2\n"
- " it eq @ explicit IT needed for the 2b label\n"
- "2: " TUSER(streq) " %3, [%4]\n"
- __futex_atomic_ex_table("%5")
- : "+r" (ret), "=&r" (val)
- : "r" (oldval), "r" (newval), "r" (uaddr), "Ir" (-EFAULT)
- : "cc", "memory");
- uaccess_restore(__ua_flags);
-
- *uval = val;
- preempt_enable();
-
- return ret;
-}
+#define __futex_atomic_cmpxchg_op(ret, val, uaddr, oldval, newval) \
+({ \
+ unsigned int __ua_flags; \
+ preempt_disable(); \
+ __ua_flags = uaccess_save_and_enable(); \
+ __asm__ __volatile__( \
+ "@futex_atomic_cmpxchg_inatomic\n" \
+ "1: " TUSER(ldr) " %1, [%4]\n" \
+ " teq %1, %2\n" \
+ " it eq @ explicit IT needed for the 2b label\n" \
+ "2: " TUSER(streq) " %3, [%4]\n" \
+ __futex_atomic_ex_table("%5") \
+ : "+r" (ret), "=&r" (val) \
+ : "r" (oldval), "r" (newval), "r" (uaddr), "Ir" (-EFAULT) \
+ : "cc", "memory"); \
+ uaccess_restore(__ua_flags); \
+ preempt_enable(); \
+})
#endif /* !SMP */
-static inline int
-futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
-{
- int op = (encoded_op >> 28) & 7;
- int cmp = (encoded_op >> 24) & 15;
- int oparg = (encoded_op << 8) >> 20;
- int cmparg = (encoded_op << 20) >> 20;
- int oldval = 0, ret, tmp;
+#define __futex_atomic_op_inuser(op, oldval, uaddr, oparg) \
+({ \
+ int __ret, tmp; \
+ pagefault_disable(); \
+ switch (op) { \
+ case FUTEX_OP_SET: \
+ __futex_atomic_op("mov %0, %4", \
+ __ret, oldval, tmp, uaddr, oparg); \
+ break; \
+ case FUTEX_OP_ADD: \
+ __futex_atomic_op("add %0, %1, %4", \
+ __ret, oldval, tmp, uaddr, oparg); \
+ break; \
+ case FUTEX_OP_OR: \
+ __futex_atomic_op("orr %0, %1, %4", \
+ __ret, oldval, tmp, uaddr, oparg); \
+ break; \
+ case FUTEX_OP_ANDN: \
+ __futex_atomic_op("and %0, %1, %4", \
+ __ret, oldval, tmp, uaddr, ~oparg); \
+ break; \
+ case FUTEX_OP_XOR: \
+ __futex_atomic_op("eor %0, %1, %4", \
+ __ret, oldval, tmp, uaddr, oparg); \
+ break; \
+ default: \
+ ret = -ENOSYS; \
+ } \
+ pagefault_enable(); \
+ __ret; \
+})
- if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
- oparg = 1 << oparg;
+#define __futex_atomic_cmpxchg_inatomic(uval, uaddr, oldval, newval) \
+({ \
+ int __ret; \
+ u32 val; \
+ __futex_atomic_cmpxchg_op(__ret, val, uaddr, oldval, newval); \
+ *uval = val; \
+ __ret; \
+})
- if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
- return -EFAULT;
-
-#ifndef CONFIG_SMP
- preempt_disable();
-#endif
- pagefault_disable();
-
- switch (op) {
- case FUTEX_OP_SET:
- __futex_atomic_op("mov %0, %4", ret, oldval, tmp, uaddr, oparg);
- break;
- case FUTEX_OP_ADD:
- __futex_atomic_op("add %0, %1, %4", ret, oldval, tmp, uaddr, oparg);
- break;
- case FUTEX_OP_OR:
- __futex_atomic_op("orr %0, %1, %4", ret, oldval, tmp, uaddr, oparg);
- break;
- case FUTEX_OP_ANDN:
- __futex_atomic_op("and %0, %1, %4", ret, oldval, tmp, uaddr, ~oparg);
- break;
- case FUTEX_OP_XOR:
- __futex_atomic_op("eor %0, %1, %4", ret, oldval, tmp, uaddr, oparg);
- break;
- default:
- ret = -ENOSYS;
- }
-
- pagefault_enable();
-#ifndef CONFIG_SMP
- preempt_enable();
-#endif
-
- if (!ret) {
- switch (cmp) {
- case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
- case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
- case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
- case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
- case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
- case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
- default: ret = -ENOSYS;
- }
- }
- return ret;
-}
+#include <asm-generic/futex.h>
#endif /* __KERNEL__ */
#endif /* _ASM_ARM_FUTEX_H */
--
2.10.0
^ permalink raw reply related
* [PATCH 1/2] asm-generic/futex.h: code refactoring
From: Joel Porquet @ 2016-10-10 0:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161010000308.13212-1-joel@porquet.org>
The generic header "asm-generic/futex.h" defines the implementations of
atomic functions "futex_atomic_op_inuser()" and
"futex_atomic_cmpxchg_inatomic()". Currently, each of these functions is
actually defined twice: once for uniprocessor machines and once for
multiprocessor machines.
However, these {smp,!smp} implementations, especially for
"futex_atomic_op_inuser()", have some code in common that could be
refactored. Furthermore, most the arch ports usually redefine their own
"asm/futex.h" header completely, instead of using the generic header
even though a good chunk of the code is shared (once again, especially
for 'futex_atomic_op_inuser()').
This patch refactors the uniprocessor and multiprocessor implementations
of both functions into a single implementation, making the
machine-specific part a customizable macro.
As a (hopefully good) side-effect, this makes it possible for arch ports
to start including this generic header, instead of redefining it
completely, and only overload the macros with arch-specific routines.
Signed-off-by: Joel Porquet <joel@porquet.org>
---
include/asm-generic/futex.h | 219 ++++++++++++++++++++++----------------------
1 file changed, 112 insertions(+), 107 deletions(-)
diff --git a/include/asm-generic/futex.h b/include/asm-generic/futex.h
index bf2d34c..a72b36b 100644
--- a/include/asm-generic/futex.h
+++ b/include/asm-generic/futex.h
@@ -6,12 +6,114 @@
#include <asm/errno.h>
#ifndef CONFIG_SMP
+
/*
- * The following implementation only for uniprocessor machines.
- * It relies on preempt_disable() ensuring mutual exclusion.
- *
+ * The following implementations are for uniprocessor machines.
+ * They rely on preempt_disable() to ensure mutual exclusion.
*/
+#ifndef __futex_atomic_op_inuser
+#define __futex_atomic_op_inuser(op, oldval, uaddr, oparg) \
+({ \
+ int __ret; \
+ u32 tmp; \
+ \
+ preempt_disable(); \
+ pagefault_disable(); \
+ \
+ __ret = -EFAULT; \
+ if (unlikely(get_user(oldval, uaddr) != 0)) \
+ goto out_pagefault_enable; \
+ \
+ __ret = 0; \
+ tmp = oldval; \
+ \
+ switch (op) { \
+ case FUTEX_OP_SET: \
+ tmp = oparg; \
+ break; \
+ case FUTEX_OP_ADD: \
+ tmp += oparg; \
+ break; \
+ case FUTEX_OP_OR: \
+ tmp |= oparg; \
+ break; \
+ case FUTEX_OP_ANDN: \
+ tmp &= ~oparg; \
+ break; \
+ case FUTEX_OP_XOR: \
+ tmp ^= oparg; \
+ break; \
+ default: \
+ __ret = -ENOSYS; \
+ } \
+ \
+ if (__ret == 0 && unlikely(put_user(tmp, uaddr) != 0)) \
+ __ret = -EFAULT; \
+ \
+out_pagefault_enable: \
+ pagefault_enable(); \
+ preempt_enable(); \
+ \
+ __ret; \
+})
+#endif
+
+#ifndef __futex_atomic_cmpxchg_inatomic
+#define __futex_atomic_cmpxchg_inatomic(uval, uaddr, oldval, newval) \
+({ \
+ int __ret = 0; \
+ u32 tmp; \
+ \
+ preempt_disable(); \
+ if (unlikely(get_user(tmp, uaddr) != 0)) \
+ __ret = -EFAULT; \
+ \
+ if (__ret == 0 && tmp == oldval && \
+ unlikely(put_user(newval, uaddr) != 0)) \
+ __ret = -EFAULT; \
+ \
+ *uval = tmp; \
+ preempt_enable(); \
+ \
+ __ret; \
+})
+#endif
+
+#else
+
+/*
+ * For multiprocessor machines, these macro should be overloaded with
+ * implementations based on arch-specific atomic instructions to ensure proper
+ * mutual exclusion
+ */
+#ifndef __futex_atomic_op_inuser
+#define __futex_atomic_op_inuser(op, oldval, uaddr, oparg) \
+({ \
+ int __ret; \
+ switch (op) { \
+ case FUTEX_OP_SET: \
+ case FUTEX_OP_ADD: \
+ case FUTEX_OP_OR: \
+ case FUTEX_OP_ANDN: \
+ case FUTEX_OP_XOR: \
+ default: \
+ __ret = -ENOSYS; \
+ } \
+ __ret; \
+})
+#endif
+
+#ifndef __futex_atomic_cmpxchg_inatomic
+#define __futex_atomic_cmpxchg_inatomic(uval, uaddr, oldval, newval) \
+({ \
+ int __ret = -ENOSYS; \
+ __ret; \
+})
+#endif
+
+#endif
+
/**
* futex_atomic_op_inuser() - Atomic arithmetic operation with constant
* argument and comparison of the previous
@@ -31,48 +133,15 @@ futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
int cmp = (encoded_op >> 24) & 15;
int oparg = (encoded_op << 8) >> 20;
int cmparg = (encoded_op << 20) >> 20;
- int oldval, ret;
- u32 tmp;
+ int oldval = 0, ret;
if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
oparg = 1 << oparg;
- preempt_disable();
- pagefault_disable();
+ if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
+ return -EFAULT;
- ret = -EFAULT;
- if (unlikely(get_user(oldval, uaddr) != 0))
- goto out_pagefault_enable;
-
- ret = 0;
- tmp = oldval;
-
- switch (op) {
- case FUTEX_OP_SET:
- tmp = oparg;
- break;
- case FUTEX_OP_ADD:
- tmp += oparg;
- break;
- case FUTEX_OP_OR:
- tmp |= oparg;
- break;
- case FUTEX_OP_ANDN:
- tmp &= ~oparg;
- break;
- case FUTEX_OP_XOR:
- tmp ^= oparg;
- break;
- default:
- ret = -ENOSYS;
- }
-
- if (ret == 0 && unlikely(put_user(tmp, uaddr) != 0))
- ret = -EFAULT;
-
-out_pagefault_enable:
- pagefault_enable();
- preempt_enable();
+ ret = __futex_atomic_op_inuser(op, oldval, uaddr, oparg);
if (ret == 0) {
switch (cmp) {
@@ -103,76 +172,12 @@ futex_atomic_op_inuser(int encoded_op, u32 __user *uaddr)
*/
static inline int
futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
- u32 oldval, u32 newval)
+ u32 oldval, u32 newval)
{
- u32 val;
-
- preempt_disable();
- if (unlikely(get_user(val, uaddr) != 0)) {
- preempt_enable();
- return -EFAULT;
- }
-
- if (val == oldval && unlikely(put_user(newval, uaddr) != 0)) {
- preempt_enable();
- return -EFAULT;
- }
-
- *uval = val;
- preempt_enable();
-
- return 0;
-}
-
-#else
-static inline int
-futex_atomic_op_inuser (int encoded_op, u32 __user *uaddr)
-{
- int op = (encoded_op >> 28) & 7;
- int cmp = (encoded_op >> 24) & 15;
- int oparg = (encoded_op << 8) >> 20;
- int cmparg = (encoded_op << 20) >> 20;
- int oldval = 0, ret;
- if (encoded_op & (FUTEX_OP_OPARG_SHIFT << 28))
- oparg = 1 << oparg;
-
- if (! access_ok (VERIFY_WRITE, uaddr, sizeof(u32)))
+ if (!access_ok(VERIFY_WRITE, uaddr, sizeof(u32)))
return -EFAULT;
- pagefault_disable();
-
- switch (op) {
- case FUTEX_OP_SET:
- case FUTEX_OP_ADD:
- case FUTEX_OP_OR:
- case FUTEX_OP_ANDN:
- case FUTEX_OP_XOR:
- default:
- ret = -ENOSYS;
- }
-
- pagefault_enable();
-
- if (!ret) {
- switch (cmp) {
- case FUTEX_OP_CMP_EQ: ret = (oldval == cmparg); break;
- case FUTEX_OP_CMP_NE: ret = (oldval != cmparg); break;
- case FUTEX_OP_CMP_LT: ret = (oldval < cmparg); break;
- case FUTEX_OP_CMP_GE: ret = (oldval >= cmparg); break;
- case FUTEX_OP_CMP_LE: ret = (oldval <= cmparg); break;
- case FUTEX_OP_CMP_GT: ret = (oldval > cmparg); break;
- default: ret = -ENOSYS;
- }
- }
- return ret;
-}
-
-static inline int
-futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
- u32 oldval, u32 newval)
-{
- return -ENOSYS;
+ return __futex_atomic_cmpxchg_inatomic(uval, uaddr, oldval, newval);
}
-#endif /* CONFIG_SMP */
#endif
--
2.10.0
^ permalink raw reply related
* [PATCH 0/2] make asm-generic/futex.h usable for more arch ports
From: Joel Porquet @ 2016-10-10 0:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I've had a patch on my shelf for a couple of years, from when I ported Linux on
a new processor architecture for an academic project, and thought I could send
it and let you decide if it's worth taking or not.
During my port, I basically modified the generic header "asm-generic/futex.h"
and made it into a more generic version so that I could include it in my code
and only redefine the necessary arch-specific bits.
Right now, most of the arch ports redefine their own "asm/futex.h" completely
although, for example for "futex_atomic_op_inuser()", they often share the exact
same preamble and epilogue and could benefit from some code refactoring.
My (short) series is made of two patches: 1/ refactoring "asm-generic/futex.h"
in order to make the arch-specific routines into overload-able macros that arch
ports can redefine when required, 2/ an example of how to use this refactoring
with the ARM port.
Let me know what you think.
Cheers,
Jo?l
Joel Porquet (2):
asm-generic/futex.h: code refactoring
arm: futex: Use asm-generic/futex.h instead of redefining the entire
header
arch/arm/include/asm/futex.h | 203 +++++++++++++++++----------------------
include/asm-generic/futex.h | 219 ++++++++++++++++++++++---------------------
2 files changed, 196 insertions(+), 226 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Mark Rutland @ 2016-10-09 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-V+OKoeNFqvHvQOOFYi4VLm5mLKrmf9Z5oZY4KQkirsQ@mail.gmail.com>
On Fri, Oct 07, 2016 at 10:31:14AM +0100, Ard Biesheuvel wrote:
> On 12 September 2016 at 17:15, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> > Move the statically allocated zero page from the .bss section to right
> > before swapper_pg_dir. This allows us to refer to its physical address
> > by simply reading TTBR1_EL1 (which always points to swapper_pg_dir and
> > always has its ASID field cleared), and subtracting PAGE_SIZE.
> >
> > To protect the zero page from inadvertent modification, carve out a
> > segment that covers it as well as idmap_pg_dir[], and mark it read-only
> > in both the primary and the linear mappings of the kernel.
[...]
> > - map_kernel_segment(pgd, _data, _end, PAGE_KERNEL, &vmlinux_data);
> > + map_kernel_segment(pgd, _data, __robss_start, PAGE_KERNEL,
> > + &vmlinux_data);
> > + map_kernel_segment(pgd, __robss_start, __robss_end, PAGE_KERNEL_RO,
> > + &vmlinux_robss);
>
> I realised it is actually unnecessary to map the idmap and the zero
> page into the kernel mapping, so we could drop this line.
Given that drivers use the zero page, I wouldn't be entirely surprised to see
phys_to_virt(virt_to_phys(zero_page)) happen indirectly, and the end result
read. Are we sure that doesn't happen anywhere?
For the idmap, I think we might walk that were we to take a fault (though
perhaps we don't). Otherwise, unless we add a sysfs walker for it I guess we
don't strictly need it in the linear map.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Alan Stern @ 2016-10-09 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009163446.GA9672@kozik-lap>
On Sun, 9 Oct 2016, Krzysztof Kozlowski wrote:
> On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> > Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> > as to avoid them being build when not used. This also allows us to use the
> > SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
> >
> > Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> > ---
> > drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> > index 42e5b66..1899900 100644
> > --- a/drivers/usb/host/ehci-exynos.c
> > +++ b/drivers/usb/host/ehci-exynos.c
> > @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> > return 0;
> > }
> >
> > -#ifdef CONFIG_PM
> > +#ifdef CONFIG_PM_SLEEP
>
> Does not look like an equivalent change. How will it behave in a config
> with !SUSPEND && !HIBERNATE && PM?
It's hard to say what Anand originally had in mind. To me, it looks
like it will behave exactly the same as before, the only difference
being that the object image will not contain unused exynos_ehci_suspend
and exynos_ehci_resume routines. And the compiler won't issue a
warning at build time that the routines are unused.
Alan Stern
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Chris Wilson @ 2016-10-09 19:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAEi0qNnozbib-92NwWpUV=_YiiUHYGzzBuuY8kDZY9gaZm-W7Q@mail.gmail.com>
On Sun, Oct 09, 2016 at 12:00:31PM -0700, Joel Fernandes wrote:
> Ok. So I'll submit a patch with mutex for purge_lock and use
> cond_resched_lock for the vmap_area_lock as you suggested. I'll also
> drop the lazy_max_pages to 8MB as Andi suggested to reduce the lock
> hold time. Let me know if you have any objections.
The downside of using a mutex here though, is that we may be called
from contexts that cannot sleep (alloc_vmap_area), or reschedule for
that matter! If we change the notion of purged, we can forgo the mutex
in favour of spinning on the direct reclaim path. That just leaves the
complication of whether to use cond_resched_lock() or a lock around
the individual __free_vmap_area().
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 19:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009183933.GA15270@kozik-lap>
hi Krzysztof,
On 10 October 2016 at 00:09, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 11:57:59PM +0530, Anand Moon wrote:
>> hi Krzysztof,
>>
>> On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
>> >> Hi Krzysztof,
>> >>
>> >> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> >> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> >> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> >> >> as to avoid them being build when not used. This also allows us to use the
>> >> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>> >> >>
>> >> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> >> ---
>> >> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> >> >> 1 file changed, 6 insertions(+), 8 deletions(-)
>> >> >>
>> >> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> >> >> index 42e5b66..1899900 100644
>> >> >> --- a/drivers/usb/host/ehci-exynos.c
>> >> >> +++ b/drivers/usb/host/ehci-exynos.c
>> >> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> >> >> return 0;
>> >> >> }
>> >> >>
>> >> >> -#ifdef CONFIG_PM
>> >> >> +#ifdef CONFIG_PM_SLEEP
>> >> >
>> >> > Does not look like an equivalent change. How will it behave in a config
>> >> > with !SUSPEND && !HIBERNATE && PM?
>> >> >
>> >>
>> >> [snip]
>> >>
>> >> I just wanted to update suspend and resume callback to use
>> >> SET_SYSTEM_SLEEP_PM_OPS
>> >> as they are define under CONFIG_PM_SLEEP so I update above to avoid
>> >> compilation warning/error.
>> >
>> Apologize: for not understanding your question.
>>
>> > First of all you did not answer to my question, so let me rephrase into
>> > two:
>> > 1. Is the code equivalent?
>>
>> No CONFIG_PM and CONFIG_PM_SLEEP are different options.
>> But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
>
> So the code is not equivalent...
>
>>
>> CONFIG_PM_SLEEP=n or
>> # CONFIG_PM_SLEEP is not set
>>
>> > 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
>>
>> #
>> # Power management options
>> #
>> # CONFIG_SUSPEND is not set
>> # CONFIG_HIBERNATION is not set
>> # CONFIG_PM is not set
>>
>> When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
>> CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
>
> In my config, the CONFIG_PM was enabled thus the code changes the
> functionality... Maybe this was intented but I really don't get it from
> the commit message or from your explanations here.
>
> Krzysztof
Ok I will keep the changes to use CONFIG_PM,
but use the SET_SYSTEM_SLEEP_PM_OPS option in V2 patch.
Is that ok.
-Best Regards
-Anand Moon
^ permalink raw reply
* [PATCH] mm/vmalloc: reduce the number of lazy_max_pages to reduce latency
From: Joel Fernandes @ 2016-10-09 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009124242.GA2718@nuc-i3427.alporthouse.com>
On Sun, Oct 9, 2016 at 5:42 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
[..]
>> > My understanding is that
>> >
>> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
>> > index 91f44e78c516..3f7c6d6969ac 100644
>> > --- a/mm/vmalloc.c
>> > +++ b/mm/vmalloc.c
>> > @@ -626,7 +626,6 @@ void set_iounmap_nonlazy(void)
>> > static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> > int sync, int force_flush)
>> > {
>> > - static DEFINE_SPINLOCK(purge_lock);
>> > struct llist_node *valist;
>> > struct vmap_area *va;
>> > struct vmap_area *n_va;
>> > @@ -637,12 +636,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> > * should not expect such behaviour. This just simplifies locking for
>> > * the case that isn't actually used at the moment anyway.
>> > */
>> > - if (!sync && !force_flush) {
>> > - if (!spin_trylock(&purge_lock))
>> > - return;
>> > - } else
>> > - spin_lock(&purge_lock);
>> > -
>> > if (sync)
>> > purge_fragmented_blocks_allcpus();
>> >
>> > @@ -667,7 +660,6 @@ static void __purge_vmap_area_lazy(unsigned long *start, unsigned long *end,
>> > __free_vmap_area(va);
>> > spin_unlock(&vmap_area_lock);
>> > }
>> > - spin_unlock(&purge_lock);
>> > }
>> >
>> [..]
>> > should now be safe. That should significantly reduce the preempt-disabled
>> > section, I think.
>>
>> I believe that the purge_lock is supposed to prevent concurrent purges
>> from happening.
>>
>> For the case where if you have another concurrent overflow happen in
>> alloc_vmap_area() between the spin_unlock and purge :
>>
>> spin_unlock(&vmap_area_lock);
>> if (!purged)
>> purge_vmap_area_lazy();
>>
>> Then the 2 purges would happen at the same time and could subtract
>> vmap_lazy_nr twice.
>
> That itself is not the problem, as each instance of
> __purge_vmap_area_lazy() operates on its own freelist, and so there will
> be no double accounting.
>
> However, removing the lock removes the serialisation which does mean
> that alloc_vmap_area() will not block on another thread conducting the
> purge, and so it will try to reallocate before that is complete and the
> free area made available. It also means that we are doing the
> atomic_sub(vmap_lazy_nr) too early.
>
> That supports making the outer lock a mutex as you suggested. But I think
> cond_resched_lock() is better for the vmap_area_lock (just because it
> turns out to be an expensive loop and we may want the reschedule).
> -Chris
Ok. So I'll submit a patch with mutex for purge_lock and use
cond_resched_lock for the vmap_area_lock as you suggested. I'll also
drop the lazy_max_pages to 8MB as Andi suggested to reduce the lock
hold time. Let me know if you have any objections.
Thanks,
Joel
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Krzysztof Kozlowski @ 2016-10-09 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgS9tbhPK4jwoqR6G1=iKAo15H3Dizu3Lp03KMGbQ4aj9A@mail.gmail.com>
On Sun, Oct 09, 2016 at 11:57:59PM +0530, Anand Moon wrote:
> hi Krzysztof,
>
> On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
> >> Hi Krzysztof,
> >>
> >> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> >> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> >> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> >> >> as to avoid them being build when not used. This also allows us to use the
> >> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
> >> >>
> >> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> >> ---
> >> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> >> >> 1 file changed, 6 insertions(+), 8 deletions(-)
> >> >>
> >> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> >> >> index 42e5b66..1899900 100644
> >> >> --- a/drivers/usb/host/ehci-exynos.c
> >> >> +++ b/drivers/usb/host/ehci-exynos.c
> >> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> >> >> return 0;
> >> >> }
> >> >>
> >> >> -#ifdef CONFIG_PM
> >> >> +#ifdef CONFIG_PM_SLEEP
> >> >
> >> > Does not look like an equivalent change. How will it behave in a config
> >> > with !SUSPEND && !HIBERNATE && PM?
> >> >
> >>
> >> [snip]
> >>
> >> I just wanted to update suspend and resume callback to use
> >> SET_SYSTEM_SLEEP_PM_OPS
> >> as they are define under CONFIG_PM_SLEEP so I update above to avoid
> >> compilation warning/error.
> >
> Apologize: for not understanding your question.
>
> > First of all you did not answer to my question, so let me rephrase into
> > two:
> > 1. Is the code equivalent?
>
> No CONFIG_PM and CONFIG_PM_SLEEP are different options.
> But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
So the code is not equivalent...
>
> CONFIG_PM_SLEEP=n or
> # CONFIG_PM_SLEEP is not set
>
> > 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
>
> #
> # Power management options
> #
> # CONFIG_SUSPEND is not set
> # CONFIG_HIBERNATION is not set
> # CONFIG_PM is not set
>
> When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
> CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
In my config, the CONFIG_PM was enabled thus the code changes the
functionality... Maybe this was intented but I really don't get it from
the commit message or from your explanations here.
Krzysztof
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009172757.GA11916@kozik-lap>
hi Krzysztof,
On 9 October 2016 at 22:57, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> >> as to avoid them being build when not used. This also allows us to use the
>> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>> >>
>> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> >> ---
>> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> >> 1 file changed, 6 insertions(+), 8 deletions(-)
>> >>
>> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> >> index 42e5b66..1899900 100644
>> >> --- a/drivers/usb/host/ehci-exynos.c
>> >> +++ b/drivers/usb/host/ehci-exynos.c
>> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> >> return 0;
>> >> }
>> >>
>> >> -#ifdef CONFIG_PM
>> >> +#ifdef CONFIG_PM_SLEEP
>> >
>> > Does not look like an equivalent change. How will it behave in a config
>> > with !SUSPEND && !HIBERNATE && PM?
>> >
>>
>> [snip]
>>
>> I just wanted to update suspend and resume callback to use
>> SET_SYSTEM_SLEEP_PM_OPS
>> as they are define under CONFIG_PM_SLEEP so I update above to avoid
>> compilation warning/error.
>
Apologize: for not understanding your question.
> First of all you did not answer to my question, so let me rephrase into
> two:
> 1. Is the code equivalent?
No CONFIG_PM and CONFIG_PM_SLEEP are different options.
But I could not disable CONFIG_PM_SLEEP option with either in exynos_defconfig
CONFIG_PM_SLEEP=n or
# CONFIG_PM_SLEEP is not set
> 2. What will be the output with !SUSPEND && !HIBERNATE && PM?
#
# Power management options
#
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
# CONFIG_PM is not set
When CONFIG_SUSPEND and CONFIG_HIBERNATION are not set
CONFIG_PM is disabled and so is CONFIG_PM_SLEEP.
Best Regards
-Anand Moon
>
> You didn't mention compilation warning/error in message commit so I do
> not know what you are thinking about...
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Krzysztof Kozlowski @ 2016-10-09 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22GgjF=wVzL3fF7xzvOZtJpiZjVcFTrvDQAu6T2RCfY89g@mail.gmail.com>
On Mon, Oct 10, 2016 at 02:49:01AM +0900, Tomasz Figa wrote:
> 2016-10-10 1:39 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> > On Sun, Oct 09, 2016 at 04:04:11PM +0900, Tomasz Figa wrote:
> >> Hi Krzysztof,
> >>
> >> 2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> >> >
> >> > Hi,
> >> >
> >> > Changes since v2
> >> > ================
> >> > 1. Combine separate patchsets into one. Previously I sent separately the fixes
> >> > and changes for S3C platforms.
> >> > 2. Fix issues pointed during review.
> >> > 3. Add review tags.
> >> >
> >> > Changes since v1
> >> > ================
> >> > 1. Follow Arnd's suggestion about moving the macros to common place.
> >> > 2. Subjects: replace "GPIO" with "pinctrl".
> >> > 3. There were some major changes here so I did not add Javier's
> >> > reviewed-by and tested-by tags.
> >> >
> >> > Merging
> >> > =======
> >> > Patches #1 and #2 should probably go through pinctrl tree. In that case I would
> >> > appreciate a stable branch/tag so DTS could base on top of it.
> >> >
> >> > Goal
> >> > ====
> >> > Increase readability:
> >> > uart0_data: uart0-data {
> >> > samsung,pins = "gpa0-0", "gpa0-1";
> >> > - samsung,pin-function = <2>;
> >> > - samsung,pin-pud = <0>;
> >> > - samsung,pin-drv = <0>;
> >> > + samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> >> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> >> > + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
> >>
> >> I like the idea, thanks for cleaning this up. However I'd like to
> >> bikeshed the prefix a bit. Since the properties are already prefixed
> >> by "samsung,", I think it would make much more sense to also prefix
> >> the generic values with "SAMSUNG_". Of course for soc/family-specific
> >> values, the soc/family name prefix sounds right.
> >
> > I am lost. Sorry, I don't get what kind of final prefixes you would like
> > to have.
> >
> > SAMSUNG_EXYNOS4_PIN_DRV_LV1
> > SAMSUNG_EXYNOS5260_PIN_DRV_LV1
> > ?
>
> For SoC-specific definitions:
>
> EXYNOS4_PIN_DRV_LV1
> EXYNOS5260_PIN_DRV_LV1
ok... so no change needed in my patch.
>
> >
> >> Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
> >> of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
> >> however hurts the consistency and could confuse the people writing new
> >> dts files.
> >
> > SAMSUNG_S3C64XX_PIN_PUD_NONE
> > SAMSUNG_EXYNOS_PIN_PUD_NONE
>
> For definitions common for the whole Samsung pinctrl driver:
>
> SAMSUNG_PIN_PUD_NONE
These are not the same. The "none" is the same but rest is not.
> But actually I think I missed the fact that there is almost no common
> definitions. Is that correct? Was that the missing part of my
> understanding?
Yes. The only common definition for all Samsung SoCs would be the
function of a pin. On the other hand this will bring inconsistency:
everything prefixed with SoC except the function.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Tomasz Figa @ 2016-10-09 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009163910.GB9672@kozik-lap>
2016-10-10 1:39 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> On Sun, Oct 09, 2016 at 04:04:11PM +0900, Tomasz Figa wrote:
>> Hi Krzysztof,
>>
>> 2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
>> >
>> > Hi,
>> >
>> > Changes since v2
>> > ================
>> > 1. Combine separate patchsets into one. Previously I sent separately the fixes
>> > and changes for S3C platforms.
>> > 2. Fix issues pointed during review.
>> > 3. Add review tags.
>> >
>> > Changes since v1
>> > ================
>> > 1. Follow Arnd's suggestion about moving the macros to common place.
>> > 2. Subjects: replace "GPIO" with "pinctrl".
>> > 3. There were some major changes here so I did not add Javier's
>> > reviewed-by and tested-by tags.
>> >
>> > Merging
>> > =======
>> > Patches #1 and #2 should probably go through pinctrl tree. In that case I would
>> > appreciate a stable branch/tag so DTS could base on top of it.
>> >
>> > Goal
>> > ====
>> > Increase readability:
>> > uart0_data: uart0-data {
>> > samsung,pins = "gpa0-0", "gpa0-1";
>> > - samsung,pin-function = <2>;
>> > - samsung,pin-pud = <0>;
>> > - samsung,pin-drv = <0>;
>> > + samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
>> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
>> > + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
>>
>> I like the idea, thanks for cleaning this up. However I'd like to
>> bikeshed the prefix a bit. Since the properties are already prefixed
>> by "samsung,", I think it would make much more sense to also prefix
>> the generic values with "SAMSUNG_". Of course for soc/family-specific
>> values, the soc/family name prefix sounds right.
>
> I am lost. Sorry, I don't get what kind of final prefixes you would like
> to have.
>
> SAMSUNG_EXYNOS4_PIN_DRV_LV1
> SAMSUNG_EXYNOS5260_PIN_DRV_LV1
> ?
For SoC-specific definitions:
EXYNOS4_PIN_DRV_LV1
EXYNOS5260_PIN_DRV_LV1
>
>> Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
>> of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
>> however hurts the consistency and could confuse the people writing new
>> dts files.
>
> SAMSUNG_S3C64XX_PIN_PUD_NONE
> SAMSUNG_EXYNOS_PIN_PUD_NONE
For definitions common for the whole Samsung pinctrl driver:
SAMSUNG_PIN_PUD_NONE
...
But actually I think I missed the fact that there is almost no common
definitions. Is that correct? Was that the missing part of my
understanding?
Best regards,
Tomasz
^ permalink raw reply
* [PATCH 6/6] crypto: arm64/aes-neon - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The AES implementation using pure NEON instructions relies on the generic
AES key schedule generation routines, which store the round keys as arrays
of 32-bit quantities stored in memory using native endianness. This means
we should refer to these round keys using 4x4 loads rather than 16x1 loads.
In addition, the ShiftRows tables are loading using a single scalar load,
which is also affected by endianness, so emit these tables in the correct
order depending on whether we are building for big endian or not.
Fixes: 49788fe2a128 ("arm64/crypto: AES-ECB/CBC/CTR/XTS using ARMv8 NEON and Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-neon.S | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index b93170e1cc93..85f07ead7c5c 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arch/arm64/crypto/aes-neon.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
#define AES_ENTRY(func) ENTRY(neon_ ## func)
#define AES_ENDPROC(func) ENDPROC(neon_ ## func)
@@ -83,13 +84,13 @@
.endm
.macro do_block, enc, in, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in\().16b, \in\().16b, v15.16b /* ^round key */
tbl \in\().16b, {\in\().16b}, v13.16b /* ShiftRows */
sub_bytes \in
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -229,7 +230,7 @@
.endm
.macro do_block_2x, enc, in0, in1 rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -237,7 +238,7 @@
sub_bytes_2x \in0, \in1
tbl \in0\().16b, {\in0\().16b}, v13.16b /* ShiftRows */
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -254,7 +255,7 @@
.endm
.macro do_block_4x, enc, in0, in1, in2, in3, rounds, rk, rkp, i
- ld1 {v15.16b}, [\rk]
+ ld1 {v15.4s}, [\rk]
add \rkp, \rk, #16
mov \i, \rounds
1111: eor \in0\().16b, \in0\().16b, v15.16b /* ^round key */
@@ -266,7 +267,7 @@
tbl \in1\().16b, {\in1\().16b}, v13.16b /* ShiftRows */
tbl \in2\().16b, {\in2\().16b}, v13.16b /* ShiftRows */
tbl \in3\().16b, {\in3\().16b}, v13.16b /* ShiftRows */
- ld1 {v15.16b}, [\rkp], #16
+ ld1 {v15.4s}, [\rkp], #16
subs \i, \i, #1
beq 2222f
.if \enc == 1
@@ -306,12 +307,16 @@
.text
.align 4
.LForward_ShiftRows:
- .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3
- .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb
+CPU_LE( .byte 0x0, 0x5, 0xa, 0xf, 0x4, 0x9, 0xe, 0x3 )
+CPU_LE( .byte 0x8, 0xd, 0x2, 0x7, 0xc, 0x1, 0x6, 0xb )
+CPU_BE( .byte 0xb, 0x6, 0x1, 0xc, 0x7, 0x2, 0xd, 0x8 )
+CPU_BE( .byte 0x3, 0xe, 0x9, 0x4, 0xf, 0xa, 0x5, 0x0 )
.LReverse_ShiftRows:
- .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb
- .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3
+CPU_LE( .byte 0x0, 0xd, 0xa, 0x7, 0x4, 0x1, 0xe, 0xb )
+CPU_LE( .byte 0x8, 0x5, 0x2, 0xf, 0xc, 0x9, 0x6, 0x3 )
+CPU_BE( .byte 0x3, 0x6, 0x9, 0xc, 0xf, 0x2, 0x5, 0x8 )
+CPU_BE( .byte 0xb, 0xe, 0x1, 0x4, 0x7, 0xa, 0xd, 0x0 )
.LForward_Sbox:
.byte 0x63, 0x7c, 0x77, 0x7b, 0xf2, 0x6b, 0x6f, 0xc5
--
2.7.4
^ permalink raw reply related
* [PATCH 5/6] crypto: arm64/aes-ccm-ce: fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The AES-CCM implementation that uses ARMv8 Crypto Extensions instructions
refers to the AES round keys as pairs of 64-bit quantities, which causes
failures when building the code for big endian. In addition, it byte swaps
the input counter unconditionally, while this is only required for little
endian builds. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
1 file changed, 27 insertions(+), 26 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S
index a2a7fbcacc14..3363560c79b7 100644
--- a/arch/arm64/crypto/aes-ce-ccm-core.S
+++ b/arch/arm64/crypto/aes-ce-ccm-core.S
@@ -9,6 +9,7 @@
*/
#include <linux/linkage.h>
+#include <asm/assembler.h>
.text
.arch armv8-a+crypto
@@ -19,7 +20,7 @@
*/
ENTRY(ce_aes_ccm_auth_data)
ldr w8, [x3] /* leftover from prev round? */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v0.16b}, [x0] /* load mac */
cbz w8, 1f
sub w8, w8, #16
eor v1.16b, v1.16b, v1.16b
@@ -31,7 +32,7 @@ ENTRY(ce_aes_ccm_auth_data)
beq 8f /* out of input? */
cbnz w8, 0b
eor v0.16b, v0.16b, v1.16b
-1: ld1 {v3.2d}, [x4] /* load first round key */
+1: ld1 {v3.16b}, [x4] /* load first round key */
prfm pldl1strm, [x1]
cmp w5, #12 /* which key size? */
add x6, x4, #16
@@ -41,17 +42,17 @@ ENTRY(ce_aes_ccm_auth_data)
mov v5.16b, v3.16b
b 4f
2: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x6], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x6], #16 /* load 2nd round key */
3: aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
-4: ld1 {v3.2d}, [x6], #16 /* load next round key */
+4: ld1 {v3.16b}, [x6], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
-5: ld1 {v4.2d}, [x6], #16 /* load next round key */
+5: ld1 {v4.16b}, [x6], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
- ld1 {v5.2d}, [x6], #16 /* load next round key */
+ ld1 {v5.16b}, [x6], #16 /* load next round key */
bpl 3b
aese v0.16b, v4.16b
subs w2, w2, #16 /* last data? */
@@ -60,7 +61,7 @@ ENTRY(ce_aes_ccm_auth_data)
ld1 {v1.16b}, [x1], #16 /* load next input block */
eor v0.16b, v0.16b, v1.16b /* xor with mac */
bne 1b
-6: st1 {v0.2d}, [x0] /* store mac */
+6: st1 {v0.16b}, [x0] /* store mac */
beq 10f
adds w2, w2, #16
beq 10f
@@ -79,7 +80,7 @@ ENTRY(ce_aes_ccm_auth_data)
adds w7, w7, #1
bne 9b
eor v0.16b, v0.16b, v1.16b
- st1 {v0.2d}, [x0]
+ st1 {v0.16b}, [x0]
10: str w8, [x3]
ret
ENDPROC(ce_aes_ccm_auth_data)
@@ -89,27 +90,27 @@ ENDPROC(ce_aes_ccm_auth_data)
* u32 rounds);
*/
ENTRY(ce_aes_ccm_final)
- ld1 {v3.2d}, [x2], #16 /* load first round key */
- ld1 {v0.2d}, [x0] /* load mac */
+ ld1 {v3.16b}, [x2], #16 /* load first round key */
+ ld1 {v0.16b}, [x0] /* load mac */
cmp w3, #12 /* which key size? */
sub w3, w3, #2 /* modified # of rounds */
- ld1 {v1.2d}, [x1] /* load 1st ctriv */
+ ld1 {v1.16b}, [x1] /* load 1st ctriv */
bmi 0f
bne 3f
mov v5.16b, v3.16b
b 2f
0: mov v4.16b, v3.16b
-1: ld1 {v5.2d}, [x2], #16 /* load next round key */
+1: ld1 {v5.16b}, [x2], #16 /* load next round key */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-2: ld1 {v3.2d}, [x2], #16 /* load next round key */
+2: ld1 {v3.16b}, [x2], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-3: ld1 {v4.2d}, [x2], #16 /* load next round key */
+3: ld1 {v4.16b}, [x2], #16 /* load next round key */
subs w3, w3, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
@@ -120,47 +121,47 @@ ENTRY(ce_aes_ccm_final)
aese v1.16b, v4.16b
/* final round key cancels out */
eor v0.16b, v0.16b, v1.16b /* en-/decrypt the mac */
- st1 {v0.2d}, [x0] /* store result */
+ st1 {v0.16b}, [x0] /* store result */
ret
ENDPROC(ce_aes_ccm_final)
.macro aes_ccm_do_crypt,enc
ldr x8, [x6, #8] /* load lower ctr */
- ld1 {v0.2d}, [x5] /* load mac */
- rev x8, x8 /* keep swabbed ctr in reg */
+ ld1 {v0.16b}, [x5] /* load mac */
+CPU_LE( rev x8, x8 ) /* keep swabbed ctr in reg */
0: /* outer loop */
- ld1 {v1.1d}, [x6] /* load upper ctr */
+ ld1 {v1.8b}, [x6] /* load upper ctr */
prfm pldl1strm, [x1]
add x8, x8, #1
rev x9, x8
cmp w4, #12 /* which key size? */
sub w7, w4, #2 /* get modified # of rounds */
ins v1.d[1], x9 /* no carry in lower ctr */
- ld1 {v3.2d}, [x3] /* load first round key */
+ ld1 {v3.16b}, [x3] /* load first round key */
add x10, x3, #16
bmi 1f
bne 4f
mov v5.16b, v3.16b
b 3f
1: mov v4.16b, v3.16b
- ld1 {v5.2d}, [x10], #16 /* load 2nd round key */
+ ld1 {v5.16b}, [x10], #16 /* load 2nd round key */
2: /* inner loop: 3 rounds, 2x interleaved */
aese v0.16b, v4.16b
aesmc v0.16b, v0.16b
aese v1.16b, v4.16b
aesmc v1.16b, v1.16b
-3: ld1 {v3.2d}, [x10], #16 /* load next round key */
+3: ld1 {v3.16b}, [x10], #16 /* load next round key */
aese v0.16b, v5.16b
aesmc v0.16b, v0.16b
aese v1.16b, v5.16b
aesmc v1.16b, v1.16b
-4: ld1 {v4.2d}, [x10], #16 /* load next round key */
+4: ld1 {v4.16b}, [x10], #16 /* load next round key */
subs w7, w7, #3
aese v0.16b, v3.16b
aesmc v0.16b, v0.16b
aese v1.16b, v3.16b
aesmc v1.16b, v1.16b
- ld1 {v5.2d}, [x10], #16 /* load next round key */
+ ld1 {v5.16b}, [x10], #16 /* load next round key */
bpl 2b
aese v0.16b, v4.16b
aese v1.16b, v4.16b
@@ -177,14 +178,14 @@ ENDPROC(ce_aes_ccm_final)
eor v0.16b, v0.16b, v2.16b /* xor mac with pt ^ rk[last] */
st1 {v1.16b}, [x0], #16 /* write output block */
bne 0b
- rev x8, x8
- st1 {v0.2d}, [x5] /* store mac */
+CPU_LE( rev x8, x8 )
+ st1 {v0.16b}, [x5] /* store mac */
str x8, [x6, #8] /* store lsb end of ctr (BE) */
5: ret
6: eor v0.16b, v0.16b, v5.16b /* final round mac */
eor v1.16b, v1.16b, v5.16b /* final round enc */
- st1 {v0.2d}, [x5] /* store mac */
+ st1 {v0.16b}, [x5] /* store mac */
add w2, w2, #16 /* process partial tail block */
7: ldrb w9, [x1], #1 /* get 1 byte of input */
umov w6, v1.b[0] /* get top crypted ctr byte */
--
2.7.4
^ permalink raw reply related
* [PATCH 4/6] crypto: arm64/sha2-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA256 digest is an array of 8 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x32 vector
ones where appropriate.
Fixes: 6ba6c74dfc6b ("arm64/crypto: SHA-224/SHA-256 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha2-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S
index 5df9d9d470ad..01cfee066837 100644
--- a/arch/arm64/crypto/sha2-ce-core.S
+++ b/arch/arm64/crypto/sha2-ce-core.S
@@ -85,7 +85,7 @@ ENTRY(sha2_ce_transform)
ld1 {v12.4s-v15.4s}, [x8]
/* load state */
- ldp dga, dgb, [x0]
+ ld1 {dgav.4s, dgbv.4s}, [x0]
/* load sha256_ce_state::finalize */
ldr w4, [x0, #:lo12:sha256_ce_offsetof_finalize]
@@ -148,6 +148,6 @@ CPU_LE( rev32 v19.16b, v19.16b )
b 1b
/* store new state */
-3: stp dga, dgb, [x0]
+3: st1 {dgav.4s, dgbv.4s}, [x0]
ret
ENDPROC(sha2_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH 3/6] crypto: arm64/sha1-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The SHA1 digest is an array of 5 32-bit quantities, so we should refer
to them as such in order for this code to work correctly when built for
big endian. So replace 16 byte scalar loads and stores with 4x4 vector
ones where appropriate.
Fixes: 2c98833a42cd ("arm64/crypto: SHA-1 using ARMv8 Crypto Extensions")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/sha1-ce-core.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S
index 033aae6d732a..c98e7e849f06 100644
--- a/arch/arm64/crypto/sha1-ce-core.S
+++ b/arch/arm64/crypto/sha1-ce-core.S
@@ -78,7 +78,7 @@ ENTRY(sha1_ce_transform)
ld1r {k3.4s}, [x6]
/* load state */
- ldr dga, [x0]
+ ld1 {dgav.4s}, [x0]
ldr dgb, [x0, #16]
/* load sha1_ce_state::finalize */
@@ -144,7 +144,7 @@ CPU_LE( rev32 v11.16b, v11.16b )
b 1b
/* store new state */
-3: str dga, [x0]
+3: st1 {dgav.4s}, [x0]
str dgb, [x0, #16]
ret
ENDPROC(sha1_ce_transform)
--
2.7.4
^ permalink raw reply related
* [PATCH 2/6] crypto: arm64/ghash-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The GHASH key and digest are both pairs of 64-bit quantities, but the
GHASH code does not always refer to them as such, causing failures when
built for big endian. So replace the 16x1 loads and stores with 2x8 ones.
Fixes: b913a6404ce2 ("arm64/crypto: improve performance of GHASH algorithm")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/ghash-ce-core.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S
index dc457015884e..f0bb9f0b524f 100644
--- a/arch/arm64/crypto/ghash-ce-core.S
+++ b/arch/arm64/crypto/ghash-ce-core.S
@@ -29,8 +29,8 @@
* struct ghash_key const *k, const char *head)
*/
ENTRY(pmull_ghash_update)
- ld1 {SHASH.16b}, [x3]
- ld1 {XL.16b}, [x1]
+ ld1 {SHASH.2d}, [x3]
+ ld1 {XL.2d}, [x1]
movi MASK.16b, #0xe1
ext SHASH2.16b, SHASH.16b, SHASH.16b, #8
shl MASK.2d, MASK.2d, #57
@@ -74,6 +74,6 @@ CPU_LE( rev64 T1.16b, T1.16b )
cbnz w0, 0b
- st1 {XL.16b}, [x1]
+ st1 {XL.2d}, [x1]
ret
ENDPROC(pmull_ghash_update)
--
2.7.4
^ permalink raw reply related
* [PATCH 1/6] crypto: arm64/aes-ce - fix for big endian
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476034945-9186-1-git-send-email-ard.biesheuvel@linaro.org>
The core AES cipher implementation that uses ARMv8 Crypto Extensions
instructions erroneously loads the round keys as 64-bit quantities,
which causes the algorithm to fail when built for big endian. In
addition, the key schedule generation routine fails to take endianness
into account as well, when loading the combining the input key with
the round constants. So fix both issues.
Fixes: 12ac3efe74f8 ("arm64/crypto: use crypto instructions to generate AES key schedule")
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
arch/arm64/crypto/aes-ce-cipher.c | 25 ++++++++++++--------
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-cipher.c b/arch/arm64/crypto/aes-ce-cipher.c
index f7bd9bf0bbb3..50d9fe11d0c8 100644
--- a/arch/arm64/crypto/aes-ce-cipher.c
+++ b/arch/arm64/crypto/aes-ce-cipher.c
@@ -47,24 +47,24 @@ static void aes_cipher_encrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aese v0.16b, v2.16b ;"
" aesmc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aese v0.16b, v3.16b ;"
" aesmc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aese v0.16b, v1.16b ;"
" aesmc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aese v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -92,24 +92,24 @@ static void aes_cipher_decrypt(struct crypto_tfm *tfm, u8 dst[], u8 const src[])
kernel_neon_begin_partial(4);
__asm__(" ld1 {v0.16b}, %[in] ;"
- " ld1 {v1.2d}, [%[key]], #16 ;"
+ " ld1 {v1.16b}, [%[key]], #16 ;"
" cmp %w[rounds], #10 ;"
" bmi 0f ;"
" bne 3f ;"
" mov v3.16b, v1.16b ;"
" b 2f ;"
"0: mov v2.16b, v1.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
"1: aesd v0.16b, v2.16b ;"
" aesimc v0.16b, v0.16b ;"
- "2: ld1 {v1.2d}, [%[key]], #16 ;"
+ "2: ld1 {v1.16b}, [%[key]], #16 ;"
" aesd v0.16b, v3.16b ;"
" aesimc v0.16b, v0.16b ;"
- "3: ld1 {v2.2d}, [%[key]], #16 ;"
+ "3: ld1 {v2.16b}, [%[key]], #16 ;"
" subs %w[rounds], %w[rounds], #3 ;"
" aesd v0.16b, v1.16b ;"
" aesimc v0.16b, v0.16b ;"
- " ld1 {v3.2d}, [%[key]], #16 ;"
+ " ld1 {v3.16b}, [%[key]], #16 ;"
" bpl 1b ;"
" aesd v0.16b, v2.16b ;"
" eor v0.16b, v0.16b, v3.16b ;"
@@ -173,7 +173,12 @@ int ce_aes_expandkey(struct crypto_aes_ctx *ctx, const u8 *in_key,
u32 *rki = ctx->key_enc + (i * kwords);
u32 *rko = rki + kwords;
+#ifndef CONFIG_CPU_BIG_ENDIAN
rko[0] = ror32(aes_sub(rki[kwords - 1]), 8) ^ rcon[i] ^ rki[0];
+#else
+ rko[0] = rol32(aes_sub(rki[kwords - 1]), 8) ^ (rcon[i] << 24) ^
+ rki[0];
+#endif
rko[1] = rko[0] ^ rki[1];
rko[2] = rko[1] ^ rki[2];
rko[3] = rko[2] ^ rki[3];
--
2.7.4
^ permalink raw reply related
* [PATCH 0/6] crypto: arm64 - big endian fixes
From: Ard Biesheuvel @ 2016-10-09 17:42 UTC (permalink / raw)
To: linux-arm-kernel
As it turns out, none of the accelerated crypto routines under arch/arm64/crypto
currently work, or have ever worked correctly when built for big endian. So this
series fixes all of them.
Each of these patches carries a fixes tag, and could be backported to stable.
However, for patches #1 and #5, the fixes tag denotes the oldest commit that the
fix is compatible with, not the patch that introduced the algorithm. This is due
to the fact that the key schedules are incompatible between generic AES and the
arm64 Crypto Extensions implementation (but only when building for big endian)
This is not a problem in practice, but it does mean that the AES-CCM and AES in
EBC/CBC/CTR/XTS mode implementations before v3.19 require a different fix, i.e.,
one that is compatible with the generic AES key schedule generation code (which
it currently no longer uses)
In any case, please apply with cc to stable.
Ard Biesheuvel (6):
crypto: arm64/aes-ce - fix for big endian
crypto: arm64/ghash-ce - fix for big endian
crypto: arm64/sha1-ce - fix for big endian
crypto: arm64/sha2-ce - fix for big endian
crypto: arm64/aes-ccm-ce: fix for big endian
crypto: arm64/aes-neon - fix for big endian
arch/arm64/crypto/aes-ce-ccm-core.S | 53 ++++++++++----------
arch/arm64/crypto/aes-ce-cipher.c | 25 +++++----
arch/arm64/crypto/aes-neon.S | 25 +++++----
arch/arm64/crypto/ghash-ce-core.S | 6 +--
arch/arm64/crypto/sha1-ce-core.S | 4 +-
arch/arm64/crypto/sha2-ce-core.S | 4 +-
6 files changed, 64 insertions(+), 53 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Krzysztof Kozlowski @ 2016-10-09 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANAwSgSr6-0x47=0P_NCiGCv=FSZR9dNT89JpY=9R_32U8HywQ@mail.gmail.com>
On Sun, Oct 09, 2016 at 10:45:40PM +0530, Anand Moon wrote:
> Hi Krzysztof,
>
> On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> >> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> >> as to avoid them being build when not used. This also allows us to use the
> >> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
> >>
> >> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> >> ---
> >> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> >> 1 file changed, 6 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> >> index 42e5b66..1899900 100644
> >> --- a/drivers/usb/host/ehci-exynos.c
> >> +++ b/drivers/usb/host/ehci-exynos.c
> >> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> >> return 0;
> >> }
> >>
> >> -#ifdef CONFIG_PM
> >> +#ifdef CONFIG_PM_SLEEP
> >
> > Does not look like an equivalent change. How will it behave in a config
> > with !SUSPEND && !HIBERNATE && PM?
> >
>
> [snip]
>
> I just wanted to update suspend and resume callback to use
> SET_SYSTEM_SLEEP_PM_OPS
> as they are define under CONFIG_PM_SLEEP so I update above to avoid
> compilation warning/error.
First of all you did not answer to my question, so let me rephrase into
two:
1. Is the code equivalent?
2. What will be the output with !SUSPEND && !HIBERNATE && PM?
You didn't mention compilation warning/error in message commit so I do
not know what you are thinking about...
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Anand Moon @ 2016-10-09 17:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161009163446.GA9672@kozik-lap>
Hi Krzysztof,
On 9 October 2016 at 22:04, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
>> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
>> as to avoid them being build when not used. This also allows us to use the
>> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>>
>> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
>> ---
>> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
>> 1 file changed, 6 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index 42e5b66..1899900 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> -#ifdef CONFIG_PM
>> +#ifdef CONFIG_PM_SLEEP
>
> Does not look like an equivalent change. How will it behave in a config
> with !SUSPEND && !HIBERNATE && PM?
>
[snip]
I just wanted to update suspend and resume callback to use
SET_SYSTEM_SLEEP_PM_OPS
as they are define under CONFIG_PM_SLEEP so I update above to avoid
compilation warning/error.
http://lxr.free-electrons.com/source/include/linux/pm.h#L321
-Best Regards
Anand Moon
^ permalink raw reply
* [PATCH v3 00/17] pinctrl: exynos/samsung: Add header with values used for configuration
From: Krzysztof Kozlowski @ 2016-10-09 16:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CA+Ln22Eotn=dLyA8KYT_6Fnwvp1sTSxzP8DepAFB2P8EUMME6Q@mail.gmail.com>
On Sun, Oct 09, 2016 at 04:04:11PM +0900, Tomasz Figa wrote:
> Hi Krzysztof,
>
> 2016-09-04 20:04 GMT+09:00 Krzysztof Kozlowski <krzk@kernel.org>:
> >
> > Hi,
> >
> > Changes since v2
> > ================
> > 1. Combine separate patchsets into one. Previously I sent separately the fixes
> > and changes for S3C platforms.
> > 2. Fix issues pointed during review.
> > 3. Add review tags.
> >
> > Changes since v1
> > ================
> > 1. Follow Arnd's suggestion about moving the macros to common place.
> > 2. Subjects: replace "GPIO" with "pinctrl".
> > 3. There were some major changes here so I did not add Javier's
> > reviewed-by and tested-by tags.
> >
> > Merging
> > =======
> > Patches #1 and #2 should probably go through pinctrl tree. In that case I would
> > appreciate a stable branch/tag so DTS could base on top of it.
> >
> > Goal
> > ====
> > Increase readability:
> > uart0_data: uart0-data {
> > samsung,pins = "gpa0-0", "gpa0-1";
> > - samsung,pin-function = <2>;
> > - samsung,pin-pud = <0>;
> > - samsung,pin-drv = <0>;
> > + samsung,pin-function = <EXYNOS_PIN_FUNC_2>;
> > + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>;
> > + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>;
>
> I like the idea, thanks for cleaning this up. However I'd like to
> bikeshed the prefix a bit. Since the properties are already prefixed
> by "samsung,", I think it would make much more sense to also prefix
> the generic values with "SAMSUNG_". Of course for soc/family-specific
> values, the soc/family name prefix sounds right.
I am lost. Sorry, I don't get what kind of final prefixes you would like
to have.
SAMSUNG_EXYNOS4_PIN_DRV_LV1
SAMSUNG_EXYNOS5260_PIN_DRV_LV1
?
> Similarly for rest of the value names, such as SAMSUNG_PIN_PUD instead
> of SAMSUNG_PIN_PULL, which obviously sounds more like correct English,
> however hurts the consistency and could confuse the people writing new
> dts files.
SAMSUNG_S3C64XX_PIN_PUD_NONE
SAMSUNG_EXYNOS_PIN_PUD_NONE
?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 1/2] host: ehci-exynos: Convert to use the SET_SYSTEM_SLEEP_PM_OPS
From: Krzysztof Kozlowski @ 2016-10-09 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476023655-3232-1-git-send-email-linux.amoon@gmail.com>
On Sun, Oct 09, 2016 at 02:34:14PM +0000, Anand Moon wrote:
> Move the ehci-exynos system PM callbacks within #ifdef CONFIG_PM_SLEEP
> as to avoid them being build when not used. This also allows us to use the
> SET_SYSTEM_SLEEP_PM_OPS macro which simplifies the code.
>
> Signed-off-by: Anand Moon <linux.amoon@gmail.com>
> ---
> drivers/usb/host/ehci-exynos.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index 42e5b66..1899900 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -251,7 +251,7 @@ static int exynos_ehci_remove(struct platform_device *pdev)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
Does not look like an equivalent change. How will it behave in a config
with !SUSPEND && !HIBERNATE && PM?
Best regards,
Krzysztof
> static int exynos_ehci_suspend(struct device *dev)
> {
> struct usb_hcd *hcd = dev_get_drvdata(dev);
> @@ -292,15 +292,13 @@ static int exynos_ehci_resume(struct device *dev)
> ehci_resume(hcd, false);
> return 0;
> }
> -#else
> -#define exynos_ehci_suspend NULL
> -#define exynos_ehci_resume NULL
> -#endif
>
> static const struct dev_pm_ops exynos_ehci_pm_ops = {
> - .suspend = exynos_ehci_suspend,
> - .resume = exynos_ehci_resume,
> + SET_SYSTEM_SLEEP_PM_OPS(exynos_ehci_suspend, exynos_ehci_resume)
> };
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#define DEV_PM_OPS IS_ENABLED(CONFIG_PM_SLEEP) ? &exynos_ehci_pm_ops : NULL
>
> #ifdef CONFIG_OF
> static const struct of_device_id exynos_ehci_match[] = {
> @@ -317,7 +315,7 @@ static struct platform_driver exynos_ehci_driver = {
> .shutdown = usb_hcd_platform_shutdown,
> .driver = {
> .name = "exynos-ehci",
> - .pm = &exynos_ehci_pm_ops,
> + .pm = DEV_PM_OPS,
> .of_match_table = of_match_ptr(exynos_ehci_match),
> }
> };
> --
> 2.7.4
>
^ 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