Re: [PATCH v3] arm: imx: dts: Use lower case for bindings notation

[Shawn Guo]

On Fri, Dec 15, 2017 at 08:19:30PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files using lower case to fix the following dtc warnings:
> 
> Warning (simple_bus_reg): Node /XXX@ simple-bus unit address format 
> error, expected ""
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e 
> "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e 
> "s/@0+\(.*\) {/@\1 {/g" {} +^C
> 
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
> 
> Reported-by: David Daney 
> Suggested-by: Rob Herring 
> Signed-off-by: Mathieu Malaterre 

Applied, thanks.

Re: [PATCH v3] arm: imx: dts: Use lower case for bindings notation

[Shawn Guo]

On Fri, Dec 15, 2017 at 08:19:30PM +0100, Mathieu Malaterre wrote:
> Improve the DTS files using lower case to fix the following dtc warnings:
> 
> Warning (simple_bus_reg): Node /XXX@ simple-bus unit address format 
> error, expected ""
> 
> Converted using the following command:
> 
> find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -i -e 
> "s/@\([0-9a-fA-FxX\.;:#]+\)\s*{/@\L\1 {/g" -e "s/@0x\(.*\) {/@\1 {/g" -e 
> "s/@0+\(.*\) {/@\1 {/g" {} +^C
> 
> For simplicity, two sed expressions were used to solve each warnings 
> separately.
> 
> To make the regex expression more robust a few other issues were resolved,
> namely setting unit-address to lower case, and adding a whitespace before the
> the opening curly brace:
> 
> https://elinux.org/Device_Tree_Linux#Linux_conventions
> 
> This is a follow up to commit 4c9847b7375a ("dt-bindings: Remove leading 0x 
> from bindings notation")
> 
> Reported-by: David Daney 
> Suggested-by: Rob Herring 
> Signed-off-by: Mathieu Malaterre 

Applied, thanks.

[RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

[Masami Hiramatsu]

Support in-kernel fault-injection framework via debugfs.
This allows you to inject a conditional error to specified
function using debugfs interfaces.

Signed-off-by: Masami Hiramatsu 
---
 Documentation/fault-injection/fault-injection.txt |5 +
 kernel/Makefile   |1 
 kernel/fail_function.c|  169 +
 lib/Kconfig.debug |   10 +
 4 files changed, 185 insertions(+)
 create mode 100644 kernel/fail_function.c

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 918972babcd8..6243a588dd71 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -30,6 +30,11 @@ o fail_mmc_request
   injects MMC data errors on devices permitted by setting
   debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
 
+o fail_function
+
+  injects error return on specific functions by setting debugfs entries
+  under /sys/kernel/debug/fail_function. No boot option supported.
+
 Configure fault-injection capabilities behavior
 ---
 
diff --git a/kernel/Makefile b/kernel/Makefile
index 172d151d429c..f85ae5dfa474 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
 obj-$(CONFIG_GCOV_KERNEL) += gcov/
 obj-$(CONFIG_KCOV) += kcov.o
 obj-$(CONFIG_KPROBES) += kprobes.o
+obj-$(CONFIG_FAIL_FUNCTION) += fail_function.o
 obj-$(CONFIG_KGDB) += debug/
 obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
 obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o
diff --git a/kernel/fail_function.c b/kernel/fail_function.c
new file mode 100644
index ..203d3582487a
--- /dev/null
+++ b/kernel/fail_function.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * fail_function.c: Function-based error injection
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs);
+
+static DEFINE_MUTEX(fei_lock);
+static struct {
+   struct kprobe kp;
+   unsigned long retval;
+   struct fault_attr attr;
+} fei_attr = {
+   .kp = { .pre_handler = fei_kprobe_handler, },
+   .retval = ~0UL, /* This indicates -1 in long/int return value */
+   .attr = FAULT_ATTR_INITIALIZER,
+};
+
+static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
+{
+   if (should_fail(_attr.attr, 1)) {
+   regs_set_return_value(regs, fei_attr.retval);
+   override_function_with_return(regs);
+   /* Kprobe specific fixup */
+   reset_current_kprobe();
+   preempt_enable_no_resched();
+   return 1;
+   }
+
+   return 0;
+}
+NOKPROBE_SYMBOL(fei_kprobe_handler)
+
+static void *fei_seq_start(struct seq_file *m, loff_t *pos)
+{
+   mutex_lock(_lock);
+   return *pos == 0 ? (void *)1 : NULL;
+}
+
+static void fei_seq_stop(struct seq_file *m, void *v)
+{
+   mutex_unlock(_lock);
+}
+
+static void *fei_seq_next(struct seq_file *m, void *v, loff_t *pos)
+{
+   return NULL;
+}
+
+static int fei_seq_show(struct seq_file *m, void *v)
+{
+   if (fei_attr.kp.addr)
+   seq_printf(m, "%pf\n", fei_attr.kp.addr);
+   else
+   seq_puts(m, "# not specified\n");
+   return 0;
+}
+
+static const struct seq_operations fei_seq_ops = {
+   .start  = fei_seq_start,
+   .next   = fei_seq_next,
+   .stop   = fei_seq_stop,
+   .show   = fei_seq_show,
+};
+
+static int fei_open(struct inode *inode, struct file *file)
+{
+   return seq_open(file, _seq_ops);
+}
+
+static ssize_t fei_write(struct file *file, const char __user *buffer,
+size_t count, loff_t *ppos)
+{
+   unsigned long addr;
+   char *buf, *sym;
+   int ret;
+
+   /* cut off if it is too long */
+   if (count > KSYM_NAME_LEN)
+   count = KSYM_NAME_LEN;
+   buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   if (copy_from_user(buf, buffer, count)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   buf[count] = '\0';
+   sym = strstrip(buf);
+
+   if (strlen(sym) == 0 || sym[0] == '0') {
+   if (fei_attr.kp.addr) {
+   unregister_kprobe(_attr.kp);
+   fei_attr.kp.addr = NULL;
+   }
+   ret = count;
+   goto out;
+   }
+
+   addr = kallsyms_lookup_name(sym);
+   if (!addr) {
+   ret = -EINVAL;
+   goto out;
+   }
+   if (!within_error_injection_list(addr)) {
+   ret = -ERANGE;
+   goto out;
+   }
+
+   if (fei_attr.kp.addr) {
+   

[RFC PATCH bpf-next v2 4/4] error-injection: Support fault injection framework

[Masami Hiramatsu]

Support in-kernel fault-injection framework via debugfs.
This allows you to inject a conditional error to specified
function using debugfs interfaces.

Signed-off-by: Masami Hiramatsu 
---
 Documentation/fault-injection/fault-injection.txt |5 +
 kernel/Makefile   |1 
 kernel/fail_function.c|  169 +
 lib/Kconfig.debug |   10 +
 4 files changed, 185 insertions(+)
 create mode 100644 kernel/fail_function.c

diff --git a/Documentation/fault-injection/fault-injection.txt 
b/Documentation/fault-injection/fault-injection.txt
index 918972babcd8..6243a588dd71 100644
--- a/Documentation/fault-injection/fault-injection.txt
+++ b/Documentation/fault-injection/fault-injection.txt
@@ -30,6 +30,11 @@ o fail_mmc_request
   injects MMC data errors on devices permitted by setting
   debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
 
+o fail_function
+
+  injects error return on specific functions by setting debugfs entries
+  under /sys/kernel/debug/fail_function. No boot option supported.
+
 Configure fault-injection capabilities behavior
 ---
 
diff --git a/kernel/Makefile b/kernel/Makefile
index 172d151d429c..f85ae5dfa474 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_AUDIT_TREE) += audit_tree.o
 obj-$(CONFIG_GCOV_KERNEL) += gcov/
 obj-$(CONFIG_KCOV) += kcov.o
 obj-$(CONFIG_KPROBES) += kprobes.o
+obj-$(CONFIG_FAIL_FUNCTION) += fail_function.o
 obj-$(CONFIG_KGDB) += debug/
 obj-$(CONFIG_DETECT_HUNG_TASK) += hung_task.o
 obj-$(CONFIG_LOCKUP_DETECTOR) += watchdog.o
diff --git a/kernel/fail_function.c b/kernel/fail_function.c
new file mode 100644
index ..203d3582487a
--- /dev/null
+++ b/kernel/fail_function.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * fail_function.c: Function-based error injection
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs);
+
+static DEFINE_MUTEX(fei_lock);
+static struct {
+   struct kprobe kp;
+   unsigned long retval;
+   struct fault_attr attr;
+} fei_attr = {
+   .kp = { .pre_handler = fei_kprobe_handler, },
+   .retval = ~0UL, /* This indicates -1 in long/int return value */
+   .attr = FAULT_ATTR_INITIALIZER,
+};
+
+static int fei_kprobe_handler(struct kprobe *kp, struct pt_regs *regs)
+{
+   if (should_fail(_attr.attr, 1)) {
+   regs_set_return_value(regs, fei_attr.retval);
+   override_function_with_return(regs);
+   /* Kprobe specific fixup */
+   reset_current_kprobe();
+   preempt_enable_no_resched();
+   return 1;
+   }
+
+   return 0;
+}
+NOKPROBE_SYMBOL(fei_kprobe_handler)
+
+static void *fei_seq_start(struct seq_file *m, loff_t *pos)
+{
+   mutex_lock(_lock);
+   return *pos == 0 ? (void *)1 : NULL;
+}
+
+static void fei_seq_stop(struct seq_file *m, void *v)
+{
+   mutex_unlock(_lock);
+}
+
+static void *fei_seq_next(struct seq_file *m, void *v, loff_t *pos)
+{
+   return NULL;
+}
+
+static int fei_seq_show(struct seq_file *m, void *v)
+{
+   if (fei_attr.kp.addr)
+   seq_printf(m, "%pf\n", fei_attr.kp.addr);
+   else
+   seq_puts(m, "# not specified\n");
+   return 0;
+}
+
+static const struct seq_operations fei_seq_ops = {
+   .start  = fei_seq_start,
+   .next   = fei_seq_next,
+   .stop   = fei_seq_stop,
+   .show   = fei_seq_show,
+};
+
+static int fei_open(struct inode *inode, struct file *file)
+{
+   return seq_open(file, _seq_ops);
+}
+
+static ssize_t fei_write(struct file *file, const char __user *buffer,
+size_t count, loff_t *ppos)
+{
+   unsigned long addr;
+   char *buf, *sym;
+   int ret;
+
+   /* cut off if it is too long */
+   if (count > KSYM_NAME_LEN)
+   count = KSYM_NAME_LEN;
+   buf = kmalloc(sizeof(char) * (count + 1), GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   if (copy_from_user(buf, buffer, count)) {
+   ret = -EFAULT;
+   goto out;
+   }
+   buf[count] = '\0';
+   sym = strstrip(buf);
+
+   if (strlen(sym) == 0 || sym[0] == '0') {
+   if (fei_attr.kp.addr) {
+   unregister_kprobe(_attr.kp);
+   fei_attr.kp.addr = NULL;
+   }
+   ret = count;
+   goto out;
+   }
+
+   addr = kallsyms_lookup_name(sym);
+   if (!addr) {
+   ret = -EINVAL;
+   goto out;
+   }
+   if (!within_error_injection_list(addr)) {
+   ret = -ERANGE;
+   goto out;
+   }
+
+   if (fei_attr.kp.addr) {
+   unregister_kprobe(_attr.kp);
+  

[RFC PATCH bpf-next v2 3/4] error-injection: Separate error-injection from kprobe

[Masami Hiramatsu]

Since error-injection framework is not limited to be used
by kprobes, nor bpf. Other kernel subsystems can use it
freely for checking safeness of error-injection, e.g.
livepatch, ftrace etc.
So this separate error-injection framework from kprobes.

Some differences has been made:

- "kprobe" word is removed from any APIs/structures.
- BPF_ALLOW_ERROR_INJECTION() is renamed to
  ALLOW_ERROR_INJECTION() since it is not limited for BPF too.
- CONFIG_FUNCTION_ERROR_INJECTION is the config item of this
  feature. It is automatically enabled if the arch supports
  error injection feature for kprobe or ftrace etc.

Signed-off-by: Masami Hiramatsu 
---
  Changes in v2:
   - Fix the override function name to override_function_with_return()
   - Show only function name in the list, user don't have to care about
 it's size, since function override only happens at the entry.
---
 arch/Kconfig   |2 
 arch/x86/Kconfig   |2 
 arch/x86/include/asm/error-injection.h |   12 ++
 arch/x86/kernel/kprobes/ftrace.c   |   14 --
 arch/x86/lib/Makefile  |2 
 arch/x86/lib/error-inject.c|   19 +++
 fs/btrfs/disk-io.c |2 
 fs/btrfs/free-space-cache.c|2 
 include/asm-generic/error-injection.h  |   20 +++
 include/asm-generic/vmlinux.lds.h  |   14 +-
 include/linux/bpf.h|   12 --
 include/linux/error-injection.h|   21 +++
 include/linux/kprobes.h|1 
 include/linux/module.h |6 -
 kernel/kprobes.c   |  163 --
 kernel/module.c|8 +
 kernel/trace/Kconfig   |2 
 kernel/trace/bpf_trace.c   |2 
 kernel/trace/trace_kprobe.c|3 
 lib/Kconfig.debug  |4 +
 lib/Makefile   |1 
 lib/error-inject.c |  198 
 22 files changed, 300 insertions(+), 210 deletions(-)
 create mode 100644 arch/x86/include/asm/error-injection.h
 create mode 100644 arch/x86/lib/error-inject.c
 create mode 100644 include/asm-generic/error-injection.h
 create mode 100644 include/linux/error-injection.h
 create mode 100644 lib/error-inject.c

diff --git a/arch/Kconfig b/arch/Kconfig
index d3f4aaf9cb7a..97376accfb14 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -196,7 +196,7 @@ config HAVE_OPTPROBES
 config HAVE_KPROBES_ON_FTRACE
bool
 
-config HAVE_KPROBE_OVERRIDE
+config HAVE_FUNCTION_ERROR_INJECTION
bool
 
 config HAVE_NMI
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 04d66e6fa447..fc519e3ae754 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,7 +154,7 @@ config X86
select HAVE_KERNEL_XZ
select HAVE_KPROBES
select HAVE_KPROBES_ON_FTRACE
-   select HAVE_KPROBE_OVERRIDE
+   select HAVE_FUNCTION_ERROR_INJECTION
select HAVE_KRETPROBES
select HAVE_KVM
select HAVE_LIVEPATCH   if X86_64
diff --git a/arch/x86/include/asm/error-injection.h 
b/arch/x86/include/asm/error-injection.h
new file mode 100644
index ..6c2a133622f4
--- /dev/null
+++ b/arch/x86/include/asm/error-injection.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ERROR_INJECTION_H
+#define _ASM_ERROR_INJECTION_H
+
+#include 
+#include 
+#include 
+
+asmlinkage void just_return_func(void);
+void override_function_with_return(struct pt_regs *regs);
+
+#endif /* _ASM_ERROR_INJECTION_H */
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index 1ea748d682fd..8dc0161cec8f 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -97,17 +97,3 @@ int arch_prepare_kprobe_ftrace(struct kprobe *p)
p->ainsn.boostable = false;
return 0;
 }
-
-asmlinkage void override_func(void);
-asm(
-   ".type override_func, @function\n"
-   "override_func:\n"
-   "   ret\n"
-   ".size override_func, .-override_func\n"
-);
-
-void arch_ftrace_kprobe_override_function(struct pt_regs *regs)
-{
-   regs->ip = (unsigned long)_func;
-}
-NOKPROBE_SYMBOL(arch_ftrace_kprobe_override_function);
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 7b181b61170e..081f09435d28 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -26,6 +26,8 @@ lib-y += memcpy_$(BITS).o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
 lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-eval.o
 lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
+lib-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
+
 
 obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
 
diff --git a/arch/x86/lib/error-inject.c b/arch/x86/lib/error-inject.c
new file mode 100644
index ..7b881d03d0dd
--- /dev/null
+++ b/arch/x86/lib/error-inject.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: 

[RFC PATCH bpf-next v2 3/4] error-injection: Separate error-injection from kprobe

[Masami Hiramatsu]

Since error-injection framework is not limited to be used
by kprobes, nor bpf. Other kernel subsystems can use it
freely for checking safeness of error-injection, e.g.
livepatch, ftrace etc.
So this separate error-injection framework from kprobes.

Some differences has been made:

- "kprobe" word is removed from any APIs/structures.
- BPF_ALLOW_ERROR_INJECTION() is renamed to
  ALLOW_ERROR_INJECTION() since it is not limited for BPF too.
- CONFIG_FUNCTION_ERROR_INJECTION is the config item of this
  feature. It is automatically enabled if the arch supports
  error injection feature for kprobe or ftrace etc.

Signed-off-by: Masami Hiramatsu 
---
  Changes in v2:
   - Fix the override function name to override_function_with_return()
   - Show only function name in the list, user don't have to care about
 it's size, since function override only happens at the entry.
---
 arch/Kconfig   |2 
 arch/x86/Kconfig   |2 
 arch/x86/include/asm/error-injection.h |   12 ++
 arch/x86/kernel/kprobes/ftrace.c   |   14 --
 arch/x86/lib/Makefile  |2 
 arch/x86/lib/error-inject.c|   19 +++
 fs/btrfs/disk-io.c |2 
 fs/btrfs/free-space-cache.c|2 
 include/asm-generic/error-injection.h  |   20 +++
 include/asm-generic/vmlinux.lds.h  |   14 +-
 include/linux/bpf.h|   12 --
 include/linux/error-injection.h|   21 +++
 include/linux/kprobes.h|1 
 include/linux/module.h |6 -
 kernel/kprobes.c   |  163 --
 kernel/module.c|8 +
 kernel/trace/Kconfig   |2 
 kernel/trace/bpf_trace.c   |2 
 kernel/trace/trace_kprobe.c|3 
 lib/Kconfig.debug  |4 +
 lib/Makefile   |1 
 lib/error-inject.c |  198 
 22 files changed, 300 insertions(+), 210 deletions(-)
 create mode 100644 arch/x86/include/asm/error-injection.h
 create mode 100644 arch/x86/lib/error-inject.c
 create mode 100644 include/asm-generic/error-injection.h
 create mode 100644 include/linux/error-injection.h
 create mode 100644 lib/error-inject.c

diff --git a/arch/Kconfig b/arch/Kconfig
index d3f4aaf9cb7a..97376accfb14 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -196,7 +196,7 @@ config HAVE_OPTPROBES
 config HAVE_KPROBES_ON_FTRACE
bool
 
-config HAVE_KPROBE_OVERRIDE
+config HAVE_FUNCTION_ERROR_INJECTION
bool
 
 config HAVE_NMI
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 04d66e6fa447..fc519e3ae754 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -154,7 +154,7 @@ config X86
select HAVE_KERNEL_XZ
select HAVE_KPROBES
select HAVE_KPROBES_ON_FTRACE
-   select HAVE_KPROBE_OVERRIDE
+   select HAVE_FUNCTION_ERROR_INJECTION
select HAVE_KRETPROBES
select HAVE_KVM
select HAVE_LIVEPATCH   if X86_64
diff --git a/arch/x86/include/asm/error-injection.h 
b/arch/x86/include/asm/error-injection.h
new file mode 100644
index ..6c2a133622f4
--- /dev/null
+++ b/arch/x86/include/asm/error-injection.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_ERROR_INJECTION_H
+#define _ASM_ERROR_INJECTION_H
+
+#include 
+#include 
+#include 
+
+asmlinkage void just_return_func(void);
+void override_function_with_return(struct pt_regs *regs);
+
+#endif /* _ASM_ERROR_INJECTION_H */
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index 1ea748d682fd..8dc0161cec8f 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -97,17 +97,3 @@ int arch_prepare_kprobe_ftrace(struct kprobe *p)
p->ainsn.boostable = false;
return 0;
 }
-
-asmlinkage void override_func(void);
-asm(
-   ".type override_func, @function\n"
-   "override_func:\n"
-   "   ret\n"
-   ".size override_func, .-override_func\n"
-);
-
-void arch_ftrace_kprobe_override_function(struct pt_regs *regs)
-{
-   regs->ip = (unsigned long)_func;
-}
-NOKPROBE_SYMBOL(arch_ftrace_kprobe_override_function);
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 7b181b61170e..081f09435d28 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -26,6 +26,8 @@ lib-y += memcpy_$(BITS).o
 lib-$(CONFIG_RWSEM_XCHGADD_ALGORITHM) += rwsem.o
 lib-$(CONFIG_INSTRUCTION_DECODER) += insn.o inat.o insn-eval.o
 lib-$(CONFIG_RANDOMIZE_BASE) += kaslr.o
+lib-$(CONFIG_FUNCTION_ERROR_INJECTION) += error-inject.o
+
 
 obj-y += msr.o msr-reg.o msr-reg-export.o hweight.o
 
diff --git a/arch/x86/lib/error-inject.c b/arch/x86/lib/error-inject.c
new file mode 100644
index ..7b881d03d0dd
--- /dev/null
+++ b/arch/x86/lib/error-inject.c
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 

[RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

[Masami Hiramatsu]

Check whether error injectable event is on function entry or not.
Currently it checks the event is ftrace-based kprobes or not,
but that is wrong. It should check if the event is on the entry
of target function. Since error injection will override a function
to just return with modified return value, that operation must
be done before the target function starts making stackframe.

As a side effect, bpf error injection is no need to depend on
function-tracer. It can work with sw-breakpoint based kprobe
events too.

Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/Kconfig|2 --
 kernel/trace/bpf_trace.c|6 +++---
 kernel/trace/trace_kprobe.c |8 +---
 kernel/trace/trace_probe.h  |   12 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ae3a2d519e50..6400e1bf97c5 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -533,9 +533,7 @@ config FUNCTION_PROFILER
 config BPF_KPROBE_OVERRIDE
bool "Enable BPF programs to override a kprobed function"
depends on BPF_EVENTS
-   depends on KPROBES_ON_FTRACE
depends on HAVE_KPROBE_OVERRIDE
-   depends on DYNAMIC_FTRACE_WITH_REGS
default n
help
 Allows BPF to override the execution of a probed function and
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f6d2327ecb59..d663660f8392 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -800,11 +800,11 @@ int perf_event_attach_bpf_prog(struct perf_event *event,
int ret = -EEXIST;
 
/*
-* Kprobe override only works for ftrace based kprobes, and only if they
-* are on the opt-in list.
+* Kprobe override only works if they are on the function entry,
+* and only if they are on the opt-in list.
 */
if (prog->kprobe_override &&
-   (!trace_kprobe_ftrace(event->tp_event) ||
+   (!trace_kprobe_on_func_entry(event->tp_event) ||
 !trace_kprobe_error_injectable(event->tp_event)))
return -EINVAL;
 
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 91f4b57dab82..265e3e27e8dc 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -88,13 +88,15 @@ static nokprobe_inline unsigned long 
trace_kprobe_nhit(struct trace_kprobe *tk)
return nhit;
 }
 
-int trace_kprobe_ftrace(struct trace_event_call *call)
+bool trace_kprobe_on_func_entry(struct trace_event_call *call)
 {
struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
-   return kprobe_ftrace(>rp.kp);
+
+   return kprobe_on_func_entry(tk->rp.kp.addr, tk->rp.kp.symbol_name,
+   tk->rp.kp.offset);
 }
 
-int trace_kprobe_error_injectable(struct trace_event_call *call)
+bool trace_kprobe_error_injectable(struct trace_event_call *call)
 {
struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
unsigned long addr;
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index 5e54d748c84c..e101c5bb9eda 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -252,8 +252,8 @@ struct symbol_cache;
 unsigned long update_symbol_cache(struct symbol_cache *sc);
 void free_symbol_cache(struct symbol_cache *sc);
 struct symbol_cache *alloc_symbol_cache(const char *sym, long offset);
-int trace_kprobe_ftrace(struct trace_event_call *call);
-int trace_kprobe_error_injectable(struct trace_event_call *call);
+bool trace_kprobe_on_func_entry(struct trace_event_call *call);
+bool trace_kprobe_error_injectable(struct trace_event_call *call);
 #else
 /* uprobes do not support symbol fetch methods */
 #define fetch_symbol_u8NULL
@@ -280,14 +280,14 @@ alloc_symbol_cache(const char *sym, long offset)
return NULL;
 }
 
-static inline int trace_kprobe_ftrace(struct trace_event_call *call)
+static inline bool trace_kprobe_on_func_entry(struct trace_event_call *call)
 {
-   return 0;
+   return false;
 }
 
-static inline int trace_kprobe_error_injectable(struct trace_event_call *call)
+static inline bool trace_kprobe_error_injectable(struct trace_event_call *call)
 {
-   return 0;
+   return false;
 }
 #endif /* CONFIG_KPROBE_EVENTS */
 

[RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

[Masami Hiramatsu]

Check whether error injectable event is on function entry or not.
Currently it checks the event is ftrace-based kprobes or not,
but that is wrong. It should check if the event is on the entry
of target function. Since error injection will override a function
to just return with modified return value, that operation must
be done before the target function starts making stackframe.

As a side effect, bpf error injection is no need to depend on
function-tracer. It can work with sw-breakpoint based kprobe
events too.

Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/Kconfig|2 --
 kernel/trace/bpf_trace.c|6 +++---
 kernel/trace/trace_kprobe.c |8 +---
 kernel/trace/trace_probe.h  |   12 ++--
 4 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
index ae3a2d519e50..6400e1bf97c5 100644
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@ -533,9 +533,7 @@ config FUNCTION_PROFILER
 config BPF_KPROBE_OVERRIDE
bool "Enable BPF programs to override a kprobed function"
depends on BPF_EVENTS
-   depends on KPROBES_ON_FTRACE
depends on HAVE_KPROBE_OVERRIDE
-   depends on DYNAMIC_FTRACE_WITH_REGS
default n
help
 Allows BPF to override the execution of a probed function and
diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index f6d2327ecb59..d663660f8392 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -800,11 +800,11 @@ int perf_event_attach_bpf_prog(struct perf_event *event,
int ret = -EEXIST;
 
/*
-* Kprobe override only works for ftrace based kprobes, and only if they
-* are on the opt-in list.
+* Kprobe override only works if they are on the function entry,
+* and only if they are on the opt-in list.
 */
if (prog->kprobe_override &&
-   (!trace_kprobe_ftrace(event->tp_event) ||
+   (!trace_kprobe_on_func_entry(event->tp_event) ||
 !trace_kprobe_error_injectable(event->tp_event)))
return -EINVAL;
 
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 91f4b57dab82..265e3e27e8dc 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -88,13 +88,15 @@ static nokprobe_inline unsigned long 
trace_kprobe_nhit(struct trace_kprobe *tk)
return nhit;
 }
 
-int trace_kprobe_ftrace(struct trace_event_call *call)
+bool trace_kprobe_on_func_entry(struct trace_event_call *call)
 {
struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
-   return kprobe_ftrace(>rp.kp);
+
+   return kprobe_on_func_entry(tk->rp.kp.addr, tk->rp.kp.symbol_name,
+   tk->rp.kp.offset);
 }
 
-int trace_kprobe_error_injectable(struct trace_event_call *call)
+bool trace_kprobe_error_injectable(struct trace_event_call *call)
 {
struct trace_kprobe *tk = (struct trace_kprobe *)call->data;
unsigned long addr;
diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
index 5e54d748c84c..e101c5bb9eda 100644
--- a/kernel/trace/trace_probe.h
+++ b/kernel/trace/trace_probe.h
@@ -252,8 +252,8 @@ struct symbol_cache;
 unsigned long update_symbol_cache(struct symbol_cache *sc);
 void free_symbol_cache(struct symbol_cache *sc);
 struct symbol_cache *alloc_symbol_cache(const char *sym, long offset);
-int trace_kprobe_ftrace(struct trace_event_call *call);
-int trace_kprobe_error_injectable(struct trace_event_call *call);
+bool trace_kprobe_on_func_entry(struct trace_event_call *call);
+bool trace_kprobe_error_injectable(struct trace_event_call *call);
 #else
 /* uprobes do not support symbol fetch methods */
 #define fetch_symbol_u8NULL
@@ -280,14 +280,14 @@ alloc_symbol_cache(const char *sym, long offset)
return NULL;
 }
 
-static inline int trace_kprobe_ftrace(struct trace_event_call *call)
+static inline bool trace_kprobe_on_func_entry(struct trace_event_call *call)
 {
-   return 0;
+   return false;
 }
 
-static inline int trace_kprobe_error_injectable(struct trace_event_call *call)
+static inline bool trace_kprobe_error_injectable(struct trace_event_call *call)
 {
-   return 0;
+   return false;
 }
 #endif /* CONFIG_KPROBE_EVENTS */
 

[RFC PATCH bpf-next v2 2/4] tracing/kprobe: bpf: Compare instruction pointer with original one

[Masami Hiramatsu]

Compare instruction pointer with original one on the
stack instead using per-cpu bpf_kprobe_override flag.

This patch also consolidates reset_current_kprobe() and
preempt_enable_no_resched() blocks. Those can be done
in one place.

Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/bpf_trace.c|1 -
 kernel/trace/trace_kprobe.c |   21 +++--
 2 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d663660f8392..cefa9b0e396c 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -83,7 +83,6 @@ EXPORT_SYMBOL_GPL(trace_call_bpf);
 #ifdef CONFIG_BPF_KPROBE_OVERRIDE
 BPF_CALL_2(bpf_override_return, struct pt_regs *, regs, unsigned long, rc)
 {
-   __this_cpu_write(bpf_kprobe_override, 1);
regs_set_return_value(regs, rc);
arch_ftrace_kprobe_override_function(regs);
return 0;
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 265e3e27e8dc..a7c7035963f2 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -42,8 +42,6 @@ struct trace_kprobe {
(offsetof(struct trace_kprobe, tp.args) +   \
(sizeof(struct probe_arg) * (n)))
 
-DEFINE_PER_CPU(int, bpf_kprobe_override);
-
 static nokprobe_inline bool trace_kprobe_is_return(struct trace_kprobe *tk)
 {
return tk->rp.handler != NULL;
@@ -1204,6 +1202,7 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs 
*regs)
int rctx;
 
if (bpf_prog_array_valid(call)) {
+   unsigned long orig_ip = instruction_pointer(regs);
int ret;
 
ret = trace_call_bpf(call, regs);
@@ -1211,12 +1210,13 @@ kprobe_perf_func(struct trace_kprobe *tk, struct 
pt_regs *regs)
/*
 * We need to check and see if we modified the pc of the
 * pt_regs, and if so clear the kprobe and return 1 so that we
-* don't do the instruction skipping.  Also reset our state so
-* we are clean the next pass through.
+* don't do the single stepping.
+* The ftrace kprobe handler leaves it up to us to re-enable
+* preemption here before returning if we've modified the ip.
 */
-   if (__this_cpu_read(bpf_kprobe_override)) {
-   __this_cpu_write(bpf_kprobe_override, 0);
+   if (orig_ip != instruction_pointer(regs)) {
reset_current_kprobe();
+   preempt_enable_no_resched();
return 1;
}
if (!ret)
@@ -1324,15 +1324,8 @@ static int kprobe_dispatcher(struct kprobe *kp, struct 
pt_regs *regs)
if (tk->tp.flags & TP_FLAG_TRACE)
kprobe_trace_func(tk, regs);
 #ifdef CONFIG_PERF_EVENTS
-   if (tk->tp.flags & TP_FLAG_PROFILE) {
+   if (tk->tp.flags & TP_FLAG_PROFILE)
ret = kprobe_perf_func(tk, regs);
-   /*
-* The ftrace kprobe handler leaves it up to us to re-enable
-* preemption here before returning if we've modified the ip.
-*/
-   if (ret)
-   preempt_enable_no_resched();
-   }
 #endif
return ret;
 }

[RFC PATCH bpf-next v2 2/4] tracing/kprobe: bpf: Compare instruction pointer with original one

[Masami Hiramatsu]

Compare instruction pointer with original one on the
stack instead using per-cpu bpf_kprobe_override flag.

This patch also consolidates reset_current_kprobe() and
preempt_enable_no_resched() blocks. Those can be done
in one place.

Signed-off-by: Masami Hiramatsu 
---
 kernel/trace/bpf_trace.c|1 -
 kernel/trace/trace_kprobe.c |   21 +++--
 2 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
index d663660f8392..cefa9b0e396c 100644
--- a/kernel/trace/bpf_trace.c
+++ b/kernel/trace/bpf_trace.c
@@ -83,7 +83,6 @@ EXPORT_SYMBOL_GPL(trace_call_bpf);
 #ifdef CONFIG_BPF_KPROBE_OVERRIDE
 BPF_CALL_2(bpf_override_return, struct pt_regs *, regs, unsigned long, rc)
 {
-   __this_cpu_write(bpf_kprobe_override, 1);
regs_set_return_value(regs, rc);
arch_ftrace_kprobe_override_function(regs);
return 0;
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 265e3e27e8dc..a7c7035963f2 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -42,8 +42,6 @@ struct trace_kprobe {
(offsetof(struct trace_kprobe, tp.args) +   \
(sizeof(struct probe_arg) * (n)))
 
-DEFINE_PER_CPU(int, bpf_kprobe_override);
-
 static nokprobe_inline bool trace_kprobe_is_return(struct trace_kprobe *tk)
 {
return tk->rp.handler != NULL;
@@ -1204,6 +1202,7 @@ kprobe_perf_func(struct trace_kprobe *tk, struct pt_regs 
*regs)
int rctx;
 
if (bpf_prog_array_valid(call)) {
+   unsigned long orig_ip = instruction_pointer(regs);
int ret;
 
ret = trace_call_bpf(call, regs);
@@ -1211,12 +1210,13 @@ kprobe_perf_func(struct trace_kprobe *tk, struct 
pt_regs *regs)
/*
 * We need to check and see if we modified the pc of the
 * pt_regs, and if so clear the kprobe and return 1 so that we
-* don't do the instruction skipping.  Also reset our state so
-* we are clean the next pass through.
+* don't do the single stepping.
+* The ftrace kprobe handler leaves it up to us to re-enable
+* preemption here before returning if we've modified the ip.
 */
-   if (__this_cpu_read(bpf_kprobe_override)) {
-   __this_cpu_write(bpf_kprobe_override, 0);
+   if (orig_ip != instruction_pointer(regs)) {
reset_current_kprobe();
+   preempt_enable_no_resched();
return 1;
}
if (!ret)
@@ -1324,15 +1324,8 @@ static int kprobe_dispatcher(struct kprobe *kp, struct 
pt_regs *regs)
if (tk->tp.flags & TP_FLAG_TRACE)
kprobe_trace_func(tk, regs);
 #ifdef CONFIG_PERF_EVENTS
-   if (tk->tp.flags & TP_FLAG_PROFILE) {
+   if (tk->tp.flags & TP_FLAG_PROFILE)
ret = kprobe_perf_func(tk, regs);
-   /*
-* The ftrace kprobe handler leaves it up to us to re-enable
-* preemption here before returning if we've modified the ip.
-*/
-   if (ret)
-   preempt_enable_no_resched();
-   }
 #endif
return ret;
 }

[RFC PATCH bpf-next v2 0/4] Separate error injection table from kprobes

[Masami Hiramatsu]

Hi Josef and Alexei,

Here are the 2nd version of patches to moving error injection
table from kprobes. In this series I did a small fixes and
add function-based fault injection.

Here is the previous version:

https://lkml.org/lkml/2017/12/22/554

There are 2 main reasons why I separate it from kprobes.

 - kprobes users can modify execution path not only at 
   error-injection whitelist functions but also other
   functions. I don't like to suggest user that such
   limitation is from kprobes itself.

 - This error injection information is also useful for
   ftrace (function-hook) and livepatch. It should not
   be limited by CONFIG_KPROBES.

So I introduced CONFIG_FUNCTION_ERROR_INJECTION for this feature.
Also CONFIG_FAIL_FUNCTION is added, which provides function-based
error injection interface via debugfs following fault-injection
framework. See [4/4].

Any thoughts?

BTW, I think we should add an error-range description in
ALLOW_ERROR_INJECTION() macro. If user sets a success
return value and override it by mistake, caller must
break data or cause kernel panic.

Thank you,

---

Masami Hiramatsu (4):
  tracing/kprobe: bpf: Check error injectable event is on function entry
  tracing/kprobe: bpf: Compare instruction pointer with original one
  error-injection: Separate error-injection from kprobe
  error-injection: Support fault injection framework


 Documentation/fault-injection/fault-injection.txt |5 +
 arch/Kconfig  |2 
 arch/x86/Kconfig  |2 
 arch/x86/include/asm/error-injection.h|   12 +
 arch/x86/kernel/kprobes/ftrace.c  |   14 -
 arch/x86/lib/Makefile |2 
 arch/x86/lib/error-inject.c   |   19 ++
 fs/btrfs/disk-io.c|2 
 fs/btrfs/free-space-cache.c   |2 
 include/asm-generic/error-injection.h |   20 ++
 include/asm-generic/vmlinux.lds.h |   14 +
 include/linux/bpf.h   |   12 -
 include/linux/error-injection.h   |   21 ++
 include/linux/kprobes.h   |1 
 include/linux/module.h|6 -
 kernel/Makefile   |1 
 kernel/fail_function.c|  169 ++
 kernel/kprobes.c  |  163 -
 kernel/module.c   |8 -
 kernel/trace/Kconfig  |4 
 kernel/trace/bpf_trace.c  |9 -
 kernel/trace/trace_kprobe.c   |   32 +--
 kernel/trace/trace_probe.h|   12 +
 lib/Kconfig.debug |   14 +
 lib/Makefile  |1 
 lib/error-inject.c|  198 +
 26 files changed, 506 insertions(+), 239 deletions(-)
 create mode 100644 arch/x86/include/asm/error-injection.h
 create mode 100644 arch/x86/lib/error-inject.c
 create mode 100644 include/asm-generic/error-injection.h
 create mode 100644 include/linux/error-injection.h
 create mode 100644 kernel/fail_function.c
 create mode 100644 lib/error-inject.c

--
Masami Hiramatsu (Linaro)

[RFC PATCH bpf-next v2 0/4] Separate error injection table from kprobes

[Masami Hiramatsu]

Hi Josef and Alexei,

Here are the 2nd version of patches to moving error injection
table from kprobes. In this series I did a small fixes and
add function-based fault injection.

Here is the previous version:

https://lkml.org/lkml/2017/12/22/554

There are 2 main reasons why I separate it from kprobes.

 - kprobes users can modify execution path not only at 
   error-injection whitelist functions but also other
   functions. I don't like to suggest user that such
   limitation is from kprobes itself.

 - This error injection information is also useful for
   ftrace (function-hook) and livepatch. It should not
   be limited by CONFIG_KPROBES.

So I introduced CONFIG_FUNCTION_ERROR_INJECTION for this feature.
Also CONFIG_FAIL_FUNCTION is added, which provides function-based
error injection interface via debugfs following fault-injection
framework. See [4/4].

Any thoughts?

BTW, I think we should add an error-range description in
ALLOW_ERROR_INJECTION() macro. If user sets a success
return value and override it by mistake, caller must
break data or cause kernel panic.

Thank you,

---

Masami Hiramatsu (4):
  tracing/kprobe: bpf: Check error injectable event is on function entry
  tracing/kprobe: bpf: Compare instruction pointer with original one
  error-injection: Separate error-injection from kprobe
  error-injection: Support fault injection framework


 Documentation/fault-injection/fault-injection.txt |5 +
 arch/Kconfig  |2 
 arch/x86/Kconfig  |2 
 arch/x86/include/asm/error-injection.h|   12 +
 arch/x86/kernel/kprobes/ftrace.c  |   14 -
 arch/x86/lib/Makefile |2 
 arch/x86/lib/error-inject.c   |   19 ++
 fs/btrfs/disk-io.c|2 
 fs/btrfs/free-space-cache.c   |2 
 include/asm-generic/error-injection.h |   20 ++
 include/asm-generic/vmlinux.lds.h |   14 +
 include/linux/bpf.h   |   12 -
 include/linux/error-injection.h   |   21 ++
 include/linux/kprobes.h   |1 
 include/linux/module.h|6 -
 kernel/Makefile   |1 
 kernel/fail_function.c|  169 ++
 kernel/kprobes.c  |  163 -
 kernel/module.c   |8 -
 kernel/trace/Kconfig  |4 
 kernel/trace/bpf_trace.c  |9 -
 kernel/trace/trace_kprobe.c   |   32 +--
 kernel/trace/trace_probe.h|   12 +
 lib/Kconfig.debug |   14 +
 lib/Makefile  |1 
 lib/error-inject.c|  198 +
 26 files changed, 506 insertions(+), 239 deletions(-)
 create mode 100644 arch/x86/include/asm/error-injection.h
 create mode 100644 arch/x86/lib/error-inject.c
 create mode 100644 include/asm-generic/error-injection.h
 create mode 100644 include/linux/error-injection.h
 create mode 100644 kernel/fail_function.c
 create mode 100644 lib/error-inject.c

--
Masami Hiramatsu (Linaro)

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

[Sagar Arun Kamble]

On 12/15/2017 10:40 PM, Takashi Iwai wrote:

On Fri, 15 Dec 2017 17:51:25 +0100,
Richard Cochran wrote:

On Fri, Dec 15, 2017 at 12:10:47PM +0100, Takashi Iwai wrote:


-   struct cyclecounter *cc = _dev->tc.cc;
-   cc->read = azx_cc_read;
-   cc->mask = CLOCKSOURCE_MASK(32);
-   cc->mult = 125; /* saturation after 195 years */
-   cc->shift = 0;

I want to get away from this mess of open coded structure
initialization and use a proper functional interface instead.

I agree that a proper functional interface would be better, too.
But not a form like foo(501, 21, 10, 499, 5678).
In C syntax, you may more easily pass a wrong value than open codes.


nsec = 0; /* audio time is elapsed time since trigger */
-   timecounter_init(tc, nsec);
+   timecounter_initialize(tc,
+  azx_cc_read,
+  CLOCKSOURCE_MASK(32),
+  125, /* saturation after 195 years */
+  0,
+  nsec);

Hmm, a function with so many arguments is difficult to remember and is
often error-prone.  By this transition, it becomes harder to read
through.

Please suggest a better way.

I have no good idea ATM, sorry.

Or can we provide simpler versions for covering some defaults?  At
least reducing the number of arguments would make things easier.
Thought about specifying 1. cyclecounter read func 2. frequency 3. width 
of counter as parameters here
which can get rid of mult, shift params. But this is not easy as most of 
the drivers do not specify

cyclecounter frequency and instead hard-code the mult/shift factors.
How about passing initialized cyclecounter struct?


Takashi

Re: [alsa-devel] [PATCH 15/27] ALSA: hda - Use timecounter_initialize interface

[Sagar Arun Kamble]

On 12/15/2017 10:40 PM, Takashi Iwai wrote:

On Fri, 15 Dec 2017 17:51:25 +0100,
Richard Cochran wrote:

On Fri, Dec 15, 2017 at 12:10:47PM +0100, Takashi Iwai wrote:


-   struct cyclecounter *cc = _dev->tc.cc;
-   cc->read = azx_cc_read;
-   cc->mask = CLOCKSOURCE_MASK(32);
-   cc->mult = 125; /* saturation after 195 years */
-   cc->shift = 0;

I want to get away from this mess of open coded structure
initialization and use a proper functional interface instead.

I agree that a proper functional interface would be better, too.
But not a form like foo(501, 21, 10, 499, 5678).
In C syntax, you may more easily pass a wrong value than open codes.


nsec = 0; /* audio time is elapsed time since trigger */
-   timecounter_init(tc, nsec);
+   timecounter_initialize(tc,
+  azx_cc_read,
+  CLOCKSOURCE_MASK(32),
+  125, /* saturation after 195 years */
+  0,
+  nsec);

Hmm, a function with so many arguments is difficult to remember and is
often error-prone.  By this transition, it becomes harder to read
through.

Please suggest a better way.

I have no good idea ATM, sorry.

Or can we provide simpler versions for covering some defaults?  At
least reducing the number of arguments would make things easier.
Thought about specifying 1. cyclecounter read func 2. frequency 3. width 
of counter as parameters here
which can get rid of mult, shift params. But this is not easy as most of 
the drivers do not specify

cyclecounter frequency and instead hard-code the mult/shift factors.
How about passing initialized cyclecounter struct?


Takashi

Re: [PATCH] mfd: axp20x: Mark axp288 CHRG_BAK_CTRL register volatile

[Chen-Yu Tsai]

On Fri, Dec 22, 2017 at 8:35 PM, Hans de Goede  wrote:
> The input current limit bits get updated by the charger detection logic,
> so we should not cache the contents of this register.
>
> Signed-off-by: Hans de Goede 

Reviewed-by: Chen-Yu Tsai 

Re: [PATCH] mfd: axp20x: Mark axp288 CHRG_BAK_CTRL register volatile

[Chen-Yu Tsai]

On Fri, Dec 22, 2017 at 8:35 PM, Hans de Goede  wrote:
> The input current limit bits get updated by the charger detection logic,
> so we should not cache the contents of this register.
>
> Signed-off-by: Hans de Goede 

Reviewed-by: Chen-Yu Tsai 

[PATCH]cpuidle: preventive check in cpuidle_select against crash

[gaurav jindal]

When selecting the idle state using cpuidle_select, there is no
check on cpuidle_curr_governor. In cpuidle_switch_governor,
cpuidle_currr_governor can be set to NULL to specify "disabled".

Since cpuidle_select cannot return negative value, it has to return 0
in case of error. Printing logs and returning can help in debugging and
preventing possible kernel crash scenarios.

Signed-off-by: Gaurav Jindal

---

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 68a1682..bf08e3a 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -268,6 +268,19 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct 
cpuidle_driver *drv,
  */
 int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
 {
+
+   /* Since negative return is not allowed
+* we have to return 0 even if the
+* framework cannot select the idle state
+*/
+   if (!cpuidle_curr_governor) {
+   pr_err("idle governor is disabled\n");
+   return 0;
+   }
+   if (!cpuidle_curr_governor->select) {
+   pr_err("idle governor select is NULL\n");
+   return 0;
+   }
return cpuidle_curr_governor->select(drv, dev);
 }

[PATCH]cpuidle: preventive check in cpuidle_select against crash

[gaurav jindal]

When selecting the idle state using cpuidle_select, there is no
check on cpuidle_curr_governor. In cpuidle_switch_governor,
cpuidle_currr_governor can be set to NULL to specify "disabled".

Since cpuidle_select cannot return negative value, it has to return 0
in case of error. Printing logs and returning can help in debugging and
preventing possible kernel crash scenarios.

Signed-off-by: Gaurav Jindal

---

diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 68a1682..bf08e3a 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -268,6 +268,19 @@ int cpuidle_enter_state(struct cpuidle_device *dev, struct 
cpuidle_driver *drv,
  */
 int cpuidle_select(struct cpuidle_driver *drv, struct cpuidle_device *dev)
 {
+
+   /* Since negative return is not allowed
+* we have to return 0 even if the
+* framework cannot select the idle state
+*/
+   if (!cpuidle_curr_governor) {
+   pr_err("idle governor is disabled\n");
+   return 0;
+   }
+   if (!cpuidle_curr_governor->select) {
+   pr_err("idle governor select is NULL\n");
+   return 0;
+   }
return cpuidle_curr_governor->select(drv, dev);
 }

[PATCH] tracing: Fix crash when it fails to alloc ring buffer

[Chunyan Zhang]

From: Jing Xia 

Double free of the ring buffer happens when it fails to alloc new
ring buffer instance for max_buffer if TRACER_MAX_TRACE is configured.
The root cause is that the pointer is not set to NULL after the buffer
is freed in allocate_trace_buffers(), and the freeing of the ring
buffer is invoked again later if the pointer is not equal to Null,
as:

instance_mkdir()
|-allocate_trace_buffers()
|-allocate_trace_buffer(tr, >trace_buffer...)
|-allocate_trace_buffer(tr, >max_buffer...)

  // allocate fail(-ENOMEM),first free
  // and the buffer pointer is not set to null
|-ring_buffer_free(tr->trace_buffer.buffer)

   // out_free_tr
|-free_trace_buffers()
|-free_trace_buffer(>trace_buffer);

  //if trace_buffer is not null, free again
|-ring_buffer_free(buf->buffer)
|-rb_free_cpu_buffer(buffer->buffers[cpu])
// ring_buffer_per_cpu is null, and
// crash in ring_buffer_per_cpu->pages

Signed-off-by: Jing Xia 
Signed-off-by: Chunyan Zhang 
---
 kernel/trace/trace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 73e67b6..ed1c0d1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7622,7 +7622,9 @@ static int allocate_trace_buffers(struct trace_array *tr, 
int size)
allocate_snapshot ? size : 1);
if (WARN_ON(ret)) {
ring_buffer_free(tr->trace_buffer.buffer);
+   tr->trace_buffer.buffer = NULL;
free_percpu(tr->trace_buffer.data);
+   tr->trace_buffer.data = NULL;
return -ENOMEM;
}
tr->allocated_snapshot = allocate_snapshot;
-- 
2.7.4

[PATCH] tracing: Fix crash when it fails to alloc ring buffer

[Chunyan Zhang]

From: Jing Xia 

Double free of the ring buffer happens when it fails to alloc new
ring buffer instance for max_buffer if TRACER_MAX_TRACE is configured.
The root cause is that the pointer is not set to NULL after the buffer
is freed in allocate_trace_buffers(), and the freeing of the ring
buffer is invoked again later if the pointer is not equal to Null,
as:

instance_mkdir()
|-allocate_trace_buffers()
|-allocate_trace_buffer(tr, >trace_buffer...)
|-allocate_trace_buffer(tr, >max_buffer...)

  // allocate fail(-ENOMEM),first free
  // and the buffer pointer is not set to null
|-ring_buffer_free(tr->trace_buffer.buffer)

   // out_free_tr
|-free_trace_buffers()
|-free_trace_buffer(>trace_buffer);

  //if trace_buffer is not null, free again
|-ring_buffer_free(buf->buffer)
|-rb_free_cpu_buffer(buffer->buffers[cpu])
// ring_buffer_per_cpu is null, and
// crash in ring_buffer_per_cpu->pages

Signed-off-by: Jing Xia 
Signed-off-by: Chunyan Zhang 
---
 kernel/trace/trace.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 73e67b6..ed1c0d1 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -7622,7 +7622,9 @@ static int allocate_trace_buffers(struct trace_array *tr, 
int size)
allocate_snapshot ? size : 1);
if (WARN_ON(ret)) {
ring_buffer_free(tr->trace_buffer.buffer);
+   tr->trace_buffer.buffer = NULL;
free_percpu(tr->trace_buffer.data);
+   tr->trace_buffer.data = NULL;
return -ENOMEM;
}
tr->allocated_snapshot = allocate_snapshot;
-- 
2.7.4

Re: WARNING in do_debug

[Dmitry Vyukov]

On Tue, Dec 26, 2017 at 1:55 AM, Wanpeng Li  wrote:
> 2017-12-26 8:22 GMT+08:00 syzbot
> :
>> syzkaller has found reproducer for the following crash on
>> 464e1d5f23cca236b930ef068c328a64cab78fb1
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue=ed3b37ac63a060bdc184d126c0655c1af8b6de62
>
> There is a fix in kvm/queue.

Hi Wanpeng,

syzbot does not know about the fix and still thinks that this bug is
open. Please tell it about the fix:


> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> Note: all commands must start from beginning of the line.




>> WARNING: CPU: 0 PID: 3356 at arch/x86/kernel/traps.c:801
>> cond_local_irq_disable arch/x86/kernel/traps.c:86 [inline]
>> WARNING: CPU: 0 PID: 3356 at arch/x86/kernel/traps.c:801
>> do_debug+0x4d8/0x6e0 arch/x86/kernel/traps.c:815
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 0 PID: 3356 Comm: syzkaller834441 Not tainted 4.15.0-rc5+ #237
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  <#DB>
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  panic+0x1e4/0x41c kernel/panic.c:183
>>  __warn+0x1dc/0x200 kernel/panic.c:547
>>  report_bug+0x211/0x2d0 lib/bug.c:184
>>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1061
>> RIP: 0010:cond_local_irq_disable arch/x86/kernel/traps.c:86 [inline]
>> RIP: 0010:do_debug+0x4d8/0x6e0 arch/x86/kernel/traps.c:815
>> RSP: 0018:fe80ee98 EFLAGS: 00010246
>> RAX: dc00 RBX: fe80ef58 RCX: 
>> RDX: 1fd01dfc RSI: 0001 RDI: 85ec81f8
>> RBP: fe80ef48 R08: fe80efe8 R09: 
>> R10:  R11:  R12: e003
>> R13: 8801c2340040 R14: 1fd01dd8 R15: 4000
>>  debug+0x34/0x60 arch/x86/entry/entry_64.S:1214
>> RIP: 0010:__put_user_8+0x1f/0x25 arch/x86/lib/putuser.S:83
>> RSP: 0018:8801c9f8ff28 EFLAGS: 0293
>> RAX: 5a4195b6 RBX: 7fffeff9 RCX: 2000
>> RDX:  RSI: 0001 RDI: 0282
>> RBP: 8801c9f8ff48 R08:  R09: 1100393f1fc2
>> R10: 8801c9f8fdd8 R11:  R12: 5a4195b6
>> R13: 2000 R14: 7f2c937f99c0 R15: 0001
>>  
>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x44aef9
>> RSP: 002b:7f2c937f8ce8 EFLAGS: 0206 ORIG_RAX: 00c9
>> RAX: ffda RBX: 006dcc24 RCX: 0044aef9
>> RDX: 0044aef9 RSI: 0044aef9 RDI: 2000
>> RBP: 006dcc20 R08:  R09: 
>> R10:  R11: 0206 R12: 
>> R13: 7ffe9191073f R14: 7f2c937f99c0 R15: 0001
>>
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>

Re: WARNING in do_debug

[Dmitry Vyukov]

On Tue, Dec 26, 2017 at 1:55 AM, Wanpeng Li  wrote:
> 2017-12-26 8:22 GMT+08:00 syzbot
> :
>> syzkaller has found reproducer for the following crash on
>> 464e1d5f23cca236b930ef068c328a64cab78fb1
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> C reproducer is attached
>> syzkaller reproducer is attached. See https://goo.gl/kgGztJ
>> for information about syzkaller reproducers
>>
>
> https://git.kernel.org/pub/scm/virt/kvm/kvm.git/commit/?h=queue=ed3b37ac63a060bdc184d126c0655c1af8b6de62
>
> There is a fix in kvm/queue.

Hi Wanpeng,

syzbot does not know about the fix and still thinks that this bug is
open. Please tell it about the fix:


> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> Note: all commands must start from beginning of the line.




>> WARNING: CPU: 0 PID: 3356 at arch/x86/kernel/traps.c:801
>> cond_local_irq_disable arch/x86/kernel/traps.c:86 [inline]
>> WARNING: CPU: 0 PID: 3356 at arch/x86/kernel/traps.c:801
>> do_debug+0x4d8/0x6e0 arch/x86/kernel/traps.c:815
>> Kernel panic - not syncing: panic_on_warn set ...
>>
>> CPU: 0 PID: 3356 Comm: syzkaller834441 Not tainted 4.15.0-rc5+ #237
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>>  <#DB>
>>  __dump_stack lib/dump_stack.c:17 [inline]
>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>  panic+0x1e4/0x41c kernel/panic.c:183
>>  __warn+0x1dc/0x200 kernel/panic.c:547
>>  report_bug+0x211/0x2d0 lib/bug.c:184
>>  fixup_bug.part.11+0x37/0x80 arch/x86/kernel/traps.c:178
>>  fixup_bug arch/x86/kernel/traps.c:247 [inline]
>>  do_error_trap+0x2d7/0x3e0 arch/x86/kernel/traps.c:296
>>  do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:315
>>  invalid_op+0x22/0x40 arch/x86/entry/entry_64.S:1061
>> RIP: 0010:cond_local_irq_disable arch/x86/kernel/traps.c:86 [inline]
>> RIP: 0010:do_debug+0x4d8/0x6e0 arch/x86/kernel/traps.c:815
>> RSP: 0018:fe80ee98 EFLAGS: 00010246
>> RAX: dc00 RBX: fe80ef58 RCX: 
>> RDX: 1fd01dfc RSI: 0001 RDI: 85ec81f8
>> RBP: fe80ef48 R08: fe80efe8 R09: 
>> R10:  R11:  R12: e003
>> R13: 8801c2340040 R14: 1fd01dd8 R15: 4000
>>  debug+0x34/0x60 arch/x86/entry/entry_64.S:1214
>> RIP: 0010:__put_user_8+0x1f/0x25 arch/x86/lib/putuser.S:83
>> RSP: 0018:8801c9f8ff28 EFLAGS: 0293
>> RAX: 5a4195b6 RBX: 7fffeff9 RCX: 2000
>> RDX:  RSI: 0001 RDI: 0282
>> RBP: 8801c9f8ff48 R08:  R09: 1100393f1fc2
>> R10: 8801c9f8fdd8 R11:  R12: 5a4195b6
>> R13: 2000 R14: 7f2c937f99c0 R15: 0001
>>  
>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x44aef9
>> RSP: 002b:7f2c937f8ce8 EFLAGS: 0206 ORIG_RAX: 00c9
>> RAX: ffda RBX: 006dcc24 RCX: 0044aef9
>> RDX: 0044aef9 RSI: 0044aef9 RDI: 2000
>> RBP: 006dcc20 R08:  R09: 
>> R10:  R11: 0206 R12: 
>> R13: 7ffe9191073f R14: 7f2c937f99c0 R15: 0001
>>
>> Dumping ftrace buffer:
>>(ftrace buffer empty)
>> Kernel Offset: disabled
>> Rebooting in 86400 seconds..
>>

RE: [PATCH] arm: imx: suspend/resume: use outer_disable/resume

[Peng Fan]

Hi Shawn,

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Tuesday, December 26, 2017 11:31 AM
> To: Peng Fan 
> Cc: A.s. Dong ; linux-kernel@vger.kernel.org; Russell
> King ; Fabio Estevam ;
> Sascha Hauer ; van.free...@gmail.com; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH] arm: imx: suspend/resume: use outer_disable/resume
> 
> On Sun, Dec 10, 2017 at 08:07:18PM +0800, Peng Fan wrote:
> > Use outer_disable/resume for suspend/resume.
> > With the two APIs used, code could be simplified and easy to extend to
> > introduce l2c_write_sec for i.MX platforms when moving Linux Kernel
> > runs in non-secure world.
> >
> > Signed-off-by: Peng Fan 
> > Cc: Shawn Guo 
> > Cc: Sascha Hauer 
> > Cc: Fabio Estevam 
> > Cc: Russell King 
> > Cc: Dong Aisheng 
> > ---
> >  arch/arm/mach-imx/pm-imx6.c  |  2 ++
> >  arch/arm/mach-imx/suspend-imx6.S | 24 
> 
> I'm fine with the patch in general.  But this piece of code is running on a 
> few
> i.MX6 platforms, and I'm wondering on which SoCs you have verified the
> change work fine.

I tested it on 6Q-SDB board. Is it ok?

Thanks,
Peng.

> 
> Shawn

RE: [PATCH] arm: imx: suspend/resume: use outer_disable/resume

[Peng Fan]

Hi Shawn,

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Tuesday, December 26, 2017 11:31 AM
> To: Peng Fan 
> Cc: A.s. Dong ; linux-kernel@vger.kernel.org; Russell
> King ; Fabio Estevam ;
> Sascha Hauer ; van.free...@gmail.com; linux-arm-
> ker...@lists.infradead.org
> Subject: Re: [PATCH] arm: imx: suspend/resume: use outer_disable/resume
> 
> On Sun, Dec 10, 2017 at 08:07:18PM +0800, Peng Fan wrote:
> > Use outer_disable/resume for suspend/resume.
> > With the two APIs used, code could be simplified and easy to extend to
> > introduce l2c_write_sec for i.MX platforms when moving Linux Kernel
> > runs in non-secure world.
> >
> > Signed-off-by: Peng Fan 
> > Cc: Shawn Guo 
> > Cc: Sascha Hauer 
> > Cc: Fabio Estevam 
> > Cc: Russell King 
> > Cc: Dong Aisheng 
> > ---
> >  arch/arm/mach-imx/pm-imx6.c  |  2 ++
> >  arch/arm/mach-imx/suspend-imx6.S | 24 
> 
> I'm fine with the patch in general.  But this piece of code is running on a 
> few
> i.MX6 platforms, and I'm wondering on which SoCs you have verified the
> change work fine.

I tested it on 6Q-SDB board. Is it ok?

Thanks,
Peng.

> 
> Shawn

[PATCH 10/11 v2] ARM: s3c24xx/s3c64xx: constify gpio_led

[Arvind Yadav]

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-s3c24xx/mach-h1940.c| 2 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c   | 2 +-
 arch/arm/mach-s3c64xx/mach-hmt.c  | 2 +-
 arch/arm/mach-s3c64xx/mach-smartq5.c  | 2 +-
 arch/arm/mach-s3c64xx/mach-smartq7.c  | 2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c 
b/arch/arm/mach-s3c24xx/mach-h1940.c
index 7ed7861..6a3e0e6 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -413,7 +413,7 @@ int h1940_led_blink_set(struct gpio_desc *desc, int state,
 }
 EXPORT_SYMBOL(h1940_led_blink_set);
 
-static struct gpio_led h1940_leds_desc[] = {
+static const struct gpio_led h1940_leds_desc[] = {
{
.name   = "Green",
.default_trigger= "main-battery-full",
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c 
b/arch/arm/mach-s3c24xx/mach-rx1950.c
index e86ad6a..97bb6a5 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -295,7 +295,7 @@ static int rx1950_led_blink_set(struct gpio_desc *desc, int 
state,
return 0;
 }
 
-static struct gpio_led rx1950_leds_desc[] = {
+static const struct gpio_led rx1950_leds_desc[] = {
{
.name   = "Green",
.default_trigger= "main-battery-full",
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index 59b5531..f8d644f 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -207,7 +207,7 @@ static struct s3c2410_platform_nand hmt_nand_info = {
.ecc_mode   = NAND_ECC_SOFT,
 };
 
-static struct gpio_led hmt_leds[] = {
+static const struct gpio_led hmt_leds[] = {
{ /* left function keys */
.name   = "left:blue",
.gpio   = S3C64XX_GPO(12),
diff --git a/arch/arm/mach-s3c64xx/mach-smartq5.c 
b/arch/arm/mach-s3c64xx/mach-smartq5.c
index 0972b6c..5a7cd8f 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq5.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq5.c
@@ -35,7 +35,7 @@
 #include "common.h"
 #include "mach-smartq.h"
 
-static struct gpio_led smartq5_leds[] = {
+static const struct gpio_led smartq5_leds[] = {
{
.name   = "smartq5:green",
.active_low = 1,
diff --git a/arch/arm/mach-s3c64xx/mach-smartq7.c 
b/arch/arm/mach-s3c64xx/mach-smartq7.c
index 51ac1c6..9de9fc2 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq7.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq7.c
@@ -35,7 +35,7 @@
 #include "common.h"
 #include "mach-smartq.h"
 
-static struct gpio_led smartq7_leds[] = {
+static const struct gpio_led smartq7_leds[] = {
{
.name   = "smartq7:red",
.active_low = 1,
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 92ec8c3..be9d98f 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -497,7 +497,7 @@ static struct wm8350_platform_data __initdata 
smdk6410_wm8350_pdata = {
 #endif
 
 #ifdef CONFIG_SMDK6410_WM1192_EV1
-static struct gpio_led wm1192_pmic_leds[] = {
+static const struct gpio_led wm1192_pmic_leds[] = {
{
.name = "PMIC:red:power",
.gpio = GPIO_BOARD_START + 3,
-- 
2.7.4

[PATCH 11/11 v2] ARM: pxa: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'. Resolve auto build test ERROR.

 arch/arm/mach-pxa/balloon3.c  | 4 ++--
 arch/arm/mach-pxa/corgi.c | 2 +-
 arch/arm/mach-pxa/csb701.c| 2 +-
 arch/arm/mach-pxa/magician.c  | 2 +-
 arch/arm/mach-pxa/mioa701.c   | 2 +-
 arch/arm/mach-pxa/palmld.c| 2 +-
 arch/arm/mach-pxa/palmz72.c   | 2 +-
 arch/arm/mach-pxa/pcm027.c| 2 +-
 arch/arm/mach-pxa/raumfeld.c  | 4 ++--
 arch/arm/mach-pxa/spitz.c | 2 +-
 arch/arm/mach-pxa/stargate2.c | 2 +-
 arch/arm/mach-pxa/tosa.c  | 2 +-
 arch/arm/mach-pxa/trizeps4.c  | 2 +-
 arch/arm/mach-pxa/zeus.c  | 2 +-
 14 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index d6d92f3..abcfb19 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -387,7 +387,7 @@ static unsigned long balloon3_led_pin_config[] __initdata = 
{
GPIO10_GPIO,/* Heartbeat LED */
 };
 
-struct gpio_led balloon3_gpio_leds[] = {
+const struct gpio_led balloon3_gpio_leds[] = {
{
.name   = "balloon3:green:idle",
.default_trigger= "heartbeat",
@@ -414,7 +414,7 @@ static struct platform_device balloon3_leds = {
}
 };
 
-struct gpio_led balloon3_pcf_gpio_leds[] = {
+const struct gpio_led balloon3_pcf_gpio_leds[] = {
{
.name   = "balloon3:green:led0",
.gpio   = BALLOON3_PCF_GPIO_LED0,
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 7270f0db..6d6ded0 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -450,7 +450,7 @@ static struct platform_device corgi_gpio_keys_device = {
 /*
  * Corgi LEDs
  */
-static struct gpio_led corgi_gpio_leds[] = {
+static const struct gpio_led corgi_gpio_leds[] = {
{
.name   = "corgi:amber:charge",
.default_trigger= "sharpsl-charge",
diff --git a/arch/arm/mach-pxa/csb701.c b/arch/arm/mach-pxa/csb701.c
index 527c9fd..b062b50 100644
--- a/arch/arm/mach-pxa/csb701.c
+++ b/arch/arm/mach-pxa/csb701.c
@@ -24,7 +24,7 @@ static struct gpio_keys_platform_data csb701_gpio_keys_data = 
{
.nbuttons = ARRAY_SIZE(csb701_buttons),
 };
 
-static struct gpio_led csb701_leds[] = {
+static const struct gpio_led csb701_leds[] = {
{
.name   = "csb701:yellow:heartbeat",
.default_trigger = "heartbeat",
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index 7f3566c..505c9cc 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -424,7 +424,7 @@ static struct platform_device backlight = {
  * GPIO LEDs, Phone keys backlight, vibra
  */
 
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
{
.name = "magician::vibra",
.default_trigger = "none",
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 8a5d049..88115f0 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -274,7 +274,7 @@ static struct gpio_keys_platform_data 
mioa701_gpio_keys_data = {
  */
 #define ONE_LED(_gpio, _name) \
 { .gpio = (_gpio), .name = (_name), .active_low = true }
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
ONE_LED(GPIO10_LED_nCharging, "mioa701:charging"),
ONE_LED(GPIO97_LED_nBlue, "mioa701:blue"),
ONE_LED(GPIO98_LED_nOrange, "mioa701:orange"),
diff --git a/arch/arm/mach-pxa/palmld.c b/arch/arm/mach-pxa/palmld.c
index 980f284..eb5992b 100644
--- a/arch/arm/mach-pxa/palmld.c
+++ b/arch/arm/mach-pxa/palmld.c
@@ -246,7 +246,7 @@ static inline void palmld_keys_init(void) {}
  * LEDs
  
**/
 #if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
-struct gpio_led gpio_leds[] = {
+const struct gpio_led gpio_leds[] = {
 {
.name   = "palmld:green:led",
.default_trigger= "none",
diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
index 5877e54..99c5bf2 100644
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@ -182,7 +182,7 @@ static inline void palmz72_kpc_init(void) {}
  * LEDs
  
**/
 #if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
{
   

[PATCH 10/11 v2] ARM: s3c24xx/s3c64xx: constify gpio_led

[Arvind Yadav]

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-s3c24xx/mach-h1940.c| 2 +-
 arch/arm/mach-s3c24xx/mach-rx1950.c   | 2 +-
 arch/arm/mach-s3c64xx/mach-hmt.c  | 2 +-
 arch/arm/mach-s3c64xx/mach-smartq5.c  | 2 +-
 arch/arm/mach-s3c64xx/mach-smartq7.c  | 2 +-
 arch/arm/mach-s3c64xx/mach-smdk6410.c | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/mach-s3c24xx/mach-h1940.c 
b/arch/arm/mach-s3c24xx/mach-h1940.c
index 7ed7861..6a3e0e6 100644
--- a/arch/arm/mach-s3c24xx/mach-h1940.c
+++ b/arch/arm/mach-s3c24xx/mach-h1940.c
@@ -413,7 +413,7 @@ int h1940_led_blink_set(struct gpio_desc *desc, int state,
 }
 EXPORT_SYMBOL(h1940_led_blink_set);
 
-static struct gpio_led h1940_leds_desc[] = {
+static const struct gpio_led h1940_leds_desc[] = {
{
.name   = "Green",
.default_trigger= "main-battery-full",
diff --git a/arch/arm/mach-s3c24xx/mach-rx1950.c 
b/arch/arm/mach-s3c24xx/mach-rx1950.c
index e86ad6a..97bb6a5 100644
--- a/arch/arm/mach-s3c24xx/mach-rx1950.c
+++ b/arch/arm/mach-s3c24xx/mach-rx1950.c
@@ -295,7 +295,7 @@ static int rx1950_led_blink_set(struct gpio_desc *desc, int 
state,
return 0;
 }
 
-static struct gpio_led rx1950_leds_desc[] = {
+static const struct gpio_led rx1950_leds_desc[] = {
{
.name   = "Green",
.default_trigger= "main-battery-full",
diff --git a/arch/arm/mach-s3c64xx/mach-hmt.c b/arch/arm/mach-s3c64xx/mach-hmt.c
index 59b5531..f8d644f 100644
--- a/arch/arm/mach-s3c64xx/mach-hmt.c
+++ b/arch/arm/mach-s3c64xx/mach-hmt.c
@@ -207,7 +207,7 @@ static struct s3c2410_platform_nand hmt_nand_info = {
.ecc_mode   = NAND_ECC_SOFT,
 };
 
-static struct gpio_led hmt_leds[] = {
+static const struct gpio_led hmt_leds[] = {
{ /* left function keys */
.name   = "left:blue",
.gpio   = S3C64XX_GPO(12),
diff --git a/arch/arm/mach-s3c64xx/mach-smartq5.c 
b/arch/arm/mach-s3c64xx/mach-smartq5.c
index 0972b6c..5a7cd8f 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq5.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq5.c
@@ -35,7 +35,7 @@
 #include "common.h"
 #include "mach-smartq.h"
 
-static struct gpio_led smartq5_leds[] = {
+static const struct gpio_led smartq5_leds[] = {
{
.name   = "smartq5:green",
.active_low = 1,
diff --git a/arch/arm/mach-s3c64xx/mach-smartq7.c 
b/arch/arm/mach-s3c64xx/mach-smartq7.c
index 51ac1c6..9de9fc2 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq7.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq7.c
@@ -35,7 +35,7 @@
 #include "common.h"
 #include "mach-smartq.h"
 
-static struct gpio_led smartq7_leds[] = {
+static const struct gpio_led smartq7_leds[] = {
{
.name   = "smartq7:red",
.active_low = 1,
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c 
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index 92ec8c3..be9d98f 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -497,7 +497,7 @@ static struct wm8350_platform_data __initdata 
smdk6410_wm8350_pdata = {
 #endif
 
 #ifdef CONFIG_SMDK6410_WM1192_EV1
-static struct gpio_led wm1192_pmic_leds[] = {
+static const struct gpio_led wm1192_pmic_leds[] = {
{
.name = "PMIC:red:power",
.gpio = GPIO_BOARD_START + 3,
-- 
2.7.4

[PATCH 11/11 v2] ARM: pxa: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'. Resolve auto build test ERROR.

 arch/arm/mach-pxa/balloon3.c  | 4 ++--
 arch/arm/mach-pxa/corgi.c | 2 +-
 arch/arm/mach-pxa/csb701.c| 2 +-
 arch/arm/mach-pxa/magician.c  | 2 +-
 arch/arm/mach-pxa/mioa701.c   | 2 +-
 arch/arm/mach-pxa/palmld.c| 2 +-
 arch/arm/mach-pxa/palmz72.c   | 2 +-
 arch/arm/mach-pxa/pcm027.c| 2 +-
 arch/arm/mach-pxa/raumfeld.c  | 4 ++--
 arch/arm/mach-pxa/spitz.c | 2 +-
 arch/arm/mach-pxa/stargate2.c | 2 +-
 arch/arm/mach-pxa/tosa.c  | 2 +-
 arch/arm/mach-pxa/trizeps4.c  | 2 +-
 arch/arm/mach-pxa/zeus.c  | 2 +-
 14 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/arch/arm/mach-pxa/balloon3.c b/arch/arm/mach-pxa/balloon3.c
index d6d92f3..abcfb19 100644
--- a/arch/arm/mach-pxa/balloon3.c
+++ b/arch/arm/mach-pxa/balloon3.c
@@ -387,7 +387,7 @@ static unsigned long balloon3_led_pin_config[] __initdata = 
{
GPIO10_GPIO,/* Heartbeat LED */
 };
 
-struct gpio_led balloon3_gpio_leds[] = {
+const struct gpio_led balloon3_gpio_leds[] = {
{
.name   = "balloon3:green:idle",
.default_trigger= "heartbeat",
@@ -414,7 +414,7 @@ static struct platform_device balloon3_leds = {
}
 };
 
-struct gpio_led balloon3_pcf_gpio_leds[] = {
+const struct gpio_led balloon3_pcf_gpio_leds[] = {
{
.name   = "balloon3:green:led0",
.gpio   = BALLOON3_PCF_GPIO_LED0,
diff --git a/arch/arm/mach-pxa/corgi.c b/arch/arm/mach-pxa/corgi.c
index 7270f0db..6d6ded0 100644
--- a/arch/arm/mach-pxa/corgi.c
+++ b/arch/arm/mach-pxa/corgi.c
@@ -450,7 +450,7 @@ static struct platform_device corgi_gpio_keys_device = {
 /*
  * Corgi LEDs
  */
-static struct gpio_led corgi_gpio_leds[] = {
+static const struct gpio_led corgi_gpio_leds[] = {
{
.name   = "corgi:amber:charge",
.default_trigger= "sharpsl-charge",
diff --git a/arch/arm/mach-pxa/csb701.c b/arch/arm/mach-pxa/csb701.c
index 527c9fd..b062b50 100644
--- a/arch/arm/mach-pxa/csb701.c
+++ b/arch/arm/mach-pxa/csb701.c
@@ -24,7 +24,7 @@ static struct gpio_keys_platform_data csb701_gpio_keys_data = 
{
.nbuttons = ARRAY_SIZE(csb701_buttons),
 };
 
-static struct gpio_led csb701_leds[] = {
+static const struct gpio_led csb701_leds[] = {
{
.name   = "csb701:yellow:heartbeat",
.default_trigger = "heartbeat",
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index 7f3566c..505c9cc 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -424,7 +424,7 @@ static struct platform_device backlight = {
  * GPIO LEDs, Phone keys backlight, vibra
  */
 
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
{
.name = "magician::vibra",
.default_trigger = "none",
diff --git a/arch/arm/mach-pxa/mioa701.c b/arch/arm/mach-pxa/mioa701.c
index 8a5d049..88115f0 100644
--- a/arch/arm/mach-pxa/mioa701.c
+++ b/arch/arm/mach-pxa/mioa701.c
@@ -274,7 +274,7 @@ static struct gpio_keys_platform_data 
mioa701_gpio_keys_data = {
  */
 #define ONE_LED(_gpio, _name) \
 { .gpio = (_gpio), .name = (_name), .active_low = true }
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
ONE_LED(GPIO10_LED_nCharging, "mioa701:charging"),
ONE_LED(GPIO97_LED_nBlue, "mioa701:blue"),
ONE_LED(GPIO98_LED_nOrange, "mioa701:orange"),
diff --git a/arch/arm/mach-pxa/palmld.c b/arch/arm/mach-pxa/palmld.c
index 980f284..eb5992b 100644
--- a/arch/arm/mach-pxa/palmld.c
+++ b/arch/arm/mach-pxa/palmld.c
@@ -246,7 +246,7 @@ static inline void palmld_keys_init(void) {}
  * LEDs
  
**/
 #if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
-struct gpio_led gpio_leds[] = {
+const struct gpio_led gpio_leds[] = {
 {
.name   = "palmld:green:led",
.default_trigger= "none",
diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
index 5877e54..99c5bf2 100644
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@ -182,7 +182,7 @@ static inline void palmz72_kpc_init(void) {}
  * LEDs
  
**/
 #if defined(CONFIG_LEDS_GPIO) || defined(CONFIG_LEDS_GPIO_MODULE)
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
{
.name 

[PATCH 09/11 v2] ARM: orion5x: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-orion5x/board-d2net.c  | 2 +-
 arch/arm/mach-orion5x/dns323-setup.c | 2 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c | 2 +-
 arch/arm/mach-orion5x/mv2120-setup.c | 2 +-
 arch/arm/mach-orion5x/net2big-setup.c| 2 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c  | 2 +-
 arch/arm/mach-orion5x/ts409-setup.c  | 2 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-orion5x/board-d2net.c 
b/arch/arm/mach-orion5x/board-d2net.c
index a89376a..55d6562 100644
--- a/arch/arm/mach-orion5x/board-d2net.c
+++ b/arch/arm/mach-orion5x/board-d2net.c
@@ -54,7 +54,7 @@
 #define D2NET_GPIO_BLUE_LED_BLINK_CTRL 16
 #define D2NET_GPIO_BLUE_LED_OFF23
 
-static struct gpio_led d2net_leds[] = {
+static const struct gpio_led d2net_leds[] = {
{
.name = "d2net:blue:sata",
.default_trigger = "default-on",
diff --git a/arch/arm/mach-orion5x/dns323-setup.c 
b/arch/arm/mach-orion5x/dns323-setup.c
index cd483bf..6aeab1d 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -204,7 +204,7 @@ static int __init dns323_read_mac_addr(void)
  * GPIO LEDs (simple - doesn't use hardware blinking support)
  */
 
-static struct gpio_led dns323ab_leds[] = {
+static const struct gpio_led dns323ab_leds[] = {
{
.name = "power:blue",
.gpio = DNS323_GPIO_LED_POWER2,
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c 
b/arch/arm/mach-orion5x/ls_hgl-setup.c
index 47ba6e0..c394281 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -86,7 +86,7 @@ static struct i2c_board_info __initdata ls_hgl_i2c_rtc = {
 #define LS_HGL_GPIO_LED_PWR 0
 
 
-static struct gpio_led ls_hgl_led_pins[] = {
+static const struct gpio_led ls_hgl_led_pins[] = {
{
.name  = "alarm:red",
.gpio  = LS_HGL_GPIO_LED_ALARM,
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c 
b/arch/arm/mach-orion5x/mv2120-setup.c
index 2bf8ec7..724c08a 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -136,7 +136,7 @@ static struct i2c_board_info __initdata mv2120_i2c_rtc = {
.irq= 0,
 };
 
-static struct gpio_led mv2120_led_pins[] = {
+static const struct gpio_led mv2120_led_pins[] = {
{
.name   = "mv2120:blue:health",
.gpio   = 0,
diff --git a/arch/arm/mach-orion5x/net2big-setup.c 
b/arch/arm/mach-orion5x/net2big-setup.c
index bf6be4c..7d59888 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -214,7 +214,7 @@ static void __init net2big_sata_power_init(void)
 #define NET2BIG_GPIO_SATA0_BLUE_LED17
 #define NET2BIG_GPIO_SATA1_BLUE_LED13
 
-static struct gpio_led net2big_leds[] = {
+static const struct gpio_led net2big_leds[] = {
{
.name = "net2big:red:power",
.gpio = NET2BIG_GPIO_PWR_RED_LED,
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c 
b/arch/arm/mach-orion5x/rd88f5182-setup.c
index fe3e67c..e2f280d 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -83,7 +83,7 @@ static struct platform_device rd88f5182_nor_flash = {
 
 #define RD88F5182_GPIO_LED 0
 
-static struct gpio_led rd88f5182_gpio_led_pins[] = {
+static const struct gpio_led rd88f5182_gpio_led_pins[] = {
{
.name   = "rd88f5182:cpu",
.default_trigger = "cpu0",
diff --git a/arch/arm/mach-orion5x/ts409-setup.c 
b/arch/arm/mach-orion5x/ts409-setup.c
index a77613b..a31f6848 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -169,7 +169,7 @@ static struct i2c_board_info __initdata qnap_ts409_i2c_rtc 
= {
  * LEDs attached to GPIO
  /
 
-static struct gpio_led ts409_led_pins[] = {
+static const struct gpio_led ts409_led_pins[] = {
{
.name   = "ts409:red:sata1",
.gpio   = 4,
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c 
b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index 9250bb2..5493d73 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -29,7 +29,7 @@
 /*
  * LEDs attached to GPIO
  */
-static struct gpio_led wrt350n_v2_led_pins[] = {
+static const struct 

[PATCH 06/11 v2] ARM: davinci: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c 
b/arch/arm/mach-davinci/board-neuros-osd2.c
index 0c02aaa..4da210a 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -128,7 +128,7 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
 };
 
-static struct gpio_led ntosd2_leds[] = {
+static const struct gpio_led ntosd2_leds[] = {
{ .name = "led1_green", .gpio = GPIO(10), },
{ .name = "led1_red",   .gpio = GPIO(11), },
{ .name = "led2_green", .gpio = GPIO(12), },
-- 
2.7.4

[PATCH 09/11 v2] ARM: orion5x: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-orion5x/board-d2net.c  | 2 +-
 arch/arm/mach-orion5x/dns323-setup.c | 2 +-
 arch/arm/mach-orion5x/ls_hgl-setup.c | 2 +-
 arch/arm/mach-orion5x/mv2120-setup.c | 2 +-
 arch/arm/mach-orion5x/net2big-setup.c| 2 +-
 arch/arm/mach-orion5x/rd88f5182-setup.c  | 2 +-
 arch/arm/mach-orion5x/ts409-setup.c  | 2 +-
 arch/arm/mach-orion5x/wrt350n-v2-setup.c | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-orion5x/board-d2net.c 
b/arch/arm/mach-orion5x/board-d2net.c
index a89376a..55d6562 100644
--- a/arch/arm/mach-orion5x/board-d2net.c
+++ b/arch/arm/mach-orion5x/board-d2net.c
@@ -54,7 +54,7 @@
 #define D2NET_GPIO_BLUE_LED_BLINK_CTRL 16
 #define D2NET_GPIO_BLUE_LED_OFF23
 
-static struct gpio_led d2net_leds[] = {
+static const struct gpio_led d2net_leds[] = {
{
.name = "d2net:blue:sata",
.default_trigger = "default-on",
diff --git a/arch/arm/mach-orion5x/dns323-setup.c 
b/arch/arm/mach-orion5x/dns323-setup.c
index cd483bf..6aeab1d 100644
--- a/arch/arm/mach-orion5x/dns323-setup.c
+++ b/arch/arm/mach-orion5x/dns323-setup.c
@@ -204,7 +204,7 @@ static int __init dns323_read_mac_addr(void)
  * GPIO LEDs (simple - doesn't use hardware blinking support)
  */
 
-static struct gpio_led dns323ab_leds[] = {
+static const struct gpio_led dns323ab_leds[] = {
{
.name = "power:blue",
.gpio = DNS323_GPIO_LED_POWER2,
diff --git a/arch/arm/mach-orion5x/ls_hgl-setup.c 
b/arch/arm/mach-orion5x/ls_hgl-setup.c
index 47ba6e0..c394281 100644
--- a/arch/arm/mach-orion5x/ls_hgl-setup.c
+++ b/arch/arm/mach-orion5x/ls_hgl-setup.c
@@ -86,7 +86,7 @@ static struct i2c_board_info __initdata ls_hgl_i2c_rtc = {
 #define LS_HGL_GPIO_LED_PWR 0
 
 
-static struct gpio_led ls_hgl_led_pins[] = {
+static const struct gpio_led ls_hgl_led_pins[] = {
{
.name  = "alarm:red",
.gpio  = LS_HGL_GPIO_LED_ALARM,
diff --git a/arch/arm/mach-orion5x/mv2120-setup.c 
b/arch/arm/mach-orion5x/mv2120-setup.c
index 2bf8ec7..724c08a 100644
--- a/arch/arm/mach-orion5x/mv2120-setup.c
+++ b/arch/arm/mach-orion5x/mv2120-setup.c
@@ -136,7 +136,7 @@ static struct i2c_board_info __initdata mv2120_i2c_rtc = {
.irq= 0,
 };
 
-static struct gpio_led mv2120_led_pins[] = {
+static const struct gpio_led mv2120_led_pins[] = {
{
.name   = "mv2120:blue:health",
.gpio   = 0,
diff --git a/arch/arm/mach-orion5x/net2big-setup.c 
b/arch/arm/mach-orion5x/net2big-setup.c
index bf6be4c..7d59888 100644
--- a/arch/arm/mach-orion5x/net2big-setup.c
+++ b/arch/arm/mach-orion5x/net2big-setup.c
@@ -214,7 +214,7 @@ static void __init net2big_sata_power_init(void)
 #define NET2BIG_GPIO_SATA0_BLUE_LED17
 #define NET2BIG_GPIO_SATA1_BLUE_LED13
 
-static struct gpio_led net2big_leds[] = {
+static const struct gpio_led net2big_leds[] = {
{
.name = "net2big:red:power",
.gpio = NET2BIG_GPIO_PWR_RED_LED,
diff --git a/arch/arm/mach-orion5x/rd88f5182-setup.c 
b/arch/arm/mach-orion5x/rd88f5182-setup.c
index fe3e67c..e2f280d 100644
--- a/arch/arm/mach-orion5x/rd88f5182-setup.c
+++ b/arch/arm/mach-orion5x/rd88f5182-setup.c
@@ -83,7 +83,7 @@ static struct platform_device rd88f5182_nor_flash = {
 
 #define RD88F5182_GPIO_LED 0
 
-static struct gpio_led rd88f5182_gpio_led_pins[] = {
+static const struct gpio_led rd88f5182_gpio_led_pins[] = {
{
.name   = "rd88f5182:cpu",
.default_trigger = "cpu0",
diff --git a/arch/arm/mach-orion5x/ts409-setup.c 
b/arch/arm/mach-orion5x/ts409-setup.c
index a77613b..a31f6848 100644
--- a/arch/arm/mach-orion5x/ts409-setup.c
+++ b/arch/arm/mach-orion5x/ts409-setup.c
@@ -169,7 +169,7 @@ static struct i2c_board_info __initdata qnap_ts409_i2c_rtc 
= {
  * LEDs attached to GPIO
  /
 
-static struct gpio_led ts409_led_pins[] = {
+static const struct gpio_led ts409_led_pins[] = {
{
.name   = "ts409:red:sata1",
.gpio   = 4,
diff --git a/arch/arm/mach-orion5x/wrt350n-v2-setup.c 
b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
index 9250bb2..5493d73 100644
--- a/arch/arm/mach-orion5x/wrt350n-v2-setup.c
+++ b/arch/arm/mach-orion5x/wrt350n-v2-setup.c
@@ -29,7 +29,7 @@
 /*
  * LEDs attached to GPIO
  */
-static struct gpio_led wrt350n_v2_led_pins[] = {
+static const struct gpio_led 

[PATCH 06/11 v2] ARM: davinci: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-davinci/board-neuros-osd2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-davinci/board-neuros-osd2.c 
b/arch/arm/mach-davinci/board-neuros-osd2.c
index 0c02aaa..4da210a 100644
--- a/arch/arm/mach-davinci/board-neuros-osd2.c
+++ b/arch/arm/mach-davinci/board-neuros-osd2.c
@@ -128,7 +128,7 @@ static struct platform_device davinci_fb_device = {
.num_resources = 0,
 };
 
-static struct gpio_led ntosd2_leds[] = {
+static const struct gpio_led ntosd2_leds[] = {
{ .name = "led1_green", .gpio = GPIO(10), },
{ .name = "led1_red",   .gpio = GPIO(11), },
{ .name = "led2_green", .gpio = GPIO(12), },
-- 
2.7.4

[PATCH 07/11 v2] ARM: ixp4xx: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +-
 arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +-
 arch/arm/mach-ixp4xx/omixp-setup.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c 
b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 0f5c999..77d894d 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -93,7 +93,7 @@ static struct i2c_board_info __initdata 
dsmg600_i2c_board_info [] = {
},
 };
 
-static struct gpio_led dsmg600_led_pins[] = {
+static const struct gpio_led dsmg600_led_pins[] = {
{
.name   = "dsmg600:green:power",
.gpio   = DSMG600_LED_PWR_GPIO,
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c 
b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 76dfff0..8d6bab9 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -72,7 +72,7 @@ static struct i2c_board_info __initdata 
nas100d_i2c_board_info [] = {
},
 };
 
-static struct gpio_led nas100d_led_pins[] = {
+static const struct gpio_led nas100d_led_pins[] = {
{
.name   = "nas100d:green:wlan",
.gpio   = NAS100D_LED_WLAN_GPIO,
diff --git a/arch/arm/mach-ixp4xx/omixp-setup.c 
b/arch/arm/mach-ixp4xx/omixp-setup.c
index 2d494b4..42c83a6 100644
--- a/arch/arm/mach-ixp4xx/omixp-setup.c
+++ b/arch/arm/mach-ixp4xx/omixp-setup.c
@@ -152,7 +152,7 @@ static struct platform_device omixp_uart = {
.resource   = omixp_uart_resources,
 };
 
-static struct gpio_led mic256_led_pins[] = {
+static const struct gpio_led mic256_led_pins[] = {
{
.name   = "LED-A",
.gpio   = 7,
-- 
2.7.4

[PATCH 08/11 v2] ARM: OMAP1: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-omap1/board-h2.c| 2 +-
 arch/arm/mach-omap1/board-h3.c| 2 +-
 arch/arm/mach-omap1/board-htcherald.c | 2 +-
 arch/arm/mach-omap1/board-osk.c   | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index ab51f85..9aeb8ad 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -274,7 +274,7 @@ static struct platform_device h2_kp_device = {
.resource   = h2_kp_resources,
 };
 
-static struct gpio_led h2_gpio_led_pins[] = {
+static const struct gpio_led h2_gpio_led_pins[] = {
{
.name   = "h2:red",
.default_trigger = "heartbeat",
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index ad339f5..2edcd63 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -326,7 +326,7 @@ static struct spi_board_info h3_spi_board_info[] __initdata 
= {
},
 };
 
-static struct gpio_led h3_gpio_led_pins[] = {
+static const struct gpio_led h3_gpio_led_pins[] = {
{
.name   = "h3:red",
.default_trigger = "heartbeat",
diff --git a/arch/arm/mach-omap1/board-htcherald.c 
b/arch/arm/mach-omap1/board-htcherald.c
index 67d4669..e6a79fd 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -292,7 +292,7 @@ static struct platform_device herald_gpiokeys_device = {
 };
 
 /* LEDs for the Herald.  These connect to the HTCPLD GPIO device. */
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
{"dpad",NULL, HTCPLD_GPIO_LED_DPAD,0, 0, 
LEDS_GPIO_DEFSTATE_OFF},
{"kbd", NULL, HTCPLD_GPIO_LED_KBD, 0, 0, 
LEDS_GPIO_DEFSTATE_OFF},
{"vibrate", NULL, HTCPLD_GPIO_LED_VIBRATE, 0, 0, 
LEDS_GPIO_DEFSTATE_OFF},
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index c66372e..e2277b5 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -167,7 +167,7 @@ static struct platform_device *osk5912_devices[] __initdata 
= {
_cf_device,
 };
 
-static struct gpio_led tps_leds[] = {
+static const struct gpio_led tps_leds[] = {
/* NOTE:  D9 and D2 have hardware blink support.
 * Also, D9 requires non-battery power.
 */
@@ -385,7 +385,7 @@ static struct platform_device osk5912_lcd_device = {
.id = -1,
 };
 
-static struct gpio_led mistral_gpio_led_pins[] = {
+static const struct gpio_led mistral_gpio_led_pins[] = {
{
.name   = "mistral:red",
.default_trigger = "heartbeat",
-- 
2.7.4

[PATCH 07/11 v2] ARM: ixp4xx: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-ixp4xx/dsmg600-setup.c | 2 +-
 arch/arm/mach-ixp4xx/nas100d-setup.c | 2 +-
 arch/arm/mach-ixp4xx/omixp-setup.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/dsmg600-setup.c 
b/arch/arm/mach-ixp4xx/dsmg600-setup.c
index 0f5c999..77d894d 100644
--- a/arch/arm/mach-ixp4xx/dsmg600-setup.c
+++ b/arch/arm/mach-ixp4xx/dsmg600-setup.c
@@ -93,7 +93,7 @@ static struct i2c_board_info __initdata 
dsmg600_i2c_board_info [] = {
},
 };
 
-static struct gpio_led dsmg600_led_pins[] = {
+static const struct gpio_led dsmg600_led_pins[] = {
{
.name   = "dsmg600:green:power",
.gpio   = DSMG600_LED_PWR_GPIO,
diff --git a/arch/arm/mach-ixp4xx/nas100d-setup.c 
b/arch/arm/mach-ixp4xx/nas100d-setup.c
index 76dfff0..8d6bab9 100644
--- a/arch/arm/mach-ixp4xx/nas100d-setup.c
+++ b/arch/arm/mach-ixp4xx/nas100d-setup.c
@@ -72,7 +72,7 @@ static struct i2c_board_info __initdata 
nas100d_i2c_board_info [] = {
},
 };
 
-static struct gpio_led nas100d_led_pins[] = {
+static const struct gpio_led nas100d_led_pins[] = {
{
.name   = "nas100d:green:wlan",
.gpio   = NAS100D_LED_WLAN_GPIO,
diff --git a/arch/arm/mach-ixp4xx/omixp-setup.c 
b/arch/arm/mach-ixp4xx/omixp-setup.c
index 2d494b4..42c83a6 100644
--- a/arch/arm/mach-ixp4xx/omixp-setup.c
+++ b/arch/arm/mach-ixp4xx/omixp-setup.c
@@ -152,7 +152,7 @@ static struct platform_device omixp_uart = {
.resource   = omixp_uart_resources,
 };
 
-static struct gpio_led mic256_led_pins[] = {
+static const struct gpio_led mic256_led_pins[] = {
{
.name   = "LED-A",
.gpio   = 7,
-- 
2.7.4

[PATCH 08/11 v2] ARM: OMAP1: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/arm/mach-omap1/board-h2.c| 2 +-
 arch/arm/mach-omap1/board-h3.c| 2 +-
 arch/arm/mach-omap1/board-htcherald.c | 2 +-
 arch/arm/mach-omap1/board-osk.c   | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
index ab51f85..9aeb8ad 100644
--- a/arch/arm/mach-omap1/board-h2.c
+++ b/arch/arm/mach-omap1/board-h2.c
@@ -274,7 +274,7 @@ static struct platform_device h2_kp_device = {
.resource   = h2_kp_resources,
 };
 
-static struct gpio_led h2_gpio_led_pins[] = {
+static const struct gpio_led h2_gpio_led_pins[] = {
{
.name   = "h2:red",
.default_trigger = "heartbeat",
diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
index ad339f5..2edcd63 100644
--- a/arch/arm/mach-omap1/board-h3.c
+++ b/arch/arm/mach-omap1/board-h3.c
@@ -326,7 +326,7 @@ static struct spi_board_info h3_spi_board_info[] __initdata 
= {
},
 };
 
-static struct gpio_led h3_gpio_led_pins[] = {
+static const struct gpio_led h3_gpio_led_pins[] = {
{
.name   = "h3:red",
.default_trigger = "heartbeat",
diff --git a/arch/arm/mach-omap1/board-htcherald.c 
b/arch/arm/mach-omap1/board-htcherald.c
index 67d4669..e6a79fd 100644
--- a/arch/arm/mach-omap1/board-htcherald.c
+++ b/arch/arm/mach-omap1/board-htcherald.c
@@ -292,7 +292,7 @@ static struct platform_device herald_gpiokeys_device = {
 };
 
 /* LEDs for the Herald.  These connect to the HTCPLD GPIO device. */
-static struct gpio_led gpio_leds[] = {
+static const struct gpio_led gpio_leds[] = {
{"dpad",NULL, HTCPLD_GPIO_LED_DPAD,0, 0, 
LEDS_GPIO_DEFSTATE_OFF},
{"kbd", NULL, HTCPLD_GPIO_LED_KBD, 0, 0, 
LEDS_GPIO_DEFSTATE_OFF},
{"vibrate", NULL, HTCPLD_GPIO_LED_VIBRATE, 0, 0, 
LEDS_GPIO_DEFSTATE_OFF},
diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
index c66372e..e2277b5 100644
--- a/arch/arm/mach-omap1/board-osk.c
+++ b/arch/arm/mach-omap1/board-osk.c
@@ -167,7 +167,7 @@ static struct platform_device *osk5912_devices[] __initdata 
= {
_cf_device,
 };
 
-static struct gpio_led tps_leds[] = {
+static const struct gpio_led tps_leds[] = {
/* NOTE:  D9 and D2 have hardware blink support.
 * Also, D9 requires non-battery power.
 */
@@ -385,7 +385,7 @@ static struct platform_device osk5912_lcd_device = {
.id = -1,
 };
 
-static struct gpio_led mistral_gpio_led_pins[] = {
+static const struct gpio_led mistral_gpio_led_pins[] = {
{
.name   = "mistral:red",
.default_trigger = "heartbeat",
-- 
2.7.4

[PATCH 05/11 v2] sh: mach-rsk: rsk7203: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-rsk/devices-rsk7203.c 
b/arch/sh/boards/mach-rsk/devices-rsk7203.c
index a8089f7..6676c0e 100644
--- a/arch/sh/boards/mach-rsk/devices-rsk7203.c
+++ b/arch/sh/boards/mach-rsk/devices-rsk7203.c
@@ -50,7 +50,7 @@ static struct platform_device smsc911x_device = {
},
 };
 
-static struct gpio_led rsk7203_gpio_leds[] = {
+static const struct gpio_led rsk7203_gpio_leds[] = {
{
.name   = "green",
.gpio   = GPIO_PE10,
-- 
2.7.4

[PATCH 05/11 v2] sh: mach-rsk: rsk7203: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/sh/boards/mach-rsk/devices-rsk7203.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-rsk/devices-rsk7203.c 
b/arch/sh/boards/mach-rsk/devices-rsk7203.c
index a8089f7..6676c0e 100644
--- a/arch/sh/boards/mach-rsk/devices-rsk7203.c
+++ b/arch/sh/boards/mach-rsk/devices-rsk7203.c
@@ -50,7 +50,7 @@ static struct platform_device smsc911x_device = {
},
 };
 
-static struct gpio_led rsk7203_gpio_leds[] = {
+static const struct gpio_led rsk7203_gpio_leds[] = {
{
.name   = "green",
.gpio   = GPIO_PE10,
-- 
2.7.4

[PATCH 04/11 v2] x86: geode: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/x86/platform/geode/alix.c| 2 +-
 arch/x86/platform/geode/geos.c| 2 +-
 arch/x86/platform/geode/net5501.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/platform/geode/alix.c b/arch/x86/platform/geode/alix.c
index 1865c19..f447ed7 100644
--- a/arch/x86/platform/geode/alix.c
+++ b/arch/x86/platform/geode/alix.c
@@ -71,7 +71,7 @@ static struct platform_device alix_buttons_dev = {
}
 };
 
-static struct gpio_led alix_leds[] = {
+static const struct gpio_led alix_leds[] = {
{
.name = "alix:1",
.gpio = 6,
diff --git a/arch/x86/platform/geode/geos.c b/arch/x86/platform/geode/geos.c
index 4fcdb91..146697b 100644
--- a/arch/x86/platform/geode/geos.c
+++ b/arch/x86/platform/geode/geos.c
@@ -54,7 +54,7 @@ static struct platform_device geos_buttons_dev = {
}
 };
 
-static struct gpio_led geos_leds[] = {
+static const struct gpio_led geos_leds[] = {
{
.name = "geos:1",
.gpio = 6,
diff --git a/arch/x86/platform/geode/net5501.c 
b/arch/x86/platform/geode/net5501.c
index a2f6b98..e5e1a64 100644
--- a/arch/x86/platform/geode/net5501.c
+++ b/arch/x86/platform/geode/net5501.c
@@ -57,7 +57,7 @@ static struct platform_device net5501_buttons_dev = {
}
 };
 
-static struct gpio_led net5501_leds[] = {
+static const struct gpio_led net5501_leds[] = {
{
.name = "net5501:1",
.gpio = 6,
-- 
2.7.4

[PATCH 04/11 v2] x86: geode: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/x86/platform/geode/alix.c| 2 +-
 arch/x86/platform/geode/geos.c| 2 +-
 arch/x86/platform/geode/net5501.c | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/platform/geode/alix.c b/arch/x86/platform/geode/alix.c
index 1865c19..f447ed7 100644
--- a/arch/x86/platform/geode/alix.c
+++ b/arch/x86/platform/geode/alix.c
@@ -71,7 +71,7 @@ static struct platform_device alix_buttons_dev = {
}
 };
 
-static struct gpio_led alix_leds[] = {
+static const struct gpio_led alix_leds[] = {
{
.name = "alix:1",
.gpio = 6,
diff --git a/arch/x86/platform/geode/geos.c b/arch/x86/platform/geode/geos.c
index 4fcdb91..146697b 100644
--- a/arch/x86/platform/geode/geos.c
+++ b/arch/x86/platform/geode/geos.c
@@ -54,7 +54,7 @@ static struct platform_device geos_buttons_dev = {
}
 };
 
-static struct gpio_led geos_leds[] = {
+static const struct gpio_led geos_leds[] = {
{
.name = "geos:1",
.gpio = 6,
diff --git a/arch/x86/platform/geode/net5501.c 
b/arch/x86/platform/geode/net5501.c
index a2f6b98..e5e1a64 100644
--- a/arch/x86/platform/geode/net5501.c
+++ b/arch/x86/platform/geode/net5501.c
@@ -57,7 +57,7 @@ static struct platform_device net5501_buttons_dev = {
}
 };
 
-static struct gpio_led net5501_leds[] = {
+static const struct gpio_led net5501_leds[] = {
{
.name = "net5501:1",
.gpio = 6,
-- 
2.7.4

Re: [PATCH v6 3/4] iio : Add cm3218 smbus ara and acpi support

[kbuild test robot]

Hi Marc,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Marc-CAPDEVILLE/i2c-core-acpi-Add-i2c_acpi_set_connection/20171226-083729
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: i386-randconfig-c0-12261310 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/iio/light/cm32181.o: In function `cm32181_irq':
>> drivers/iio/light/cm32181.c:336: undefined reference to 
>> `i2c_smbus_alert_event'
   drivers/iio/light/cm32181.o: In function `cm32181_probe':
>> drivers/iio/light/cm32181.c:405: undefined reference to 
>> `i2c_require_smbus_alert'
   drivers/iio/light/cm32181.o: In function `cm32181_reg_init':
   drivers/iio/light/cm32181.c:95: undefined reference to 
`i2c_smbus_alert_event'

vim +336 drivers/iio/light/cm32181.c

   329  
   330  static irqreturn_t cm32181_irq(int irq, void *d)
   331  {
   332  struct cm32181_chip *cm32181 = d;
   333  
   334  if (cm32181->chip_id == CM3218_ID) {
   335  /* This is cm3218 chip irq, so handle the smbus alert */
 > 336  i2c_smbus_alert_event(cm32181->client);
   337  }
   338  
   339  return IRQ_HANDLED;
   340  }
   341  
   342  static int cm32181_probe(struct i2c_client *client,
   343  const struct i2c_device_id *id)
   344  {
   345  struct cm32181_chip *cm32181;
   346  struct iio_dev *indio_dev;
   347  int ret;
   348  const struct of_device_id *of_id;
   349  const struct acpi_device_id *acpi_id;
   350  
   351  indio_dev = devm_iio_device_alloc(>dev, 
sizeof(*cm32181));
   352  if (!indio_dev) {
   353  dev_err(>dev, "devm_iio_device_alloc failed\n");
   354  return -ENOMEM;
   355  }
   356  
   357  cm32181 = iio_priv(indio_dev);
   358  i2c_set_clientdata(client, indio_dev);
   359  cm32181->client = client;
   360  
   361  mutex_init(>lock);
   362  indio_dev->dev.parent = >dev;
   363  indio_dev->channels = cm32181_channels;
   364  indio_dev->num_channels = ARRAY_SIZE(cm32181_channels);
   365  indio_dev->info = _info;
   366  indio_dev->name = id->name;
   367  indio_dev->modes = INDIO_DIRECT_MODE;
   368  
   369  /* Lookup for chip ID from platform, acpi or of device table */
   370  if (id) {
   371  cm32181->chip_id = id->driver_data;
   372  } else if (ACPI_COMPANION(>dev)) {
   373  acpi_id = 
acpi_match_device(client->dev.driver->acpi_match_table,
   374  >dev);
   375  if (!acpi_id)
   376  return -ENODEV;
   377  
   378  cm32181->chip_id = (kernel_ulong_t)acpi_id->driver_data;
   379  } else if (client->dev.of_node) {
   380  of_id = 
of_match_device(client->dev.driver->of_match_table,
   381  >dev);
   382  if (!of_id)
   383  return -ENODEV;
   384  
   385  cm32181->chip_id = (kernel_ulong_t)of_id->data;
   386  } else {
   387  return -ENODEV;
   388  }
   389  
   390  if (cm32181->chip_id == CM3218_ID) {
   391  if (ACPI_COMPANION(>dev) &&
   392  client->addr == SMBUS_ARA_ADDR) {
   393  /*
   394   * In case this device as been enumerated by 
acpi
   395   * with the reserved smbus ARA address (first 
acpi
   396   * connection), request change of address to 
the second
   397   * connection.
   398   */
   399  ret = i2c_acpi_set_connection(client, 1);
   400  if (ret)
   401  return ret;
   402  }
   403  
   404  /* cm3218 chip require an ara device on his adapter */
 > 405  ret = i2c_require_smbus_alert(client);
   406  if (ret < 0)
   407  return ret;
   408  
   409  /*
   410   * If irq is given, request a threaded irq handler to 
manage
   411   * smbus alert.
   412   */
   413  if (client->irq > 0) {
   414  ret = devm_request_threaded_irq(>dev,
   415

Re: [PATCH v6 3/4] iio : Add cm3218 smbus ara and acpi support

[kbuild test robot]

Hi Marc,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on wsa/i2c/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Marc-CAPDEVILLE/i2c-core-acpi-Add-i2c_acpi_set_connection/20171226-083729
base:   https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git 
i2c/for-next
config: i386-randconfig-c0-12261310 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/iio/light/cm32181.o: In function `cm32181_irq':
>> drivers/iio/light/cm32181.c:336: undefined reference to 
>> `i2c_smbus_alert_event'
   drivers/iio/light/cm32181.o: In function `cm32181_probe':
>> drivers/iio/light/cm32181.c:405: undefined reference to 
>> `i2c_require_smbus_alert'
   drivers/iio/light/cm32181.o: In function `cm32181_reg_init':
   drivers/iio/light/cm32181.c:95: undefined reference to 
`i2c_smbus_alert_event'

vim +336 drivers/iio/light/cm32181.c

   329  
   330  static irqreturn_t cm32181_irq(int irq, void *d)
   331  {
   332  struct cm32181_chip *cm32181 = d;
   333  
   334  if (cm32181->chip_id == CM3218_ID) {
   335  /* This is cm3218 chip irq, so handle the smbus alert */
 > 336  i2c_smbus_alert_event(cm32181->client);
   337  }
   338  
   339  return IRQ_HANDLED;
   340  }
   341  
   342  static int cm32181_probe(struct i2c_client *client,
   343  const struct i2c_device_id *id)
   344  {
   345  struct cm32181_chip *cm32181;
   346  struct iio_dev *indio_dev;
   347  int ret;
   348  const struct of_device_id *of_id;
   349  const struct acpi_device_id *acpi_id;
   350  
   351  indio_dev = devm_iio_device_alloc(>dev, 
sizeof(*cm32181));
   352  if (!indio_dev) {
   353  dev_err(>dev, "devm_iio_device_alloc failed\n");
   354  return -ENOMEM;
   355  }
   356  
   357  cm32181 = iio_priv(indio_dev);
   358  i2c_set_clientdata(client, indio_dev);
   359  cm32181->client = client;
   360  
   361  mutex_init(>lock);
   362  indio_dev->dev.parent = >dev;
   363  indio_dev->channels = cm32181_channels;
   364  indio_dev->num_channels = ARRAY_SIZE(cm32181_channels);
   365  indio_dev->info = _info;
   366  indio_dev->name = id->name;
   367  indio_dev->modes = INDIO_DIRECT_MODE;
   368  
   369  /* Lookup for chip ID from platform, acpi or of device table */
   370  if (id) {
   371  cm32181->chip_id = id->driver_data;
   372  } else if (ACPI_COMPANION(>dev)) {
   373  acpi_id = 
acpi_match_device(client->dev.driver->acpi_match_table,
   374  >dev);
   375  if (!acpi_id)
   376  return -ENODEV;
   377  
   378  cm32181->chip_id = (kernel_ulong_t)acpi_id->driver_data;
   379  } else if (client->dev.of_node) {
   380  of_id = 
of_match_device(client->dev.driver->of_match_table,
   381  >dev);
   382  if (!of_id)
   383  return -ENODEV;
   384  
   385  cm32181->chip_id = (kernel_ulong_t)of_id->data;
   386  } else {
   387  return -ENODEV;
   388  }
   389  
   390  if (cm32181->chip_id == CM3218_ID) {
   391  if (ACPI_COMPANION(>dev) &&
   392  client->addr == SMBUS_ARA_ADDR) {
   393  /*
   394   * In case this device as been enumerated by 
acpi
   395   * with the reserved smbus ARA address (first 
acpi
   396   * connection), request change of address to 
the second
   397   * connection.
   398   */
   399  ret = i2c_acpi_set_connection(client, 1);
   400  if (ret)
   401  return ret;
   402  }
   403  
   404  /* cm3218 chip require an ara device on his adapter */
 > 405  ret = i2c_require_smbus_alert(client);
   406  if (ret < 0)
   407  return ret;
   408  
   409  /*
   410   * If irq is given, request a threaded irq handler to 
manage
   411   * smbus alert.
   412   */
   413  if (client->irq > 0) {
   414  ret = devm_request_threaded_irq(>dev,
   415

[PATCH 02/11 v2] MIPS: AR7: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/mips/ar7/platform.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
index 4674f1e..4694273 100644
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -346,7 +346,7 @@ static struct platform_device ar7_udc = {
 /*
  * LEDs
  /
-static struct gpio_led default_leds[] = {
+static const struct gpio_led default_leds[] = {
{
.name   = "status",
.gpio   = 8,
@@ -354,12 +354,12 @@ static struct gpio_led default_leds[] = {
},
 };
 
-static struct gpio_led titan_leds[] = {
+static const struct gpio_led titan_leds[] = {
{ .name = "status", .gpio = 8, .active_low = 1, },
{ .name = "wifi", .gpio = 13, .active_low = 1, },
 };
 
-static struct gpio_led dsl502t_leds[] = {
+static const struct gpio_led dsl502t_leds[] = {
{
.name   = "status",
.gpio   = 9,
@@ -377,7 +377,7 @@ static struct gpio_led dsl502t_leds[] = {
},
 };
 
-static struct gpio_led dg834g_leds[] = {
+static const struct gpio_led dg834g_leds[] = {
{
.name   = "ppp",
.gpio   = 6,
@@ -406,7 +406,7 @@ static struct gpio_led dg834g_leds[] = {
},
 };
 
-static struct gpio_led fb_sl_leds[] = {
+static const struct gpio_led fb_sl_leds[] = {
{
.name   = "1",
.gpio   = 7,
@@ -433,7 +433,7 @@ static struct gpio_led fb_sl_leds[] = {
},
 };
 
-static struct gpio_led fb_fon_leds[] = {
+static const struct gpio_led fb_fon_leds[] = {
{
.name   = "1",
.gpio   = 8,
@@ -459,7 +459,7 @@ static struct gpio_led fb_fon_leds[] = {
},
 };
 
-static struct gpio_led gt701_leds[] = {
+static const struct gpio_led gt701_leds[] = {
{
.name   = "inet:green",
.gpio   = 13,
-- 
2.7.4

[PATCH 03/11 v2] MIPS: TXX9: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/mips/txx9/rbtx4927/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index f5b367e..31955c1 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -319,7 +319,7 @@ static void __init rbtx4927_mtd_init(void)
 
 static void __init rbtx4927_gpioled_init(void)
 {
-   static struct gpio_led leds[] = {
+   static const struct gpio_led leds[] = {
{ .name = "gpioled:green:0", .gpio = 0, .active_low = 1, },
{ .name = "gpioled:green:1", .gpio = 1, .active_low = 1, },
};
-- 
2.7.4

[PATCH 02/11 v2] MIPS: AR7: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/mips/ar7/platform.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/mips/ar7/platform.c b/arch/mips/ar7/platform.c
index 4674f1e..4694273 100644
--- a/arch/mips/ar7/platform.c
+++ b/arch/mips/ar7/platform.c
@@ -346,7 +346,7 @@ static struct platform_device ar7_udc = {
 /*
  * LEDs
  /
-static struct gpio_led default_leds[] = {
+static const struct gpio_led default_leds[] = {
{
.name   = "status",
.gpio   = 8,
@@ -354,12 +354,12 @@ static struct gpio_led default_leds[] = {
},
 };
 
-static struct gpio_led titan_leds[] = {
+static const struct gpio_led titan_leds[] = {
{ .name = "status", .gpio = 8, .active_low = 1, },
{ .name = "wifi", .gpio = 13, .active_low = 1, },
 };
 
-static struct gpio_led dsl502t_leds[] = {
+static const struct gpio_led dsl502t_leds[] = {
{
.name   = "status",
.gpio   = 9,
@@ -377,7 +377,7 @@ static struct gpio_led dsl502t_leds[] = {
},
 };
 
-static struct gpio_led dg834g_leds[] = {
+static const struct gpio_led dg834g_leds[] = {
{
.name   = "ppp",
.gpio   = 6,
@@ -406,7 +406,7 @@ static struct gpio_led dg834g_leds[] = {
},
 };
 
-static struct gpio_led fb_sl_leds[] = {
+static const struct gpio_led fb_sl_leds[] = {
{
.name   = "1",
.gpio   = 7,
@@ -433,7 +433,7 @@ static struct gpio_led fb_sl_leds[] = {
},
 };
 
-static struct gpio_led fb_fon_leds[] = {
+static const struct gpio_led fb_fon_leds[] = {
{
.name   = "1",
.gpio   = 8,
@@ -459,7 +459,7 @@ static struct gpio_led fb_fon_leds[] = {
},
 };
 
-static struct gpio_led gt701_leds[] = {
+static const struct gpio_led gt701_leds[] = {
{
.name   = "inet:green",
.gpio   = 13,
-- 
2.7.4

[PATCH 03/11 v2] MIPS: TXX9: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/mips/txx9/rbtx4927/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/mips/txx9/rbtx4927/setup.c b/arch/mips/txx9/rbtx4927/setup.c
index f5b367e..31955c1 100644
--- a/arch/mips/txx9/rbtx4927/setup.c
+++ b/arch/mips/txx9/rbtx4927/setup.c
@@ -319,7 +319,7 @@ static void __init rbtx4927_mtd_init(void)
 
 static void __init rbtx4927_gpioled_init(void)
 {
-   static struct gpio_led leds[] = {
+   static const struct gpio_led leds[] = {
{ .name = "gpioled:green:0", .gpio = 0, .active_low = 1, },
{ .name = "gpioled:green:1", .gpio = 1, .active_low = 1, },
};
-- 
2.7.4

[PATCH 01/11 v2] MIPS: Alchemy: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/mips/alchemy/board-gpr.c  | 2 +-
 arch/mips/alchemy/board-mtx1.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
index 328d697..4e79dbd 100644
--- a/arch/mips/alchemy/board-gpr.c
+++ b/arch/mips/alchemy/board-gpr.c
@@ -190,7 +190,7 @@ static struct platform_device gpr_mtd_device = {
 /*
  * LEDs
  */
-static struct gpio_led gpr_gpio_leds[] = {
+static const struct gpio_led gpr_gpio_leds[] = {
{   /* green */
.name   = "gpr:green",
.gpio   = 4,
diff --git a/arch/mips/alchemy/board-mtx1.c b/arch/mips/alchemy/board-mtx1.c
index 85bb756..aab55aa 100644
--- a/arch/mips/alchemy/board-mtx1.c
+++ b/arch/mips/alchemy/board-mtx1.c
@@ -145,7 +145,7 @@ static struct platform_device mtx1_wdt = {
.resource = mtx1_wdt_res,
 };
 
-static struct gpio_led default_leds[] = {
+static const struct gpio_led default_leds[] = {
{
.name   = "mtx1:green",
.gpio = 211,
-- 
2.7.4

[PATCH 01/11 v2] MIPS: Alchemy: constify gpio_led

[Arvind Yadav]

gpio_led are not supposed to change at runtime.
struct gpio_led_platform_data working with const gpio_led
provided by . So mark the non-const structs
as const.

Signed-off-by: Arvind Yadav 
---
changes in v2:
  The GPIO LED driver can be built as a module, it can
  be loaded after the init sections have gone away.
  So removed '__initconst'.

 arch/mips/alchemy/board-gpr.c  | 2 +-
 arch/mips/alchemy/board-mtx1.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/alchemy/board-gpr.c b/arch/mips/alchemy/board-gpr.c
index 328d697..4e79dbd 100644
--- a/arch/mips/alchemy/board-gpr.c
+++ b/arch/mips/alchemy/board-gpr.c
@@ -190,7 +190,7 @@ static struct platform_device gpr_mtd_device = {
 /*
  * LEDs
  */
-static struct gpio_led gpr_gpio_leds[] = {
+static const struct gpio_led gpr_gpio_leds[] = {
{   /* green */
.name   = "gpr:green",
.gpio   = 4,
diff --git a/arch/mips/alchemy/board-mtx1.c b/arch/mips/alchemy/board-mtx1.c
index 85bb756..aab55aa 100644
--- a/arch/mips/alchemy/board-mtx1.c
+++ b/arch/mips/alchemy/board-mtx1.c
@@ -145,7 +145,7 @@ static struct platform_device mtx1_wdt = {
.resource = mtx1_wdt_res,
 };
 
-static struct gpio_led default_leds[] = {
+static const struct gpio_led default_leds[] = {
{
.name   = "mtx1:green",
.gpio = 211,
-- 
2.7.4

[PATCH] dm: add asymmetric stripe target device dirver

[tgvlcw]

From: liuchaowei 

This asymmetric stripe target device driver can achieve better io
performance between those devices which possess different io performance

There are 2 storage device or flash devices: A and B, their sequential
read performance are 220M/s and 315M/s respectively, so their sequential
read speed ratio could be approximately equal to 2:3, if we use stripe
type to combine these two devices, their layout could be showed below:

|A1|A2|B1|B2|B3|


If we select asymmetric stripe type, their layout could be illustrated
follow:

| A1  |   B1   |


The former has 5 stripe devices and each stripe device has also equal
chunk size, e.g.: 256secs. If there is a data block which size is
1280secs, so transfer the data to this stripe device will be split
to 5 ios which io size is 256secs. But if we use the asymmetric
stripe device, it only has two stripe devices and each one has be
setting in optimal chunk size, e.g.: ratio is 2:3, the first one
optimal chunk size is 512secs, the second is 768secs.  And same
1280secs data block just only be split into two ios, this can be
achieved perfect io performance.

Signed-off-by: liuchaowei 
---
 Documentation/device-mapper/asymmetric-striped.txt |  85 
 drivers/md/Kconfig |  11 +
 drivers/md/Makefile|   1 +
 drivers/md/dm-asymmetric-stripe.c  | 526 +
 drivers/md/dm.c|   5 +
 include/linux/device-mapper.h  |  15 +
 6 files changed, 643 insertions(+)
 create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
 create mode 100644 drivers/md/dm-asymmetric-stripe.c

diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
b/Documentation/device-mapper/asymmetric-striped.txt
new file mode 100644
index ..fb588535c49b
--- /dev/null
+++ b/Documentation/device-mapper/asymmetric-striped.txt
@@ -0,0 +1,85 @@
+dm-asymmetric-stripe
+=
+
+Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0)
+device across one or more underlying devices. Data is written in "chunks",
+with consecutive chunks rotating among the underlying devices. This can
+potentially provide improved I/O throughput by utilizing several physical
+devices in parallel. However, in order to gain maximum I/O performance
+between slow and fast device, there is a ratio to set up the chunk size
+among these device.
+
+Parameters:[ ]+
+: Number of underlying devices.
+: Size of each chunk of data. Must be at least as
+large as the system's PAGE_SIZE.
+: The proportion of per io size, it is the times as much
+as 1 chunk size
+: Full pathname to the underlying block-device, or a
+"major:minor" device-number.
+: Starting sector within the device.
+
+One or more underlying devices can be specified. The striped device
+size must be a multiple of the chunk size multiplied by the number of
+underlying devices. However, there is a ratio that can be set, e.g.: 2:3
+means the first one striped device optimal width size is 2 times as
+much as 1 chunk size, the second striped device is 3.
+
+
+Example scripts
+===
+
+[[
+#!/usr/bin/perl -w
+# Create a striped device across any number of underlying devices. The device
+# will be called "stripe_dev" and have a chunk-size of 128k.
+
+my $chunk_size = 128 * 2;
+my $ratio = "2:3";
+my $dev_name = "stripe_dev";
+my $num_devs = @ARGV;
+my @devs = @ARGV;
+
+if ($num_devs < 2) {
+die("Specify at least two devices\n");
+}
+
+
+$stripe_average_size = 1073741824
+$stripe_dev_size = $stripe_average_size * 5;
+
+$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
+for ($i = 0; $i < $num_devs; $i++) {
+$table .= " $devs[$i] 0";
+}
+
+`echo $table | dmsetup create $dev_name`;
+]]
+
+
+Why asymmetric striped
+===
+Considering one case:
+There are 2 storage device or flash devices: A and B, their sequential
+read performance are 220M/s and 315M/s respectively, so their sequential
+read speed could be approximately equal to 2:3, if we use stripe type
+to combine these two devices, their layout could be showed below:
+
+|A1|A2|B1|B2|B3|
+
+
+If we select asymmetric stripe type, their layout could be illustrated
+follow:
+
+| A1  |   B1   |
+
+
+The former has 5 stripe devices and each stripe 

[PATCH] dm: add asymmetric stripe target device dirver

[tgvlcw]

From: liuchaowei 

This asymmetric stripe target device driver can achieve better io
performance between those devices which possess different io performance

There are 2 storage device or flash devices: A and B, their sequential
read performance are 220M/s and 315M/s respectively, so their sequential
read speed ratio could be approximately equal to 2:3, if we use stripe
type to combine these two devices, their layout could be showed below:

|A1|A2|B1|B2|B3|


If we select asymmetric stripe type, their layout could be illustrated
follow:

| A1  |   B1   |


The former has 5 stripe devices and each stripe device has also equal
chunk size, e.g.: 256secs. If there is a data block which size is
1280secs, so transfer the data to this stripe device will be split
to 5 ios which io size is 256secs. But if we use the asymmetric
stripe device, it only has two stripe devices and each one has be
setting in optimal chunk size, e.g.: ratio is 2:3, the first one
optimal chunk size is 512secs, the second is 768secs.  And same
1280secs data block just only be split into two ios, this can be
achieved perfect io performance.

Signed-off-by: liuchaowei 
---
 Documentation/device-mapper/asymmetric-striped.txt |  85 
 drivers/md/Kconfig |  11 +
 drivers/md/Makefile|   1 +
 drivers/md/dm-asymmetric-stripe.c  | 526 +
 drivers/md/dm.c|   5 +
 include/linux/device-mapper.h  |  15 +
 6 files changed, 643 insertions(+)
 create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
 create mode 100644 drivers/md/dm-asymmetric-stripe.c

diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
b/Documentation/device-mapper/asymmetric-striped.txt
new file mode 100644
index ..fb588535c49b
--- /dev/null
+++ b/Documentation/device-mapper/asymmetric-striped.txt
@@ -0,0 +1,85 @@
+dm-asymmetric-stripe
+=
+
+Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0)
+device across one or more underlying devices. Data is written in "chunks",
+with consecutive chunks rotating among the underlying devices. This can
+potentially provide improved I/O throughput by utilizing several physical
+devices in parallel. However, in order to gain maximum I/O performance
+between slow and fast device, there is a ratio to set up the chunk size
+among these device.
+
+Parameters:[ ]+
+: Number of underlying devices.
+: Size of each chunk of data. Must be at least as
+large as the system's PAGE_SIZE.
+: The proportion of per io size, it is the times as much
+as 1 chunk size
+: Full pathname to the underlying block-device, or a
+"major:minor" device-number.
+: Starting sector within the device.
+
+One or more underlying devices can be specified. The striped device
+size must be a multiple of the chunk size multiplied by the number of
+underlying devices. However, there is a ratio that can be set, e.g.: 2:3
+means the first one striped device optimal width size is 2 times as
+much as 1 chunk size, the second striped device is 3.
+
+
+Example scripts
+===
+
+[[
+#!/usr/bin/perl -w
+# Create a striped device across any number of underlying devices. The device
+# will be called "stripe_dev" and have a chunk-size of 128k.
+
+my $chunk_size = 128 * 2;
+my $ratio = "2:3";
+my $dev_name = "stripe_dev";
+my $num_devs = @ARGV;
+my @devs = @ARGV;
+
+if ($num_devs < 2) {
+die("Specify at least two devices\n");
+}
+
+
+$stripe_average_size = 1073741824
+$stripe_dev_size = $stripe_average_size * 5;
+
+$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
+for ($i = 0; $i < $num_devs; $i++) {
+$table .= " $devs[$i] 0";
+}
+
+`echo $table | dmsetup create $dev_name`;
+]]
+
+
+Why asymmetric striped
+===
+Considering one case:
+There are 2 storage device or flash devices: A and B, their sequential
+read performance are 220M/s and 315M/s respectively, so their sequential
+read speed could be approximately equal to 2:3, if we use stripe type
+to combine these two devices, their layout could be showed below:
+
+|A1|A2|B1|B2|B3|
+
+
+If we select asymmetric stripe type, their layout could be illustrated
+follow:
+
+| A1  |   B1   |
+
+
+The former has 5 stripe devices and each stripe device has also equal
+chunk size, 

Re: BUG warnings in 4.14.9

[Willy Tarreau]

Hi Chris,

On Tue, Dec 26, 2017 at 01:49:59AM +, Chris Rankin wrote:
(...)
> [   35.100181] Call Trace:
> [   35.102709]  dump_stack+0x46/0x59
> [   35.106095]  check_preemption_disabled+0xca/0xda
> [   35.110786]  ip6_pol_route+0x46b/0x509 [ipv6]
(...)

One patch touched this area between 4.14.8 and 4.14.9, you may try
to revert it to see if it fixes the issue :

9704f81 ("ipv6: grab rt->rt6i_ref before allocating pcpu rt")

Willy

Re: BUG warnings in 4.14.9

[Willy Tarreau]

Hi Chris,

On Tue, Dec 26, 2017 at 01:49:59AM +, Chris Rankin wrote:
(...)
> [   35.100181] Call Trace:
> [   35.102709]  dump_stack+0x46/0x59
> [   35.106095]  check_preemption_disabled+0xca/0xda
> [   35.110786]  ip6_pol_route+0x46b/0x509 [ipv6]
(...)

One patch touched this area between 4.14.8 and 4.14.9, you may try
to revert it to see if it fixes the issue :

9704f81 ("ipv6: grab rt->rt6i_ref before allocating pcpu rt")

Willy

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

[Huang, Ying]

Minchan Kim  writes:

> On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote:
>> Minchan Kim  writes:
>> 
>> > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote:
>> >> Minchan Kim  writes:
>> >> 
>> >> > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote:
>> >> >> From: Huang Ying 
>> >> >> 
>> >> >> When the swapin is performed, after getting the swap entry information
>> >> >> from the page table, system will swap in the swap entry, without any
>> >> >> lock held to prevent the swap device from being swapoff.  This may
>> >> >> cause the race like below,
>> >> >> 
>> >> >> CPU 1  CPU 2
>> >> >> -  -
>> >> >>do_swap_page
>> >> >>  swapin_readahead
>> >> >>__read_swap_cache_async
>> >> >> swapoff  swapcache_prepare
>> >> >>   p->swap_map = NULL   __swap_duplicate
>> >> >>  p->swap_map[?] /* !!! NULL 
>> >> >> pointer access */
>> >> >> 
>> >> >> Because swapoff is usually done when system shutdown only, the race
>> >> >> may not hit many people in practice.  But it is still a race need to
>> >> >> be fixed.
>> >> >> 
>> >> >> To fix the race, get_swap_device() is added to check whether the
>> >> >> specified swap entry is valid in its swap device.  If so, it will keep
>> >> >> the swap entry valid via preventing the swap device from being
>> >> >> swapoff, until put_swap_device() is called.
>> >> >> 
>> >> >> Because swapoff() is very race code path, to make the normal path runs
>> >> >> as fast as possible, RCU instead of reference count is used to
>> >> >> implement get/put_swap_device().  From get_swap_device() to
>> >> >> put_swap_device(), the RCU read lock is held, so synchronize_rcu() in
>> >> >> swapoff() will wait until put_swap_device() is called.
>> >> >> 
>> >> >> In addition to swap_map, cluster_info, etc. data structure in the
>> >> >> struct swap_info_struct, the swap cache radix tree will be freed after
>> >> >> swapoff, so this patch fixes the race between swap cache looking up
>> >> >> and swapoff too.
>> >> >> 
>> >> >> Cc: Hugh Dickins 
>> >> >> Cc: Paul E. McKenney 
>> >> >> Cc: Minchan Kim 
>> >> >> Cc: Johannes Weiner 
>> >> >> Cc: Tim Chen 
>> >> >> Cc: Shaohua Li 
>> >> >> Cc: Mel Gorman 
>> >> >> Cc: "Jrme Glisse" 
>> >> >> Cc: Michal Hocko 
>> >> >> Cc: Andrea Arcangeli 
>> >> >> Cc: David Rientjes 
>> >> >> Cc: Rik van Riel 
>> >> >> Cc: Jan Kara 
>> >> >> Cc: Dave Jiang 
>> >> >> Cc: Aaron Lu 
>> >> >> Signed-off-by: "Huang, Ying" 
>> >> >> 
>> >> >> Changelog:
>> >> >> 
>> >> >> v4:
>> >> >> 
>> >> >> - Use synchronize_rcu() in enable_swap_info() to reduce overhead of
>> >> >>   normal paths further.
>> >> >
>> >> > Hi Huang,
>> >> 
>> >> Hi, Minchan,
>> >> 
>> >> > This version is much better than old. To me, it's due to not rcu,
>> >> > srcu, refcount thing but it adds swap device dependency(i.e., get/put)
>> >> > into every swap related functions so users who don't interested on swap
>> >> > don't need to care of it. Good.
>> >> >
>> >> > The problem is caused by freeing by swap related-data structure
>> >> > *dynamically* while old swap logic was based on static data
>> >> > structure(i.e., never freed and the verify it's stale).
>> >> > So, I reviewed some places where use PageSwapCache and swp_entry_t
>> >> > which could make access of swap related data structures.
>> >> >
>> >> > A example is __isolate_lru_page
>> >> >
>> >> > It calls page_mapping to get a address_space.
>> >> > What happens if the page is on SwapCache and raced with swapoff?
>> >> > The mapping got could be disappeared by the race. Right?
>> >> 
>> >> Yes.  We should think about that.  Considering the file cache pages, the
>> >> address_space backing the file cache pages may be freed dynamically too.
>> >> So to use page_mapping() return value for the file cache pages, some
>> >> kind of locking is needed to guarantee the address_space isn't freed
>> >> under us.  Page may be locked, or under writeback, or some other locks
>> >
>> > I didn't look at the code in detail but I guess every file page should
>> > be freed before the address space destruction and page_lock/lru_lock makes
>> > the work safe, I guess. So, it wouldn't be a problem.
>> >
>> > However, in case of swapoff, it doesn't remove pages from LRU list
>> > so there is no lock to prevent the race at this moment. :(
>> 
>> Take a look at file cache pages and file 

Re: [PATCH -V4 -mm] mm, swap: Fix race between swapoff and some swap operations

[Huang, Ying]

Minchan Kim  writes:

> On Fri, Dec 22, 2017 at 10:14:43PM +0800, Huang, Ying wrote:
>> Minchan Kim  writes:
>> 
>> > On Thu, Dec 21, 2017 at 03:48:56PM +0800, Huang, Ying wrote:
>> >> Minchan Kim  writes:
>> >> 
>> >> > On Wed, Dec 20, 2017 at 09:26:32AM +0800, Huang, Ying wrote:
>> >> >> From: Huang Ying 
>> >> >> 
>> >> >> When the swapin is performed, after getting the swap entry information
>> >> >> from the page table, system will swap in the swap entry, without any
>> >> >> lock held to prevent the swap device from being swapoff.  This may
>> >> >> cause the race like below,
>> >> >> 
>> >> >> CPU 1  CPU 2
>> >> >> -  -
>> >> >>do_swap_page
>> >> >>  swapin_readahead
>> >> >>__read_swap_cache_async
>> >> >> swapoff  swapcache_prepare
>> >> >>   p->swap_map = NULL   __swap_duplicate
>> >> >>  p->swap_map[?] /* !!! NULL 
>> >> >> pointer access */
>> >> >> 
>> >> >> Because swapoff is usually done when system shutdown only, the race
>> >> >> may not hit many people in practice.  But it is still a race need to
>> >> >> be fixed.
>> >> >> 
>> >> >> To fix the race, get_swap_device() is added to check whether the
>> >> >> specified swap entry is valid in its swap device.  If so, it will keep
>> >> >> the swap entry valid via preventing the swap device from being
>> >> >> swapoff, until put_swap_device() is called.
>> >> >> 
>> >> >> Because swapoff() is very race code path, to make the normal path runs
>> >> >> as fast as possible, RCU instead of reference count is used to
>> >> >> implement get/put_swap_device().  From get_swap_device() to
>> >> >> put_swap_device(), the RCU read lock is held, so synchronize_rcu() in
>> >> >> swapoff() will wait until put_swap_device() is called.
>> >> >> 
>> >> >> In addition to swap_map, cluster_info, etc. data structure in the
>> >> >> struct swap_info_struct, the swap cache radix tree will be freed after
>> >> >> swapoff, so this patch fixes the race between swap cache looking up
>> >> >> and swapoff too.
>> >> >> 
>> >> >> Cc: Hugh Dickins 
>> >> >> Cc: Paul E. McKenney 
>> >> >> Cc: Minchan Kim 
>> >> >> Cc: Johannes Weiner 
>> >> >> Cc: Tim Chen 
>> >> >> Cc: Shaohua Li 
>> >> >> Cc: Mel Gorman 
>> >> >> Cc: "Jrme Glisse" 
>> >> >> Cc: Michal Hocko 
>> >> >> Cc: Andrea Arcangeli 
>> >> >> Cc: David Rientjes 
>> >> >> Cc: Rik van Riel 
>> >> >> Cc: Jan Kara 
>> >> >> Cc: Dave Jiang 
>> >> >> Cc: Aaron Lu 
>> >> >> Signed-off-by: "Huang, Ying" 
>> >> >> 
>> >> >> Changelog:
>> >> >> 
>> >> >> v4:
>> >> >> 
>> >> >> - Use synchronize_rcu() in enable_swap_info() to reduce overhead of
>> >> >>   normal paths further.
>> >> >
>> >> > Hi Huang,
>> >> 
>> >> Hi, Minchan,
>> >> 
>> >> > This version is much better than old. To me, it's due to not rcu,
>> >> > srcu, refcount thing but it adds swap device dependency(i.e., get/put)
>> >> > into every swap related functions so users who don't interested on swap
>> >> > don't need to care of it. Good.
>> >> >
>> >> > The problem is caused by freeing by swap related-data structure
>> >> > *dynamically* while old swap logic was based on static data
>> >> > structure(i.e., never freed and the verify it's stale).
>> >> > So, I reviewed some places where use PageSwapCache and swp_entry_t
>> >> > which could make access of swap related data structures.
>> >> >
>> >> > A example is __isolate_lru_page
>> >> >
>> >> > It calls page_mapping to get a address_space.
>> >> > What happens if the page is on SwapCache and raced with swapoff?
>> >> > The mapping got could be disappeared by the race. Right?
>> >> 
>> >> Yes.  We should think about that.  Considering the file cache pages, the
>> >> address_space backing the file cache pages may be freed dynamically too.
>> >> So to use page_mapping() return value for the file cache pages, some
>> >> kind of locking is needed to guarantee the address_space isn't freed
>> >> under us.  Page may be locked, or under writeback, or some other locks
>> >
>> > I didn't look at the code in detail but I guess every file page should
>> > be freed before the address space destruction and page_lock/lru_lock makes
>> > the work safe, I guess. So, it wouldn't be a problem.
>> >
>> > However, in case of swapoff, it doesn't remove pages from LRU list
>> > so there is no lock to prevent the race at this moment. :(
>> 
>> Take a look at file cache pages and file cache address_space freeing
>> code path.  It appears that similar situation is possible for them too.
>> 
>> The file cache pages will be delete from file cache address_space before
>> address_space (embedded in inode) is freed.  But they will be deleted
>> from LRU list only when its refcount dropped to zero, please take a look
>> at put_page() and release_pages().  While address_space will be freed
>> after 

[lkp-robot] [lib/rbtree,drm/mm] adc8732ba8: WARNING:at_lib/stackdepot.c:#depot_save_stack

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: adc8732ba8dc55ea7dd226a2edc59a8ef57478cf ("lib/rbtree,drm/mm: Add 
rbtree_replace_node_cached()")
git://anongit.freedesktop.org/drm-intel topic/core-for-CI

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 64c8972077 | 
adc8732ba8 |
+---+++
| boot_successes| 50 | 2
  |
| boot_failures | 4  | 58   
  |
| WARNING:possible_circular_locking_dependency_detected | 3  |  
  |
| BUG:kernel_in_stage   | 1  |  
  |
| WARNING:at_lib/stackdepot.c:#depot_save_stack | 0  | 19   
  |
| RIP:depot_save_stack  | 0  | 19   
  |
| BUG:kernel_hang_in_boot_stage | 0  | 42   
  |
+---+++



[  204.261001] WARNING: CPU: 0 PID: 1 at lib/stackdepot.c:119 
depot_save_stack+0x275/0x490
[  204.262751] Modules linked in:
[  204.263130] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.15.0-rc3-5-gadc8732 #2
[  204.263990] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  204.264007] RIP: 0010:depot_save_stack+0x275/0x490
[  204.264007] RSP: :8818b9d0 EFLAGS: 00010082
[  204.264007] RAX: 0022 RBX: d053170d RCX: 810cc732
[  204.264007] RDX:  RSI:  RDI: 810ca57c
[  204.264007] RBP: 8818ba40 R08: 0001 R09: 20f1
[  204.264007] R10: 0001 R11:  R12: 0120
[  204.264007] R13: 0020 R14: 0020 R15: 
[  204.264007] FS:  () GS:8222c000() 
knlGS:
[  204.264007] CS:  0010 DS:  ES:  CR0: 80050033
[  204.264007] CR2:  CR3: 02216000 CR4: 06b0
[  204.264007] Call Trace:
[  204.264007]  ? save_stack+0x74/0x90
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? add_hole+0x148/0x180
[  204.264007]  ? drm_mm_reserve_node+0x1a0/0x230
[  204.264007]  ? evict_something+0x1b4/0x320
[  204.264007]  ? igt_evict_range+0x1dc/0x450
[  204.264007]  ? test_drm_mm_init+0x1fa/0x2a0
[  204.264007]  ? drm_fb_helper_modinit+0x37/0x37
[  204.264007]  ? do_one_initcall+0x57/0x1e0
[  204.264007]  ? drm_mm_reserve_node+0x1a0/0x230
[  204.264007]  ? evict_something+0x1b4/0x320
[  204.264007]  ? igt_evict_range+0x1dc/0x450
[  204.264007]  ? test_drm_mm_init+0x1fa/0x2a0
[  204.264007]  ? drm_fb_helper_modinit+0x37/0x37
[  204.264007]  ? do_one_initcall+0x57/0x1e0
[  204.264007]  ? kernel_init_freeable+0x19f/0x2ca
[  204.264007]  ? rest_init+0x140/0x140
[  204.264007]  ? kernel_init+0xf/0x160
[  204.264007]  ? rest_init+0x140/0x140
[  204.264007]  ? rest_init+0x140/0x140
[  204.264007]  ? ret_from_fork+0x24/0x30
[  204.264007] Code: c7 60 d2 25 82 e8 8c 68 72 00 e9 d8 fe ff ff 80 3d 5f 52 
01 01 00 75 15 48 c7 c7 78 26 f3 81 c6 05 4f 52 01 01 01 e8 cb 2e da ff <0f> 

[lkp-robot] [lib/rbtree,drm/mm] adc8732ba8: WARNING:at_lib/stackdepot.c:#depot_save_stack

[kernel test robot]

FYI, we noticed the following commit (built with gcc-7):

commit: adc8732ba8dc55ea7dd226a2edc59a8ef57478cf ("lib/rbtree,drm/mm: Add 
rbtree_replace_node_cached()")
git://anongit.freedesktop.org/drm-intel topic/core-for-CI

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 64c8972077 | 
adc8732ba8 |
+---+++
| boot_successes| 50 | 2
  |
| boot_failures | 4  | 58   
  |
| WARNING:possible_circular_locking_dependency_detected | 3  |  
  |
| BUG:kernel_in_stage   | 1  |  
  |
| WARNING:at_lib/stackdepot.c:#depot_save_stack | 0  | 19   
  |
| RIP:depot_save_stack  | 0  | 19   
  |
| BUG:kernel_hang_in_boot_stage | 0  | 42   
  |
+---+++



[  204.261001] WARNING: CPU: 0 PID: 1 at lib/stackdepot.c:119 
depot_save_stack+0x275/0x490
[  204.262751] Modules linked in:
[  204.263130] CPU: 0 PID: 1 Comm: swapper Not tainted 
4.15.0-rc3-5-gadc8732 #2
[  204.263990] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[  204.264007] RIP: 0010:depot_save_stack+0x275/0x490
[  204.264007] RSP: :8818b9d0 EFLAGS: 00010082
[  204.264007] RAX: 0022 RBX: d053170d RCX: 810cc732
[  204.264007] RDX:  RSI:  RDI: 810ca57c
[  204.264007] RBP: 8818ba40 R08: 0001 R09: 20f1
[  204.264007] R10: 0001 R11:  R12: 0120
[  204.264007] R13: 0020 R14: 0020 R15: 
[  204.264007] FS:  () GS:8222c000() 
knlGS:
[  204.264007] CS:  0010 DS:  ES:  CR0: 80050033
[  204.264007] CR2:  CR3: 02216000 CR4: 06b0
[  204.264007] Call Trace:
[  204.264007]  ? save_stack+0x74/0x90
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_add_node+0x103/0x160
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? drm_mm_interval_tree_augment_rotate+0x61/0x70
[  204.264007]  ? add_hole+0x148/0x180
[  204.264007]  ? drm_mm_reserve_node+0x1a0/0x230
[  204.264007]  ? evict_something+0x1b4/0x320
[  204.264007]  ? igt_evict_range+0x1dc/0x450
[  204.264007]  ? test_drm_mm_init+0x1fa/0x2a0
[  204.264007]  ? drm_fb_helper_modinit+0x37/0x37
[  204.264007]  ? do_one_initcall+0x57/0x1e0
[  204.264007]  ? drm_mm_reserve_node+0x1a0/0x230
[  204.264007]  ? evict_something+0x1b4/0x320
[  204.264007]  ? igt_evict_range+0x1dc/0x450
[  204.264007]  ? test_drm_mm_init+0x1fa/0x2a0
[  204.264007]  ? drm_fb_helper_modinit+0x37/0x37
[  204.264007]  ? do_one_initcall+0x57/0x1e0
[  204.264007]  ? kernel_init_freeable+0x19f/0x2ca
[  204.264007]  ? rest_init+0x140/0x140
[  204.264007]  ? kernel_init+0xf/0x160
[  204.264007]  ? rest_init+0x140/0x140
[  204.264007]  ? rest_init+0x140/0x140
[  204.264007]  ? ret_from_fork+0x24/0x30
[  204.264007] Code: c7 60 d2 25 82 e8 8c 68 72 00 e9 d8 fe ff ff 80 3d 5f 52 
01 01 00 75 15 48 c7 c7 78 26 f3 81 c6 05 4f 52 01 01 01 e8 cb 2e da ff <0f> 

RE: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

[Lipengcheng]

Hi,

> -Original Message-
> From: Manu Gautam [mailto:mgau...@codeaurora.org]
> Sent: Tuesday, December 26, 2017 1:01 PM
> To: Lipengcheng; ba...@kernel.org
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> linux-...@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value
> 
> Hi,
> 
> 
> On 12/26/2017 8:22 AM, Lipengcheng wrote:
> > The value is 4, it can cache four descriptors. When streaming_interval
> > = 1, it can tolerate 500us. Some busy scenes, it may be more than
> > 500us because cpu scheduling is not timely. There will have some
> > problems. It is better set to eight.
> >
> > Signed-off-by: Pengcheng Li 
> > ---
> >  drivers/usb/gadget/function/uvc.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/function/uvc.h
> > b/drivers/usb/gadget/function/uvc.h
> > index a64e07e..901487e 100644
> > --- a/drivers/usb/gadget/function/uvc.h
> > +++ b/drivers/usb/gadget/function/uvc.h
> > @@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
> >   * Driver specific constants
> >   */
> >
> > -#define UVC_NUM_REQUESTS   4
> > +#define UVC_NUM_REQUESTS   8
> 
> Can we rather make it 16?
> I ran into similar issue on QCOM platform with DWC3 and with 8 requests also 
> data loss was observed. 16 requests (i.e. ~2msec) worked fine.
I think 16 is ok. The value 4 has a bit too small .In hisilicon asic, I set the 
value 32(4ms) and it is ok. The bad impact is the need to expend more memory 
space. So therefore need to match with the respective chip platform to find the 
appropriate value.
> 
> >  #define UVC_MAX_REQUEST_SIZE   64
> >  #define UVC_MAX_EVENTS 4
> >
> > --
> > 2.7.4
> >
> > N r  y   b X  ǧv ^ )޺{.n +{ ^n r   z   h&   G   h (
> >  階 ݢj"   m z ޖ   f   h   ~ mml==
> 
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project

RE: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

[Lipengcheng]

Hi,

> -Original Message-
> From: Manu Gautam [mailto:mgau...@codeaurora.org]
> Sent: Tuesday, December 26, 2017 1:01 PM
> To: Lipengcheng; ba...@kernel.org
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; 
> linux-...@vger.kernel.org
> Subject: Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value
> 
> Hi,
> 
> 
> On 12/26/2017 8:22 AM, Lipengcheng wrote:
> > The value is 4, it can cache four descriptors. When streaming_interval
> > = 1, it can tolerate 500us. Some busy scenes, it may be more than
> > 500us because cpu scheduling is not timely. There will have some
> > problems. It is better set to eight.
> >
> > Signed-off-by: Pengcheng Li 
> > ---
> >  drivers/usb/gadget/function/uvc.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/usb/gadget/function/uvc.h
> > b/drivers/usb/gadget/function/uvc.h
> > index a64e07e..901487e 100644
> > --- a/drivers/usb/gadget/function/uvc.h
> > +++ b/drivers/usb/gadget/function/uvc.h
> > @@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
> >   * Driver specific constants
> >   */
> >
> > -#define UVC_NUM_REQUESTS   4
> > +#define UVC_NUM_REQUESTS   8
> 
> Can we rather make it 16?
> I ran into similar issue on QCOM platform with DWC3 and with 8 requests also 
> data loss was observed. 16 requests (i.e. ~2msec) worked fine.
I think 16 is ok. The value 4 has a bit too small .In hisilicon asic, I set the 
value 32(4ms) and it is ok. The bad impact is the need to expend more memory 
space. So therefore need to match with the respective chip platform to find the 
appropriate value.
> 
> >  #define UVC_MAX_REQUEST_SIZE   64
> >  #define UVC_MAX_EVENTS 4
> >
> > --
> > 2.7.4
> >
> > N r  y   b X  ǧv ^ )޺{.n +{ ^n r   z   h&   G   h (
> >  階 ݢj"   m z ޖ   f   h   ~ mml==
> 
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a 
> Linux Foundation Collaborative Project

Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

[Manu Gautam]

Hi,


On 12/26/2017 8:22 AM, Lipengcheng wrote:
> The value is 4, it can cache four descriptors. When streaming_interval = 1,
> it can tolerate 500us. Some busy scenes, it may be more than 500us because
> cpu scheduling is not timely. There will have some problems. It is better
> set to eight.
>
> Signed-off-by: Pengcheng Li 
> ---
>  drivers/usb/gadget/function/uvc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/uvc.h 
> b/drivers/usb/gadget/function/uvc.h
> index a64e07e..901487e 100644
> --- a/drivers/usb/gadget/function/uvc.h
> +++ b/drivers/usb/gadget/function/uvc.h
> @@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
>   * Driver specific constants
>   */
>
> -#define UVC_NUM_REQUESTS   4
> +#define UVC_NUM_REQUESTS   8

Can we rather make it 16?
I ran into similar issue on QCOM platform with DWC3 and with 8 requests also 
data loss
was observed. 16 requests (i.e. ~2msec) worked fine.

>  #define UVC_MAX_REQUEST_SIZE   64
>  #define UVC_MAX_EVENTS 4
>
> --
> 2.7.4
>
> N�r��y���b�X��ǧv�^�)޺{.n�+{�^n�r���z���h&���G���h�(�階�ݢj"���m�z�ޖ���f���h���~�mml==

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

[Manu Gautam]

Hi,


On 12/26/2017 8:22 AM, Lipengcheng wrote:
> The value is 4, it can cache four descriptors. When streaming_interval = 1,
> it can tolerate 500us. Some busy scenes, it may be more than 500us because
> cpu scheduling is not timely. There will have some problems. It is better
> set to eight.
>
> Signed-off-by: Pengcheng Li 
> ---
>  drivers/usb/gadget/function/uvc.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/uvc.h 
> b/drivers/usb/gadget/function/uvc.h
> index a64e07e..901487e 100644
> --- a/drivers/usb/gadget/function/uvc.h
> +++ b/drivers/usb/gadget/function/uvc.h
> @@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
>   * Driver specific constants
>   */
>
> -#define UVC_NUM_REQUESTS   4
> +#define UVC_NUM_REQUESTS   8

Can we rather make it 16?
I ran into similar issue on QCOM platform with DWC3 and with 8 requests also 
data loss
was observed. 16 requests (i.e. ~2msec) worked fine.

>  #define UVC_MAX_REQUEST_SIZE   64
>  #define UVC_MAX_EVENTS 4
>
> --
> 2.7.4
>
> N�r��y���b�X��ǧv�^�)޺{.n�+{�^n�r���z���h&���G���h�(�階�ݢj"���m�z�ޖ���f���h���~�mml==

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform

[SZ Lin]

Add support for Moxa UC-8410A open platform

The UC-8410A computing platform is designed
for embedded communication-centric industrial applications

The features of UC-8410A are:
* QSPI flash
* SD slot
* 3x LAN
* 8x RS-232/422/485 ports, software-selectable
* Mini PCIe form factor with PCIe/USB signal
* 2x USB host
* TPM
* Watchdog
* RTC
* User LEDs
* Beeper
* Push button

Signed-off-by: Jimmy Chen 
Signed-off-by: Harry YJ Jhou 
Signed-off-by: SZ Lin 

---
Changes from v2:
- Replace underscore with hyphen in node name
- Add unit address after nodes with 'reg' property
- Sort nodes with unit-address in order of the address
- Fix up unit-address in partitions node

 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 
 2 files changed, 242 insertions(+)
 create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..62ce9b27ad30 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
 dtb-$(CONFIG_SOC_LS1021A) += \
+   ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-twr.dtb
 dtb-$(CONFIG_SOC_VF610) += \
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts 
b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
new file mode 100644
index ..d01f64b252b1
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
+ *
+ * Author: Harry YJ Jhou (周亞諄) 
+ * Jimmy Chen (陳永達)
+ * SZ Lin (林上智)
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include "ls1021a.dtsi"
+
+/ {
+   model = "Moxa UC-8410A";
+
+   aliases {
+   enet0_rgmii_phy = _phy0;
+   enet1_rgmii_phy = _phy1;
+   enet2_rgmii_phy = _phy2;
+   };
+
+   sys_mclk: clock-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <24576000>;
+   };
+
+   reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   cel-pwr {
+   label = "UC8410A:CEL-PWR";
+   gpios = < 27 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   cel-reset {
+   label = "UC8410A:CEL-RESET";
+   gpios = < 28 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   str-led {
+   label = "UC8410A:RED:PROG";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   };
+
+   sw-ready {
+   label = "UC8410A:GREEN:SWRDY";
+   gpios = < 18 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+
+   beeper {
+   label = "UC8410A:BEEP";
+   gpios = < 20 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   prog-led0 {
+   label = "UC8410A:GREEN:PROG2";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   prog-led1 {
+   label = "UC8410A:GREEN:PROG1";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   prog-led2 {
+   label = "UC8410A:GREEN:PROG0";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   wifi-signal0 {
+   label = "UC8410A:GREEN:CEL2";
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   wifi-signal1 {
+   label = "UC8410A:GREEN:CEL1";
+   gpios = < 18 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   wifi-signal2 {
+   label = "UC8410A:GREEN:CEL0";
+  

[PATCH v3] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform

[SZ Lin]

Add support for Moxa UC-8410A open platform

The UC-8410A computing platform is designed
for embedded communication-centric industrial applications

The features of UC-8410A are:
* QSPI flash
* SD slot
* 3x LAN
* 8x RS-232/422/485 ports, software-selectable
* Mini PCIe form factor with PCIe/USB signal
* 2x USB host
* TPM
* Watchdog
* RTC
* User LEDs
* Beeper
* Push button

Signed-off-by: Jimmy Chen 
Signed-off-by: Harry YJ Jhou 
Signed-off-by: SZ Lin 

---
Changes from v2:
- Replace underscore with hyphen in node name
- Add unit address after nodes with 'reg' property
- Sort nodes with unit-address in order of the address
- Fix up unit-address in partitions node

 arch/arm/boot/dts/Makefile  |   1 +
 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 
 2 files changed, 242 insertions(+)
 create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d0381e9caf21..62ce9b27ad30 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
imx7s-colibri-eval-v3.dtb \
imx7s-warp.dtb
 dtb-$(CONFIG_SOC_LS1021A) += \
+   ls1021a-moxa-uc-8410a.dtb \
ls1021a-qds.dtb \
ls1021a-twr.dtb
 dtb-$(CONFIG_SOC_VF610) += \
diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts 
b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
new file mode 100644
index ..d01f64b252b1
--- /dev/null
+++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
@@ -0,0 +1,241 @@
+/*
+ * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
+ *
+ * Author: Harry YJ Jhou (周亞諄) 
+ * Jimmy Chen (陳永達)
+ * SZ Lin (林上智)
+ *
+ * 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.
+ */
+
+/dts-v1/;
+
+#include 
+#include 
+#include "ls1021a.dtsi"
+
+/ {
+   model = "Moxa UC-8410A";
+
+   aliases {
+   enet0_rgmii_phy = _phy0;
+   enet1_rgmii_phy = _phy1;
+   enet2_rgmii_phy = _phy2;
+   };
+
+   sys_mclk: clock-mclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <24576000>;
+   };
+
+   reg_3p3v: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "3P3V";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-always-on;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   cel-pwr {
+   label = "UC8410A:CEL-PWR";
+   gpios = < 27 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   cel-reset {
+   label = "UC8410A:CEL-RESET";
+   gpios = < 28 GPIO_ACTIVE_LOW>;
+   default-state = "off";
+   };
+
+   str-led {
+   label = "UC8410A:RED:PROG";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "mmc0";
+   };
+
+   sw-ready {
+   label = "UC8410A:GREEN:SWRDY";
+   gpios = < 18 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+
+   beeper {
+   label = "UC8410A:BEEP";
+   gpios = < 20 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   prog-led0 {
+   label = "UC8410A:GREEN:PROG2";
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   prog-led1 {
+   label = "UC8410A:GREEN:PROG1";
+   gpios = < 15 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   prog-led2 {
+   label = "UC8410A:GREEN:PROG0";
+   gpios = < 16 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   wifi-signal0 {
+   label = "UC8410A:GREEN:CEL2";
+   gpios = < 17 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   wifi-signal1 {
+   label = "UC8410A:GREEN:CEL1";
+   gpios = < 18 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   wifi-signal2 {
+   label = "UC8410A:GREEN:CEL0";
+   gpios = < 19 GPIO_ACTIVE_HIGH>;
+   default-state = "off";
+   };
+
+   

Re: [PATCH v1 6/9] ufs: sysfs: string descriptors

[kbuild test robot]

Hi Stanislav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Nijnikov/ufs-sysfs-read-only-access-to-device-descriptors-attributes-and-flags/20171226-075252
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   WARNING: modpost: missing MODULE_LICENSE() in drivers/hid/hid-holtekff.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-sysfs.o
   see include/linux/module.h for more information
   ERROR: "ufs_sysfs_add_device_management" [drivers/scsi/ufs/ufshcd.ko] 
undefined!
   ERROR: "ufs_sysfs_remove_device_management" [drivers/scsi/ufs/ufshcd.ko] 
undefined!
>> ERROR: "ufshcd_read_string_desc" [drivers/scsi/ufs/ufs-sysfs.ko] undefined!
   ERROR: "ufshcd_query_descriptor_retry" [drivers/scsi/ufs/ufs-sysfs.ko] 
undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v1 6/9] ufs: sysfs: string descriptors

[kbuild test robot]

Hi Stanislav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Nijnikov/ufs-sysfs-read-only-access-to-device-descriptors-attributes-and-flags/20171226-075252
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   WARNING: modpost: missing MODULE_LICENSE() in drivers/hid/hid-holtekff.o
   see include/linux/module.h for more information
   WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-sysfs.o
   see include/linux/module.h for more information
   ERROR: "ufs_sysfs_add_device_management" [drivers/scsi/ufs/ufshcd.ko] 
undefined!
   ERROR: "ufs_sysfs_remove_device_management" [drivers/scsi/ufs/ufshcd.ko] 
undefined!
>> ERROR: "ufshcd_read_string_desc" [drivers/scsi/ufs/ufs-sysfs.ko] undefined!
   ERROR: "ufshcd_query_descriptor_retry" [drivers/scsi/ufs/ufs-sysfs.ko] 
undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.

[Paul Gortmaker]

There is a regression new to 4.15 that happens in a rather common
workflow which results in the frustrating situation where the user has
clearly disabled UNWINDER_ORC in their ".config" file, and yet they
still get the immediate false error saying they need libelf-dev since
"CONFIG_UNWINDER_ORC=y" is still set, and hence they can not build.

The regression requires UNWINDER_ORC=y (now the default in commit
fc72ae40e303) followed by the user subsequently disabling it, which is
common if the user doesn't have libelf-dev and doesn't care about ORC.

This happens because the recently added test in the top level Makefile
assumes that ,config data will be mapped into include/config/auto.conf
either by the end user running "make oldconfig" or the Makefile itself
detecting that "silentoldconfig" should be run.  As the simple
reproducer below shows, this clearly does not happen as expected.

Note that the test for CONFIG_STACK_VALIDATION and libelf-dev in the
same place in the Makefile is broken in the same way, but since it is a
warning and not an error, nobody cared about the bogus false positives.

Since there is no way I'm going to debug Makefile stuff on Christmas
Day, I figured that I should at least report it intstead.  The work
around is to save your .config and run a "make distclean" or manually
clobber the stale include/config/auto.conf or similar.  But a frustrated
user wouldn't know that w/o the root cause...


- reproducer 

paul@gw:~/git/linux-head$ git describe 
v4.15-rc5
paul@gw:~/git/linux-head$ make distclean 
paul@gw:~/git/linux-head$ make defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
paul@gw:~/git/linux-head$ make
scripts/kconfig/conf  --silentoldconfig Kconfig
Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, 
please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
paul@gw:~/git/linux-head$ vi .config  # disable ORC in favour of FRAME_POINTER
paul@gw:~/git/linux-head$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
paul@gw:~/git/linux-head$ grep UNWINDER .config
# CONFIG_UNWINDER_ORC is not set
CONFIG_UNWINDER_FRAME_POINTER=y
paul@gw:~/git/linux-head$ make
Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, 
please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
paul@gw:~/git/linux-head$ ls -l .config include/config/auto.conf
-rw-rw-r-- 1 paul paul 115953 Dec 25 22:48 .config
-rw-rw-r-- 1 paul paul  33069 Dec 25 22:46 include/config/auto.conf
paul@gw:~/git/linux-head$ grep UNWINDER include/config/auto.conf
CONFIG_UNWINDER_ORC=y
paul@gw:~/git/linux-head$ 

- reproducer 

[Regression 4.15] Can't kill CONFIG_UNWINDER_ORC with fire or plague.

[Paul Gortmaker]

There is a regression new to 4.15 that happens in a rather common
workflow which results in the frustrating situation where the user has
clearly disabled UNWINDER_ORC in their ".config" file, and yet they
still get the immediate false error saying they need libelf-dev since
"CONFIG_UNWINDER_ORC=y" is still set, and hence they can not build.

The regression requires UNWINDER_ORC=y (now the default in commit
fc72ae40e303) followed by the user subsequently disabling it, which is
common if the user doesn't have libelf-dev and doesn't care about ORC.

This happens because the recently added test in the top level Makefile
assumes that ,config data will be mapped into include/config/auto.conf
either by the end user running "make oldconfig" or the Makefile itself
detecting that "silentoldconfig" should be run.  As the simple
reproducer below shows, this clearly does not happen as expected.

Note that the test for CONFIG_STACK_VALIDATION and libelf-dev in the
same place in the Makefile is broken in the same way, but since it is a
warning and not an error, nobody cared about the bogus false positives.

Since there is no way I'm going to debug Makefile stuff on Christmas
Day, I figured that I should at least report it intstead.  The work
around is to save your .config and run a "make distclean" or manually
clobber the stale include/config/auto.conf or similar.  But a frustrated
user wouldn't know that w/o the root cause...


- reproducer 

paul@gw:~/git/linux-head$ git describe 
v4.15-rc5
paul@gw:~/git/linux-head$ make distclean 
paul@gw:~/git/linux-head$ make defconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
*** Default configuration is based on 'x86_64_defconfig'
#
# configuration written to .config
#
paul@gw:~/git/linux-head$ make
scripts/kconfig/conf  --silentoldconfig Kconfig
Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, 
please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
paul@gw:~/git/linux-head$ vi .config  # disable ORC in favour of FRAME_POINTER
paul@gw:~/git/linux-head$ make oldconfig
scripts/kconfig/conf  --oldconfig Kconfig
#
# configuration written to .config
#
paul@gw:~/git/linux-head$ grep UNWINDER .config
# CONFIG_UNWINDER_ORC is not set
CONFIG_UNWINDER_FRAME_POINTER=y
paul@gw:~/git/linux-head$ make
Makefile:926: *** "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, 
please install libelf-dev, libelf-devel or elfutils-libelf-devel".  Stop.
paul@gw:~/git/linux-head$ ls -l .config include/config/auto.conf
-rw-rw-r-- 1 paul paul 115953 Dec 25 22:48 .config
-rw-rw-r-- 1 paul paul  33069 Dec 25 22:46 include/config/auto.conf
paul@gw:~/git/linux-head$ grep UNWINDER include/config/auto.conf
CONFIG_UNWINDER_ORC=y
paul@gw:~/git/linux-head$ 

- reproducer 

Re: [PATCH] dm: add asymmetric stripe target device dirver

[Randy Dunlap]

On 12/25/2017 07:52 PM, tgv...@gmail.com wrote:
> From: liuchaowei 
> 
> This asymmetric stripe target device driver can achieve better io
> performance between those devices which possess different io performance
> 
> There are 2 storage device or flash devices: A and B, their sequential
> read permance are 220M/s and 315M/s inspectively, so their sequential

   performancerespectively,

> read speed could be approximately equal to 2:3, if we use stripe type
> to combine these two devices, their layout could be showed below:
> 
> |A1|A2|B1|B2|B3|
> 
> 
> If we seletect asymmetric stripe type, their layout could be illustrated

select

> follow:
> 
> | A1  |   B1   |
> 
> 
> The former has 5 stripe devices and each stripe device has also equal
> chunk size, e.g.: 256secs. If there is a data block which size is
> 1280secs, so transfer the data to this stripe defvice will be split

device

> to 5 ios which io size is 256secs. But if we use the asymmetric
> stripe device, it only has two stripe devices and each one has be
> setting in optimal chunk size, e.g.: ratio is 2:3, the first one
> optimal chunk size is 512secs, the second is 768secs.  And same
> 1280secs data block just only be splited two ios, this can be achieve

   split into two ios,

> perfect io performance.
> 
> Change-Id: Iebaee3480e27022e2b3a7edbfb65425b1166274e
> Signed-off-by: liuchaowei 
> ---
>  Documentation/device-mapper/asymmetric-striped.txt |  85 
>  drivers/md/Kconfig |  11 +
>  drivers/md/Makefile|   1 +
>  drivers/md/dm-asymmetric-stripe.c  | 523 
> +
>  drivers/md/dm.c|   5 +
>  include/linux/device-mapper.h  |  15 +
>  6 files changed, 640 insertions(+)
>  create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
>  create mode 100644 drivers/md/dm-asymmetric-stripe.c
> 
> diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
> b/Documentation/device-mapper/asymmetric-striped.txt
> new file mode 100644
> index ..0412a224a49e
> --- /dev/null
> +++ b/Documentation/device-mapper/asymmetric-striped.txt
> @@ -0,0 +1,85 @@
> +dm-asymmetric-stripe
> +=
> +
> +Device-Mapper's "asm-striped" target is used to create a striped (i.e. 
> RAID-0)
> +device across one or more underlying devices. Data is written in "chunks",
> +with consecutive chunks rotating among the underlying devices. This can
> +potentially provide improved I/O throughput by utilizing several physical
> +devices in parallel. However, in order to gain maximum I/O performance 
> bewteen

  
between

> +slow and fast device, there is a ratio to set up the chunk size among these
> +device.
> +
> +Parameters:[ ]+
> +: Number of underlying devices.
> +: Size of each chunk of data. Must be at least as
> +large as the system's PAGE_SIZE.
> +: The proportion of per io size, it is the times as much
> +as 1 chunk size
> +: Full pathname to the underlying block-device, or a
> +"major:minor" device-number.
> +: Starting sector within the device.
> +
> +One or more underlying devices can be specified. The striped device
> +size must be a multiple of the chunk size multiplied by the number of 
> underlying
> +devices. However, there is a ratio can be setting, e.g.: 2:3 means the first 
> one

 there is a ratio that can be set,

> +striped device optimal width size is 2 time as much as 1 chunk size, the 
> second

  times

> +striped device is 3.
> +
> +
> +Example scripts
> +===
> +
> +[[
> +#!/usr/bin/perl -w
> +# Create a striped device across any number of underlying devices. The device
> +# will be called "stripe_dev" and have a chunk-size of 128k.
> +
> +my $chunk_size = 128 * 2;
> +my $ratio = "2:3";
> +my $dev_name = "stripe_dev";
> +my $num_devs = @ARGV;
> +my @devs = @ARGV;
> +
> +if ($num_devs < 2) {
> +die("Specify at least two devices\n");
> +}
> +
> +
> +$stripe_average_size = 1073741824
> +$stripe_dev_size = $stripe_average_size * 5;
> +
> +$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
> +for ($i = 0; $i < $num_devs; $i++) {
> +$table .= " $devs[$i] 0";
> +}
> +
> +`echo $table | dmsetup create $dev_name`;
> +]]
> +
> +
> +Why asymmetric striped
> +===
> +Considering one case:
> +There are 2 storage device or flash devices: A and B, their 

Re: [PATCH] dm: add asymmetric stripe target device dirver

[Randy Dunlap]

On 12/25/2017 07:52 PM, tgv...@gmail.com wrote:
> From: liuchaowei 
> 
> This asymmetric stripe target device driver can achieve better io
> performance between those devices which possess different io performance
> 
> There are 2 storage device or flash devices: A and B, their sequential
> read permance are 220M/s and 315M/s inspectively, so their sequential

   performancerespectively,

> read speed could be approximately equal to 2:3, if we use stripe type
> to combine these two devices, their layout could be showed below:
> 
> |A1|A2|B1|B2|B3|
> 
> 
> If we seletect asymmetric stripe type, their layout could be illustrated

select

> follow:
> 
> | A1  |   B1   |
> 
> 
> The former has 5 stripe devices and each stripe device has also equal
> chunk size, e.g.: 256secs. If there is a data block which size is
> 1280secs, so transfer the data to this stripe defvice will be split

device

> to 5 ios which io size is 256secs. But if we use the asymmetric
> stripe device, it only has two stripe devices and each one has be
> setting in optimal chunk size, e.g.: ratio is 2:3, the first one
> optimal chunk size is 512secs, the second is 768secs.  And same
> 1280secs data block just only be splited two ios, this can be achieve

   split into two ios,

> perfect io performance.
> 
> Change-Id: Iebaee3480e27022e2b3a7edbfb65425b1166274e
> Signed-off-by: liuchaowei 
> ---
>  Documentation/device-mapper/asymmetric-striped.txt |  85 
>  drivers/md/Kconfig |  11 +
>  drivers/md/Makefile|   1 +
>  drivers/md/dm-asymmetric-stripe.c  | 523 
> +
>  drivers/md/dm.c|   5 +
>  include/linux/device-mapper.h  |  15 +
>  6 files changed, 640 insertions(+)
>  create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
>  create mode 100644 drivers/md/dm-asymmetric-stripe.c
> 
> diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
> b/Documentation/device-mapper/asymmetric-striped.txt
> new file mode 100644
> index ..0412a224a49e
> --- /dev/null
> +++ b/Documentation/device-mapper/asymmetric-striped.txt
> @@ -0,0 +1,85 @@
> +dm-asymmetric-stripe
> +=
> +
> +Device-Mapper's "asm-striped" target is used to create a striped (i.e. 
> RAID-0)
> +device across one or more underlying devices. Data is written in "chunks",
> +with consecutive chunks rotating among the underlying devices. This can
> +potentially provide improved I/O throughput by utilizing several physical
> +devices in parallel. However, in order to gain maximum I/O performance 
> bewteen

  
between

> +slow and fast device, there is a ratio to set up the chunk size among these
> +device.
> +
> +Parameters:[ ]+
> +: Number of underlying devices.
> +: Size of each chunk of data. Must be at least as
> +large as the system's PAGE_SIZE.
> +: The proportion of per io size, it is the times as much
> +as 1 chunk size
> +: Full pathname to the underlying block-device, or a
> +"major:minor" device-number.
> +: Starting sector within the device.
> +
> +One or more underlying devices can be specified. The striped device
> +size must be a multiple of the chunk size multiplied by the number of 
> underlying
> +devices. However, there is a ratio can be setting, e.g.: 2:3 means the first 
> one

 there is a ratio that can be set,

> +striped device optimal width size is 2 time as much as 1 chunk size, the 
> second

  times

> +striped device is 3.
> +
> +
> +Example scripts
> +===
> +
> +[[
> +#!/usr/bin/perl -w
> +# Create a striped device across any number of underlying devices. The device
> +# will be called "stripe_dev" and have a chunk-size of 128k.
> +
> +my $chunk_size = 128 * 2;
> +my $ratio = "2:3";
> +my $dev_name = "stripe_dev";
> +my $num_devs = @ARGV;
> +my @devs = @ARGV;
> +
> +if ($num_devs < 2) {
> +die("Specify at least two devices\n");
> +}
> +
> +
> +$stripe_average_size = 1073741824
> +$stripe_dev_size = $stripe_average_size * 5;
> +
> +$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
> +for ($i = 0; $i < $num_devs; $i++) {
> +$table .= " $devs[$i] 0";
> +}
> +
> +`echo $table | dmsetup create $dev_name`;
> +]]
> +
> +
> +Why asymmetric striped
> +===
> +Considering one case:
> +There are 2 storage device or flash devices: A and B, their sequential
> +read permance are 

[PATCH] MIPS: Loongson64: Drop 32-bit support for Loongson 2E/2F devices

[Jiaxun Yang]

Make loongson64 a pure 64-bit mach.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/loongson64/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/mips/loongson64/Kconfig b/arch/mips/loongson64/Kconfig
index 0d249fc3cfe9..a7d9a9241ac4 100644
--- a/arch/mips/loongson64/Kconfig
+++ b/arch/mips/loongson64/Kconfig
@@ -17,7 +17,6 @@ config LEMOTE_FULOONG2E
select I8259
select ISA
select IRQ_MIPS_CPU
-   select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HIGHMEM
@@ -49,7 +48,6 @@ config LEMOTE_MACH2F
select ISA
select SYS_HAS_CPU_LOONGSON2F
select SYS_HAS_EARLY_PRINTK
-   select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
-- 
2.15.1

[PATCH] MIPS: Loongson64: Drop 32-bit support for Loongson 2E/2F devices

[Jiaxun Yang]

Make loongson64 a pure 64-bit mach.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/loongson64/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/mips/loongson64/Kconfig b/arch/mips/loongson64/Kconfig
index 0d249fc3cfe9..a7d9a9241ac4 100644
--- a/arch/mips/loongson64/Kconfig
+++ b/arch/mips/loongson64/Kconfig
@@ -17,7 +17,6 @@ config LEMOTE_FULOONG2E
select I8259
select ISA
select IRQ_MIPS_CPU
-   select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_LITTLE_ENDIAN
select SYS_SUPPORTS_HIGHMEM
@@ -49,7 +48,6 @@ config LEMOTE_MACH2F
select ISA
select SYS_HAS_CPU_LOONGSON2F
select SYS_HAS_EARLY_PRINTK
-   select SYS_SUPPORTS_32BIT_KERNEL
select SYS_SUPPORTS_64BIT_KERNEL
select SYS_SUPPORTS_HIGHMEM
select SYS_SUPPORTS_LITTLE_ENDIAN
-- 
2.15.1

Re: [PATCH v2] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform

[Shawn Guo]

On Mon, Dec 11, 2017 at 07:51:25PM +0800, SZ Lin wrote:
> Add support for Moxa UC-8410A open platform
> 
> The UC-8410A computing platform is designed
> for embedded communication-centric industrial applications
> 
> The features of UC-8410A are:
> * QSPI flash
> * SD slot
> * 3x LAN
> * 8x RS-232/422/485 ports, software-selectable
> * Mini PCIe form factor with PCIe/USB signal
> * 2x USB host
> * TPM
> * Watchdog
> * RTC
> * User LEDs
> * Beeper
> * Push button
> 
> Signed-off-by: Jimmy Chen 
> Signed-off-by: Harry YJ Jhou 
> Signed-off-by: SZ Lin 
> 
> --
> Changes from v1:
> - Add newline between nodes
> - Add push button node
> - Insert newline between property list and child node
> - Include file of "include/dt-bindings/gpio/gpio.h"
> - Include file of "include/dt-bindings/input/input.h"
> - Use polartiy defines for gpios to make it more readable
> - Put 'status' at the end of property list
> - Change GPIO pin number in cel_pwr and cel_reset
> - Sort the labeled node alphabetically
> - Drop container node of regulator and put fixed regulator directly
>   under root
> ---
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 
> 
>  2 files changed, 242 insertions(+)
>  create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..62ce9b27ad30 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
>   imx7s-colibri-eval-v3.dtb \
>   imx7s-warp.dtb
>  dtb-$(CONFIG_SOC_LS1021A) += \
> + ls1021a-moxa-uc-8410a.dtb \
>   ls1021a-qds.dtb \
>   ls1021a-twr.dtb
>  dtb-$(CONFIG_SOC_VF610) += \
> diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts 
> b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> new file mode 100644
> index ..bc73b5187990
> --- /dev/null
> +++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> @@ -0,0 +1,241 @@
> +/*
> + * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
> + *
> + * Author: Harry YJ Jhou (周亞諄) 
> + * Jimmy Chen (陳永達)
> + * SZ Lin (林上智)
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "ls1021a.dtsi"
> +
> +/ {
> + model = "Moxa UC-8410A";
> +
> + aliases {
> + enet0_rgmii_phy = _phy0;
> + enet1_rgmii_phy = _phy1;
> + enet2_rgmii_phy = _phy2;
> + };
> +
> + sys_mclk: clock-mclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24576000>;
> + };
> +
> + reg_3p3v: regulator-3p3v {
> +   compatible = "regulator-fixed";
> +   regulator-name = "3P3V";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + cel_pwr {

We generally use hyphen rather than underscore in node name.

> + label = "UC8410A:CEL-PWR";
> + gpios = < 27 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + cel_reset {
> + label = "UC8410A:CEL-RESET";
> + gpios = < 28 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + str_led {
> + label = "UC8410A:RED:PROG";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + };
> +
> + sw_ready {
> + label = "UC8410A:GREEN:SWRDY";
> + gpios = < 18 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + beeper {
> + label = "UC8410A:BEEP";
> + gpios = < 20 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led0 {
> + label = "UC8410A:GREEN:PROG2";
> + gpios = < 14 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led1 {
> + label = "UC8410A:GREEN:PROG1";
> + gpios = < 15 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led2 {
> + label = "UC8410A:GREEN:PROG0";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> 

Re: [PATCH v2] ARM: dts: ls1021a: add support for Moxa UC-8410A open platform

[Shawn Guo]

On Mon, Dec 11, 2017 at 07:51:25PM +0800, SZ Lin wrote:
> Add support for Moxa UC-8410A open platform
> 
> The UC-8410A computing platform is designed
> for embedded communication-centric industrial applications
> 
> The features of UC-8410A are:
> * QSPI flash
> * SD slot
> * 3x LAN
> * 8x RS-232/422/485 ports, software-selectable
> * Mini PCIe form factor with PCIe/USB signal
> * 2x USB host
> * TPM
> * Watchdog
> * RTC
> * User LEDs
> * Beeper
> * Push button
> 
> Signed-off-by: Jimmy Chen 
> Signed-off-by: Harry YJ Jhou 
> Signed-off-by: SZ Lin 
> 
> --
> Changes from v1:
> - Add newline between nodes
> - Add push button node
> - Insert newline between property list and child node
> - Include file of "include/dt-bindings/gpio/gpio.h"
> - Include file of "include/dt-bindings/input/input.h"
> - Use polartiy defines for gpios to make it more readable
> - Put 'status' at the end of property list
> - Change GPIO pin number in cel_pwr and cel_reset
> - Sort the labeled node alphabetically
> - Drop container node of regulator and put fixed regulator directly
>   under root
> ---
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts | 241 
> 
>  2 files changed, 242 insertions(+)
>  create mode 100644 arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..62ce9b27ad30 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -520,6 +520,7 @@ dtb-$(CONFIG_SOC_IMX7D) += \
>   imx7s-colibri-eval-v3.dtb \
>   imx7s-warp.dtb
>  dtb-$(CONFIG_SOC_LS1021A) += \
> + ls1021a-moxa-uc-8410a.dtb \
>   ls1021a-qds.dtb \
>   ls1021a-twr.dtb
>  dtb-$(CONFIG_SOC_VF610) += \
> diff --git a/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts 
> b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> new file mode 100644
> index ..bc73b5187990
> --- /dev/null
> +++ b/arch/arm/boot/dts/ls1021a-moxa-uc-8410a.dts
> @@ -0,0 +1,241 @@
> +/*
> + * Copyright (C) 2017 Moxa Inc. - https://www.moxa.com/
> + *
> + * Author: Harry YJ Jhou (周亞諄) 
> + * Jimmy Chen (陳永達)
> + * SZ Lin (林上智)
> + *
> + * 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.
> + */
> +
> +/dts-v1/;
> +
> +#include 
> +#include 
> +#include "ls1021a.dtsi"
> +
> +/ {
> + model = "Moxa UC-8410A";
> +
> + aliases {
> + enet0_rgmii_phy = _phy0;
> + enet1_rgmii_phy = _phy1;
> + enet2_rgmii_phy = _phy2;
> + };
> +
> + sys_mclk: clock-mclk {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <24576000>;
> + };
> +
> + reg_3p3v: regulator-3p3v {
> +   compatible = "regulator-fixed";
> +   regulator-name = "3P3V";
> +   regulator-min-microvolt = <330>;
> +   regulator-max-microvolt = <330>;
> +   regulator-always-on;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + cel_pwr {

We generally use hyphen rather than underscore in node name.

> + label = "UC8410A:CEL-PWR";
> + gpios = < 27 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + cel_reset {
> + label = "UC8410A:CEL-RESET";
> + gpios = < 28 GPIO_ACTIVE_LOW>;
> + default-state = "off";
> + };
> +
> + str_led {
> + label = "UC8410A:RED:PROG";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "mmc0";
> + };
> +
> + sw_ready {
> + label = "UC8410A:GREEN:SWRDY";
> + gpios = < 18 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + beeper {
> + label = "UC8410A:BEEP";
> + gpios = < 20 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led0 {
> + label = "UC8410A:GREEN:PROG2";
> + gpios = < 14 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led1 {
> + label = "UC8410A:GREEN:PROG1";
> + gpios = < 15 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + prog_led2 {
> + label = "UC8410A:GREEN:PROG0";
> + gpios = < 16 GPIO_ACTIVE_HIGH>;
> + default-state = "off";
> + };
> +
> + wifi_signal0 {
> + 

[PATCH] dm: add asymmetric stripe target device dirver

[tgvlcw]

From: liuchaowei 

This asymmetric stripe target device driver can achieve better io
performance between those devices which possess different io performance

There are 2 storage device or flash devices: A and B, their sequential
read permance are 220M/s and 315M/s inspectively, so their sequential
read speed could be approximately equal to 2:3, if we use stripe type
to combine these two devices, their layout could be showed below:

|A1|A2|B1|B2|B3|


If we seletect asymmetric stripe type, their layout could be illustrated
follow:

| A1  |   B1   |


The former has 5 stripe devices and each stripe device has also equal
chunk size, e.g.: 256secs. If there is a data block which size is
1280secs, so transfer the data to this stripe defvice will be split
to 5 ios which io size is 256secs. But if we use the asymmetric
stripe device, it only has two stripe devices and each one has be
setting in optimal chunk size, e.g.: ratio is 2:3, the first one
optimal chunk size is 512secs, the second is 768secs.  And same
1280secs data block just only be splited two ios, this can be achieve
perfect io performance.

Change-Id: Iebaee3480e27022e2b3a7edbfb65425b1166274e
Signed-off-by: liuchaowei 
---
 Documentation/device-mapper/asymmetric-striped.txt |  85 
 drivers/md/Kconfig |  11 +
 drivers/md/Makefile|   1 +
 drivers/md/dm-asymmetric-stripe.c  | 523 +
 drivers/md/dm.c|   5 +
 include/linux/device-mapper.h  |  15 +
 6 files changed, 640 insertions(+)
 create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
 create mode 100644 drivers/md/dm-asymmetric-stripe.c

diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
b/Documentation/device-mapper/asymmetric-striped.txt
new file mode 100644
index ..0412a224a49e
--- /dev/null
+++ b/Documentation/device-mapper/asymmetric-striped.txt
@@ -0,0 +1,85 @@
+dm-asymmetric-stripe
+=
+
+Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0)
+device across one or more underlying devices. Data is written in "chunks",
+with consecutive chunks rotating among the underlying devices. This can
+potentially provide improved I/O throughput by utilizing several physical
+devices in parallel. However, in order to gain maximum I/O performance bewteen
+slow and fast device, there is a ratio to set up the chunk size among these
+device.
+
+Parameters:[ ]+
+: Number of underlying devices.
+: Size of each chunk of data. Must be at least as
+large as the system's PAGE_SIZE.
+: The proportion of per io size, it is the times as much
+as 1 chunk size
+: Full pathname to the underlying block-device, or a
+"major:minor" device-number.
+: Starting sector within the device.
+
+One or more underlying devices can be specified. The striped device
+size must be a multiple of the chunk size multiplied by the number of 
underlying
+devices. However, there is a ratio can be setting, e.g.: 2:3 means the first 
one
+striped device optimal width size is 2 time as much as 1 chunk size, the second
+striped device is 3.
+
+
+Example scripts
+===
+
+[[
+#!/usr/bin/perl -w
+# Create a striped device across any number of underlying devices. The device
+# will be called "stripe_dev" and have a chunk-size of 128k.
+
+my $chunk_size = 128 * 2;
+my $ratio = "2:3";
+my $dev_name = "stripe_dev";
+my $num_devs = @ARGV;
+my @devs = @ARGV;
+
+if ($num_devs < 2) {
+die("Specify at least two devices\n");
+}
+
+
+$stripe_average_size = 1073741824
+$stripe_dev_size = $stripe_average_size * 5;
+
+$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
+for ($i = 0; $i < $num_devs; $i++) {
+$table .= " $devs[$i] 0";
+}
+
+`echo $table | dmsetup create $dev_name`;
+]]
+
+
+Why asymmetric striped
+===
+Considering one case:
+There are 2 storage device or flash devices: A and B, their sequential
+read permance are 220M/s and 315M/s inspectively, so their sequential
+read speed could be approximately equal to 2:3, if we use stripe type
+to combine these two devices, their layout could be showed below:
+
+|A1|A2|B1|B2|B3|
+
+
+If we seletect asymmetric stripe type, their layout could be illustrated
+follow:
+
+| A1  |   B1   |
+
+
+The 

[PATCH] dm: add asymmetric stripe target device dirver

[tgvlcw]

From: liuchaowei 

This asymmetric stripe target device driver can achieve better io
performance between those devices which possess different io performance

There are 2 storage device or flash devices: A and B, their sequential
read permance are 220M/s and 315M/s inspectively, so their sequential
read speed could be approximately equal to 2:3, if we use stripe type
to combine these two devices, their layout could be showed below:

|A1|A2|B1|B2|B3|


If we seletect asymmetric stripe type, their layout could be illustrated
follow:

| A1  |   B1   |


The former has 5 stripe devices and each stripe device has also equal
chunk size, e.g.: 256secs. If there is a data block which size is
1280secs, so transfer the data to this stripe defvice will be split
to 5 ios which io size is 256secs. But if we use the asymmetric
stripe device, it only has two stripe devices and each one has be
setting in optimal chunk size, e.g.: ratio is 2:3, the first one
optimal chunk size is 512secs, the second is 768secs.  And same
1280secs data block just only be splited two ios, this can be achieve
perfect io performance.

Change-Id: Iebaee3480e27022e2b3a7edbfb65425b1166274e
Signed-off-by: liuchaowei 
---
 Documentation/device-mapper/asymmetric-striped.txt |  85 
 drivers/md/Kconfig |  11 +
 drivers/md/Makefile|   1 +
 drivers/md/dm-asymmetric-stripe.c  | 523 +
 drivers/md/dm.c|   5 +
 include/linux/device-mapper.h  |  15 +
 6 files changed, 640 insertions(+)
 create mode 100644 Documentation/device-mapper/asymmetric-striped.txt
 create mode 100644 drivers/md/dm-asymmetric-stripe.c

diff --git a/Documentation/device-mapper/asymmetric-striped.txt 
b/Documentation/device-mapper/asymmetric-striped.txt
new file mode 100644
index ..0412a224a49e
--- /dev/null
+++ b/Documentation/device-mapper/asymmetric-striped.txt
@@ -0,0 +1,85 @@
+dm-asymmetric-stripe
+=
+
+Device-Mapper's "asm-striped" target is used to create a striped (i.e. RAID-0)
+device across one or more underlying devices. Data is written in "chunks",
+with consecutive chunks rotating among the underlying devices. This can
+potentially provide improved I/O throughput by utilizing several physical
+devices in parallel. However, in order to gain maximum I/O performance bewteen
+slow and fast device, there is a ratio to set up the chunk size among these
+device.
+
+Parameters:[ ]+
+: Number of underlying devices.
+: Size of each chunk of data. Must be at least as
+large as the system's PAGE_SIZE.
+: The proportion of per io size, it is the times as much
+as 1 chunk size
+: Full pathname to the underlying block-device, or a
+"major:minor" device-number.
+: Starting sector within the device.
+
+One or more underlying devices can be specified. The striped device
+size must be a multiple of the chunk size multiplied by the number of 
underlying
+devices. However, there is a ratio can be setting, e.g.: 2:3 means the first 
one
+striped device optimal width size is 2 time as much as 1 chunk size, the second
+striped device is 3.
+
+
+Example scripts
+===
+
+[[
+#!/usr/bin/perl -w
+# Create a striped device across any number of underlying devices. The device
+# will be called "stripe_dev" and have a chunk-size of 128k.
+
+my $chunk_size = 128 * 2;
+my $ratio = "2:3";
+my $dev_name = "stripe_dev";
+my $num_devs = @ARGV;
+my @devs = @ARGV;
+
+if ($num_devs < 2) {
+die("Specify at least two devices\n");
+}
+
+
+$stripe_average_size = 1073741824
+$stripe_dev_size = $stripe_average_size * 5;
+
+$table = "0 $stripe_dev_size asm-striped $num_devs $chunk_size $ratio";
+for ($i = 0; $i < $num_devs; $i++) {
+$table .= " $devs[$i] 0";
+}
+
+`echo $table | dmsetup create $dev_name`;
+]]
+
+
+Why asymmetric striped
+===
+Considering one case:
+There are 2 storage device or flash devices: A and B, their sequential
+read permance are 220M/s and 315M/s inspectively, so their sequential
+read speed could be approximately equal to 2:3, if we use stripe type
+to combine these two devices, their layout could be showed below:
+
+|A1|A2|B1|B2|B3|
+
+
+If we seletect asymmetric stripe type, their layout could be illustrated
+follow:
+
+| A1  |   B1   |
+
+
+The former has 5 stripe devices and each 

[PATCH] clk: mediatek: adjust dependency of reset.c to avoid unexpectedly being built

[sean.wang]

From: Sean Wang 

commit 74cb0d6dde8 ("clk: mediatek: fixup test-building of MediaTek clock
drivers") can let the build system looking into the directory where the
clock drivers resides and then allow test-building the drivers.

But the change also gives rise to certain incorrect behavior which is
reset.c being built even not depending on either COMPILE_TEST or
ARCH_MEDIATEK alternative dependency. To get rid of reset.c being built
unexpectedly on the other platforms, it would be a good change that the
file should be built depending on its own specific configuration rather
than just on generic RESET_CONTROLLER one.

Signed-off-by: Sean Wang 
Cc: Jean Delvare 
---
 drivers/clk/mediatek/Kconfig   | 7 +++
 drivers/clk/mediatek/Makefile  | 2 +-
 drivers/clk/mediatek/clk-mtk.h | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 7338f81..52d880a 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -9,6 +9,13 @@ config COMMON_CLK_MEDIATEK
---help---
  MediaTek SoCs' clock support.
 
+config RESET_MEDIATEK
+   bool "MediaTek Reset Driver"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on RESET_CONTROLLER
+   help
+ This enables the reset controller driver used on MediaTek SoCs.
+
 config COMMON_CLK_MT2701
bool "Clock driver for MediaTek MT2701"
depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index c421ffc..2a48006 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o clk-cpumux.o
-obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_RESET_MEDIATEK) += reset.o
 obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
 obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
 obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index bf8006d..0322dec 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -229,7 +229,7 @@ void mtk_clk_register_plls(struct device_node *node,
 struct clk *mtk_clk_register_ref2usb_tx(const char *name,
const char *parent_name, void __iomem *reg);
 
-#ifdef CONFIG_RESET_CONTROLLER
+#ifdef CONFIG_RESET_MEDIATEK
 void mtk_register_reset_controller(struct device_node *np,
unsigned int num_regs, int regofs);
 #else
-- 
2.7.4

[PATCH] clk: mediatek: adjust dependency of reset.c to avoid unexpectedly being built

[sean.wang]

From: Sean Wang 

commit 74cb0d6dde8 ("clk: mediatek: fixup test-building of MediaTek clock
drivers") can let the build system looking into the directory where the
clock drivers resides and then allow test-building the drivers.

But the change also gives rise to certain incorrect behavior which is
reset.c being built even not depending on either COMPILE_TEST or
ARCH_MEDIATEK alternative dependency. To get rid of reset.c being built
unexpectedly on the other platforms, it would be a good change that the
file should be built depending on its own specific configuration rather
than just on generic RESET_CONTROLLER one.

Signed-off-by: Sean Wang 
Cc: Jean Delvare 
---
 drivers/clk/mediatek/Kconfig   | 7 +++
 drivers/clk/mediatek/Makefile  | 2 +-
 drivers/clk/mediatek/clk-mtk.h | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
index 7338f81..52d880a 100644
--- a/drivers/clk/mediatek/Kconfig
+++ b/drivers/clk/mediatek/Kconfig
@@ -9,6 +9,13 @@ config COMMON_CLK_MEDIATEK
---help---
  MediaTek SoCs' clock support.
 
+config RESET_MEDIATEK
+   bool "MediaTek Reset Driver"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   depends on RESET_CONTROLLER
+   help
+ This enables the reset controller driver used on MediaTek SoCs.
+
 config COMMON_CLK_MT2701
bool "Clock driver for MediaTek MT2701"
depends on (ARCH_MEDIATEK && ARM) || COMPILE_TEST
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index c421ffc..2a48006 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,6 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_COMMON_CLK_MEDIATEK) += clk-mtk.o clk-pll.o clk-gate.o 
clk-apmixed.o clk-cpumux.o
-obj-$(CONFIG_RESET_CONTROLLER) += reset.o
+obj-$(CONFIG_RESET_MEDIATEK) += reset.o
 obj-$(CONFIG_COMMON_CLK_MT6797) += clk-mt6797.o
 obj-$(CONFIG_COMMON_CLK_MT6797_IMGSYS) += clk-mt6797-img.o
 obj-$(CONFIG_COMMON_CLK_MT6797_MMSYS) += clk-mt6797-mm.o
diff --git a/drivers/clk/mediatek/clk-mtk.h b/drivers/clk/mediatek/clk-mtk.h
index bf8006d..0322dec 100644
--- a/drivers/clk/mediatek/clk-mtk.h
+++ b/drivers/clk/mediatek/clk-mtk.h
@@ -229,7 +229,7 @@ void mtk_clk_register_plls(struct device_node *node,
 struct clk *mtk_clk_register_ref2usb_tx(const char *name,
const char *parent_name, void __iomem *reg);
 
-#ifdef CONFIG_RESET_CONTROLLER
+#ifdef CONFIG_RESET_MEDIATEK
 void mtk_register_reset_controller(struct device_node *np,
unsigned int num_regs, int regofs);
 #else
-- 
2.7.4

Re: [PATCH] arm: imx: suspend/resume: use outer_disable/resume

[Shawn Guo]

On Sun, Dec 10, 2017 at 08:07:18PM +0800, Peng Fan wrote:
> Use outer_disable/resume for suspend/resume.
> With the two APIs used, code could be simplified and easy to extend
> to introduce l2c_write_sec for i.MX platforms when moving Linux Kernel
> runs in non-secure world.
> 
> Signed-off-by: Peng Fan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Russell King 
> Cc: Dong Aisheng 
> ---
>  arch/arm/mach-imx/pm-imx6.c  |  2 ++
>  arch/arm/mach-imx/suspend-imx6.S | 24 

I'm fine with the patch in general.  But this piece of code is running
on a few i.MX6 platforms, and I'm wondering on which SoCs you have
verified the change work fine.

Shawn

Re: [PATCH] arm: imx: suspend/resume: use outer_disable/resume

[Shawn Guo]

On Sun, Dec 10, 2017 at 08:07:18PM +0800, Peng Fan wrote:
> Use outer_disable/resume for suspend/resume.
> With the two APIs used, code could be simplified and easy to extend
> to introduce l2c_write_sec for i.MX platforms when moving Linux Kernel
> runs in non-secure world.
> 
> Signed-off-by: Peng Fan 
> Cc: Shawn Guo 
> Cc: Sascha Hauer 
> Cc: Fabio Estevam 
> Cc: Russell King 
> Cc: Dong Aisheng 
> ---
>  arch/arm/mach-imx/pm-imx6.c  |  2 ++
>  arch/arm/mach-imx/suspend-imx6.S | 24 

I'm fine with the patch in general.  But this piece of code is running
on a few i.MX6 platforms, and I'm wondering on which SoCs you have
verified the change work fine.

Shawn

[PATCH v6 3/4] MIPS: Loongson64: Load platform device during boot

[Jiaxun Yang]

This patch just add pdev during boot to load the platform driver

Signed-off-by: Jiaxun Yang 
---
 arch/mips/loongson64/lemote-2f/Makefile   |  2 +-
 arch/mips/loongson64/lemote-2f/platform.c | 25 +
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/loongson64/lemote-2f/platform.c

diff --git a/arch/mips/loongson64/lemote-2f/Makefile 
b/arch/mips/loongson64/lemote-2f/Makefile
index 08b8abcbfef5..31c90737b98c 100644
--- a/arch/mips/loongson64/lemote-2f/Makefile
+++ b/arch/mips/loongson64/lemote-2f/Makefile
@@ -2,7 +2,7 @@
 # Makefile for lemote loongson2f family machines
 #
 
-obj-y += clock.o machtype.o irq.o reset.o ec_kb3310b.o
+obj-y += clock.o machtype.o irq.o reset.o ec_kb3310b.o platform.o
 
 #
 # Suspend Support
diff --git a/arch/mips/loongson64/lemote-2f/platform.c 
b/arch/mips/loongson64/lemote-2f/platform.c
new file mode 100644
index ..e0007f6c456a
--- /dev/null
+++ b/arch/mips/loongson64/lemote-2f/platform.c
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* 
+* Copyright (C) 2017 Jiaxun Yang 
+*
+*/
+
+#include 
+#include 
+
+#include 
+
+static struct platform_device yeeloong_pdev = {
+   .name = "yeeloong_laptop",
+   .id = -1,
+};
+
+static int __init lemote2f_platform_init(void)
+{
+   if (mips_machtype != MACH_LEMOTE_YL2F89)
+   return -ENODEV;
+
+   return platform_device_register(_pdev);
+}
+
+arch_initcall(lemote2f_platform_init);
-- 
2.15.1

[PATCH v6 3/4] MIPS: Loongson64: Load platform device during boot

[Jiaxun Yang]

This patch just add pdev during boot to load the platform driver

Signed-off-by: Jiaxun Yang 
---
 arch/mips/loongson64/lemote-2f/Makefile   |  2 +-
 arch/mips/loongson64/lemote-2f/platform.c | 25 +
 2 files changed, 26 insertions(+), 1 deletion(-)
 create mode 100644 arch/mips/loongson64/lemote-2f/platform.c

diff --git a/arch/mips/loongson64/lemote-2f/Makefile 
b/arch/mips/loongson64/lemote-2f/Makefile
index 08b8abcbfef5..31c90737b98c 100644
--- a/arch/mips/loongson64/lemote-2f/Makefile
+++ b/arch/mips/loongson64/lemote-2f/Makefile
@@ -2,7 +2,7 @@
 # Makefile for lemote loongson2f family machines
 #
 
-obj-y += clock.o machtype.o irq.o reset.o ec_kb3310b.o
+obj-y += clock.o machtype.o irq.o reset.o ec_kb3310b.o platform.o
 
 #
 # Suspend Support
diff --git a/arch/mips/loongson64/lemote-2f/platform.c 
b/arch/mips/loongson64/lemote-2f/platform.c
new file mode 100644
index ..e0007f6c456a
--- /dev/null
+++ b/arch/mips/loongson64/lemote-2f/platform.c
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* 
+* Copyright (C) 2017 Jiaxun Yang 
+*
+*/
+
+#include 
+#include 
+
+#include 
+
+static struct platform_device yeeloong_pdev = {
+   .name = "yeeloong_laptop",
+   .id = -1,
+};
+
+static int __init lemote2f_platform_init(void)
+{
+   if (mips_machtype != MACH_LEMOTE_YL2F89)
+   return -ENODEV;
+
+   return platform_device_register(_pdev);
+}
+
+arch_initcall(lemote2f_platform_init);
-- 
2.15.1

[PATCH v6 1/4] MIPS: Loongson64: lemote-2f move ec_kb3310b.h to include dir and clean up

[Jiaxun Yang]

To operate EC from platform driver, this head file need able to be include
from anywhere. This patch just move ec_kb3310b.h to include dir and
clean up ec_kb3310b.h.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/include/asm/mach-loongson64/ec_kb3310b.h | 170 +++
 arch/mips/loongson64/lemote-2f/ec_kb3310b.c|   2 +-
 arch/mips/loongson64/lemote-2f/ec_kb3310b.h| 188 -
 arch/mips/loongson64/lemote-2f/pm.c|   4 +-
 arch/mips/loongson64/lemote-2f/reset.c |   4 +-
 5 files changed, 175 insertions(+), 193 deletions(-)
 create mode 100644 arch/mips/include/asm/mach-loongson64/ec_kb3310b.h
 delete mode 100644 arch/mips/loongson64/lemote-2f/ec_kb3310b.h

diff --git a/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h 
b/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h
new file mode 100644
index ..2e8690532ea5
--- /dev/null
+++ b/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h
@@ -0,0 +1,170 @@
+/*
+ * KB3310B Embedded Controller
+ *
+ *  Copyright (C) 2008 Lemote Inc.
+ *  Author: liujl , 2008-03-14
+ *  Copyright (C) 2009 Lemote Inc.
+ *  Author: Wu Zhangjin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef _EC_KB3310B_H
+#define _EC_KB3310B_H
+
+extern unsigned char ec_read(unsigned short addr);
+extern void ec_write(unsigned short addr, unsigned char val);
+extern int ec_query_seq(unsigned char cmd);
+extern int ec_query_event_num(void);
+extern int ec_get_event_num(void);
+
+typedef int (*sci_handler) (int status);
+extern sci_handler yeeloong_report_lid_status;
+
+#define ON 1
+#define OFF0
+
+#define SCI_IRQ_NUM 0x0A
+
+/*
+ * The following registers are determined by the EC index configuration.
+ * 1, fill the PORT_HIGH as EC register high part.
+ * 2, fill the PORT_LOW as EC register low part.
+ * 3, fill the PORT_DATA as EC register write data or get the data from it.
+ */
+#defineEC_IO_PORT_HIGH 0x0381
+#defineEC_IO_PORT_LOW  0x0382
+#defineEC_IO_PORT_DATA 0x0383
+
+/*
+ * EC delay time is 500us for register and status access
+ */
+#defineEC_REG_DELAY500 /* unit : us */
+#defineEC_CMD_TIMEOUT  0x1000
+
+/*
+ * EC access port for SCI communication
+ */
+#defineEC_CMD_PORT 0x66
+#defineEC_STS_PORT 0x66
+#defineEC_DAT_PORT 0x62
+#defineCMD_INIT_IDLE_MODE  0xdd
+#defineCMD_EXIT_IDLE_MODE  0xdf
+#defineCMD_INIT_RESET_MODE 0xd8
+#defineCMD_REBOOT_SYSTEM   0x8c
+#defineCMD_GET_EVENT_NUM   0x84
+#defineCMD_PROGRAM_PIECE   0xda
+
+/* Temperature & Fan registers */
+#defineREG_TEMPERATURE_VALUE   0xF458
+#defineREG_FAN_AUTO_MAN_SWITCH 0xF459
+#defineBIT_FAN_AUTO0
+#defineBIT_FAN_MANUAL  1
+#defineREG_FAN_CONTROL 0xF4D2
+#defineREG_FAN_STATUS  0xF4DA
+#defineREG_FAN_SPEED_HIGH  0xFE22
+#defineREG_FAN_SPEED_LOW   0xFE23
+#defineREG_FAN_SPEED_LEVEL 0xF4CC
+/* Fan speed divider */
+#defineFAN_SPEED_DIVIDER   48  /* (60*1000*1000/62.5/2)*/
+
+/* Battery registers */
+#defineREG_BAT_DESIGN_CAP_HIGH 0xF77D
+#defineREG_BAT_DESIGN_CAP_LOW  0xF77E
+#defineREG_BAT_FULLCHG_CAP_HIGH0xF780
+#defineREG_BAT_FULLCHG_CAP_LOW 0xF781
+#defineREG_BAT_DESIGN_VOL_HIGH 0xF782
+#defineREG_BAT_DESIGN_VOL_LOW  0xF783
+#defineREG_BAT_CURRENT_HIGH0xF784
+#defineREG_BAT_CURRENT_LOW 0xF785
+#defineREG_BAT_VOLTAGE_HIGH0xF786
+#defineREG_BAT_VOLTAGE_LOW 0xF787
+#defineREG_BAT_TEMPERATURE_HIGH0xF788
+#defineREG_BAT_TEMPERATURE_LOW 0xF789
+#defineREG_BAT_RELATIVE_CAP_HIGH   0xF492
+#defineREG_BAT_RELATIVE_CAP_LOW0xF493
+#defineREG_BAT_VENDOR  0xF4C4
+#defineFLAG_BAT_VENDOR_SANYO   0x01
+#defineFLAG_BAT_VENDOR_SIMPLO  0x02
+#defineREG_BAT_CELL_COUNT  0xF4C6
+#defineFLAG_BAT_CELL_3S1P  0x03
+#defineFLAG_BAT_CELL_3S2P  0x06
+#defineREG_BAT_CHARGE  0xF4A2
+#defineFLAG_BAT_CHARGE_DISCHARGE   0x01
+#defineFLAG_BAT_CHARGE_CHARGE  0x02
+#defineFLAG_BAT_CHARGE_ACPOWER 0x00
+#defineREG_BAT_STATUS  0xF4B0
+#defineBIT_BAT_STATUS_LOW  (1 << 5)
+#defineBIT_BAT_STATUS_DESTROY  (1 << 2)
+#define

[PATCH v6 1/4] MIPS: Loongson64: lemote-2f move ec_kb3310b.h to include dir and clean up

[Jiaxun Yang]

To operate EC from platform driver, this head file need able to be include
from anywhere. This patch just move ec_kb3310b.h to include dir and
clean up ec_kb3310b.h.

Signed-off-by: Jiaxun Yang 
---
 arch/mips/include/asm/mach-loongson64/ec_kb3310b.h | 170 +++
 arch/mips/loongson64/lemote-2f/ec_kb3310b.c|   2 +-
 arch/mips/loongson64/lemote-2f/ec_kb3310b.h| 188 -
 arch/mips/loongson64/lemote-2f/pm.c|   4 +-
 arch/mips/loongson64/lemote-2f/reset.c |   4 +-
 5 files changed, 175 insertions(+), 193 deletions(-)
 create mode 100644 arch/mips/include/asm/mach-loongson64/ec_kb3310b.h
 delete mode 100644 arch/mips/loongson64/lemote-2f/ec_kb3310b.h

diff --git a/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h 
b/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h
new file mode 100644
index ..2e8690532ea5
--- /dev/null
+++ b/arch/mips/include/asm/mach-loongson64/ec_kb3310b.h
@@ -0,0 +1,170 @@
+/*
+ * KB3310B Embedded Controller
+ *
+ *  Copyright (C) 2008 Lemote Inc.
+ *  Author: liujl , 2008-03-14
+ *  Copyright (C) 2009 Lemote Inc.
+ *  Author: Wu Zhangjin 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifndef _EC_KB3310B_H
+#define _EC_KB3310B_H
+
+extern unsigned char ec_read(unsigned short addr);
+extern void ec_write(unsigned short addr, unsigned char val);
+extern int ec_query_seq(unsigned char cmd);
+extern int ec_query_event_num(void);
+extern int ec_get_event_num(void);
+
+typedef int (*sci_handler) (int status);
+extern sci_handler yeeloong_report_lid_status;
+
+#define ON 1
+#define OFF0
+
+#define SCI_IRQ_NUM 0x0A
+
+/*
+ * The following registers are determined by the EC index configuration.
+ * 1, fill the PORT_HIGH as EC register high part.
+ * 2, fill the PORT_LOW as EC register low part.
+ * 3, fill the PORT_DATA as EC register write data or get the data from it.
+ */
+#defineEC_IO_PORT_HIGH 0x0381
+#defineEC_IO_PORT_LOW  0x0382
+#defineEC_IO_PORT_DATA 0x0383
+
+/*
+ * EC delay time is 500us for register and status access
+ */
+#defineEC_REG_DELAY500 /* unit : us */
+#defineEC_CMD_TIMEOUT  0x1000
+
+/*
+ * EC access port for SCI communication
+ */
+#defineEC_CMD_PORT 0x66
+#defineEC_STS_PORT 0x66
+#defineEC_DAT_PORT 0x62
+#defineCMD_INIT_IDLE_MODE  0xdd
+#defineCMD_EXIT_IDLE_MODE  0xdf
+#defineCMD_INIT_RESET_MODE 0xd8
+#defineCMD_REBOOT_SYSTEM   0x8c
+#defineCMD_GET_EVENT_NUM   0x84
+#defineCMD_PROGRAM_PIECE   0xda
+
+/* Temperature & Fan registers */
+#defineREG_TEMPERATURE_VALUE   0xF458
+#defineREG_FAN_AUTO_MAN_SWITCH 0xF459
+#defineBIT_FAN_AUTO0
+#defineBIT_FAN_MANUAL  1
+#defineREG_FAN_CONTROL 0xF4D2
+#defineREG_FAN_STATUS  0xF4DA
+#defineREG_FAN_SPEED_HIGH  0xFE22
+#defineREG_FAN_SPEED_LOW   0xFE23
+#defineREG_FAN_SPEED_LEVEL 0xF4CC
+/* Fan speed divider */
+#defineFAN_SPEED_DIVIDER   48  /* (60*1000*1000/62.5/2)*/
+
+/* Battery registers */
+#defineREG_BAT_DESIGN_CAP_HIGH 0xF77D
+#defineREG_BAT_DESIGN_CAP_LOW  0xF77E
+#defineREG_BAT_FULLCHG_CAP_HIGH0xF780
+#defineREG_BAT_FULLCHG_CAP_LOW 0xF781
+#defineREG_BAT_DESIGN_VOL_HIGH 0xF782
+#defineREG_BAT_DESIGN_VOL_LOW  0xF783
+#defineREG_BAT_CURRENT_HIGH0xF784
+#defineREG_BAT_CURRENT_LOW 0xF785
+#defineREG_BAT_VOLTAGE_HIGH0xF786
+#defineREG_BAT_VOLTAGE_LOW 0xF787
+#defineREG_BAT_TEMPERATURE_HIGH0xF788
+#defineREG_BAT_TEMPERATURE_LOW 0xF789
+#defineREG_BAT_RELATIVE_CAP_HIGH   0xF492
+#defineREG_BAT_RELATIVE_CAP_LOW0xF493
+#defineREG_BAT_VENDOR  0xF4C4
+#defineFLAG_BAT_VENDOR_SANYO   0x01
+#defineFLAG_BAT_VENDOR_SIMPLO  0x02
+#defineREG_BAT_CELL_COUNT  0xF4C6
+#defineFLAG_BAT_CELL_3S1P  0x03
+#defineFLAG_BAT_CELL_3S2P  0x06
+#defineREG_BAT_CHARGE  0xF4A2
+#defineFLAG_BAT_CHARGE_DISCHARGE   0x01
+#defineFLAG_BAT_CHARGE_CHARGE  0x02
+#defineFLAG_BAT_CHARGE_ACPOWER 0x00
+#defineREG_BAT_STATUS  0xF4B0
+#defineBIT_BAT_STATUS_LOW  (1 << 5)
+#defineBIT_BAT_STATUS_DESTROY  (1 << 2)
+#defineBIT_BAT_STATUS_FULL (1 << 1)
+#define

Add YeeLoong support v6

[Jiaxun Yang]

Change since v5:
Use arcs_cmdline instead of loongson_cmdline
Fix GPL copyright issues


Change since v4:
Use SPDX ids copyright header

[PATCH v6 2/4] MIPS: Loongson64: Yeeloong add platform driver

[Jiaxun Yang]

Yeeloong is a laptop with a MIPS Loongson 2F processor, AMD CS5536
chipset, and KB3310B controller.

This yeeloong_laptop module enables access to sensors, battery,
video camera switch, external video connector event, and some
additional buttons.

This driver was orginally from linux-loongson-community. I Just do
some clean up and port to mainline kernel tree.

Signed-off-by: Jiaxun Yang 
---
 drivers/platform/mips/Kconfig   |   19 +
 drivers/platform/mips/Makefile  |3 +
 drivers/platform/mips/yeeloong_laptop.c | 1141 +++
 3 files changed, 1163 insertions(+)
 create mode 100755 drivers/platform/mips/yeeloong_laptop.c

diff --git a/drivers/platform/mips/Kconfig b/drivers/platform/mips/Kconfig
index b3ae30a4c67b..acd27e36710b 100644
--- a/drivers/platform/mips/Kconfig
+++ b/drivers/platform/mips/Kconfig
@@ -23,4 +23,23 @@ config CPU_HWMON
help
  Loongson-3A/3B CPU Hwmon (temperature sensor) driver.
 
+config LEMOTE_YEELOONG2F
+   tristate "Lemote YeeLoong Laptop"
+   depends on LEMOTE_MACH2F
+   select BACKLIGHT_LCD_SUPPORT
+   select LCD_CLASS_DEVICE
+   select BACKLIGHT_CLASS_DEVICE
+   select POWER_SUPPLY
+   select HWMON
+   select INPUT
+   select INPUT_MISC
+   select INPUT_SPARSEKMAP
+   select INPUT_EVDEV
+   default m
+   help
+ YeeLoong netbook is a mini laptop made by Lemote, which is basically
+ compatible to FuLoong2F mini PC, but it has an extra Embedded
+ Controller(kb3310b) for battery, hotkey, backlight, temperature and
+ fan management.
+
 endif # MIPS_PLATFORM_DEVICES
diff --git a/drivers/platform/mips/Makefile b/drivers/platform/mips/Makefile
index 8dfd03924c37..b3172b081a2f 100644
--- a/drivers/platform/mips/Makefile
+++ b/drivers/platform/mips/Makefile
@@ -1 +1,4 @@
 obj-$(CONFIG_CPU_HWMON) += cpu_hwmon.o
+
+obj-$(CONFIG_LEMOTE_YEELOONG2F)+= yeeloong_laptop.o
+CFLAGS_yeeloong_laptop.o = -I$(srctree)/arch/mips/loongson/lemote-2f
diff --git a/drivers/platform/mips/yeeloong_laptop.c 
b/drivers/platform/mips/yeeloong_laptop.c
new file mode 100755
index ..dc2189e1df26
--- /dev/null
+++ b/drivers/platform/mips/yeeloong_laptop.c
@@ -0,0 +1,1141 @@
+/* SPDX-License-Identifier: GPL */
+
+/*
+ * Driver for YeeLoong laptop extras
+ *
+ *  Copyright (C) 2017 Jiaxun Yang 
+ *
+ *  Copyright (C) 2009 Lemote Inc.
+ *  Author: Wu Zhangjin , Liu Junliang 
+ *
+ *  Fixes: Petr Pisar , 2012, 2013, 2014, 2015.
+ *
+ */
+
+#include 
+#include 
+#include/* for backlight subdriver */
+#include 
+#include/* for hwmon subdriver */
+#include 
+#include/* for clamp_val() */
+#include/* for hotkey subdriver */
+#include 
+#include 
+#include 
+#include /* for AC & Battery subdriver */
+#include/* For MODULE_DEVICE_TABLE() */
+
+#include 
+
+#include 
+
+#include  /* for arcs_cmdline */
+#include 
+
+/* common function */
+#define EC_VER_LEN 64
+
+static int ec_version_before(char *version)
+{
+   char *p, ec_ver[EC_VER_LEN];
+
+   p = strstr(arcs_cmdline, "EC_VER=");
+   if (!p)
+   memset(ec_ver, 0, EC_VER_LEN);
+   else {
+   strncpy(ec_ver, p, EC_VER_LEN);
+   p = strstr(ec_ver, " ");
+   if (p)
+   *p = '\0';
+   }
+
+   return (strncasecmp(ec_ver, version, 64) < 0);
+}
+
+/* backlight subdriver */
+#define MAX_BRIGHTNESS 8
+
+static int yeeloong_set_brightness(struct backlight_device *bd)
+{
+   unsigned int level, current_level;
+   static unsigned int old_level;
+
+   level = (bd->props.fb_blank == FB_BLANK_UNBLANK &&
+bd->props.power == FB_BLANK_UNBLANK) ?
+   bd->props.brightness : 0;
+
+   level = clamp_val(level, 0, MAX_BRIGHTNESS);
+
+   /* Avoid to modify the brightness when EC is tuning it */
+   if (old_level != level) {
+   current_level = ec_read(REG_DISPLAY_BRIGHTNESS);
+   if (old_level == current_level)
+   ec_write(REG_DISPLAY_BRIGHTNESS, level);
+   old_level = level;
+   }
+
+   return 0;
+}
+
+static int yeeloong_get_brightness(struct backlight_device *bd)
+{
+   return ec_read(REG_DISPLAY_BRIGHTNESS);
+}
+
+const struct backlight_ops backlight_ops = {
+   .get_brightness = yeeloong_get_brightness,
+   .update_status = yeeloong_set_brightness,
+};
+
+static struct backlight_device *yeeloong_backlight_dev;
+
+static int yeeloong_backlight_init(void)
+{
+   int ret;
+   struct backlight_properties props;
+
+   memset(, 0, sizeof(struct backlight_properties));
+   props.type = BACKLIGHT_RAW;
+   props.max_brightness = MAX_BRIGHTNESS;
+   yeeloong_backlight_dev = backlight_device_register("backlight0", NULL,
+   NULL, 

[PATCH v6 4/4] MAINTAINERS: Add entry for Lemote YeeLoong Extra Driver

[Jiaxun Yang]

Add myself as a maintainer of Lemote YeeLoong Extra driver

Signed-off-by: Jiaxun Yang 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)
 mode change 100644 => 100755 MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
old mode 100644
new mode 100755
index a6e86e20761e..5a7c0d4b233a
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7873,6 +7873,12 @@ W:   http://legousb.sourceforge.net/
 S: Maintained
 F: drivers/usb/misc/legousbtower.c
 
+Lemote YeeLoong EXTRAS DRIVER
+M: Jiaxun Yang 
+L: linux-m...@linux-mips.org
+S: Maintained
+F: drivers/platform/mips/yeeloong_laptop.c
+
 LG2160 MEDIA DRIVER
 M: Michael Krufky 
 L: linux-me...@vger.kernel.org
-- 
2.15.1

Add YeeLoong support v6

[Jiaxun Yang]

Change since v5:
Use arcs_cmdline instead of loongson_cmdline
Fix GPL copyright issues


Change since v4:
Use SPDX ids copyright header

[PATCH v6 2/4] MIPS: Loongson64: Yeeloong add platform driver

[Jiaxun Yang]

Yeeloong is a laptop with a MIPS Loongson 2F processor, AMD CS5536
chipset, and KB3310B controller.

This yeeloong_laptop module enables access to sensors, battery,
video camera switch, external video connector event, and some
additional buttons.

This driver was orginally from linux-loongson-community. I Just do
some clean up and port to mainline kernel tree.

Signed-off-by: Jiaxun Yang 
---
 drivers/platform/mips/Kconfig   |   19 +
 drivers/platform/mips/Makefile  |3 +
 drivers/platform/mips/yeeloong_laptop.c | 1141 +++
 3 files changed, 1163 insertions(+)
 create mode 100755 drivers/platform/mips/yeeloong_laptop.c

diff --git a/drivers/platform/mips/Kconfig b/drivers/platform/mips/Kconfig
index b3ae30a4c67b..acd27e36710b 100644
--- a/drivers/platform/mips/Kconfig
+++ b/drivers/platform/mips/Kconfig
@@ -23,4 +23,23 @@ config CPU_HWMON
help
  Loongson-3A/3B CPU Hwmon (temperature sensor) driver.
 
+config LEMOTE_YEELOONG2F
+   tristate "Lemote YeeLoong Laptop"
+   depends on LEMOTE_MACH2F
+   select BACKLIGHT_LCD_SUPPORT
+   select LCD_CLASS_DEVICE
+   select BACKLIGHT_CLASS_DEVICE
+   select POWER_SUPPLY
+   select HWMON
+   select INPUT
+   select INPUT_MISC
+   select INPUT_SPARSEKMAP
+   select INPUT_EVDEV
+   default m
+   help
+ YeeLoong netbook is a mini laptop made by Lemote, which is basically
+ compatible to FuLoong2F mini PC, but it has an extra Embedded
+ Controller(kb3310b) for battery, hotkey, backlight, temperature and
+ fan management.
+
 endif # MIPS_PLATFORM_DEVICES
diff --git a/drivers/platform/mips/Makefile b/drivers/platform/mips/Makefile
index 8dfd03924c37..b3172b081a2f 100644
--- a/drivers/platform/mips/Makefile
+++ b/drivers/platform/mips/Makefile
@@ -1 +1,4 @@
 obj-$(CONFIG_CPU_HWMON) += cpu_hwmon.o
+
+obj-$(CONFIG_LEMOTE_YEELOONG2F)+= yeeloong_laptop.o
+CFLAGS_yeeloong_laptop.o = -I$(srctree)/arch/mips/loongson/lemote-2f
diff --git a/drivers/platform/mips/yeeloong_laptop.c 
b/drivers/platform/mips/yeeloong_laptop.c
new file mode 100755
index ..dc2189e1df26
--- /dev/null
+++ b/drivers/platform/mips/yeeloong_laptop.c
@@ -0,0 +1,1141 @@
+/* SPDX-License-Identifier: GPL */
+
+/*
+ * Driver for YeeLoong laptop extras
+ *
+ *  Copyright (C) 2017 Jiaxun Yang 
+ *
+ *  Copyright (C) 2009 Lemote Inc.
+ *  Author: Wu Zhangjin , Liu Junliang 
+ *
+ *  Fixes: Petr Pisar , 2012, 2013, 2014, 2015.
+ *
+ */
+
+#include 
+#include 
+#include/* for backlight subdriver */
+#include 
+#include/* for hwmon subdriver */
+#include 
+#include/* for clamp_val() */
+#include/* for hotkey subdriver */
+#include 
+#include 
+#include 
+#include /* for AC & Battery subdriver */
+#include/* For MODULE_DEVICE_TABLE() */
+
+#include 
+
+#include 
+
+#include  /* for arcs_cmdline */
+#include 
+
+/* common function */
+#define EC_VER_LEN 64
+
+static int ec_version_before(char *version)
+{
+   char *p, ec_ver[EC_VER_LEN];
+
+   p = strstr(arcs_cmdline, "EC_VER=");
+   if (!p)
+   memset(ec_ver, 0, EC_VER_LEN);
+   else {
+   strncpy(ec_ver, p, EC_VER_LEN);
+   p = strstr(ec_ver, " ");
+   if (p)
+   *p = '\0';
+   }
+
+   return (strncasecmp(ec_ver, version, 64) < 0);
+}
+
+/* backlight subdriver */
+#define MAX_BRIGHTNESS 8
+
+static int yeeloong_set_brightness(struct backlight_device *bd)
+{
+   unsigned int level, current_level;
+   static unsigned int old_level;
+
+   level = (bd->props.fb_blank == FB_BLANK_UNBLANK &&
+bd->props.power == FB_BLANK_UNBLANK) ?
+   bd->props.brightness : 0;
+
+   level = clamp_val(level, 0, MAX_BRIGHTNESS);
+
+   /* Avoid to modify the brightness when EC is tuning it */
+   if (old_level != level) {
+   current_level = ec_read(REG_DISPLAY_BRIGHTNESS);
+   if (old_level == current_level)
+   ec_write(REG_DISPLAY_BRIGHTNESS, level);
+   old_level = level;
+   }
+
+   return 0;
+}
+
+static int yeeloong_get_brightness(struct backlight_device *bd)
+{
+   return ec_read(REG_DISPLAY_BRIGHTNESS);
+}
+
+const struct backlight_ops backlight_ops = {
+   .get_brightness = yeeloong_get_brightness,
+   .update_status = yeeloong_set_brightness,
+};
+
+static struct backlight_device *yeeloong_backlight_dev;
+
+static int yeeloong_backlight_init(void)
+{
+   int ret;
+   struct backlight_properties props;
+
+   memset(, 0, sizeof(struct backlight_properties));
+   props.type = BACKLIGHT_RAW;
+   props.max_brightness = MAX_BRIGHTNESS;
+   yeeloong_backlight_dev = backlight_device_register("backlight0", NULL,
+   NULL, _ops, );
+
+   if (IS_ERR(yeeloong_backlight_dev)) {
+   ret = PTR_ERR(yeeloong_backlight_dev);
+  

[PATCH v6 4/4] MAINTAINERS: Add entry for Lemote YeeLoong Extra Driver

[Jiaxun Yang]

Add myself as a maintainer of Lemote YeeLoong Extra driver

Signed-off-by: Jiaxun Yang 
---
 MAINTAINERS | 6 ++
 1 file changed, 6 insertions(+)
 mode change 100644 => 100755 MAINTAINERS

diff --git a/MAINTAINERS b/MAINTAINERS
old mode 100644
new mode 100755
index a6e86e20761e..5a7c0d4b233a
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7873,6 +7873,12 @@ W:   http://legousb.sourceforge.net/
 S: Maintained
 F: drivers/usb/misc/legousbtower.c
 
+Lemote YeeLoong EXTRAS DRIVER
+M: Jiaxun Yang 
+L: linux-m...@linux-mips.org
+S: Maintained
+F: drivers/platform/mips/yeeloong_laptop.c
+
 LG2160 MEDIA DRIVER
 M: Michael Krufky 
 L: linux-me...@vger.kernel.org
-- 
2.15.1

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

[Wei Wang]

On 12/25/2017 10:51 PM, Tetsuo Handa wrote:

Wei Wang wrote:

@@ -173,8 +292,15 @@ static unsigned fill_balloon(struct
virtio_balloon *vb, size_t num)
 while ((page = balloon_page_pop())) {
   balloon_page_enqueue(>vb_dev_info, page);
+if (use_sg) {
+if (xb_set_page(vb, page, _min, _max) < 0) {
+__free_page(page);
+continue;
+}
+} else {
+set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+}

Is this the right behaviour?

I don't think so. In the worst case, we can set no bit using
xb_set_page().

If we can't record the page in the xb,
wouldn't we rather send it across as a single page?


I think that we need to be able to fallback to !use_sg path when OOM.

I also have different thoughts:

1) For OOM, we have leak_balloon_sg_oom (oom has nothing to do with
fill_balloon), which does not use xbitmap to record pages, thus no
memory allocation.

2) If the memory is already under pressure, it is pointless to
continue inflating memory to the host. We need to give thanks to the
memory allocation failure reported by xbitmap, which gets us a chance
to release the inflated pages that have been demonstrated to cause the
memory pressure of the guest.


Forgot to add my conclusion: I think the above behavior is correct.


What is the desired behavior when hitting OOM path during inflate/deflate?
Once inflation started, the inflation logic is called again and again
until the balloon inflates to the requested size.


The above is true, but I can't agree with the following. Please see below.


Such situation will
continue wasting CPU resource between inflate-due-to-host's-request versus
deflate-due-to-guest's-OOM. It is pointless but cannot stop doing pointless
thing.


What we are doing here is to free the pages that were just allocated in 
this round of inflating. Next round will be sometime later when the 
balloon work item gets its turn to run. Yes, it will then continue to 
inflate.

Here are the two cases that will happen then:
1) the guest is still under memory pressure, the inflate will fail at 
memory allocation, which results in a msleep(200), and then it exists 
for another time to run.
2) the guest isn't under memory pressure any more (e.g. the task which 
consumes the huge amount of memory is gone), it will continue to inflate 
as normal till the requested size.


I think what we are doing is a quite sensible behavior, except a small 
change I plan to make:


while ((page = balloon_page_pop())) {
-   balloon_page_enqueue(>vb_dev_info, page);
if (use_sg) {
if (xb_set_page(vb, page, _min, _max) < 
0) {

__free_page(page);
continue;
}
} else {
set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
}
+ balloon_page_enqueue(>vb_dev_info, page);



Also, as of Linux 4.15, only up to VIRTIO_BALLOON_ARRAY_PFNS_MAX pages (i.e.
1MB) are invisible from deflate request. That amount would be an acceptable
error. But your patch makes more pages being invisible, for pages allocated
by balloon_page_alloc() without holding balloon_lock are stored into a local
variable "LIST_HEAD(pages)" (which means that balloon_page_dequeue() with
balloon_lock held won't be able to find pages not yet queued by
balloon_page_enqueue()), doesn't it? What if all memory pages were held in
"LIST_HEAD(pages)" and balloon_page_dequeue() was called before
balloon_page_enqueue() is called?



If we think of the balloon driver just as a regular driver or 
application, that will be a pretty nature thing. A regular driver can 
eat a huge amount of memory for its own usages, would this amount of 
memory be treated as an error as they are invisible to the 
balloon_page_enqueue?


Best,
Wei

Re: [PATCH v20 4/7] virtio-balloon: VIRTIO_BALLOON_F_SG

[Wei Wang]

On 12/25/2017 10:51 PM, Tetsuo Handa wrote:

Wei Wang wrote:

@@ -173,8 +292,15 @@ static unsigned fill_balloon(struct
virtio_balloon *vb, size_t num)
 while ((page = balloon_page_pop())) {
   balloon_page_enqueue(>vb_dev_info, page);
+if (use_sg) {
+if (xb_set_page(vb, page, _min, _max) < 0) {
+__free_page(page);
+continue;
+}
+} else {
+set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
+}

Is this the right behaviour?

I don't think so. In the worst case, we can set no bit using
xb_set_page().

If we can't record the page in the xb,
wouldn't we rather send it across as a single page?


I think that we need to be able to fallback to !use_sg path when OOM.

I also have different thoughts:

1) For OOM, we have leak_balloon_sg_oom (oom has nothing to do with
fill_balloon), which does not use xbitmap to record pages, thus no
memory allocation.

2) If the memory is already under pressure, it is pointless to
continue inflating memory to the host. We need to give thanks to the
memory allocation failure reported by xbitmap, which gets us a chance
to release the inflated pages that have been demonstrated to cause the
memory pressure of the guest.


Forgot to add my conclusion: I think the above behavior is correct.


What is the desired behavior when hitting OOM path during inflate/deflate?
Once inflation started, the inflation logic is called again and again
until the balloon inflates to the requested size.


The above is true, but I can't agree with the following. Please see below.


Such situation will
continue wasting CPU resource between inflate-due-to-host's-request versus
deflate-due-to-guest's-OOM. It is pointless but cannot stop doing pointless
thing.


What we are doing here is to free the pages that were just allocated in 
this round of inflating. Next round will be sometime later when the 
balloon work item gets its turn to run. Yes, it will then continue to 
inflate.

Here are the two cases that will happen then:
1) the guest is still under memory pressure, the inflate will fail at 
memory allocation, which results in a msleep(200), and then it exists 
for another time to run.
2) the guest isn't under memory pressure any more (e.g. the task which 
consumes the huge amount of memory is gone), it will continue to inflate 
as normal till the requested size.


I think what we are doing is a quite sensible behavior, except a small 
change I plan to make:


while ((page = balloon_page_pop())) {
-   balloon_page_enqueue(>vb_dev_info, page);
if (use_sg) {
if (xb_set_page(vb, page, _min, _max) < 
0) {

__free_page(page);
continue;
}
} else {
set_page_pfns(vb, vb->pfns + vb->num_pfns, page);
}
+ balloon_page_enqueue(>vb_dev_info, page);



Also, as of Linux 4.15, only up to VIRTIO_BALLOON_ARRAY_PFNS_MAX pages (i.e.
1MB) are invisible from deflate request. That amount would be an acceptable
error. But your patch makes more pages being invisible, for pages allocated
by balloon_page_alloc() without holding balloon_lock are stored into a local
variable "LIST_HEAD(pages)" (which means that balloon_page_dequeue() with
balloon_lock held won't be able to find pages not yet queued by
balloon_page_enqueue()), doesn't it? What if all memory pages were held in
"LIST_HEAD(pages)" and balloon_page_dequeue() was called before
balloon_page_enqueue() is called?



If we think of the balloon driver just as a regular driver or 
application, that will be a pretty nature thing. A regular driver can 
eat a huge amount of memory for its own usages, would this amount of 
memory be treated as an error as they are invisible to the 
balloon_page_enqueue?


Best,
Wei

Re: [PATCH net-next v8 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE

[Florian Fainelli]

On December 24, 2017 5:10:37 PM PST, Kunihiko Hayashi 
 wrote:
>DT bindings for the AVE ethernet controller found on Socionext's
>UniPhier platforms.
>
>Signed-off-by: Kunihiko Hayashi 
>Signed-off-by: Jassi Brar 
>Acked-by: Rob Herring 

Reviewed-by: Florian Fainelli 

-- 
Florian

Re: [PATCH net-next v8 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE

[Florian Fainelli]

On December 24, 2017 5:10:37 PM PST, Kunihiko Hayashi 
 wrote:
>DT bindings for the AVE ethernet controller found on Socionext's
>UniPhier platforms.
>
>Signed-off-by: Kunihiko Hayashi 
>Signed-off-by: Jassi Brar 
>Acked-by: Rob Herring 

Reviewed-by: Florian Fainelli 

-- 
Florian

[PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

[Lipengcheng]

The value is 4, it can cache four descriptors. When streaming_interval = 1,
it can tolerate 500us. Some busy scenes, it may be more than 500us because
cpu scheduling is not timely. There will have some problems. It is better
set to eight.

Signed-off-by: Pengcheng Li 
---
 drivers/usb/gadget/function/uvc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/uvc.h 
b/drivers/usb/gadget/function/uvc.h
index a64e07e..901487e 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
  * Driver specific constants
  */

-#define UVC_NUM_REQUESTS   4
+#define UVC_NUM_REQUESTS   8
 #define UVC_MAX_REQUEST_SIZE   64
 #define UVC_MAX_EVENTS 4

--
2.7.4

[PATCH] usb: gadget: uvc:change the UVC_NUM_REQUESTS value

[Lipengcheng]

The value is 4, it can cache four descriptors. When streaming_interval = 1,
it can tolerate 500us. Some busy scenes, it may be more than 500us because
cpu scheduling is not timely. There will have some problems. It is better
set to eight.

Signed-off-by: Pengcheng Li 
---
 drivers/usb/gadget/function/uvc.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/uvc.h 
b/drivers/usb/gadget/function/uvc.h
index a64e07e..901487e 100644
--- a/drivers/usb/gadget/function/uvc.h
+++ b/drivers/usb/gadget/function/uvc.h
@@ -90,7 +90,7 @@ extern unsigned int uvc_gadget_trace_param;
  * Driver specific constants
  */

-#define UVC_NUM_REQUESTS   4
+#define UVC_NUM_REQUESTS   8
 #define UVC_MAX_REQUEST_SIZE   64
 #define UVC_MAX_EVENTS 4

--
2.7.4

Re: [PATCH v1 1/9] ufs: sysfs: device descriptor

[kbuild test robot]

Hi Stanislav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Nijnikov/ufs-sysfs-read-only-access-to-device-descriptors-attributes-and-flags/20171226-075252
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: x86_64-kexec (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-sysfs.o
   see include/linux/module.h for more information
>> ERROR: "ufs_sysfs_remove_device_management" [drivers/scsi/ufs/ufshcd.ko] 
>> undefined!
>> ERROR: "ufs_sysfs_add_device_management" [drivers/scsi/ufs/ufshcd.ko] 
>> undefined!
>> ERROR: "ufshcd_query_descriptor_retry" [drivers/scsi/ufs/ufs-sysfs.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v1 1/9] ufs: sysfs: device descriptor

[kbuild test robot]

Hi Stanislav,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.15-rc5 next-20171222]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Stanislav-Nijnikov/ufs-sysfs-read-only-access-to-device-descriptors-attributes-and-flags/20171226-075252
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: x86_64-kexec (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   WARNING: modpost: missing MODULE_LICENSE() in drivers/scsi/ufs/ufs-sysfs.o
   see include/linux/module.h for more information
>> ERROR: "ufs_sysfs_remove_device_management" [drivers/scsi/ufs/ufshcd.ko] 
>> undefined!
>> ERROR: "ufs_sysfs_add_device_management" [drivers/scsi/ufs/ufshcd.ko] 
>> undefined!
>> ERROR: "ufshcd_query_descriptor_retry" [drivers/scsi/ufs/ufs-sysfs.ko] 
>> undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[PATCH v2] perf report: Fix a no annotate browser displayed issue

[Jin Yao]

v2:
--
Fix a crash bug when perform 'perf report --stdio'.

The reason is that we init the symbol annotation only in browser mode,
it doesn't allocate/init resources for stdio mode.

So now in hist_iter__branch_callback(), it will return directly if it's
not in browser mode.

initial post

When enabling '-b' option in perf record, for example,

perf record -b ...
perf report

and then browsing the annotate browser from perf report, it would
be failed (annotate browser can't be displayed).

It's because the '.add_entry_cb' op of struct report is overwritten
by hist_iter__branch_callback() in builtin-report.c. But this function
doesn't do something like mapping symbols and sources. So next,
do_annotate() will return directly.

notes = symbol__annotation(act->ms.sym);
if (!notes->src)
return 0;

This patch adds the lost code to hist_iter__branch_callback (
refer to hist_iter__report_callback).

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-report.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index eb9ce63..07827cd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -162,12 +162,28 @@ static int hist_iter__branch_callback(struct 
hist_entry_iter *iter,
struct hist_entry *he = iter->he;
struct report *rep = arg;
struct branch_info *bi;
+   struct perf_sample *sample = iter->sample;
+   struct perf_evsel *evsel = iter->evsel;
+   int err;
+
+   if (!ui__has_annotation())
+   return 0;
+
+   hist__account_cycles(sample->branch_stack, al, sample,
+rep->nonany_branch_mode);
 
bi = he->branch_info;
+   err = addr_map_symbol__inc_samples(>from, sample, evsel->idx);
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(>to, sample, evsel->idx);
+
branch_type_count(>brtype_stat, >flags,
  bi->from.addr, bi->to.addr);
 
-   return 0;
+out:
+   return err;
 }
 
 static int process_sample_event(struct perf_tool *tool,
-- 
2.7.4

[PATCH v2] perf report: Fix a no annotate browser displayed issue

[Jin Yao]

v2:
--
Fix a crash bug when perform 'perf report --stdio'.

The reason is that we init the symbol annotation only in browser mode,
it doesn't allocate/init resources for stdio mode.

So now in hist_iter__branch_callback(), it will return directly if it's
not in browser mode.

initial post

When enabling '-b' option in perf record, for example,

perf record -b ...
perf report

and then browsing the annotate browser from perf report, it would
be failed (annotate browser can't be displayed).

It's because the '.add_entry_cb' op of struct report is overwritten
by hist_iter__branch_callback() in builtin-report.c. But this function
doesn't do something like mapping symbols and sources. So next,
do_annotate() will return directly.

notes = symbol__annotation(act->ms.sym);
if (!notes->src)
return 0;

This patch adds the lost code to hist_iter__branch_callback (
refer to hist_iter__report_callback).

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-report.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index eb9ce63..07827cd 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -162,12 +162,28 @@ static int hist_iter__branch_callback(struct 
hist_entry_iter *iter,
struct hist_entry *he = iter->he;
struct report *rep = arg;
struct branch_info *bi;
+   struct perf_sample *sample = iter->sample;
+   struct perf_evsel *evsel = iter->evsel;
+   int err;
+
+   if (!ui__has_annotation())
+   return 0;
+
+   hist__account_cycles(sample->branch_stack, al, sample,
+rep->nonany_branch_mode);
 
bi = he->branch_info;
+   err = addr_map_symbol__inc_samples(>from, sample, evsel->idx);
+   if (err)
+   goto out;
+
+   err = addr_map_symbol__inc_samples(>to, sample, evsel->idx);
+
branch_type_count(>brtype_stat, >flags,
  bi->from.addr, bi->to.addr);
 
-   return 0;
+out:
+   return err;
 }
 
 static int process_sample_event(struct perf_tool *tool,
-- 
2.7.4

[RFC PATCH v12 2/5] of/irq: Adjust of_pci_irq parsing for multiple interrupts

[Jeffy Chen]

Currently we are considering the first irq as the PCI interrupt pin,
but a PCI device may have multiple interrupts(e.g. PCIe WAKE# pin).

Only parse the PCI interrupt pin when the irq is unnamed or named as
"pci".

Signed-off-by: Jeffy Chen 
---

Changes in v13: None
Changes in v12: None
Changes in v11:
Address Brian's comments.

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v3: None
Changes in v2: None

 drivers/of/of_pci_irq.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 3a05568f65df..d39565d5477b 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -27,9 +27,25 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
 */
dn = pci_device_to_OF_node(pdev);
if (dn) {
-   rc = of_irq_parse_one(dn, 0, out_irq);
-   if (!rc)
-   return rc;
+   struct property *prop;
+   const char *name;
+   int index = 0;
+
+   of_property_for_each_string(dn, "interrupt-names", prop, name) {
+   if (!strcmp(name, "pci"))
+   break;
+   index++;
+   }
+
+   /*
+* Only parse from DT if we have no "interrupt-names",
+* or if we found an interrupt named "pci".
+*/
+   if (index == 0 || name) {
+   rc = of_irq_parse_one(dn, index, out_irq);
+   if (!rc)
+   return rc;
+   }
}
 
/* Ok, we don't, time to have fun. Let's start by building up an
-- 
2.11.0

[RFC PATCH v12 2/5] of/irq: Adjust of_pci_irq parsing for multiple interrupts

[Jeffy Chen]

Currently we are considering the first irq as the PCI interrupt pin,
but a PCI device may have multiple interrupts(e.g. PCIe WAKE# pin).

Only parse the PCI interrupt pin when the irq is unnamed or named as
"pci".

Signed-off-by: Jeffy Chen 
---

Changes in v13: None
Changes in v12: None
Changes in v11:
Address Brian's comments.

Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v3: None
Changes in v2: None

 drivers/of/of_pci_irq.c | 22 +++---
 1 file changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/of/of_pci_irq.c b/drivers/of/of_pci_irq.c
index 3a05568f65df..d39565d5477b 100644
--- a/drivers/of/of_pci_irq.c
+++ b/drivers/of/of_pci_irq.c
@@ -27,9 +27,25 @@ int of_irq_parse_pci(const struct pci_dev *pdev, struct 
of_phandle_args *out_irq
 */
dn = pci_device_to_OF_node(pdev);
if (dn) {
-   rc = of_irq_parse_one(dn, 0, out_irq);
-   if (!rc)
-   return rc;
+   struct property *prop;
+   const char *name;
+   int index = 0;
+
+   of_property_for_each_string(dn, "interrupt-names", prop, name) {
+   if (!strcmp(name, "pci"))
+   break;
+   index++;
+   }
+
+   /*
+* Only parse from DT if we have no "interrupt-names",
+* or if we found an interrupt named "pci".
+*/
+   if (index == 0 || name) {
+   rc = of_irq_parse_one(dn, index, out_irq);
+   if (!rc)
+   return rc;
+   }
}
 
/* Ok, we don't, time to have fun. Let's start by building up an
-- 
2.11.0