[PATCH 4.9 15/29] tools include: Introduce linux/bug.h, from the kernel sources

2018-06-03 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnaldo Carvalho de Melo 

commit 379d61b1c7d42512cded04d372f15a7e725db9e1 upstream.

With just what we will need in the upcoming changesets, the
BUILD_BUG_ON_ZERO() definition.

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-lw8zg7x6ttwcvqhp90mwe...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/include/linux/bug.h |   10 ++
 tools/perf/MANIFEST   |1 +
 2 files changed, 11 insertions(+)

--- /dev/null
+++ b/tools/include/linux/bug.h
@@ -0,0 +1,10 @@
+#ifndef _TOOLS_PERF_LINUX_BUG_H
+#define _TOOLS_PERF_LINUX_BUG_H
+
+/* Force a compilation error if condition is true, but also produce a
+   result (of value 0 and type size_t), so the expression can be used
+   e.g. in a structure initializer (or where-ever else comma expressions
+   aren't permitted). */
+#define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
+
+#endif /* _TOOLS_PERF_LINUX_BUG_H */
--- a/tools/perf/MANIFEST
+++ b/tools/perf/MANIFEST
@@ -63,6 +63,7 @@ tools/include/linux/bitops.h
 tools/include/linux/compiler.h
 tools/include/linux/compiler-gcc.h
 tools/include/linux/coresight-pmu.h
+tools/include/linux/bug.h
 tools/include/linux/filter.h
 tools/include/linux/hash.h
 tools/include/linux/kernel.h




[PATCH 4.9 02/29] objtool: Move checking code to check.c

2018-06-03 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Poimboeuf 

commit dcc914f44f065ef73685b37e59877a5bb3cb7358 upstream.

In preparation for the new 'objtool undwarf generate' command, which
will rely on 'objtool check', move the checking code from
builtin-check.c to check.c where it can be used by other commands.

Signed-off-by: Josh Poimboeuf 
Reviewed-by: Jiri Slaby 
Cc: Andy Lutomirski 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: live-patch...@vger.kernel.org
Link: 
http://lkml.kernel.org/r/294c5c695fd73c1a5000bbe5960a7c9bec4ee6b4.1498659915.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
[backported by hand to 4.9, this was a pain... - gregkh]
Signed-off-by: Greg Kroah-Hartman 

---
 tools/objtool/Build   |1 
 tools/objtool/builtin-check.c | 1346 --
 tools/objtool/check.c | 1327 +
 tools/objtool/check.h |   51 +
 4 files changed, 1392 insertions(+), 1333 deletions(-)

--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,5 +1,6 @@
 objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
+objtool-y += check.o
 objtool-y += elf.o
 objtool-y += special.o
 objtool-y += objtool.o
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2015 Josh Poimboeuf 
+ * Copyright (C) 2015-2017 Josh Poimboeuf 
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -25,1352 +25,32 @@
  * For more information, see tools/objtool/Documentation/stack-validation.txt.
  */
 
-#include 
-#include 
 #include 
-
 #include "builtin.h"
-#include "elf.h"
-#include "special.h"
-#include "arch.h"
-#include "warn.h"
-
-#include 
-
-#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
-
-#define STATE_FP_SAVED 0x1
-#define STATE_FP_SETUP 0x2
-#define STATE_FENTRY   0x4
-
-struct instruction {
-   struct list_head list;
-   struct hlist_node hash;
-   struct section *sec;
-   unsigned long offset;
-   unsigned int len, state;
-   unsigned char type;
-   unsigned long immediate;
-   bool alt_group, visited, dead_end, ignore_alts;
-   struct symbol *call_dest;
-   struct instruction *jump_dest;
-   struct list_head alts;
-   struct symbol *func;
-};
-
-struct alternative {
-   struct list_head list;
-   struct instruction *insn;
-};
-
-struct objtool_file {
-   struct elf *elf;
-   struct list_head insn_list;
-   DECLARE_HASHTABLE(insn_hash, 16);
-   struct section *rodata, *whitelist;
-   bool ignore_unreachables, c_file;
-};
-
-const char *objname;
-static bool nofp;
-
-static struct instruction *find_insn(struct objtool_file *file,
-struct section *sec, unsigned long offset)
-{
-   struct instruction *insn;
-
-   hash_for_each_possible(file->insn_hash, insn, hash, offset)
-   if (insn->sec == sec && insn->offset == offset)
-   return insn;
-
-   return NULL;
-}
-
-static struct instruction *next_insn_same_sec(struct objtool_file *file,
- struct instruction *insn)
-{
-   struct instruction *next = list_next_entry(insn, list);
-
-   if (&next->list == &file->insn_list || next->sec != insn->sec)
-   return NULL;
-
-   return next;
-}
-
-static bool gcov_enabled(struct objtool_file *file)
-{
-   struct section *sec;
-   struct symbol *sym;
-
-   list_for_each_entry(sec, &file->elf->sections, list)
-   list_for_each_entry(sym, &sec->symbol_list, list)
-   if (!strncmp(sym->name, "__gcov_.", 8))
-   return true;
-
-   return false;
-}
-
-#define for_each_insn(file, insn)  \
-   list_for_each_entry(insn, &file->insn_list, list)
-
-#define func_for_each_insn(file, func, insn)   \
-   for (insn = find_insn(file, func->sec, func->offset);   \
-insn && &insn->list != &file->insn_list && \
-   insn->sec == func->sec &&   \
-   insn->offset < func->offset + func->len;\
-insn = list_next_entry(insn, list))
-
-#define func_for_each_insn_continue_reverse(file, func, insn)  \
-   for (insn = list_prev_entry(insn, list);\
-&insn->list != &file->insn_list && \
-   insn->sec == func->sec && insn->offset >= func->offset; \
-insn = list_prev_entry(insn, list))
-
-#define sec_for_each_insn_from(file, insn) \
-   for (; insn; insn = next_insn_same_sec(file, insn))
-
-
-/*
- * Check if the function has been ma

[PATCH 4.9 11/29] tools include: Adopt kernels refcount.h

2018-06-03 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Arnaldo Carvalho de Melo 

commit 73a9bf95ed1c05698ecabe2f28c47aedfa61b52b upstream.

To aid in catching bugs when using atomics as a reference count.

This is a trimmed down version with just what is used by tools/ at
this point.

After this, the patches submitted by Elena for tools/ doing the
conversion from atomic_ to recount_ methods can be applied and tested.

To activate it, buint perf with:

  make DEBUG=1 -C tools/perf

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Elena Reshetova 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: http://lkml.kernel.org/n/tip-dqtxsumns9ov0l9r5x398...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/include/linux/refcount.h |  151 +
 tools/perf/MANIFEST|1 
 2 files changed, 152 insertions(+)

--- /dev/null
+++ b/tools/include/linux/refcount.h
@@ -0,0 +1,151 @@
+#ifndef _TOOLS_LINUX_REFCOUNT_H
+#define _TOOLS_LINUX_REFCOUNT_H
+
+/*
+ * Variant of atomic_t specialized for reference counts.
+ *
+ * The interface matches the atomic_t interface (to aid in porting) but only
+ * provides the few functions one should use for reference counting.
+ *
+ * It differs in that the counter saturates at UINT_MAX and will not move once
+ * there. This avoids wrapping the counter and causing 'spurious'
+ * use-after-free issues.
+ *
+ * Memory ordering rules are slightly relaxed wrt regular atomic_t functions
+ * and provide only what is strictly required for refcounts.
+ *
+ * The increments are fully relaxed; these will not provide ordering. The
+ * rationale is that whatever is used to obtain the object we're increasing the
+ * reference count on will provide the ordering. For locked data structures,
+ * its the lock acquire, for RCU/lockless data structures its the dependent
+ * load.
+ *
+ * Do note that inc_not_zero() provides a control dependency which will order
+ * future stores against the inc, this ensures we'll never modify the object
+ * if we did not in fact acquire a reference.
+ *
+ * The decrements will provide release order, such that all the prior loads and
+ * stores will be issued before, it also provides a control dependency, which
+ * will order us against the subsequent free().
+ *
+ * The control dependency is against the load of the cmpxchg (ll/sc) that
+ * succeeded. This means the stores aren't fully ordered, but this is fine
+ * because the 1->0 transition indicates no concurrency.
+ *
+ * Note that the allocator is responsible for ordering things between free()
+ * and alloc().
+ *
+ */
+
+#include 
+#include 
+
+#ifdef NDEBUG
+#define REFCOUNT_WARN(cond, str) (void)(cond)
+#define __refcount_check
+#else
+#define REFCOUNT_WARN(cond, str) BUG_ON(cond)
+#define __refcount_check   __must_check
+#endif
+
+typedef struct refcount_struct {
+   atomic_t refs;
+} refcount_t;
+
+#define REFCOUNT_INIT(n)   { .refs = ATOMIC_INIT(n), }
+
+static inline void refcount_set(refcount_t *r, unsigned int n)
+{
+   atomic_set(&r->refs, n);
+}
+
+static inline unsigned int refcount_read(const refcount_t *r)
+{
+   return atomic_read(&r->refs);
+}
+
+/*
+ * Similar to atomic_inc_not_zero(), will saturate at UINT_MAX and WARN.
+ *
+ * Provides no memory ordering, it is assumed the caller has guaranteed the
+ * object memory to be stable (RCU, etc.). It does provide a control dependency
+ * and thereby orders future stores. See the comment on top.
+ */
+static inline __refcount_check
+bool refcount_inc_not_zero(refcount_t *r)
+{
+   unsigned int old, new, val = atomic_read(&r->refs);
+
+   for (;;) {
+   new = val + 1;
+
+   if (!val)
+   return false;
+
+   if (unlikely(!new))
+   return true;
+
+   old = atomic_cmpxchg_relaxed(&r->refs, val, new);
+   if (old == val)
+   break;
+
+   val = old;
+   }
+
+   REFCOUNT_WARN(new == UINT_MAX, "refcount_t: saturated; leaking 
memory.\n");
+
+   return true;
+}
+
+/*
+ * Similar to atomic_inc(), will saturate at UINT_MAX and WARN.
+ *
+ * Provides no memory ordering, it is assumed the caller already has a
+ * reference on the object, will WARN when this is not so.
+ */
+static inline void refcount_inc(refcount_t *r)
+{
+   REFCOUNT_WARN(!refcount_inc_not_zero(r), "refcount_t: increment on 0; 
use-after-free.\n");
+}
+
+/*
+ * Similar to atomic_dec_and_test(), it will WARN on underflow and fail to
+ * decrement when saturated at UINT_MAX.
+ *
+ * Provides release memory ordering, such that prior loads and stores are done
+ * before, and provides a control dependency such that free() must come after.
+ * See the comment on top.
+ */
+static inline __refcount_check
+bool refcount_sub_and_test(unsigned int i, refcount_t *r)
+{
+   unsigned int old, new, 

[PATCH 4.9 12/29] perf tools: Force fixdep compilation at the start of the build

2018-06-03 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Olsa 

commit abb26210a39522a6645bce3f438ed9a26bedb11b upstream.

The fixdep tool needs to be built before everything else, because it fixes
every object dependency file.

We handle this currently by making all objects to depend on fixdep, which is
error prone and is easily forgotten when new object is added.

Instead of this, this patch force fixdep tool to be built as the first target
in the separate make session. This way we don't need to handle extra fixdep
dependencies and we are certain there's no fixdep race with any parallel make
job.

Committer notes:

Testing it:

Before:

  $ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf ; make -k 
O=/tmp/build/perf -C tools/perf install-bin
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build

  Auto-detecting system features:
  ... dwarf: [ on  ]
  ...dwarf_getlocations: [ on  ]
  ... glibc: [ on  ]
  ...  gtk2: [ on  ]
  ...  libaudit: [ on  ]
  ...libbfd: [ on  ]
  ...libelf: [ on  ]
  ...   libnuma: [ on  ]
  ...numa_num_possible_cpus: [ on  ]
  ...   libperl: [ on  ]
  ... libpython: [ on  ]
  ...  libslang: [ on  ]
  ... libcrypto: [ on  ]
  ... libunwind: [ on  ]
  ...libdw-dwarf-unwind: [ on  ]
  ...  zlib: [ on  ]
  ...  lzma: [ on  ]
  ... get_cpuid: [ on  ]
  ...   bpf: [ on  ]

GEN  /tmp/build/perf/common-cmds.h
HOSTCC   /tmp/build/perf/fixdep.o
HOSTLD   /tmp/build/perf/fixdep-in.o
LINK /tmp/build/perf/fixdep
MKDIR/tmp/build/perf/pmu-events/
HOSTCC   /tmp/build/perf/pmu-events/json.o
MKDIR/tmp/build/perf/pmu-events/
HOSTCC   /tmp/build/perf/pmu-events/jsmn.o
HOSTCC   /tmp/build/perf/pmu-events/jevents.o
HOSTLD   /tmp/build/perf/pmu-events/jevents-in.o
PERF_VERSION = 4.9.rc8.g868cd5
CC   /tmp/build/perf/perf-read-vdso32
  

After:

  $ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf ; make -k 
O=/tmp/build/perf -C tools/perf install-bin
  make: Entering directory '/home/acme/git/linux/tools/perf'
BUILD:   Doing 'make -j4' parallel build
HOSTCC   /tmp/build/perf/fixdep.o
HOSTLD   /tmp/build/perf/fixdep-in.o
LINK /tmp/build/perf/fixdep

  Auto-detecting system features:
  ... dwarf: [ on  ]
  ...dwarf_getlocations: [ on  ]
  ... glibc: [ on  ]
  ...  gtk2: [ on  ]
  ...  libaudit: [ on  ]
  ...libbfd: [ on  ]
  ...libelf: [ on  ]
  ...   libnuma: [ on  ]
  ...numa_num_possible_cpus: [ on  ]
  ...   libperl: [ on  ]
  ... libpython: [ on  ]
  ...  libslang: [ on  ]
  ... libcrypto: [ on  ]
  ... libunwind: [ on  ]
  ...libdw-dwarf-unwind: [ on  ]
  ...  zlib: [ on  ]
  ...  lzma: [ on  ]
  ... get_cpuid: [ on  ]
  ...   bpf: [ on  ]

GEN  /tmp/build/perf/common-cmds.h
MKDIR/tmp/build/perf/fd/
CC   /tmp/build/perf/fd/array.o
LD   /tmp/build/perf/fd/libapi-in.o
MKDIR/tmp/build/perf/fs/
CC   /tmp/build/perf/event-parse.o
CC   /tmp/build/perf/fs/fs.o
PERF_VERSION = 4.9.rc8.g57a92f
CC   /tmp/build/perf/event-plugin.o
MKDIR/tmp/build/perf/fs/
CC   /tmp/build/perf/fs/tracing_path.o
  

Signed-off-by: Jiri Olsa 
Tested-by: Arnaldo Carvalho de Melo 
Cc: David Ahern 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1481030331-31944-3-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/perf/Makefile.perf |   50 +++
 1 file changed, 38 insertions(+), 12 deletions(-)

--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -177,6 +177,35 @@ ifeq ($(filter-out $(NON_CONFIG_TARGETS)
 endif
 endif
 
+# The fixdep build - we force fixdep tool to be built as
+# the first target in the separate make session not to be
+# disturbed by any parallel make jobs. Once fixdep is done
+# we issue the requested build with FIXDEP=1 variable.
+#
+# The fixdep build is disabled for $(NON_CONFIG_TARGETS)
+# targets, because it's not necessary.
+
+ifdef FIXDEP
+  force_fixdep := 0
+else
+  force_fixdep := $(config)
+endif
+
+export srctree OUTPUT RM CC CXX LD 

[PATCH 4.9 01/29] objtool: Improve detection of BUG() and other dead ends

2018-06-03 Thread Greg Kroah-Hartman
4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Josh Poimboeuf 

commit d1091c7fa3d52ebce4dd3f15d04155b3469b2f90 upstream.

The BUG() macro's use of __builtin_unreachable() via the unreachable()
macro tells gcc that the instruction is a dead end, and that it's safe
to assume the current code path will not execute past the previous
instruction.

On x86, the BUG() macro is implemented with the 'ud2' instruction.  When
objtool's branch analysis sees that instruction, it knows the current
code path has come to a dead end.

Peter Zijlstra has been working on a patch to change the WARN macros to
use 'ud2'.  That patch will break objtool's assumption that 'ud2' is
always a dead end.

Generally it's best for objtool to avoid making those kinds of
assumptions anyway.  The more ignorant it is of kernel code internals,
the better.

So create a more generic way for objtool to detect dead ends by adding
an annotation to the unreachable() macro.  The annotation stores a
pointer to the end of the unreachable code path in an '__unreachable'
section.  Objtool can read that section to find the dead ends.

Tested-by: Peter Zijlstra (Intel) 
Signed-off-by: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/41a6d33971462ebd944a1c60ad4bf5be86c17b77.1487712920.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/x86/kernel/vmlinux.lds.S   |1 
 include/linux/compiler-gcc.h|   13 
 tools/objtool/arch.h|5 +--
 tools/objtool/arch/x86/decode.c |3 --
 tools/objtool/builtin-check.c   |   60 +---
 5 files changed, 71 insertions(+), 11 deletions(-)

--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -353,6 +353,7 @@ SECTIONS
/DISCARD/ : {
*(.eh_frame)
*(__func_stack_frame_non_standard)
+   *(__unreachable)
}
 }
 
--- a/include/linux/compiler-gcc.h
+++ b/include/linux/compiler-gcc.h
@@ -203,6 +203,17 @@
 #endif
 #endif
 
+#ifdef CONFIG_STACK_VALIDATION
+#define annotate_unreachable() ({  \
+   asm("1:\t\n"\
+   ".pushsection __unreachable, \"a\"\t\n" \
+   ".long 1b\t\n"  \
+   ".popsection\t\n"); \
+})
+#else
+#define annotate_unreachable()
+#endif
+
 /*
  * Mark a position in code as unreachable.  This can be used to
  * suppress control flow warnings after asm blocks that transfer
@@ -212,7 +223,7 @@
  * this in the preprocessor, but we can live with this because they're
  * unreleased.  Really, we need to have autoconf for the kernel.
  */
-#define unreachable() __builtin_unreachable()
+#define unreachable() annotate_unreachable(); __builtin_unreachable()
 
 /* Mark a function definition as prohibited from being cloned. */
 #define __noclone  __attribute__((__noclone__, __optimize__("no-tracer")))
--- a/tools/objtool/arch.h
+++ b/tools/objtool/arch.h
@@ -31,9 +31,8 @@
 #define INSN_CALL_DYNAMIC  8
 #define INSN_RETURN9
 #define INSN_CONTEXT_SWITCH10
-#define INSN_BUG   11
-#define INSN_NOP   12
-#define INSN_OTHER 13
+#define INSN_NOP   11
+#define INSN_OTHER 12
 #define INSN_LAST  INSN_OTHER
 
 int arch_decode_instruction(struct elf *elf, struct section *sec,
--- a/tools/objtool/arch/x86/decode.c
+++ b/tools/objtool/arch/x86/decode.c
@@ -118,9 +118,6 @@ int arch_decode_instruction(struct elf *
 op2 == 0x35)
/* sysenter, sysret */
*type = INSN_CONTEXT_SWITCH;
-   else if (op2 == 0x0b || op2 == 0xb9)
-   /* ud2 */
-   *type = INSN_BUG;
else if (op2 == 0x0d || op2 == 0x1f)
/* nopl/nopw */
*type = INSN_NOP;
--- a/tools/objtool/builtin-check.c
+++ b/tools/objtool/builtin-check.c
@@ -51,7 +51,7 @@ struct instruction {
unsigned int len, state;
unsigned char type;
unsigned long immediate;
-   bool alt_group, visited, ignore_alts;
+   bool alt_group, visited, dead_end, ignore_alts;
struct symbol *call_dest;
struct instruction *jump_dest;
struct list_head alts;
@@ -330,6 +330,54 @@ static int decode_instructions(struct ob
 }
 
 /*
+ * Find all uses of the unreachable() macro, which are code path dead ends.
+ */
+static int add_dead_ends(struct objtool_file *file)
+{
+   struct section *sec;
+   struct rela *rela;
+   struct instruction *insn;
+   bool found;
+
+   sec = find_section_by_name(file->elf, ".rela__unreachable");
+   if (!sec)
+   return 0;

[PATCH 4.9 00/29] 4.9.106-stable review

2018-06-03 Thread Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.9.106 release.
There are 29 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Wed Jun  6 06:57:52 UTC 2018.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:

https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.106-rc1.gz
or in the git tree and branch at:

git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
linux-4.9.y
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 4.9.106-rc1

Greg Kroah-Hartman 
x86/xen: Add unwind hint annotations to xen_setup_gdt

Greg Kroah-Hartman 
objtool: header file sync-up

Greg Kroah-Hartman 
perf/tools: header file sync up

Josh Poimboeuf 
objtool, x86: Add several functions and files to the objtool whitelist

Josh Poimboeuf 
objtool: Fix "noreturn" detection for recursive sibling calls

Josh Poimboeuf 
objtool: Detect RIP-relative switch table references, part 2

Josh Poimboeuf 
objtool: Detect RIP-relative switch table references

Josh Poimboeuf 
objtool: Support GCC 8 switch tables

Josh Poimboeuf 
objtool: Support GCC 8's cold subfunctions

Greg Kroah-Hartman 
objtool: sync up with the 4.14.47 version of objtool

Arnaldo Carvalho de Melo 
tools include: Include missing headers for fls() and types in linux/log2.h

Arnaldo Carvalho de Melo 
tools include: Drop ARRAY_SIZE() definition from linux/hashtable.h

Arnaldo Carvalho de Melo 
tools include: Move ARRAY_SIZE() to linux/kernel.h

Arnaldo Carvalho de Melo 
tools include: Adopt __same_type() and __must_be_array() from the kernel

Arnaldo Carvalho de Melo 
tools include: Introduce linux/bug.h, from the kernel sources

Arnaldo Carvalho de Melo 
tools include uapi: Grab copies of stat.h and fcntl.h

Jiri Olsa 
perf tools: Move headers check into bash script

Jiri Olsa 
perf tools: Force fixdep compilation at the start of the build

Arnaldo Carvalho de Melo 
tools include: Adopt kernel's refcount.h

Arnaldo Carvalho de Melo 
tools include: Add UINT_MAX def to kernel.h

Arnaldo Carvalho de Melo 
tools include: Introduce atomic_cmpxchg_{relaxed,release}()

Arnaldo Carvalho de Melo 
tools include: Adopt __compiletime_error

Matthew Wilcox 
radix tree test suite: Remove types.h

Arnaldo Carvalho de Melo 
tools include: Introduce linux/compiler-gcc.h

Michael S. Tsirkin 
tools: enable endian checks for all sparse builds

Matthew Wilcox 
tools: add more bitmap functions

Jiri Olsa 
tools lib: Add for_each_clear_bit macro

Josh Poimboeuf 
objtool: Move checking code to check.c

Josh Poimboeuf 
objtool: Improve detection of BUG() and other dead ends


-

Diffstat:

 Makefile   |4 +-
 arch/x86/crypto/Makefile   |2 +
 arch/x86/crypto/sha1-mb/Makefile   |2 +
 arch/x86/crypto/sha256-mb/Makefile |2 +
 arch/x86/include/asm/orc_types.h   |  107 +
 arch/x86/include/asm/unwind_hints.h|  103 +
 arch/x86/kernel/Makefile   |1 +
 arch/x86/kernel/acpi/Makefile  |2 +
 arch/x86/kernel/kprobes/opt.c  |9 +-
 arch/x86/kernel/reboot.c   |2 +
 arch/x86/kernel/vmlinux.lds.S  |1 +
 arch/x86/kvm/svm.c |2 +
 arch/x86/kvm/vmx.c |3 +
 arch/x86/lib/msr-reg.S |8 +-
 arch/x86/net/Makefile  |2 +
 arch/x86/platform/efi/Makefile |1 +
 arch/x86/power/Makefile|2 +
 arch/x86/xen/Makefile  |3 +
 arch/x86/xen/enlighten.c   |5 +-
 include/linux/compiler-gcc.h   |   13 +-
 kernel/kexec_core.c|4 +-
 tools/arch/arm/include/uapi/asm/kvm.h  |   13 +
 tools/arch/arm64/include/uapi/asm/kvm.h|6 +
 tools/arch/powerpc/include/uapi/asm/kvm.h  |1 +
 tools/arch/s390/include/uapi/asm/kvm.h |5 +-
 tools/arch/x86/include/asm/cpufeatures.h   |   44 +-
 tools/arch/x86/include/asm/disabled-features.h |7 +-
 tools/arch/x86/include/asm/required-features.h |3 +-
 tools/include/asm-generic/bitops.h |1 +
 tools/include/asm-generic/bitops/__ffz.h   |   12 +
 tools/include/asm-generic/bitops/find.h|   28 +
 tools/include/linux/atomic.h   |6 +
 tools/include/linux/bitmap.h   |   26

linux-next: manual merge of the kvm tree with the arm64 tree

2018-06-03 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the kvm tree got a conflict in:

  arch/arm64/include/asm/processor.h

between commit:

  94b07c1f8c39 ("arm64: signal: Report signal frame size to userspace via auxv")

from the arm64 tree and commit:

  9a6e594869b2 ("arm64/sve: Move sve_pffr() to fpsimd.h and make inline")

from the kvm tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/include/asm/processor.h
index 65ab83e8926e,c99e657fdd57..
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@@ -246,9 -246,17 +248,20 @@@ void cpu_enable_pan(const struct arm64_
  void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities 
*__unused);
  void cpu_clear_disr(const struct arm64_cpu_capabilities *__unused);
  
 +extern unsigned long __ro_after_init signal_minsigstksz; /* sigframe size */
 +extern void __init minsigstksz_setup(void);
 +
+ /*
+  * Not at the top of the file due to a direct #include cycle between
+  *  and .  Deferring this #include
+  * ensures that contents of processor.h are visible to fpsimd.h even if
+  * processor.h is included first.
+  *
+  * These prctl helpers are the only things in this file that require
+  * fpsimd.h.  The core code expects them to be in this header.
+  */
+ #include 
+ 
  /* Userspace interface for PR_SVE_{SET,GET}_VL prctl()s: */
  #define SVE_SET_VL(arg)   sve_set_current_vl(arg)
  #define SVE_GET_VL()  sve_get_current_vl()


pgpZ5eFyW_P81.pgp
Description: OpenPGP digital signature


Re: [PATCH 0/4] exit: Make unlikely case in mm_update_next_owner() more scalable

2018-06-03 Thread Michal Hocko
On Fri 01-06-18 10:25:59, Eric W. Biederman wrote:
> Michal Hocko  writes:
> 
> > On Fri 01-06-18 09:32:42, Eric W. Biederman wrote:
> >> Michal Hocko  writes:
> > [...]
> >> > Group leader exiting early without tearing down the whole thread
> >> > group should be quite rare as well. No question that somebody might do
> >> > that on purpose though...
> >> 
> >> The group leader exiting early is a completely legitimate and reasonable
> >> thing to do, even if it is rare.
> >
> > I am not saying it isn't legitimate. But the most common case is the
> > main thread waiting for its threads or calling exit which would tear the
> > whole group down. Is there any easy way to achieve this other than tkill
> > to group leader? Calling exit(3) from the leader performs group exit
> > IIRC.
> 
> pthread_exit from the group leader.

Right, forgot to mention this one but this would be quite exotic, right?


> > I am not arguing this is non-issue. And it certainly is a problem once
> > somebody wants to be nasty... I was more interested how often this
> > really happens for sane workloads.
> 
> That is a fair question.  All I know for certain is that whatever Kirill
> Tkhai's workload was it was triggering this the slow path.

Yeah, that was exactly why I've asked that originally. It must be
something pretty special ;)
-- 
Michal Hocko
SUSE Labs


Re: [PATCH] mtd: rawnand: mxc: set spare area size register explicitly

2018-06-03 Thread Sascha Hauer
On Sun, Jun 03, 2018 at 01:31:35PM +0200, Martin Kaiser wrote:
> The v21 version of the NAND flash controller contains a Spare Area Size
> Register (SPAS) at offset 0x10. Its setting defaults to the maximum
> spare area size of 218 bytes. The size that is set in this register is
> used by the controller when it calculates the ECC bytes internally in
> hardware.
> 
> Usually, this register is updated from settings in the IIM fuses when
> the system is booting from nand flash. For other boot media, however,
> the SPAS register remains at the default setting, which may not work for
> the particular flash chip on the board. The same goes for flash chips
> whose configuration cannot be set in the IIM fuses (e.g. chips with 2k
> sector size and 128 bytes spare area size can't be configured in the IIM
> fuses on imx25 systems).
> 
> Set the SPAS register explicitly during the preset operation. Derive the
> register value from mtd->oobsize that was detected during probe by
> decoding the flash chip's ID bytes.
> 
> While at it, rename the define for the spare area register's offset to
> NFC_V21_RSLTSPARE_AREA. The register at offset 0x10 on v1 controllers is
> different from the register on v21 controllers.
> 
> Signed-off-by: Martin Kaiser 
> Cc: sta...@vger.kernel.org

Reviewed-by: Sascha Hauer 

Sascha

> ---
>  drivers/mtd/nand/raw/mxc_nand.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/raw/mxc_nand.c b/drivers/mtd/nand/raw/mxc_nand.c
> index 45786e7..c2f8572 100644
> --- a/drivers/mtd/nand/raw/mxc_nand.c
> +++ b/drivers/mtd/nand/raw/mxc_nand.c
> @@ -48,7 +48,7 @@
>  #define NFC_V1_V2_CONFIG (host->regs + 0x0a)
>  #define NFC_V1_V2_ECC_STATUS_RESULT  (host->regs + 0x0c)
>  #define NFC_V1_V2_RSLTMAIN_AREA  (host->regs + 0x0e)
> -#define NFC_V1_V2_RSLTSPARE_AREA (host->regs + 0x10)
> +#define NFC_V21_RSLTSPARE_AREA   (host->regs + 0x10)
>  #define NFC_V1_V2_WRPROT (host->regs + 0x12)
>  #define NFC_V1_UNLOCKSTART_BLKADDR   (host->regs + 0x14)
>  #define NFC_V1_UNLOCKEND_BLKADDR (host->regs + 0x16)
> @@ -1274,6 +1274,9 @@ static void preset_v2(struct mtd_info *mtd)
>   writew(config1, NFC_V1_V2_CONFIG1);
>   /* preset operation */
>  
> + /* spare area size in 16bit words */
> + writew(mtd->oobsize >> 1, NFC_V21_RSLTSPARE_AREA);
> +
>   /* Unlock the internal RAM Buffer */
>   writew(0x2, NFC_V1_V2_CONFIG);
>  
> -- 
> 2.1.4
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |


Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

2018-06-03 Thread Michal Hocko
On Sat 02-06-18 19:58:52, ufo19890...@gmail.com wrote:
> From: yuzhoujian 
> 
> The dump_header does not print the memcg's name when the system
> oom happened, so users cannot locate the certain container which
> contains the task that has been killed by the oom killer.
> 
> I follow the advices of David Rientjes and Michal Hocko, and refactor
> part of the oom report in a backwards compatible way. After this patch,
> users can get the memcg's path from the oom report and check the certain
> container more quickly.

I have earlier suggested that you split this into two parts. One to add
the missing information and the later to convert it to a single printk
output. Reducing the overhead from PATH_MAX to NAME_MAX is a good step
but it still really begs an example why we really insist on a single
printk and that should be in its own changelog.

Sorry if that was not clear previously.
-- 
Michal Hocko
SUSE Labs


[PATCH v3]: perf record: enable arbitrary event names thru name= modifier

2018-06-03 Thread Alexey Budankov


Enable complex event names containing [.:=,] symbols to be encoded into Perf 
trace using name= modifier e.g. like this:

perf record -e 
cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',\
period=0x3567e0,event=0x3c,cmask=0x1/Duk ./futex

Below is how it looks like in the report output. Please note explicit escaped 
quoting at cmdline string in the header so that thestring can be directly reused
for another collection in shell:

perf report --header

# 
...
# cmdline : /root/abudanko/kernel/tip/tools/perf/perf record -v -e 
cpu/name=\'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM\',period=0x3567e0,event=0x3c,cmask=0x1/Duk
 ./futex 
# event : name = 
OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM, , type = 4, 
size = 112, config = 0x13c, { sample_period, sample_freq } = 350, 
sample_type = IP|TID|TIME, disabled = 1, inh
...
# 
#
#
# Total Lost Samples: 0
#
# Samples: 24K of event 
'OFFCORE_RESPONSE:request=DEMAND_RFO:response=L3_HIT.SNOOP_HITM'
# Event count (approx.): 8649200
#
# Overhead  Command  Shared Object Symbol   
 
#   ...    
..
#
14.75%  futex[kernel.vmlinux]  [k] __entry_trampoline_start
...

perf stat -e 
cpu/name=\'CPU_CLK_UNHALTED.THREAD:cmask=0x1\',period=0x3567e0,event=0x3c,cmask=0x1/Duk
 ./futex

1000 process context switches in 16678890291ns (1667.9ns/ctxsw)

 Performance counter stats for './futex':

88,095,770,571  CPU_CLK_UNHALTED.THREAD:cmask=0x1   


  16.679542407 seconds time elapsed

Signed-off-by: Alexey Budankov 
---
Changes in v3:
- updated event name syntax in perf list docs;
- added name modifier description into perf record docs;

Changes in v2:
- aligned break according to coding guidelines;
- put comment regarding expected quoting rules; 
---
 tools/perf/Documentation/perf-list.txt   |  6 +-
 tools/perf/Documentation/perf-record.txt |  3 +++
 tools/perf/util/header.c | 20 ++--
 tools/perf/util/parse-events.l   | 18 +-
 4 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/tools/perf/Documentation/perf-list.txt 
b/tools/perf/Documentation/perf-list.txt
index 2549c34a7895..11300dbe35c5 100644
--- a/tools/perf/Documentation/perf-list.txt
+++ b/tools/perf/Documentation/perf-list.txt
@@ -124,7 +124,11 @@ The available PMUs and their raw parameters can be listed 
with
 For example the raw event "LSD.UOPS" core pmu event above could
 be specified as
 
-  perf stat -e cpu/event=0xa8,umask=0x1,name=LSD.UOPS_CYCLES,cmask=1/ ...
+  perf stat -e cpu/event=0xa8,umask=0x1,name=LSD.UOPS_CYCLES,cmask=0x1/ ...
+
+  or using extended name syntax
+
+  perf stat -e 
cpu/event=0xa8,umask=0x1,cmask=0x1,name=\'LSD.UOPS_CYCLES:cmask=0x1\'/ ...
 
 PER SOCKET PMUS
 ---
diff --git a/tools/perf/Documentation/perf-record.txt 
b/tools/perf/Documentation/perf-record.txt
index cc37b3a4be76..04168da4268e 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -57,6 +57,9 @@ OPTIONS
 FP mode, "dwarf" for DWARF mode, "lbr" for LBR mode and
 "no" for disable callgraph.
  - 'stack-size': user stack size for dwarf mode
+ - 'name' : User defined event name. Single quotes (') may be used to
+   escape symbols in the name from parsing by shell and tool
+   like this: name=\'CPU_CLK_UNHALTED.THREAD:cmask=0x1\'.
 
   See the linkperf:perf-list[1] man page for more parameters.
 
diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index a8bff2178fbc..08176e8cb3b4 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -1459,8 +1459,24 @@ static void print_cmdline(struct feat_fd *ff, FILE *fp)
 
fprintf(fp, "# cmdline : ");
 
-   for (i = 0; i < nr; i++)
-   fprintf(fp, "%s ", ff->ph->env.cmdline_argv[i]);
+   for (i = 0; i < nr; i++) {
+   char *argv_i = strdup(ff->ph->env.cmdline_argv[i]);
+   if (!argv_i) {
+   fprintf(fp, "%s ", ff->ph->env.cmdline_argv[i]);
+   } else {
+   char *mem = argv_i;
+   do {
+   char *quote = strchr(argv_i, '\'');
+   if (!quote)
+   break;
+   *quote++ = '\0';
+   fprintf(fp, "%s\\\'", argv_i);
+   argv_i = quote;
+   } while (1);
+   fprintf(fp, "%s ", argv_i);
+   free(mem);
+   }
+   }
fputc('\n', fp);
 }
 
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-eve

Re: [PATCH v4 2/2] sched/deadline: Set cp->elements[0].cpu to -1 when the heap is empty

2018-06-03 Thread Byungchul Park




On 2018-06-04 15:36, Byungchul Park wrote:

Hello Steven and Daniel,

I've changed the 2nd patch a little bit to consider cpudl_clear()
additionally. Can I keep your Acked-by on?


Very sorry. Please ignore this v4 spin.. I'll resend v5 version soon.

--
Thanks,
Byungchul


Re: [PATCH v7 1/2] Add an array of const char and enum oom_constraint in memcontrol.h

2018-06-03 Thread Michal Hocko
On Sat 02-06-18 19:58:51, ufo19890...@gmail.com wrote:
> From: yuzhoujian 
> 
> This patch will make some preparation for the follow-up patch: Refactor
> part of the oom report in dump_header. It puts enum oom_constraint in
> memcontrol.h and adds an array of const char for each constraint.

I do not get why you separate this specific part out.
oom_constraint_text is not used in the patch. It is almost always
preferable to have a user of newly added functionality.

> 
> Signed-off-by: yuzhoujian 
> ---
>  include/linux/memcontrol.h | 14 ++
>  mm/oom_kill.c  |  7 ---
>  2 files changed, 14 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
> index d99b71bc2c66..57311b6c4d67 100644
> --- a/include/linux/memcontrol.h
> +++ b/include/linux/memcontrol.h
> @@ -62,6 +62,20 @@ struct mem_cgroup_reclaim_cookie {
>   unsigned int generation;
>  };
>  
> +enum oom_constraint {
> + CONSTRAINT_NONE,
> + CONSTRAINT_CPUSET,
> + CONSTRAINT_MEMORY_POLICY,
> + CONSTRAINT_MEMCG,
> +};
> +
> +static const char * const oom_constraint_text[] = {
> + [CONSTRAINT_NONE] = "CONSTRAINT_NONE",
> + [CONSTRAINT_CPUSET] = "CONSTRAINT_CPUSET",
> + [CONSTRAINT_MEMORY_POLICY] = "CONSTRAINT_MEMORY_POLICY",
> + [CONSTRAINT_MEMCG] = "CONSTRAINT_MEMCG",
> +};
> +
>  #ifdef CONFIG_MEMCG
>  
>  #define MEM_CGROUP_ID_SHIFT  16
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 8ba6cb88cf58..c806cd656af6 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -237,13 +237,6 @@ unsigned long oom_badness(struct task_struct *p, struct 
> mem_cgroup *memcg,
>   return points > 0 ? points : 1;
>  }
>  
> -enum oom_constraint {
> - CONSTRAINT_NONE,
> - CONSTRAINT_CPUSET,
> - CONSTRAINT_MEMORY_POLICY,
> - CONSTRAINT_MEMCG,
> -};
> -
>  /*
>   * Determine the type of allocation constraint.
>   */
> -- 
> 2.14.1

-- 
Michal Hocko
SUSE Labs


[PATCH v5 2/2] sched/deadline: Set cp->elements[0].cpu to -1 when the heap is empty

2018-06-03 Thread Byungchul Park
Hello Steven and Daniel,

I've changed the 2nd patch a little bit to consider cpudl_clear()
additionally. Can I keep your Acked-by on?

(I temporarily removed the Acked-by you gave me.)

Acked-by: Steven Rostedt (VMware) 
Acked-by: Daniel Bristot de Oliveira 

-8<-
>From 1e368d276186c22f9da298206c718b33e805828d Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Mon, 4 Jun 2018 15:05:08 +0900
Subject: [PATCH v5 2/2] sched/deadline: Set cp->elements[0].cpu to -1 when the
 heap is empty

Currently, migrating tasks to cpu0 unconditionally happens when the
heap is empty, since cp->elements[0].cpu is initialized to 0(=cpu0).
We have to distinguish between the empty case and cpu0 to avoid the
unnecessary migrations. Therefore, it has to return an invalid value
e.i. -1 in the case the heap is empty.

Signed-off-by: Byungchul Park 
Suggested-by: Joel Fernandes 
---
 kernel/sched/cpudeadline.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index ae4fbdc..a200b36 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -136,6 +136,10 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
 
WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
 
+   /* The heap tree is empty, just return. */
+   if (best_cpu == -1)
+   return 0;
+
if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) &&
dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
if (later_mask)
@@ -172,6 +176,13 @@ void cpudl_clear(struct cpudl *cp, int cpu)
 * This could happen if a rq_offline_dl is
 * called for a CPU without -dl tasks running.
 */
+   } else if (cp->size == 1){
+   /* Only one element in the heap, clear it. */
+   cp->elements[0].cpu = -1;
+   cp->elements[cpu].idx = IDX_INVALID;
+   cp->size = 0;
+
+   cpumask_set_cpu(cpu, cp->free_cpus);
} else {
new_cpu = cp->elements[cp->size - 1].cpu;
cp->elements[old_idx].dl = cp->elements[cp->size - 1].dl;
@@ -267,6 +278,9 @@ int cpudl_init(struct cpudl *cp)
for_each_possible_cpu(i)
cp->elements[i].idx = IDX_INVALID;
 
+   /* Mark heap as initially empty. */
+   cp->elements[0].cpu = -1;
+
return 0;
 }
 
-- 
1.9.1



[PATCH v5 1/2] sched/deadline: Add cpudl_maximum_dl() for better readability

2018-06-03 Thread Byungchul Park
Changes from v4
 - Fix a typo in cpudl_init() of the 2nd patch

Changes from v3
 - Rebase onto the latest tip/sched/core
 - Apply what Joel suggests, to set cp->elements[0].cpu to -1
   when the heap becomes empty in cpudl_clear()

Changes from v2
 - Run spellchecker over the text and fix typos
 - Add acked-by Daniel

Changes from v1
 - Enhance commit msg
 - Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1

-8<-
>From 13efb279e8189e454062854fb1ce2df407543630 Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Mon, 4 Jun 2018 15:12:50 +0900
Subject: [PATCH v5 1/2] sched/deadline: Add cpudl_maximum_dl() for better
 readability

Current code uses cpudl_maximum() to get the root node's cpu, while it
directly accesses the root node to get the root node's dl. It would be
more readable and consistent between them if we provide the same way to
access them. So add a function for dl as we did it for cpu.

Signed-off-by: Byungchul Park 
Acked-by: Steven Rostedt (VMware) 
Acked-by: Daniel Bristot de Oliveira 
---
 kernel/sched/cpudeadline.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 5031645..ae4fbdc 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -105,11 +105,16 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
cpudl_heapify_down(cp, idx);
 }
 
-static inline int cpudl_maximum(struct cpudl *cp)
+static inline int cpudl_maximum_cpu(struct cpudl *cp)
 {
return cp->elements[0].cpu;
 }
 
+static inline u64 cpudl_maximum_dl(struct cpudl *cp)
+{
+   return cp->elements[0].dl;
+}
+
 /*
  * cpudl_find - find the best (later-dl) CPU in the system
  * @cp: the cpudl max-heap context
@@ -127,12 +132,12 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
return 1;
} else {
-   int best_cpu = cpudl_maximum(cp);
+   int best_cpu = cpudl_maximum_cpu(cp);
 
WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
 
if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) &&
-   dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
+   dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
if (later_mask)
cpumask_set_cpu(best_cpu, later_mask);
 
-- 
1.9.1



Re: [PATCH] mm: clean up page_is_poisoned in linux/mm.h

2018-06-03 Thread Michal Hocko
On Sun 03-06-18 12:22:18, kpark3...@gmail.com wrote:
> From: Sahara 
> 
> When bd33ef36("mm: enable page poisoning early at boot") got rid of
> the PAGE_EXT_DEBUG_POISON, page_is_poisoned in the header left
> behind. This patch cleans up the leftovers under the table.

Acked-by: Michal Hocko 

Btw. we tend to use abbrev = 12 for sha1 references.

> Signed-off-by: Sahara 
> ---
>  include/linux/mm.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index c6fa9a2..a53b0ad 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2522,12 +2522,10 @@ extern int apply_to_page_range(struct mm_struct *mm, 
> unsigned long address,
>  #ifdef CONFIG_PAGE_POISONING
>  extern bool page_poisoning_enabled(void);
>  extern void kernel_poison_pages(struct page *page, int numpages, int enable);
> -extern bool page_is_poisoned(struct page *page);
>  #else
>  static inline bool page_poisoning_enabled(void) { return false; }
>  static inline void kernel_poison_pages(struct page *page, int numpages,
>   int enable) { }
> -static inline bool page_is_poisoned(struct page *page) { return false; }
>  #endif
>  
>  #ifdef CONFIG_DEBUG_PAGEALLOC
> -- 
> 2.7.4

-- 
Michal Hocko
SUSE Labs


Re: [PATCH v5 05/10] cpufreq/schedutil: get max utilization

2018-06-03 Thread Vincent Guittot
On 1 June 2018 at 19:45, Joel Fernandes  wrote:
> On Fri, Jun 01, 2018 at 03:53:07PM +0200, Vincent Guittot wrote:
>> > >> >> The example with a RT task described in the cover letter can be
>> > >> >> run with a DL task and will give similar results.
>> > >
>> > > In the cover letter you says:
>> > >
>> > >A rt-app use case which creates an always running cfs thread and a
>> > >rt threads that wakes up periodically with both threads pinned on
>> > >same CPU, show lot of frequency switches of the CPU whereas the CPU
>> > >never goes idles during the test.
>> > >
>> > > I would say that's a quite specific corner case where your always
>> > > running CFS task has never accumulated a util_est sample.
>> > >
>> > > Do we really have these cases in real systems?
>> >
>> > My example is voluntary an extreme one because it's easier to
>> > highlight the problem
>> >
>> > >
>> > > Otherwise, it seems to me that we are trying to solve quite specific
>> > > corner cases by adding a not negligible level of "complexity".
>> >
>> > By complexity, do you mean :
>> >
>> > Taking into account the number cfs running task to choose between
>> > rq->dl.running_bw and avg_dl.util_avg
>> >
>> > I'm preparing a patchset that will provide the cfs waiting time in
>> > addition to dl/rt util_avg for almost no additional cost. I will try
>> > to sent the proposal later today
>>
>>
>> The code below adds the tracking of the waiting level of cfs tasks because of
>> rt/dl preemption. This waiting time can then be used when selecting an OPP
>> instead of the dl util_avg which could become higher than dl bandwidth with
>> "long" runtime
>>
>> We need only one new call for the 1st cfs task that is enqueued to get these 
>> additional metrics
>> the call to arch_scale_cpu_capacity() can be removed once the later will be
>> taken into account when computing the load (which scales only with freq
>> currently)
>>
>> For rt task, we must keep to take into account util_avg to have an idea of 
>> the
>> rt level on the cpu which is given by the badnwodth for dl
>>
>> ---
>>  kernel/sched/fair.c  | 27 +++
>>  kernel/sched/pelt.c  |  8 ++--
>>  kernel/sched/sched.h |  4 +++-
>>  3 files changed, 36 insertions(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index eac1f9a..1682ea7 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -5148,6 +5148,30 @@ static inline void hrtick_update(struct rq *rq)
>>  }
>>  #endif
>>
>> +static inline void update_cfs_wait_util_avg(struct rq *rq)
>> +{
>> + /*
>> +  * If cfs is already enqueued, we don't have anything to do because
>> +  * we already updated the non waiting time
>> +  */
>> + if (rq->cfs.h_nr_running)
>> + return;
>> +
>> + /*
>> +  * If rt is running, we update the non wait time before increasing
>> +  * cfs.h_nr_running)
>> +  */
>> + if (rq->curr->sched_class == &rt_sched_class)
>> + update_rt_rq_load_avg(rq_clock_task(rq), rq, 1);
>> +
>> + /*
>> +  * If dl is running, we update the non time before increasing
>> +  * cfs.h_nr_running)
>> +  */
>> + if (rq->curr->sched_class == &dl_sched_class)
>> + update_dl_rq_load_avg(rq_clock_task(rq), rq, 1);
>> +}
>> +
>
> Please correct me if I'm wrong but the CFS preemption-decay happens in
> set_next_entity -> update_load_avg when the CFS task is scheduled again after
> the preemption. Then can we not fix this issue by doing our UTIL_EST magic
> from set_next_entity? But yeah probably we need to be careful with overhead..

util_est is there to keep track of the last max. I'm not sure that
trying to add some magics to take into account preemption is the right
way to do. Mixing several information in the same metric just add more
fuzzy in the meaning of the metric.

>
> IMO I feel its overkill to account dl_avg when we already have DL's running
> bandwidth we can use. I understand it may be too instanenous, but perhaps we

We keep using dl bandwidth which is quite correct for dl needs but
doesn't reflect how it has disturbed other classes

> can fix CFS's problems within CFS itself and not have to do this kind of
> extra external accounting ?
>
> I also feel its better if we don't have to call update_{rt,dl}_rq_load_avg
> from within CFS class as being done above.
>
> thanks,
>
>  - Joel
>


[PATCH v4 2/2] sched/deadline: Set cp->elements[0].cpu to -1 when the heap is empty

2018-06-03 Thread Byungchul Park
Hello Steven and Daniel,

I've changed the 2nd patch a little bit to consider cpudl_clear()
additionally. Can I keep your Acked-by on?

(I temporarily removed the Acked-by you gave me.)

Acked-by: Steven Rostedt (VMware) 
Acked-by: Daniel Bristot de Oliveira 

-8<-
>From 1e368d276186c22f9da298206c718b33e805828d Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Mon, 4 Jun 2018 15:05:08 +0900
Subject: [PATCH v4 2/2] sched/deadline: Set cp->elements[0].cpu to -1 when the
 heap is empty

Currently, migrating tasks to cpu0 unconditionally happens when the
heap is empty, since cp->elements[0].cpu is initialized to 0(=cpu0).
We have to distinguish between the empty case and cpu0 to avoid the
unnecessary migrations. Therefore, it has to return an invalid value
e.i. -1 in the case the heap is empty.

Signed-off-by: Byungchul Park 
Suggested-by: Joel Fernandes 
---
 kernel/sched/cpudeadline.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index ae4fbdc..a200b36 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -136,6 +136,10 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
 
WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
 
+   /* The heap tree is empty, just return. */
+   if (best_cpu == -1)
+   return 0;
+
if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) &&
dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
if (later_mask)
@@ -172,6 +176,13 @@ void cpudl_clear(struct cpudl *cp, int cpu)
 * This could happen if a rq_offline_dl is
 * called for a CPU without -dl tasks running.
 */
+   } else if (cp->size == 1){
+   /* Only one element in the heap, clear it. */
+   cp->elements[0].cpu = -1;
+   cp->elements[cpu].idx = IDX_INVALID;
+   cp->size = 0;
+
+   cpumask_set_cpu(cpu, cp->free_cpus);
} else {
new_cpu = cp->elements[cp->size - 1].cpu;
cp->elements[old_idx].dl = cp->elements[cp->size - 1].dl;
@@ -267,6 +278,9 @@ int cpudl_init(struct cpudl *cp)
for_each_possible_cpu(i)
cp->elements[i].idx = IDX_INVALID;
 
+   /* Mark heap as initially empty. */
+   cp->elements[i].cpu = -1;
+
return 0;
 }
 
-- 
1.9.1



[PATCH v4 1/2] sched/deadline: Add cpudl_maximum_dl() for better readability

2018-06-03 Thread Byungchul Park
Changes from v3
 - Rebase onto the latest tip/sched/core
 - Apply what Joel suggests, to set cp->elements[0].cpu to -1
   when the heap becomes empty in cpudl_clear()

Changes from v2
 - Run spellchecker over the text and fix typos
 - Add acked-by Daniel

Changes from v1
 - Enhance commit msg
 - Prevent WARN in cpumask_test_cpu() in cpudl_find() when best_cpu == -1

-8<-
>From 13efb279e8189e454062854fb1ce2df407543630 Mon Sep 17 00:00:00 2001
From: Byungchul Park 
Date: Mon, 4 Jun 2018 15:12:50 +0900
Subject: [PATCH v4 1/2] sched/deadline: Add cpudl_maximum_dl() for better
 readability

Current code uses cpudl_maximum() to get the root node's cpu, while it
directly accesses the root node to get the root node's dl. It would be
more readable and consistent between them if we provide the same way to
access them. So add a function for dl as we did it for cpu.

Signed-off-by: Byungchul Park 
Acked-by: Steven Rostedt (VMware) 
Acked-by: Daniel Bristot de Oliveira 
---
 kernel/sched/cpudeadline.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c
index 5031645..ae4fbdc 100644
--- a/kernel/sched/cpudeadline.c
+++ b/kernel/sched/cpudeadline.c
@@ -105,11 +105,16 @@ static void cpudl_heapify(struct cpudl *cp, int idx)
cpudl_heapify_down(cp, idx);
 }
 
-static inline int cpudl_maximum(struct cpudl *cp)
+static inline int cpudl_maximum_cpu(struct cpudl *cp)
 {
return cp->elements[0].cpu;
 }
 
+static inline u64 cpudl_maximum_dl(struct cpudl *cp)
+{
+   return cp->elements[0].dl;
+}
+
 /*
  * cpudl_find - find the best (later-dl) CPU in the system
  * @cp: the cpudl max-heap context
@@ -127,12 +132,12 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p,
cpumask_and(later_mask, cp->free_cpus, &p->cpus_allowed)) {
return 1;
} else {
-   int best_cpu = cpudl_maximum(cp);
+   int best_cpu = cpudl_maximum_cpu(cp);
 
WARN_ON(best_cpu != -1 && !cpu_present(best_cpu));
 
if (cpumask_test_cpu(best_cpu, &p->cpus_allowed) &&
-   dl_time_before(dl_se->deadline, cp->elements[0].dl)) {
+   dl_time_before(dl_se->deadline, cpudl_maximum_dl(cp))) {
if (later_mask)
cpumask_set_cpu(best_cpu, later_mask);
 
-- 
1.9.1



Re: [PATCH] mm: kvmalloc does not fallback to vmalloc for incompatible gfp flags

2018-06-03 Thread Michal Hocko
On Sat 02-06-18 09:43:56, Linus Torvalds wrote:
> On Fri, Jun 1, 2018 at 4:53 AM Michal Hocko  wrote:
> >
> > for more context. Linus has pointed out [1] that our (well mine)
> > insisting on GFP_KERNEL compatible gfp flags for kvmalloc* can actually
> > lead to a worse code because people will work around the restriction.
> > So this patch allows kvmalloc to be more permissive and silently skip
> > vmalloc path for incompatible gfp flags.
> 
> Ack.
> 
> > This will not help my original
> > plan to enforce people to think about GFP_NOFS usage more deeply but
> > I can live with that obviously...
> 
> Is it NOFS in particular you care about?

Yes, mostly.

> The only reason for that
> should be the whole "don't recurse", and I think the naming is
> historical and slightly odd.
> 
> It was historically just about allocations that were in the writeout
> path for a block layer or filesystem - and the name made sense in that
> context. These days, I think it's just shorthand for "you can do
> simple direct reclaim from the mm itself, but you can't  block or call
> anything else".

It is still mostly used by fs code these days. There are few exceptions
though. David Chinner mentioned some DRM code which does use NOFS to
prevent recursing into their slab shrinkers.

> So I think the name and the semantics are a bit unclear, but it's
> obviously still useful.

agreed
 
> It's entirely possible that direct reclaim should never do any of the
> more complicated callback cases anyway, but we'd still need the whole
> "don't wait for the complex case" logic to avoid deadlocks.

This is problematic because we can sit on a huge amount of reclaimable
memory and the direct reclaim is the only context to trigger the oom
killer so we have to either find some other way to do the same or invoke
even the complex reclaimers. My long term plan was to convert direct NOFS
users to the scope API (see memalloc_no{fs,io}_{save,restore}) which
would mark "reclaim recursion critical sections" and all allocations
within that scope would not trigger shrinkers that could deadlock. The
current API is quite coarse but there are plans to make it more fine
grained.

Anyway, this is not directly related to this patch. Current kvmalloc
users seem to be GFP_KERNEL compliant. Let's hope it stays that way.
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

2018-06-03 Thread 禹舟键
Hi Mike
> My question was why do you call to alloc_constrained in the dump_header()
>function rather than pass the constraint that was detected a bit earlier to
>that function?

Ok, I will add a  new parameter in the dump_header.

Thank you.


Re: [PATCH V2] cros_ec_keyb: Mark cros_ec_keyb driver as wake enabled device.

2018-06-03 Thread Lee Jones
On Fri, 25 May 2018, Ravi Chandra Sadineni wrote:

> Mark cros_ec_keyb has wake enabled by default. If we see a MKBP event
> related to keyboard,  call pm_wakeup_event() to make sure wakeup
> triggers are accounted to keyb during suspend resume path.
> 
> Signed-off-by: Ravi Chandra Sadineni 
> ---
> V2: Marked the ckdev as wake enabled instead of input devices.
> 
>  drivers/input/keyboard/cros_ec_keyb.c | 21 +

>  drivers/mfd/cros_ec.c | 19 +++

For my own reference:
  Acked-for-MFD-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v7 0/9] Add support for SAMA5D2 touchscreen

2018-06-03 Thread Eugen Hristev




On 22.05.2018 20:57, Jonathan Cameron wrote:

On Tue, 22 May 2018 10:52:30 +0300
Eugen Hristev  wrote:


Hello,

This patch series is a rework of my previous series named:
[PATCH 00/14] iio: triggers: add consumer support

This is the version 7 of the series, and addresses the received feedback
on the v2 series named:
[PATCH v2 00/10]  Add support for SAMA5D2 touchscreen
and the v3 series named
[PATCH v3 00/11]  Add support for SAMA5D2 touchscreen
and the v4 series named
[PATCH v4 0/9]  Add support for SAMA5D2 touchscreen
and fixes one bug found in series named
[PATCH v5 0/9]  Add support for SAMA5D2 touchscreen
and addresses comments in series named
[PATCH v6 0/9]  Add support for SAMA5D2 touchscreen

This series applies on top of fixes-togreg branch of iio.git,
specifically on top of commit:
"f0c8d1f" : iio: adc: at91-sama5d2_adc:
  fix channel configuration for differential channels

Jonathan, if you need me to rebase this on top of testing, let me know.

Changes in previous versions are presented at the end of the cover letter below.
Thanks everyone for the feedback. Below is the original v2 cover letter:

In few words, this is the implementation of splitting the functionality
of the IP block ADC device in SAMA5D2 SoC from ADC with touchscreen
support. In order to avoid having a MFD device, two separate
drivers that would work on same register base and split the IRQ,etc,
as advised on the mailing list, I created a consumer driver for the
channels, that will connect to the ADC as described in the device tree.

I have collected feedback from everyone and here is the result:
I have added a new generic resistive touchscreen driver, which acts
as a iio consumer for the given channels and will create an input
device and report the events. It uses a callback buffer to register
to the IIO device and waits for data to be pushed.
Inside the IIO device, I have kept a similar approach with the first version
of the series, except that now the driver can take multiple buffers, and
will configure the touchscreen part of the hardware device if the specific
channels are requested.

The SAMA5D2 ADC driver registers three new channels: two for the
position on the X and Y axis, and one for the touch pressure.
When channels are requested, it will check if the touchscreen channel mask
includes the requested channels (it is possible that the consumer driver
will not request pressure for example). If it's the case, it will work
in touchscreen mode, and will refuse to do usual analog-digital conversion,
because we have a single trigger and the touchscreen needs it.
When the scan mask will include only old channels, the driver will function
in the same way as before. If the scan mask somehow is a mix of the two (the
masks intersect), the driver will refuse to work whatsoever (cannot have both
in the same time).
The driver allows reading raw data for the new channels, if claim direct
mode works: no touchscreen driver requested anything. The new channels can
act like the old ones. However, when requesting these channels, the usual
trigger will not work and will not be enabled. The touchscreen channels
require special trigger and irq configuration: pen detect, no pen detect
and a periodic trigger to sample the touchscreen position and pressure.
If the user attempts to use another trigger while there is a buffer
that already requested the touchscreen channels (thus the trigger), the
driver will refuse to comply.

In order to have defines for the channel numbers, I added a bindings include
file that goes on a separate commit :
dt-bindings: iio: adc: at91-sama5d2_adc: add channel specific consumer info
This should go in the same tree with the following commits :
   ARM: dts: at91: sama5d2: add channel cells for ADC device
   ARM: dts: at91: sama5d2: Add resistive touch device

as build will break because these commits depend on the binding one
which creates the included header file.
V5 update: After discussing with Alexandre Belloni on Mailing list, the two
DTS patches are to be taken in the next version after bindings reach mainline.

Changes in v7:
  - Addressed some feedback from Dmitry, explained in input driver patch
changelog.
  - Added Acked-by Dmitry.

Changes in v6:
  - Fixed a crash in ADC driver , explained in driver patch changelog.
  - changed a dev_err to dev_dbg in input driver.
  - added Reviewed-by Rob Herring.

Changes in v5:
  - renamed property touchscreen-threshold-pressure to touchscreen-min-pressure
  - added one return in touchscreen driver

Changes in v4:
  - removed patch for inkern module get/set kref
  - addressed feedback on both the ADC and the touchscreen driver. each
patch has a history inside the patch file for the specific changes.
  - patch that fixes the channel fix
[PATCH v3 01/11] iio: adc: at91-sama5d2_adc:
  fix channel configuration for differential channels
was accepted in fixes-togreg branch thus removed from this series.
  - added Reviewed-by for the bindings by Rob Herring

Changes in 

Re: [PATCH 02/33] mfd: omap-usb-host: use match_string() helper

2018-06-03 Thread Lee Jones
On Mon, 21 May 2018, Yisheng Xie wrote:

> match_string() returns the index of an array for a matching string,
> which can be used intead of open coded variant.
> 
> Cc: Tony Lindgren 
> Cc: Lee Jones 
> Cc: linux-o...@vger.kernel.org
> Signed-off-by: Yisheng Xie 
> ---
>  drivers/mfd/omap-usb-host.c | 24 ++--
>  1 file changed, 2 insertions(+), 22 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


linux-next: manual merge of the vfio tree with Linus' tree

2018-06-03 Thread Stephen Rothwell
Hi Alex,

Today's linux-next merge of the vfio tree got a conflict in:

  drivers/vfio/vfio_iommu_type1.c

between commit:

  89c29def6b01 ("Revert "vfio/type1: Improve memory pinning process for raw PFN 
mapping"")

from Linus' tree and commit:

  7b578b0de3d3 ("vfio/type1: Fix task tracking for QEMU vCPU hotplug")

from the vfio tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/vfio/vfio_iommu_type1.c
index 3c082451ab1a,2c71508abdd8..
--- a/drivers/vfio/vfio_iommu_type1.c
+++ b/drivers/vfio/vfio_iommu_type1.c
@@@ -422,8 -434,8 +426,8 @@@ static long vfio_pin_pages_remote(struc
 * Reserved pages aren't counted against the user, externally pinned
 * pages are already counted against the user.
 */
 -  if (!vfio_find_vpfn(dma, iova)) {
 +  if (!rsvd && !vfio_find_vpfn(dma, iova)) {
-   if (!lock_cap && current->mm->locked_vm + 1 > limit) {
+   if (!dma->lock_cap && current->mm->locked_vm + 1 > limit) {
put_pfn(*pfn_base, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n", __func__,
limit << PAGE_SHIFT);
@@@ -448,8 -459,8 +452,8 @@@
break;
}
  
 -  if (!vfio_find_vpfn(dma, iova)) {
 +  if (!rsvd && !vfio_find_vpfn(dma, iova)) {
-   if (!lock_cap &&
+   if (!dma->lock_cap &&
current->mm->locked_vm + lock_acct + 1 > limit) {
put_pfn(pfn, dma->prot);
pr_warn("%s: RLIMIT_MEMLOCK (%ld) exceeded\n",


pgpjdwkWBa7Bq.pgp
Description: OpenPGP digital signature


Re: [PATCH 1/2] mfd: stm32-timers: fix pwm-stm32 linker issue with COMPILE_TEST

2018-06-03 Thread Lee Jones
On Fri, 18 May 2018, Fabrice Gasnier wrote:

> This is seen when COMPILE_TEST=y and MFD_STM32_TIMERS=n.
> drivers/pwm/pwm-stm32.o: In function 'stm32_pwm_raw_capture':
> pwm-stm32.c:... undefined reference to 'stm32_timers_dma_burst_read'
> Fixes: 0c6609805b63 ("mfd: stm32-timers: Add support for DMAs")
> 
> Signed-off-by: Fabrice Gasnier 
> ---
>  include/linux/mfd/stm32-timers.h | 12 
>  1 file changed, 12 insertions(+)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 2/2] pwm: stm32: initialize raw local variables

2018-06-03 Thread Lee Jones
On Fri, 18 May 2018, Fabrice Gasnier wrote:

> This removes build warning when COMPILE_TEST=y and MFD_STM32_TIMERS=n
> in drivers/pwm/pwm-stm32.c. In function 'stm32_pwm_capture' 'raw_prd' and
> 'raw_dty' may be used uninitialized in this function
> [-Wmaybe-uninitialized]
> 
> Signed-off-by: Fabrice Gasnier 
> ---
>  drivers/pwm/pwm-stm32.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [RESEND PATCH v5] mfd: arizona: Update DT doc to support more standard reset binding

2018-06-03 Thread Lee Jones
On Wed, 09 May 2018, Charles Keepax wrote:

> Signed-off-by: Charles Keepax 
> Reviewed-by: Rob Herring 
> Acked-by: Lee Jones 
> ---
>  Documentation/devicetree/bindings/mfd/arizona.txt | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [RESEND PATCH v5 2/6] mfd: stm32-timers: add support for dmas

2018-06-03 Thread Lee Jones
On Wed, 16 May 2018, Fabrice Gasnier wrote:

> STM32 Timers can support up to 7 DMA requests:
> - 4 channels, update, compare and trigger.
> Optionally request part, or all DMAs from stm32-timers MFD core.
> 
> Also add routine to implement burst reads using DMA from timer registers.
> This is exported. So, it can be used by child drivers, PWM capture
> for instance (but not limited to).
> 
> Signed-off-by: Fabrice Gasnier 
> Reviewed-by: Benjamin Gaignard 
> ---
> Changes in v5:
> - fix warning on dma_mapping_error() that doesn't return an error code.
> - move stm32_timers_dma struct to header file as discussed with Lee.
>   This allows to remove alloc for this struct in stm32_timers_dma_probe.
> 
> Changes in v4:
> - Lee's comments: Add kerneldoc header, better format comments.
> 
> Changes in v3:
> - Basically Lee's comments:
> - rather create a struct stm32_timers_dma, and place a reference to it
>   in existing ddata (instead of adding priv struct).
> - rather use a struct device in exported routine prototype, and use
>   standard helpers instead of ddata. Get rid of to_stm32_timers_priv().
> - simplify error handling in probe (remove a goto)
> - comment on devm_of_platform_*populate() usage.
> 
> Changes in v2:
> - Abstract DMA handling from child driver: move it to MFD core
> - Add comments on optional dma support
> ---
>  drivers/mfd/stm32-timers.c   | 201 
> ++-
>  include/linux/mfd/stm32-timers.h |  46 +
>  2 files changed, 245 insertions(+), 2 deletions(-)

For my own reference:
  Acked-for-MFD-by: Lee Jones 

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 1/3] dt-bindings: thermal: Add binding document for SR thermal

2018-06-03 Thread Srinath Mannam
Hi Rob Herring,

Please find my comments in line..

On Fri, Jun 1, 2018 at 7:59 PM, Rob Herring  wrote:
> On Fri, Jun 1, 2018 at 3:51 AM, Srinath Mannam
>  wrote:
>> Hi Rob Herring,
>>
>> Thank you for the review.
>> Please find my answers inline..
>>
>> On Thu, May 31, 2018 at 10:18 PM, Rob Herring  wrote:
>>> On Mon, May 28, 2018 at 11:11:22AM +0530, Srinath Mannam wrote:
 From: Pramod Kumar 

 Add binding document for supported thermal implementation
 in Stingray.

 Signed-off-by: Pramod Kumar 
 Reviewed-by: Ray Jui 
 Reviewed-by: Scott Branden 
 Reviewed-by: Srinath Mannam 
 ---
  .../bindings/thermal/brcm,sr-thermal.txt   | 45 
 ++
  1 file changed, 45 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt

 diff --git a/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt 
 b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
 new file mode 100644
 index 000..33f9e11
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt
 @@ -0,0 +1,45 @@
 +* Broadcom Stingray Thermal
 +
 +This binding describes thermal sensors that is part of Stingray SoCs.
 +
 +Required properties:
 +- compatible : Must be "brcm,sr-thermal"
 +- reg : memory where tmon data will be available.
>>>
>>> What type of memory is this?
>> This is shared memory(cache-able) which is shared between two micro 
>> controllers.
>
> What else is in this shared memory? You should probably be
> representing that as a whole somewhere in DT.
Nothing else except 4 byte memory containing temperature value of one
thermal zone.
At present we configured 6 thermal zones. So six separate 4byte
memories provided in
shared memory.
>
>> One micro controller update temperature of all thermal zones in this
>> shared memory.
>> thermal driver running on another micro controller monitors
>> temperature data of all thermal zones.
>>>
 +
 +Example:
 + tmons {
 + compatible = "simple-bus";
 + #address-cells = <1>;
 + #size-cells = <1>;
 + ranges;
 +
 + tmon_ihost0: thermal@8f10 {
 + compatible = "brcm,sr-thermal";
 + reg = <0x8f10 0x4>;
 + };
>>>
>>> Convince me that you need a node per register. This can all be
>>> accomplished with a single node and either a single reg entry or a
>>> series of reg entries.
>>>
>> In our system we have 6 different thermal zones. each node belongs to
>> one thermal zone.
>> thermal driver detects each node as separate thermal zone and monitors
>> separately.
>> register entry is only 4byte memory which contains the temperature
>> value of respective thermal zone.
>> Based on requirement we can increase or decrease the number thermal
>> zones need to monitor.
>
> Still, all this can be accomplished with a single node. Having a node
> per register in DT doesn't scale.
Our approach is like we have individual controllers have one driver
with multiple DT nodes.
In coming future we will add more thermal zones based on our
requirement. then we can just
add new DT node, instead of having driver changes.
With this approach we can configure each thermal zone at different trip values.
So we must have all thermal zones are independent.
>
> Rob


Re: [PATCH v12 0/5] Fix issues with huge mapping in ioremap for ARM64

2018-06-03 Thread Chintan Pandya

Hi Will,

Just curious to know, is there anything that I should be addressing
in these patches ? For now, I don't see anything from my side that
requires modification, unless one has some more review comments on
this.

Status so far on and around this:
 - Status of Toshi's series of patches is still not clear to me.
   However, if this series can get through first, there won't
   be conflicting scenarios as far as arm64 is concerned.
 - I've rebased these patches on tip
 - Also re-tested these patches for long duration tests with
   1 GB mapping case also exercised enough. Test ended positively.

Thanks,

On 6/1/2018 6:09 PM, Chintan Pandya wrote:

This series of patches re-bring huge vmap back for arm64.

Patch 1/4 has been taken by Toshi in his series of patches
by name "[PATCH v3 0/3] fix free pmd/pte page handlings on x86"
to avoid merge conflict with this series.

These patches are tested on 4.16 kernel with Cortex-A75 based SoC.

The test used for verifying these patches is a stress test on
ioremap/unmap which tries to re-use same io-address but changes
size of mapping randomly i.e. 4K to 2M to 1G etc. The same test
used to reproduce 3rd level translation fault without these fixes
(and also of course with Revert "arm64: Enforce BBM for huge IO/VMAP
mappings" being part of the tree).

These patches can also go into '-stable' branch (if accepted)
for 4.6 onwards.

 From V11->V12:
  - Introduced p*d_page_vaddr helper macros and using them
  - Rebased over current tip

 From V10->V11:
  - Updated pud_free_pmd_page & pmd_free_pte_page to use consistent
conding style
  - Fixed few bugs by using pmd_page_paddr & pud_page_paddr

 From V9->V10:
  - Updated commit log for patch 1/4 by Toshi
  - Addressed review comments by Will on patch 3/4

 From V8->V9:
  - Used __TLBI_VADDR macros in new TLB flush API

 From V7->V8:
  - Properly fixed compilation issue in x86 file

 From V6->V7:
  - Fixed compilation issue in x86 case
  - V6 patches were not properly enumarated

 From V5->V6:
  - Use __flush_tlb_kernel_pgtable() for both PUD and PMD. Remove
"bool tlb_inv" based variance as it is not need now
  - Re-naming for consistency

 From V4->V5:
  - Add new API __flush_tlb_kernel_pgtable(unsigned long addr)
for kernel addresses

 From V3->V4:
  - Add header for 'addr' in x86 implementation
  - Re-order pmd/pud clear and table free
  - Avoid redundant TLB invalidatation in one perticular case

 From V2->V3:
  - Use the exisiting page table free interface to do arm64
specific things

 From V1->V2:
  - Rebased my patches on top of "[PATCH v2 1/2] mm/vmalloc:
Add interfaces to free unmapped page table"
  - Honored BBM for ARM64

Chintan Pandya (5):
   ioremap: Update pgtable free interfaces with addr
   arm64: tlbflush: Introduce __flush_tlb_kernel_pgtable
   arm64: pgtable: Add p*d_page_vaddr helper macros
   arm64: Implement page table free interfaces
   arm64: Re-enable huge io mappings

  arch/arm64/include/asm/pgtable.h  |  3 +++
  arch/arm64/include/asm/tlbflush.h |  7 +
  arch/arm64/mm/mmu.c   | 56 +--
  arch/x86/mm/pgtable.c |  8 +++---
  include/asm-generic/pgtable.h |  8 +++---
  lib/ioremap.c |  4 +--
  6 files changed, 57 insertions(+), 29 deletions(-)



Chintan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center,
Inc. is a member of the Code Aurora Forum, a Linux Foundation
Collaborative Project


[lkp-robot] [mm, oom] 2d251ff6e6: BUG:unable_to_handle_kernel

2018-06-03 Thread kernel test robot

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

commit: 2d251ff6e66d7978b3e7a9c69e99b7150de26926 ("mm, oom: fix unnecessary 
killing of additional processes")
url: 
https://github.com/0day-ci/linux/commits/David-Rientjes/mm-oom-fix-unnecessary-killing-of-additional-processes/20180527-033815
base: git://git.cmpxchg.org/linux-mmotm.git master

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap -m 360M

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


+--+++
|  | 0b018d19da 
| 2d251ff6e6 |
+--+++
| boot_successes   | 4  
| 0  |
| boot_failures| 4  
| 4  |
| invoked_oom-killer:gfp_mask=0x   | 4  
| 2  |
| Mem-Info | 4  
| 4  |
| Out_of_memory:Kill_process   | 4  
| 4  |
| Kernel_panic-not_syncing:Out_of_memory_and_no_killable_processes | 4  
||
| BUG:unable_to_handle_kernel  | 0  
| 4  |
| Oops:#[##]   | 0  
| 4  |
| EIP:oom_reaper   | 0  
| 4  |
| Kernel_panic-not_syncing:Fatal_exception | 0  
| 4  |
+--+++



[   11.063029] BUG: unable to handle kernel NULL pointer dereference at 0204
[   11.064104] *pde =  
[   11.064548] Oops:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[   11.065328] CPU: 0 PID: 21 Comm: oom_reaper Not tainted 
4.17.0-rc5-mm1-00218-g2d251ff #1
[   11.066537] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   11.067786] EIP: oom_reaper+0x115/0x296
[   11.068374] Code: 01 00 00 bb 54 92 65 7e c7 05 ac a8 65 7e 00 02 00 00 b8 
80 a8 65 7e e8 9c a2 63 00 85 db 0f 84 fa fe ff ff 8b 83 ac 04 00 00 <8b> b0 04 
02 00 00 8b 86 c8 02 00 00 0f ba e0 15 0f 82 55 01 00 00 
[   11.071210] EAX:  EBX: 7e659254 ECX: 0001 EDX: 
[   11.072142] ESI: 78090960 EDI: 7816b500 EBP: 78167f8c ESP: 78167f68
[   11.073073] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010202
[   11.074075] CR0: 80050033 CR2: 0204 CR3: 033d7000 CR4: 00040690
[   11.074994] Call Trace:
[   11.075380]  ? wait_woken+0x75/0x75
[   11.075911]  ? kthread+0xef/0xf4
[   11.076413]  ? __oom_reap_task_mm+0x6f/0x6f
[   11.077036]  ? kthread_create_on_node+0x1a/0x1a
[   11.077718]  ? ret_from_fork+0x19/0x24
[   11.078286] Modules linked in:
[   11.078747] CR2: 0204
[   11.079253] ---[ end trace 881b7ebfce401a98 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.17.0-rc5-mm1 Kernel Configuration
#
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_X86_32_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=2
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL

Re: [PATCH v2 5/6] ARM: dts: Add generic interconnect target module node for MCAN

2018-06-03 Thread Faiz Abbas
Hi,

On Saturday 02 June 2018 12:02 PM, Stephen Boyd wrote:
> Quoting Faiz Abbas (2018-05-30 07:11:32)
>> diff --git a/arch/arm/boot/dts/dra76x.dtsi b/arch/arm/boot/dts/dra76x.dtsi
>> index bfc82636999c..57b8dc0fe719 100644
>> --- a/arch/arm/boot/dts/dra76x.dtsi
>> +++ b/arch/arm/boot/dts/dra76x.dtsi
>> @@ -11,6 +11,25 @@
>>  / {
>> compatible = "ti,dra762", "ti,dra7";
>>  
>> +   ocp {
>> +
>> +   target-module@0x42c0 {
> 
> Drop the 0x on unit address. Also, it should match the first register
> property. And what is a "target-module"?
> 

Will fix it. And please see
Documentation/devicetree/bindings/bus/ti-sysc.txt


Thanks,
Faiz


[PATCH] panic: move bust_spinlocks(0) after console_flush_on_panic() to avoid deadlocks

2018-06-03 Thread Hoeun Ryu
From: Hoeun Ryu 

 Many console device drivers hold the uart_port->lock spinlock with irq enabled
(using spin_lock()) while the device drivers are writing characters to their 
devices,
but the device drivers just try to hold the spin lock (using spin_trylock()) if
"oops_in_progress" is equal or greater than 1 to avoid deadlocks.

 There is a case ocurring a deadlock related to the lock and oops_in_progress. 
A CPU
could be stopped by smp_send_stop() while it was holding the port lock because 
irq was
enabled. Once a CPU stops, it doesn't respond interrupts anymore and the lock 
stays
locked forever.

 console_flush_on_panic() is called during panic() and it eventually holds the 
uart
lock but the lock is held by another stopped CPU and it is a deadlock. By moving
bust_spinlocks(0) after console_flush_on_panic(), let the console device drivers
think the Oops is still in progress to call spin_trylock() instead of 
spin_lock() to
avoid the deadlock.

Signed-off-by: Hoeun Ryu 
---
 kernel/panic.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index 42e4874..b4063b6 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -233,8 +233,6 @@ void panic(const char *fmt, ...)
if (_crash_kexec_post_notifiers)
__crash_kexec(NULL);
 
-   bust_spinlocks(0);
-
/*
 * We may have ended up stopping the CPU holding the lock (in
 * smp_send_stop()) while still having some valuable data in the console
@@ -246,6 +244,8 @@ void panic(const char *fmt, ...)
debug_locks_off();
console_flush_on_panic();
 
+   bust_spinlocks(0);
+
if (!panic_blink)
panic_blink = no_blink;
 
-- 
2.1.4



Re: [PATCH] mfd: arizona: Don't use regmap_read_poll_timeout

2018-06-03 Thread Lee Jones
On Fri, 11 May 2018, Charles Keepax wrote:

> Some Arizona CODECs have a small timing window where they will
> NAK an I2C transaction if it happens before the boot done bit is
> set. This can cause the read of the register containing the boot
> done bit to fail until it is set. Since regmap_read_poll_timeout
> will abort polling if a read fails it can't be reliably used to
> poll the boot done bit over I2C.
> 
> Do a partial revert of ef84f885e037 ("mfd: arizona: Refactor
> arizona_poll_reg"), removing the regmap_read_poll_timeout but
> leaving the refactoring to make the arizona_poll_reg take more
> sensible arguments.
> 
> Fixes: ef84f885e037 ("mfd: arizona: Refactor arizona_poll_reg")
> Signed-off-by: Charles Keepax 
> ---
>  drivers/mfd/arizona-core.c | 29 +
>  1 file changed, 21 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/mfd/arizona-core.c b/drivers/mfd/arizona-core.c
> index 83f1c5a516d9..2ed29ce08dac 100644
> --- a/drivers/mfd/arizona-core.c
> +++ b/drivers/mfd/arizona-core.c
> @@ -240,18 +240,31 @@ static int arizona_poll_reg(struct arizona *arizona,
>   int timeout_ms, unsigned int reg,
>   unsigned int mask, unsigned int target)
>  {
> + ktime_t timeout = ktime_add_us(ktime_get(), timeout_ms * 1000);

USEC_PER_MSEC ?

>   unsigned int val = 0;
>   int ret;
>  
> - ret = regmap_read_poll_timeout(arizona->regmap,
> -reg, val, ((val & mask) == target),
> -ARIZONA_REG_POLL_DELAY_US,
> -timeout_ms * 1000);
> - if (ret)
> - dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n",
> - reg, val);
> + while (true) {
> + ret = regmap_read(arizona->regmap, reg, &val);
>  
> - return ret;
> + if ((val & mask) == target)
> + return 0;
> +
> + if (ktime_compare(ktime_get(), timeout) > 0)
> + break;
> +
> + usleep_range(ARIZONA_REG_POLL_DELAY_US / 2,
> +  ARIZONA_REG_POLL_DELAY_US);
> + }
> +
> + if (ret) {
> + dev_err(arizona->dev, "Failed polling reg 0x%x: %d\n",
> + reg, ret);
> + return ret;
> + }
> +
> + dev_err(arizona->dev, "Polling reg 0x%x timed out: %x\n", reg, val);
> + return -ETIMEDOUT;
>  }
>  
>  static int arizona_wait_for_boot(struct arizona *arizona)

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH] clk-si514, clk-si544: Implement prepare/unprepare/is_prepared operations

2018-06-03 Thread Mike Looijmans
This adds prepare/unprepare/is_prepared functionality to the drivers for
the SI544 and SI514 chips, allowing the clock output to be disabled when
the clock is not in use.

Signed-off-by: Mike Looijmans 
---
 drivers/clk/clk-si514.c | 38 +-
 drivers/clk/clk-si544.c | 39 ++-
 2 files changed, 75 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-si514.c b/drivers/clk/clk-si514.c
index 09b6718..153b3a2 100644
--- a/drivers/clk/clk-si514.c
+++ b/drivers/clk/clk-si514.c
@@ -74,6 +74,33 @@ static int si514_enable_output(struct clk_si514 *data, bool 
enable)
SI514_CONTROL_OE, enable ? SI514_CONTROL_OE : 0);
 }
 
+static int si514_prepare(struct clk_hw *hw)
+{
+   struct clk_si514 *data = to_clk_si514(hw);
+
+   return si514_enable_output(data, true);
+}
+
+static void si514_unprepare(struct clk_hw *hw)
+{
+   struct clk_si514 *data = to_clk_si514(hw);
+
+   si514_enable_output(data, false);
+}
+
+static int si514_is_prepared(struct clk_hw *hw)
+{
+   struct clk_si514 *data = to_clk_si514(hw);
+   unsigned int val;
+   int err;
+
+   err = regmap_read(data->regmap, SI514_REG_CONTROL, &val);
+   if (err < 0)
+   return err;
+
+   return !!(val & SI514_CONTROL_OE);
+}
+
 /* Retrieve clock multiplier and dividers from hardware */
 static int si514_get_muldiv(struct clk_si514 *data,
struct clk_si514_muldiv *settings)
@@ -235,12 +262,17 @@ static int si514_set_rate(struct clk_hw *hw, unsigned 
long rate,
 {
struct clk_si514 *data = to_clk_si514(hw);
struct clk_si514_muldiv settings;
+   unsigned int old_oe_state;
int err;
 
err = si514_calc_muldiv(&settings, rate);
if (err)
return err;
 
+   err = regmap_read(data->regmap, SI514_REG_CONTROL, &old_oe_state);
+   if (err)
+   return err;
+
si514_enable_output(data, false);
 
err = si514_set_muldiv(data, &settings);
@@ -255,12 +287,16 @@ static int si514_set_rate(struct clk_hw *hw, unsigned 
long rate,
/* Applying a new frequency can take up to 10ms */
usleep_range(1, 12000);
 
-   si514_enable_output(data, true);
+   if (old_oe_state & SI514_CONTROL_OE)
+   si514_enable_output(data, true);
 
return err;
 }
 
 static const struct clk_ops si514_clk_ops = {
+   .prepare = si514_prepare,
+   .unprepare = si514_unprepare,
+   .is_prepared = si514_is_prepared,
.recalc_rate = si514_recalc_rate,
.round_rate = si514_round_rate,
.set_rate = si514_set_rate,
diff --git a/drivers/clk/clk-si544.c b/drivers/clk/clk-si544.c
index e972ffb..f8ed9d9 100644
--- a/drivers/clk/clk-si544.c
+++ b/drivers/clk/clk-si544.c
@@ -86,6 +86,34 @@ static int si544_enable_output(struct clk_si544 *data, bool 
enable)
SI544_OE_STATE_ODC_OE, enable ? SI544_OE_STATE_ODC_OE : 0);
 }
 
+static int si544_prepare(struct clk_hw *hw)
+{
+   struct clk_si544 *data = to_clk_si544(hw);
+
+   return si544_enable_output(data, true);
+}
+
+static void si544_unprepare(struct clk_hw *hw)
+{
+   struct clk_si544 *data = to_clk_si544(hw);
+
+   si544_enable_output(data, false);
+}
+
+static int si544_is_prepared(struct clk_hw *hw)
+{
+   struct clk_si544 *data = to_clk_si544(hw);
+   unsigned int val;
+   int err;
+
+   err = regmap_read(data->regmap, SI544_REG_OE_STATE, &val);
+   if (err < 0)
+   return err;
+
+   return !!(val & SI544_OE_STATE_ODC_OE);
+}
+
+
 /* Retrieve clock multiplier and dividers from hardware */
 static int si544_get_muldiv(struct clk_si544 *data,
struct clk_si544_muldiv *settings)
@@ -273,6 +301,7 @@ static int si544_set_rate(struct clk_hw *hw, unsigned long 
rate,
 {
struct clk_si544 *data = to_clk_si544(hw);
struct clk_si544_muldiv settings;
+   unsigned int old_oe_state;
int err;
 
if (!is_valid_frequency(data, rate))
@@ -282,6 +311,10 @@ static int si544_set_rate(struct clk_hw *hw, unsigned long 
rate,
if (err)
return err;
 
+   err = regmap_read(data->regmap, SI544_REG_OE_STATE, &old_oe_state);
+   if (err)
+   return err;
+
si544_enable_output(data, false);
 
/* Allow FCAL for this frequency update */
@@ -303,12 +336,16 @@ static int si544_set_rate(struct clk_hw *hw, unsigned 
long rate,
/* Applying a new frequency can take up to 10ms */
usleep_range(1, 12000);
 
-   si544_enable_output(data, true);
+   if (old_oe_state & SI544_OE_STATE_ODC_OE)
+   si544_enable_output(data, true);
 
return err;
 }
 
 static const struct clk_ops si544_clk_ops = {
+   .prepare = si544_prepare,
+   .unprepare = si544_unprepare,
+   .is_prepared = si544_is_prepared,
.recalc_rate = si544_recalc_rate,
.round_rate = si544_round_rate,
   

Re: [PATCH v1] mfd: intel-lpss: Program REMAP register in PIO mode

2018-06-03 Thread Lee Jones
On Fri, 01 Jun 2018, Andy Shevchenko wrote:

> On Fri, 2018-05-18 at 14:51 +0100, Lee Jones wrote:
> > On Tue, 24 Apr 2018, Andy Shevchenko wrote:
> > 
> > > According to documentation REMAP register has to be programmed in
> > > either DMA or PIO mode of the slice.
> > > 
> > > Move the DMA capability check below to let REMAP register be
> > > programmed
> > > in PIO mode.
> > > 
> > > Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS
> > > devices")
> > > Cc: Mika Westerberg 
> > > Signed-off-by: Andy Shevchenko 
> > > ---
> > >  drivers/mfd/intel-lpss.c | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > Applied and tagged for -stable # 4.3+
> 
> Thanks!
> 
> Though can not see it in Linus' tree still.

Why would it be in Linus' tree?

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v1] mfd: intel-lpss: Correct names of RESETS register bits

2018-06-03 Thread Lee Jones
On Tue, 24 Apr 2018, Andy Shevchenko wrote:

> According to documentation the function has 2 bits for reset
> while iDMA 64-bit has only one.
> 
> Rename it accordingly. Note, there is no functional change since
> we always handle them together.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/mfd/intel-lpss.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


BUG: soft lockup in shrink_dcache_parent (2)

2018-06-03 Thread syzbot

Hello,

syzbot found the following crash on:

HEAD commit:325e14f97e0c Merge branch 'fixes' of git://git.kernel.org/..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=166329d780
kernel config:  https://syzkaller.appspot.com/x/.config?x=968b0b23c7854c0b
dashboard link: https://syzkaller.appspot.com/bug?extid=be3179e6006280aaf174
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)

Unfortunately, I don't have any reproducer for this crash yet.

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+be3179e6006280aaf...@syzkaller.appspotmail.com

watchdog: BUG: soft lockup - CPU#1 stuck for 134s! [syz-executor4:4588]
Modules linked in:
irq event stamp: 76609500
hardirqs last  enabled at (76609499): []  
seqcount_lockdep_reader_access include/linux/seqlock.h:83 [inline]
hardirqs last  enabled at (76609499): []  
read_seqcount_begin include/linux/seqlock.h:164 [inline]
hardirqs last  enabled at (76609499): [] read_seqbegin  
include/linux/seqlock.h:433 [inline]
hardirqs last  enabled at (76609499): []  
read_seqbegin_or_lock include/linux/seqlock.h:529 [inline]
hardirqs last  enabled at (76609499): []  
d_walk+0x80f/0xc80 fs/dcache.c:1248
hardirqs last disabled at (76609500): []  
interrupt_entry+0xb5/0xf0 arch/x86/entry/entry_64.S:625
softirqs last  enabled at (468244): []  
__do_softirq+0x778/0xaf5 kernel/softirq.c:311
softirqs last disabled at (468177): [] invoke_softirq  
kernel/softirq.c:365 [inline]
softirqs last disabled at (468177): []  
irq_exit+0x1d1/0x200 kernel/softirq.c:405

CPU: 1 PID: 4588 Comm: syz-executor4 Not tainted 4.17.0-rc7+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011
RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783  
[inline]

RIP: 0010:seqcount_lockdep_reader_access include/linux/seqlock.h:83 [inline]
RIP: 0010:read_seqcount_begin include/linux/seqlock.h:164 [inline]
RIP: 0010:read_seqbegin include/linux/seqlock.h:433 [inline]
RIP: 0010:read_seqbegin_or_lock include/linux/seqlock.h:529 [inline]
RIP: 0010:d_walk+0x840/0xc80 fs/dcache.c:1248
RSP: 0018:880183f5f9f8 EFLAGS: 0293 ORIG_RAX: ff13
RAX: 8801b0d3c680 RBX: 0293 RCX: 1100361a79e5
RDX:  RSI: 81c66cfb RDI: 0293
RBP: 880183f5fb78 R08: 8801b0d3ceb8 R09: 0006
R10: 8801b0d3c680 R11:  R12: 0200
R13: dc00 R14: 1100307ebf82 R15: 880183f5fb50
FS:  0217c940() GS:8801daf0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffca8309eac CR3: 000183eb2000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486
 vfs_rmdir+0x202/0x470 fs/namei.c:3855
 do_rmdir+0x523/0x610 fs/namei.c:3916
 __do_sys_rmdir fs/namei.c:3934 [inline]
 __se_sys_rmdir fs/namei.c:3932 [inline]
 __x64_sys_rmdir+0x36/0x40 fs/namei.c:3932
 do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x455777
RSP: 002b:7ffca830a5b8 EFLAGS: 0206 ORIG_RAX: 0054
RAX: ffda RBX: 0065 RCX: 00455777
RDX:  RSI: 7ffca830c360 RDI: 7ffca830c360
RBP: 7ffca830c360 R08:  R09: 0001
R10: 0006 R11: 0206 R12: 0217d940
R13:  R14: 0198 R15: 0001f12d
Code: 88 48 89 f8 48 c1 e8 03 42 80 3c 28 00 0f 85 1e 04 00 00 48 83 3d 78  
20 0b 07 00 0f 84 29 02 00 00 e8 e5 d7 b2 ff 48 89 df 57 9d <0f> 1f 44 00  
00 e8 d6 d7 b2 ff 49 8d 5f 80 48 c1 eb 03 4c 01 eb

Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 4581 Comm: syz-executor6 Not tainted 4.17.0-rc7+ #81
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

RIP: 0010:select_collect+0x249/0x5f0 fs/dcache.c:1443
RSP: 0018:880189947908 EFLAGS: 0286
RAX:  RBX: ed0031328f24 RCX: 81c5c3b4
RDX:  RSI: 81c5c4fa RDI: 880189947c28
RBP: 8801899479e8 R08: 88018993e5c0 R09: ed0039dde7a4
R10: ed0039dde7a4 R11: 8801ceef3d23 R12: 
R13: 110031328f28 R14: 880189947c18 R15: dc00
FS:  01790940() GS:8801dae0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 7ffebea69e9c CR3: 00018989f000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 d_walk+0x3c3/0xc80 fs/dcache.c:1276
 shrink_dcache_parent+0x179/0x230 fs/dcache.c:1486
 vfs_rmdir+0x202/0x470 fs/namei.c:3855
 do_rmdir+0x523/0x610 fs

Re: [PATCH v2] kernel: event: core: Change return type to vm_fault_t

2018-06-03 Thread Souptick Joarder
On Mon, May 21, 2018 at 11:55 PM, Souptick Joarder  wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit 1c8f422059ae ("mm: change return type to vm_fault_t")
>
> Signed-off-by: Souptick Joarder 
> Acked-by: Peter Zijlstra (Intel) 
> Reviewed-by: Matthew Wilcox 
> ---
> v2: Updated the change log.
> Acked by Peter Zijlstra.
>
>  kernel/events/core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 96db9ae..d09f1c4 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -4918,11 +4918,11 @@ void perf_event_update_userpage(struct perf_event 
> *event)
>  }
>  EXPORT_SYMBOL_GPL(perf_event_update_userpage);
>
> -static int perf_mmap_fault(struct vm_fault *vmf)
> +static vm_fault_t perf_mmap_fault(struct vm_fault *vmf)
>  {
> struct perf_event *event = vmf->vma->vm_file->private_data;
> struct ring_buffer *rb;
> -   int ret = VM_FAULT_SIGBUS;
> +   vm_fault_t ret = VM_FAULT_SIGBUS;
>
> if (vmf->flags & FAULT_FLAG_MKWRITE) {
> if (vmf->pgoff == 0)
> --
> 1.9.1
>

Any further comment on this patch ?


Testing RCU boosting with rcutorture

2018-06-03 Thread Joel Fernandes
Hi Paul,

I was testing RCU boosting behavior with rcutorture on rcu/dev and I had some
issues getting it to fail when no RCU boost is done (CONFIG_RCU_BOOST is
disabled and rcutorture is forced to test it using test_boost parameter).

It appears I need to disable RT throttling so that the readers can get
starved by the RT thread. I also noticed some problems in rcutorture where we
are not checking for failure correctly. Below is an RFC patch fixing these
issues, could you let me know your thoughts about it? Thanks a lot,

 - Joel

---8<---

From: "Joel Fernandes (Google)" 
Date: Sun, 3 Jun 2018 21:30:26 -0700
Subject: [RFC] rcutorture: Make boost test more robust

Currently, with RCU_BOOST disabled, I get no failures when forcing
rcutorture to test RCU boost priority inversion. The reason seems to be
that we don't check for failures if the callback never ran at all for
the duration of the boost-test loop.

Further, the 'rtb' and 'rtbf' counters seem to be used inconsistently.
'rtb' is incremented at the start of each test and 'rtbf' is incremented
per-cpu on each failure of call_rcu. So its possible 'rtbf' > 'rtb'.

To test the boost with rcutorture, I did following on a 4-CPU x86 machine:

# Disable RT throttling
echo 100 > /proc/sys/kernel/sched_rt_period_us
echo 100 > /proc/sys/kernel/sched_rt_runtime_us

modprobe rcutorture  test_boost=2
sleep 20
rmmod rcutorture

With patch:
rtbf: 8 rtb: 12

Without patch:
rtbf: 0 rtb: 2

In summary this patch:
 - Increments failed and total test counters once per boost-test.
 - Checks for failure cases correctly.

Signed-off-by: Joel Fernandes (Google) 
---
 kernel/rcu/rcutorture.c | 45 +++--
 1 file changed, 39 insertions(+), 6 deletions(-)

diff --git a/kernel/rcu/rcutorture.c b/kernel/rcu/rcutorture.c
index 773d6f1b4abf..1d26f9c27d36 100644
--- a/kernel/rcu/rcutorture.c
+++ b/kernel/rcu/rcutorture.c
@@ -769,6 +769,18 @@ static void rcu_torture_boost_cb(struct rcu_head *head)
smp_store_release(&rbip->inflight, 0);
 }
 
+static bool rcu_torture_boost_failed(unsigned long start, unsigned long end)
+{
+   if (end - start > test_boost_duration * HZ - HZ / 2) {
+   VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
+   n_rcu_torture_boost_failure++;
+
+   return true; /* failed */
+   }
+
+   return false; /* passed */
+}
+
 static int rcu_torture_boost(void *arg)
 {
unsigned long call_rcu_time;
@@ -789,6 +801,21 @@ static int rcu_torture_boost(void *arg)
init_rcu_head_on_stack(&rbi.rcu);
/* Each pass through the following loop does one boost-test cycle. */
do {
+   /* Track if the test failed already in this test interval? */
+   bool failed = false;
+
+   /* Increment n_rcu_torture_boosts once per boost-test */
+   while (!kthread_should_stop()) {
+   if (mutex_trylock(&boost_mutex)) {
+   n_rcu_torture_boosts++;
+   mutex_unlock(&boost_mutex);
+   break;
+   }
+   schedule_timeout_uninterruptible(1);
+   }
+   if (kthread_should_stop())
+   goto checkwait;
+
/* Wait for the next test interval. */
oldstarttime = boost_starttime;
while (ULONG_CMP_LT(jiffies, oldstarttime)) {
@@ -807,11 +834,10 @@ static int rcu_torture_boost(void *arg)
/* RCU core before ->inflight = 1. */
smp_store_release(&rbi.inflight, 1);
call_rcu(&rbi.rcu, rcu_torture_boost_cb);
-   if (jiffies - call_rcu_time >
-test_boost_duration * HZ - HZ / 2) {
-   
VERBOSE_TOROUT_STRING("rcu_torture_boost boosting failed");
-   n_rcu_torture_boost_failure++;
-   }
+   /* Check if the boost test failed */
+   failed = failed ||
+rcu_torture_boost_failed(call_rcu_time,
+jiffies);
call_rcu_time = jiffies;
}
stutter_wait("rcu_torture_boost");
@@ -819,6 +845,14 @@ static int rcu_torture_boost(void *arg)
goto checkwait;
}
 
+   /*
+* If boost never happened, then inflight will always be 1, in
+* this case the boost check would never happen in the above
+* loop so do another one here.
+*/
+   if (!failed && smp_load_acquire(&rbi.inflight))
+ 

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

2018-06-03 Thread Mike Rapoport
On Mon, Jun 04, 2018 at 10:41:10AM +0800, 禹舟键 wrote:
> Hi Tetsuo
> > Since origin_memcg_name is printed for both memcg OOM and !memcg OOM, it is 
> > strange that origin_memcg_name is updated only when memcg != NULL. Have you 
> > really tested !memcg OOM case?
> 
> if memcg == NULL , origin_memcg_name will also be NULL, so the length
> of it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM
> case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong.
> 
> Thanks
> Wind
> 禹舟键  于2018年6月4日周一 上午9:58写道:
> >
> > Hi Mike
> > > Please keep the brief description of the function actually brief and move 
> > > the detailed explanation after the parameters description.
> > Thanks for your advice.
> >
> > > The allocation constraint is detected by the dump_header() callers, why 
> > > not just use it here?
> > David suggest that constraint need to be printed in the oom report, so
> > I add the enum variable in this function.

My question was why do you call to alloc_constrained in the dump_header()
function rather than pass the constraint that was detected a bit earlier to
that function? 

Sorry if wasn't clear enough.

> > Thanks
> > Wind
> 

-- 
Sincerely yours,
Mike.



[GIT PULL] rslib updates for v4.18-rc1

2018-06-03 Thread Kees Cook
Hi Linus,

Please pull these rslib changes for v4.18-rc1. Thomas asked me to carry
this series since I've been coordinating VLA removal, and he's got enough
trees to worry about. :) This has been in -next for a while now.

Thanks!

-Kees

The following changes since commit 6d08b06e67cd117f6992c46611dfb4ce267cd71e:

  Linux 4.17-rc2 (2018-04-22 19:20:09 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git 
tags/rslib-v4.18-rc1

for you to fetch changes up to 45888b40d2a6221d46bb69959e2600ddba71cc1f:

  rslib: Allocate decoder buffers to avoid VLAs (2018-04-24 19:50:10 -0700)


Refactors rslib and callers to provide a per-instance allocation area
instead of performing VLAs on the stack.


Thomas Gleixner (10):
  rslib: Add GFP aware init function
  dm/verity_fec: Use GFP aware reed solomon init
  rslib: Cleanup whitespace damage
  rslib: Cleanup top level comments
  rslib: Add SPDX identifiers
  rslib: Remove GPL boilerplate
  rslib: Simplify error path
  rslib: Split rs control struct
  mtd: rawnand: diskonchip: Allocate rs control per instance
  rslib: Allocate decoder buffers to avoid VLAs

 drivers/md/dm-verity-fec.c|   2 +-
 drivers/mtd/nand/raw/cafe_nand.c  |   7 +-
 drivers/mtd/nand/raw/diskonchip.c |  67 +--
 include/linux/rslib.h |  74 +++-
 lib/reed_solomon/decode_rs.c  |  34 +++---
 lib/reed_solomon/encode_rs.c  |  15 +--
 lib/reed_solomon/reed_solomon.c   | 240 ++
 7 files changed, 243 insertions(+), 196 deletions(-)

-- 
Kees Cook
Pixel Security


Re: [PATCH v2] mm: Change return type int to vm_fault_t for fault handlers

2018-06-03 Thread Souptick Joarder
On Sun, Jun 3, 2018 at 3:31 AM, Matthew Wilcox  wrote:
> On Sun, Jun 03, 2018 at 01:34:07AM +0530, Souptick Joarder wrote:
>> @@ -3570,9 +3571,8 @@ static int hugetlb_cow(struct mm_struct *mm, struct 
>> vm_area_struct *vma,
>>   return 0;
>>   }
>>
>> - ret = (PTR_ERR(new_page) == -ENOMEM) ?
>> - VM_FAULT_OOM : VM_FAULT_SIGBUS;
>> - goto out_release_old;
>> + ret = vmf_error(PTR_ERR(new_page));
>> + goto out_release_old;
>>   }
>>
>>   /*
>
> Something weird happened to the goto here

Didn't get it ? Do you refer to wrong indent in goto ?


Re: [PATCH 2/2] tsens: Get rid of unused fields in structure

2018-06-03 Thread Rajendra Nayak



On 06/02/2018 04:41 PM, Amit Kucheria wrote:
> status_field and trdy are unused in any of the tsens drivers. Remove them.
> 
> Signed-off-by: Amit Kucheria 

Acked-by: Rajendra Nayak 

> ---
>  drivers/thermal/qcom/tsens.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
> index f15660d..77ed8dc 100644
> --- a/drivers/thermal/qcom/tsens.h
> +++ b/drivers/thermal/qcom/tsens.h
> @@ -77,9 +77,7 @@ struct tsens_device {
>   struct device   *dev;
>   u32 num_sensors;
>   struct regmap   *map;
> - struct regmap_field *status_field;
>   struct tsens_contextctx;
> - booltrdy;
>   const struct tsens_ops  *ops;
>   struct tsens_sensor sensor[0];
>  };
> 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation


Re: [PATCH 1/2] thermal: tsens: Add support for SDM845 platform

2018-06-03 Thread Rajendra Nayak



On 06/02/2018 04:41 PM, Amit Kucheria wrote:
> There are two tsens blocks on the SDM845. These will be configured through
> the devicetree.
> 
> Signed-off-by: Amit Kucheria 
> ---
>  .../devicetree/bindings/thermal/qcom-tsens.txt |  1 +
>  drivers/thermal/qcom/Makefile  |  2 +-
>  drivers/thermal/qcom/tsens-sdm845.c| 98 
> ++
>  drivers/thermal/qcom/tsens.c   |  3 +
>  drivers/thermal/qcom/tsens.h   |  1 +
>  5 files changed, 104 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/thermal/qcom/tsens-sdm845.c
> 
> diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt 
> b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> index 292ed89..8652499 100644
> --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.txt
> @@ -5,6 +5,7 @@ Required properties:
>   - "qcom,msm8916-tsens" : For 8916 Family of SoCs
>   - "qcom,msm8974-tsens" : For 8974 Family of SoCs
>   - "qcom,msm8996-tsens" : For 8996 Family of SoCs
> + - "qcom,sdm845-tsens"  : For SDM845 Family of SoCs
>  
>  - reg: Address range of the thermal registers
>  - #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 2cc2193..dc9f169 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -1,2 +1,2 @@
>  obj-$(CONFIG_QCOM_TSENS) += qcom_tsens.o
> -qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o 
> tsens-8974.o tsens-8960.o tsens-8996.o
> +qcom_tsens-y += tsens.o tsens-common.o tsens-8916.o 
> tsens-8974.o tsens-8960.o tsens-8996.o tsens-sdm845.o
> diff --git a/drivers/thermal/qcom/tsens-sdm845.c 
> b/drivers/thermal/qcom/tsens-sdm845.c
> new file mode 100644
> index 000..5d78f0b
> --- /dev/null
> +++ b/drivers/thermal/qcom/tsens-sdm845.c
> @@ -0,0 +1,98 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2018, Linaro Limited
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "tsens.h"
> +
> +#define CNTL_OFFSET  4
> +/* CNTL_OFFSET bitmasks */
> +#define EN   BIT(0)
> +#define SW_RST   BIT(1)
> +
> +#define SENSOR0_SHIFT3
> +
> +#define TRDY_OFFSET 0xe4
> +#define TRDY_READY_BIT  BIT(1)
> +
> +#define STATUS_OFFSET0xa0
> +#define LAST_TEMP_MASK   0xfff
> +#define STATUS_VALID_BIT BIT(21)
> +#define CODE_SIGN_BITBIT(11)
> +
> +static int get_temp_sdm845(struct tsens_device *tmdev, int id, int *temp)
> +{
> + struct tsens_sensor *s = &tmdev->sensor[id];
> + u32 code;
> + unsigned int sensor_addr;
> + int last_temp = 0, last_temp2 = 0, last_temp3 = 0, ret;
> +
> + ret = regmap_read(tmdev->map, TRDY_OFFSET, &code);
> + if (ret)
> + return ret;
> + if (code & TRDY_READY_BIT)
> + return -ENODATA;
> +
> + sensor_addr = STATUS_OFFSET + s->hw_id * 4;
> + ret = regmap_read(tmdev->map, sensor_addr, &code);
> + if (ret)
> + return ret;
> + last_temp = code & LAST_TEMP_MASK;
> + if (code & STATUS_VALID_BIT)
> + goto done;
> +
> + /* Try a second time */
> + ret = regmap_read(tmdev->map, sensor_addr, &code);
> + if (ret)
> + return ret;
> + if (code & STATUS_VALID_BIT) {
> + last_temp = code & LAST_TEMP_MASK;
> + goto done;
> + } else {
> + last_temp2 = code & LAST_TEMP_MASK;
> + }
> +
> + /* Try a third/last time */
> + ret = regmap_read(tmdev->map, sensor_addr, &code);
> + if (ret)
> + return ret;
> + if (code & STATUS_VALID_BIT) {
> + last_temp = code & LAST_TEMP_MASK;
> + goto done;
> + } else {
> + last_temp3 = code & LAST_TEMP_MASK;
> + }
> +
> + if (last_temp == last_temp2)
> + last_temp = last_temp2;
> + else if (last_temp2 == last_temp3)
> + last_temp = last_temp3;
> +done:
> + /* Code sign bit is the sign extension for a negative value */
> + if (last_temp & CODE_SIGN_BIT)
> + last_temp |= ~CODE_SIGN_BIT;
> +
> + /* Temperatures are in deciCelicius */
> + *temp = last_temp * 100;

This looks the same as what we do for 8996. Does it make sense to move this
to tsens-common and reuse in both 8996 and 845?

> +
> + return 0;
> +}
> +
> +static const struct regmap_config tsens_config = {
> + .reg_bits   = 32,
> + .val_bits   = 32,
> + .reg_stride = 4,
> +};
> +
> +
> +static const struct tsens_ops ops_sdm845 = {
> + .init   = init_common,
> + .get_temp   = get_temp_sdm845,
> +};
> +
> +const struct tsens_data data_sdm845 = {
> + .ops= &ops_sdm845,
> +};
> diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
> index 3f9fe

[GIT PULL] userns vfs bits for v4.18-rc1

2018-06-03 Thread Eric W. Biederman


Linus,

Please pull the userns-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
userns-linus

   HEAD: f3f1a18330ac1b717cd7a32adff38d965f365aa2 fs: Allow CAP_SYS_ADMIN in 
s_user_ns to freeze and thaw filesystems

Apologies for the resend I forgot the diffstat and the subject line.

This is the last couple of vfs bits to enable root in a user namespace
to mount and manipulate a filesystem with backing store (AKA not a
virtual filesystem like proc, but a filesystem where the unprivileged
user controls the content).   The target filesystem for this work
is fuse, and Miklos should be sending you the pull request for the
fuse bits this merge window.

The two key patches are " evm: Don't update hmacs in user ns mounts" and
"vfs: Don't allow changing the link count of an inode with an invalid
uid or gid".  Those close small gaps in the vfs that would be a problem
if an unprivileged fuse filesystem is mounted.

The rest of the changes are things that are now safe to allow a root
user in a user namespace to do with a filesystem they have mounted.  The
most interesting development is that remount is now safe.

Eric W. Biederman (5):
  vfs: Don't allow changing the link count of an inode with an invalid uid 
or gid
  vfs: Allow userns root to call mknod on owned filesystems.
  fs: Allow superblock owner to replace invalid owners of inodes
  fs: Allow superblock owner to access do_remount_sb()
  capabilities: Allow privileged user in s_user_ns to set security.* xattrs

Seth Forshee (2):
  evm: Don't update hmacs in user ns mounts
  fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems

 fs/attr.c   | 36 
 fs/ioctl.c  |  4 ++--
 fs/namei.c  | 16 
 fs/namespace.c  |  4 ++--
 security/commoncap.c|  8 ++--
 security/integrity/evm/evm_crypto.c |  3 ++-
 6 files changed, 52 insertions(+), 19 deletions(-)

Eric


[GIT PULL] siginfo work for v4.18-rc1

2018-06-03 Thread Eric W. Biederman
Linus,

Please pull the siginfo-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
siginfo-linus

   HEAD: 26da35010c6d6ce317d511c8186585bdd8ab6629 signal/sh: Stop gcc warning 
about an impossible case in do_divide_error

Apologies for the resend I spaced and forgot the diffstat earlier.

This set of changes close the known issues with setting si_code to an
invalid value, and with not fully initializing struct siginfo.  There
remains work to do on nds32, arc, unicore32, powerpc, arm, arm64, ia64
and x86 to get the code that generates siginfo into a simpler and more
maintainable state.  Most of that work involves refactoring the signal
handling code and thus careful code review.

Also not included is the work to shrink the in kernel version of struct
siginfo.  That depends on getting the number of places that directly
manipulate struct siginfo under control, as it requires the introduction
of struct kernel_siginfo for the in kernel things.

Overall this set of changes looks like it is making good progress,
and with a little luck I will be wrapping up the siginfo work
next development cycle.

Dmitry V. Levin (1):
  sparc: fix compat siginfo ABI regression

Eric W. Biederman (44):
  signal/alpha: Document a conflict with SI_USER for SIGFPE
  signal/sh: Use force_sig_fault in hw_breakpoint_handler
  signal/nds32: Use force_sig in unhandled_interruption and 
unhandled_exceptions
  signal/nds32: Use force_sig(SIGILL) in do_revisn
  signal: Ensure every siginfo we send has all bits initialized
  signal: Reduce copy_siginfo_to_user to just copy_to_user
  signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout
  signal: Remove SEGV_BNDERR ifdefs
  signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO
  signal/alpha: Replace FPE_FIXME with FPE_FLTUNK
  signal/ia64: Replace FPE_FIXME with FPE_FLTUNK
  signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK
  signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
  signal: Add TRAP_UNK si_code for undiagnosted trap exceptions
  signal/alpha:  Replace TRAP_FIXME with TRAP_UNK
  signal/powerpc: Replace TRAP_FIXME with TRAP_UNK
  signal/alpha: Use send_sig_fault where appropriate
  signal/alpha: Use force_sig_fault where appropriate
  signal/c6x: Use force_sig_fault where appropriate
  signal/hexagon: Use force_sig_fault as appropriate
  signal/m68k: Use force_sig_fault where appropriate
  signal/microblaze: Remove the commented out force_sig_info in 
do_page_fault
  signal/microblaze: Use force_sig_fault where appropriate
  signal/mips: Use force_sig_fault where appropriate
  signal/nds32: Use force_sig_fault where appropriate
  signal/nios2: Use force_sig_fault where appropriate
  signal/openrisc: Use force_sig_fault where appropriate
  signal/parisc: Use force_sig_mceerr where appropriate
  signal/parisc: Use force_sig_fault where appropriate
  signal/riscv: Use force_sig_fault where appropriate
  signal/riscv: Replace do_trap_siginfo with force_sig_fault
  signal/s390: Use force_sig_fault where appropriate
  signal/sh: Use force_sig_fault where appropriate
  signal/sparc: Use send_sig_fault where appropriate
  signal/sparc: Use force_sig_fault where appropriate
  signal/um: Use force_sig_fault where appropriate
  signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
  signal/xtensa: Use force_sig_fault where appropriate
  signal/signalfd: Remove __put_user from signalfd_copyinfo
  signal/signalfd: Add support for SIGSYS
  signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code
  signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR}
  signal/um: More carefully relay signals in relay_signal.
  signal/sh: Stop gcc warning about an impossible case in do_divide_error

Guenter Roeck (1):
  signal/mips: Report FPE_FLTUNK for undiagnosed floating point exceptions

 arch/alpha/include/uapi/asm/siginfo.h |  14 ---
 arch/alpha/kernel/osf_sys.c   |  11 +-
 arch/alpha/kernel/signal.c|  20 +---
 arch/alpha/kernel/traps.c |  79 -
 arch/alpha/mm/fault.c |  13 +--
 arch/arc/mm/fault.c   |   2 +
 arch/arm/kernel/ptrace.c  |   1 +
 arch/arm/kernel/swp_emulate.c |   1 +
 arch/arm/kernel/traps.c   |   5 +
 arch/arm/mm/alignment.c   |   1 +
 arch/arm/mm/fault.c   |   4 +
 arch/arm/vfp/vfpmodule.c  |   3 +-
 arch/arm64/kernel/fpsimd.c|   2 +-
 arch/arm64/kernel/sys_compat.c|   1 +
 arch/arm64/kernel/traps.c |   1 +
 arch/arm64/mm/fault.c |  18 ++-
 arch/c6x/kernel/traps.c   |   9 +-
 arch/hexagon/kernel/traps.c   

Re: [PATCH] nfc: st21nfca: use setup_timer instead of init_timer

2018-06-03 Thread Samuel Ortiz
Hi Colin,

On Fri, Nov 24, 2017 at 01:37:41PM +, Colin King wrote:
> From: Colin Ian King 
> 
> Use setup_timer function instead of initializing timer with the
> function and data fields.
> 
> Signed-off-by: Colin Ian King 
> ---
>  drivers/nfc/st21nfca/se.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.


[GIT PULL] siginfo work for v4.18-rc1

2018-06-03 Thread Eric W. Biederman


Linus,

Please pull the siginfo-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
siginfo-linus

   HEAD: 26da35010c6d6ce317d511c8186585bdd8ab6629 signal/sh: Stop gcc warning 
about an impossible case in do_divide_error

This set of changes close the known issues with setting si_code to an
invalid value, and with not fully initializing struct siginfo.  There
remains work to do on nds32, arc, unicore32, powerpc, arm, arm64, ia64
and x86 to get the code that generates siginfo into a simpler and more
maintainable state.  Most of that work involves refactoring the signal
handling code and thus careful code review.

Also not included is the work to shrink the in kernel version of struct
siginfo.  That depends on getting the number of places that directly
manipulate struct siginfo under control, as it requires the introduction
of struct kernel_siginfo for the in kernel things.

Overall this set of changes looks like it is making good progress,
and with a little luck I will be wrapping up the siginfo work
next development cycle.

Dmitry V. Levin (1):
  sparc: fix compat siginfo ABI regression

Eric W. Biederman (44):
  signal/alpha: Document a conflict with SI_USER for SIGFPE
  signal/sh: Use force_sig_fault in hw_breakpoint_handler
  signal/nds32: Use force_sig in unhandled_interruption and 
unhandled_exceptions
  signal/nds32: Use force_sig(SIGILL) in do_revisn
  signal: Ensure every siginfo we send has all bits initialized
  signal: Reduce copy_siginfo_to_user to just copy_to_user
  signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout
  signal: Remove SEGV_BNDERR ifdefs
  signal: Remove ifdefs for BUS_MCEERR_AR and BUS_MCEERR_AO
  signal/alpha: Replace FPE_FIXME with FPE_FLTUNK
  signal/ia64: Replace FPE_FIXME with FPE_FLTUNK
  signal/powerpc: Replace FPE_FIXME with FPE_FLTUNK
  signal/unicore32: Use FPE_FLTUNK instead of 0 in ucf64_raise_sigfpe
  signal: Add TRAP_UNK si_code for undiagnosted trap exceptions
  signal/alpha:  Replace TRAP_FIXME with TRAP_UNK
  signal/powerpc: Replace TRAP_FIXME with TRAP_UNK
  signal/alpha: Use send_sig_fault where appropriate
  signal/alpha: Use force_sig_fault where appropriate
  signal/c6x: Use force_sig_fault where appropriate
  signal/hexagon: Use force_sig_fault as appropriate
  signal/m68k: Use force_sig_fault where appropriate
  signal/microblaze: Remove the commented out force_sig_info in 
do_page_fault
  signal/microblaze: Use force_sig_fault where appropriate
  signal/mips: Use force_sig_fault where appropriate
  signal/nds32: Use force_sig_fault where appropriate
  signal/nios2: Use force_sig_fault where appropriate
  signal/openrisc: Use force_sig_fault where appropriate
  signal/parisc: Use force_sig_mceerr where appropriate
  signal/parisc: Use force_sig_fault where appropriate
  signal/riscv: Use force_sig_fault where appropriate
  signal/riscv: Replace do_trap_siginfo with force_sig_fault
  signal/s390: Use force_sig_fault where appropriate
  signal/sh: Use force_sig_fault where appropriate
  signal/sparc: Use send_sig_fault where appropriate
  signal/sparc: Use force_sig_fault where appropriate
  signal/um: Use force_sig_fault where appropriate
  signal/xtensa: Consistenly use SIGBUS in do_unaligned_user
  signal/xtensa: Use force_sig_fault where appropriate
  signal/signalfd: Remove __put_user from signalfd_copyinfo
  signal/signalfd: Add support for SIGSYS
  signal: Remove unncessary #ifdef SEGV_PKUERR in 32bit compat code
  signal: Extend siginfo_layout with SIL_FAULT_{MCEERR|BNDERR|PKUERR}
  signal/um: More carefully relay signals in relay_signal.
  signal/sh: Stop gcc warning about an impossible case in do_divide_error

Guenter Roeck (1):
  signal/mips: Report FPE_FLTUNK for undiagnosed floating point exceptions

Eric


[GIT PULL] userns

2018-06-03 Thread Eric W. Biederman


Linus,

Please pull the userns-linus branch from the git tree:

   git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
userns-linus

   HEAD: f3f1a18330ac1b717cd7a32adff38d965f365aa2 fs: Allow CAP_SYS_ADMIN in 
s_user_ns to freeze and thaw filesystems

This is the last couple of vfs bits to enable root in a user namespace
to mount and manipulate a filesystem with backing store (AKA not a
virtual filesystem like proc, but a filesystem where the unprivileged
user controls the content).   The target filesystem for this work
is fuse, and Miklos should be sending you the pull request for the
fuse bits this merge window.

The two key patches are " evm: Don't update hmacs in user ns mounts" and
"vfs: Don't allow changing the link count of an inode with an invalid
uid or gid".  Those close small gaps in the vfs that would be a problem
if an unprivileged fuse filesystem is mounted.

The rest of the changes are things that are now safe to allow a root
user in a user namespace to do with a filesystem they have mounted.  The
most interesting development is that remount is now safe.

Eric W. Biederman (5):
  vfs: Don't allow changing the link count of an inode with an invalid uid 
or gid
  vfs: Allow userns root to call mknod on owned filesystems.
  fs: Allow superblock owner to replace invalid owners of inodes
  fs: Allow superblock owner to access do_remount_sb()
  capabilities: Allow privileged user in s_user_ns to set security.* xattrs

Seth Forshee (2):
  evm: Don't update hmacs in user ns mounts
  fs: Allow CAP_SYS_ADMIN in s_user_ns to freeze and thaw filesystems

Eric


[GIT PULL] chrome-platform updates for v4.18

2018-06-03 Thread Benson Leung
Hi Linus,

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/chrome-platform-for-linus-4.18

for you to fetch changes up to 79a3d60300fc28def9b58dc30d86274b47052422:

  platform/chrome: Use to_cros_ec_dev more broadly (2018-05-30 11:53:40 -0700)


Changes to chrome-platform for v4.18

Further changes from Dmitry related to the removal of platform data from
atmel_mxt_ts and chromeos_laptop. This time, we have some changes that
teach chromeos_laptop how to supply acpi properties for some input devices
so that the peripheral driver doesn't have to do dmi matching on some
Chromebook platforms.

Also adds the Chromebook Tablet switch driver, which is useful for x86
convertible Chromebooks.

Other misc. cleanup.

Thanks,
Benson


Arnd Bergmann (1):
  platform: chrome: Add input dependency for tablet switch driver

Benson Leung (2):
  platform/chrome: chromeos_tbmc - add SPDX identifier
  Merge branch 'ib-chrome-platform-atmel-mxt-ts-device-properties' into 
working-branch-for-4.18

Dmitry Torokhov (3):
  platform/chrome: cros_ec_lpc: do not try DMI match when ACPI device found
  platform/chrome: chromeos_laptop - supply properties for ACPI devices
  platform/chrome: chromeos_laptop: fix touchpad button mapping on Celes

Gwendal Grignou (2):
  platform: chrome: Add Tablet Switch ACPI driver
  platform/chrome: Use to_cros_ec_dev more broadly

 drivers/platform/chrome/Kconfig|  11 +
 drivers/platform/chrome/Makefile   |   1 +
 drivers/platform/chrome/chromeos_laptop.c  | 315 ++---
 drivers/platform/chrome/chromeos_tbmc.c| 111 ++
 drivers/platform/chrome/cros_ec_lightbar.c |  21 +-
 drivers/platform/chrome/cros_ec_lpc.c  |  13 +-
 drivers/platform/chrome/cros_ec_sysfs.c|   2 -
 drivers/platform/chrome/cros_ec_vbc.c  |   9 +-
 include/linux/mfd/cros_ec.h|   2 +
 9 files changed, 428 insertions(+), 57 deletions(-)
 create mode 100644 drivers/platform/chrome/chromeos_tbmc.c

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature


RE: [PATCH] clk: clk-fixed-factor: Use new macro CLK_OF_DECLARE_DRIVER

2018-06-03 Thread Rajan Vaja
Hi Stephen,

Thanks for the reply. 

> -Original Message-
> From: Stephen Boyd [mailto:sb...@kernel.org]
> Sent: 02 June 2018 12:11 PM
> To: Rajan Vaja 
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> ; Michal Simek ;
> mturque...@baylibre.com
> Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> CLK_OF_DECLARE_DRIVER
> 
> Quoting Rajan Vaja (2018-05-03 02:18:30)
> > Hi Stephen,
> >
> > > -Original Message-
> > > From: Rajan Vaja
> > > Sent: 16 March 2018 05:20 PM
> > > To: 'Stephen Boyd' 
> > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> > > ; Michal Simek ;
> > > mturque...@baylibre.com
> > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> > > CLK_OF_DECLARE_DRIVER
> > >
> > > Hi Stephen,
> > >
> > > Thanks for the comment.
> > >
> > > > -Original Message-
> > > > From: Stephen Boyd [mailto:sb...@kernel.org]
> > > > Sent: 16 March 2018 12:17 AM
> > > > To: Rajan Vaja 
> > > > Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Jolly Shah
> > > > ; Michal Simek ;
> > > > mturque...@baylibre.com
> > > > Subject: RE: [PATCH] clk: clk-fixed-factor: Use new macro
> > > > CLK_OF_DECLARE_DRIVER
> > > >
> > > > Quoting Rajan Vaja (2018-03-09 11:27:40)
> > > > > > From: Stephen Boyd [mailto:sb...@kernel.org]
> > > > > >
> > > > > > Is the intent to register the clk twice? I believe things are 
> > > > > > working as
> > > > > > intended without this patch, so maybe you can explain a little more
> what
> > > > > > you're trying to fix.
> > > > > [Rajan] Yes. During of_clk_init() if some DT fixed factor clock has
> > > > > parent which is neither mentioned in output-clock-names of clock
> > > > > controller nor registered as clock provider, of_clk_init() will try to
> > > > > forcefully register in second loop.
> > > > >
> > > > > if (force || parent_ready(clk_provider->np)) {
> > > > >
> > > > > /* Don't populate platform devices */
> > > > > of_node_set_flag(clk_provider->np,
> > > > >  OF_POPULATED);
> > > > >
> > > > > So registration of this DT fixed-factor clock would fail as parent
> > > > > would be NULL as below (called from _of_fixed_factor_clk_setup()):
> > > > > parent_name = of_clk_get_parent_name(node, 0);
> > > > >
> > > > > On the other hand, even if registration failed, that node will be
> > > > > marked as OF_POPULATED, so probe of clk-fixed-factor.c will also not
> > > > > be called and that DT fixed-factor clock would never be registered.
> > > > >
> > > > > Same thing is discussed at  https://lkml.org/lkml/2017/6/5/681 .
> > > >
> > > > Ok. I believe the answer is to fix the DT to describe the parent chain
> > > > properly with clock-output-names. Otherwise, we have no good way of
> > > > figuring out what the name should be.
> > > [Rajan] clock DT binding doc says that clock-output-names property
> > > is optional and sometimes not recommended.
> > > I think this patch fixes the issue we have which mandates to add clock-
> output-
> > > names
> > > property (for this particular case). Also, IIUC platform driver probe in 
> > > clk-
> fixed-
> > > factor.c
> > > will never be called unless we use CLK_OF_DECLARE_DRIVER.
> > > I completely agree that proper solution would be to stop using strings to
> > > describe clock topology.
> > [Rajan] Any comments on this?
> > Unless we have proper solution ready, we need to have some mechanism to
> handle this scenario.
> > clock-output-names is optional and without this, it mandates to use clock-
> output-names.
> >
> 
> I couldn't read your outlook sent email and I was too busy to go
> translate it. Some bug in my MUA it seems.
> 
> Can you add the output-names property? In this case it's practically
> mandatory, so if you can't do it I'd like to hear why not.
[Rajan] In our case, we are firmware maintains clock database and driver query 
clocks
from firmware and registers clock based on information received from firmware. 
So
output clock names are not fixed. 
https://patchwork.kernel.org/patch/10439893/ - dt-bindings: clock: Add bindings 
for ZynqMP clock driver
https://patchwork.kernel.org/patch/10439891/ - drivers: clk: Add ZynqMP clock 
driver



For help, whether to check the return value of sata_scr_read should be added in sata_print_link_status

2018-06-03 Thread Nixiaoming
Hello
I have trouble reading the code, I hope you can help guide

The function sata_print_link_status in the file drivers/ata/libata-core.c 
checks the return value when the function sata_scr_read is called on line 3009, 
but does not check the return value when calling sata_scr_read on line 3011.
Why are two calls handled differently?
Is there any other code logic that guarantees that the 3011 line will not 
return an exception? 

drivers/ata/libata-core.c :
3005 static void sata_print_link_status(struct ata_link *link)
3006 {
3007 u32 sstatus, scontrol, tmp;
3008
3009 if (sata_scr_read(link, SCR_STATUS, &sstatus))
3010 return;
3011 sata_scr_read(link, SCR_CONTROL, &scontrol);
3012
3013 if (ata_phys_link_online(link)) {

Thanks



linux-next: build failure after merge of the drm-msm tree

2018-06-03 Thread Stephen Rothwell
Hi Rob,

After merging the drm-msm tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:

drivers/gpu/drm/msm/adreno/a5xx_gpu.o: In function `a5xx_gpu_busy':
a5xx_gpu.c:(.text+0xcc): undefined reference to `__aeabi_uldivmod'

Caused by commit

  dd4ff3063899 ("drm/msm: re-factor devfreq code")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpykALsubR93.pgp
Description: OpenPGP digital signature


[PATCH v3] kbuild: check for pkg-config on make {menu,n,g.x}config

2018-06-03 Thread Randy Dunlap
From: Randy Dunlap 

Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
that other required files are present and to determine build flags
settings, but none of these check that pkg-config itself is present.
Add a check for all 4 of these targets and update
Documentation/process/changes.rst to mention 'pkg-config'.

Fixes kernel bugzilla #77511:
https://bugzilla.kernel.org/show_bug.cgi?id=77511

Signed-off-by: Randy Dunlap 
Cc: Bjørn Forsman 
---
Strictly speaking, pkg-config is not required if someone is only
using 'make {menu,n}config' since there are fallbacks for those
two targets.

 Documentation/process/changes.rst  |8 
 scripts/kconfig/Makefile   |6 ++
 scripts/kconfig/check-pkgconfig.sh |   12 
 3 files changed, 26 insertions(+)

--- linux-next-20180601.orig/scripts/kconfig/Makefile
+++ linux-next-20180601/scripts/kconfig/Makefile
@@ -214,11 +214,17 @@ $(obj)/gconf.o: $(obj)/.gconf-cfg
 $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
 
 # check if necessary packages are available, and configure build flags
+# pkg-config check
+define check_pkg_config
+   $(CONFIG_SHELL) $(srctree)/scripts/kconfig/check-pkgconfig.sh FORCE
+endef
+
 define filechk_conf_cfg
$(CONFIG_SHELL) $<
 endef
 
 $(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
+   $(call check_pkg_config)
$(call filechk,conf_cfg)
 
 clean-files += .*conf-cfg
--- /dev/null
+++ linux-next-20180601/scripts/kconfig/check-pkgconfig.sh
@@ -0,0 +1,12 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+# Check for pkg-config presence
+
+pkgcfg=`command -v pkg-config`
+
+if [ "$pkgcfg" = "" ]; then
+   echo "'make *config' requires 'pkg-config'. Please install it." 1>&2
+   exit 1  # error
+fi
+
+exit 0
--- linux-next-20180601.orig/Documentation/process/changes.rst
+++ linux-next-20180601/Documentation/process/changes.rst
@@ -81,6 +81,14 @@ The build system has, as of 4.13, switch
 rather than incremental linking (`ld -r`) for built-in.a intermediate steps.
 This requires binutils 2.20 or newer.
 
+pkg-config
+--
+
+The build system, as of 4.18, requires pkg-config to check for installed
+kconfig tools and to determine flags settings for use in
+'make {menu,n,g,x}config'.  Previously pkg-config was being used but not
+verified or documented.
+
 Flex
 
 



[PATCH] rtc:ds1307:it assume 20xx not 19xx.

2018-06-03 Thread Linkui
If we settime between 1970 and 2000.
for example:
$ date 052915571978
$ hwclock -w

it will be wrong, this patch fix it.

Signed-off-by: Linkui 
---
 drivers/rtc/rtc-ds1307.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
index a13e59edff53..8c218a16569d 100644
--- a/drivers/rtc/rtc-ds1307.c
+++ b/drivers/rtc/rtc-ds1307.c
@@ -425,7 +425,9 @@ static int ds1307_get_time(struct device *dev, struct 
rtc_time *t)
t->tm_mday = bcd2bin(regs[DS1307_REG_MDAY] & 0x3f);
tmp = regs[DS1307_REG_MONTH] & 0x1f;
t->tm_mon = bcd2bin(tmp) - 1;
-   t->tm_year = bcd2bin(regs[DS1307_REG_YEAR]) + 100;
+   t->tm_year = bcd2bin(regs[DS1307_REG_YEAR]);
+   if (t->tm_year >= 0 && t->tm_year <= 69)
+   t->tm_year += 100;
 
if (regs[chip->century_reg] & chip->century_bit &&
IS_ENABLED(CONFIG_RTC_DRV_DS1307_CENTURY))
@@ -454,7 +456,7 @@ static int ds1307_set_time(struct device *dev, struct 
rtc_time *t)
t->tm_hour, t->tm_mday,
t->tm_mon, t->tm_year, t->tm_wday);
 
-   if (t->tm_year < 100)
+   if (t->tm_year < 0)
return -EINVAL;
 
 #ifdef CONFIG_RTC_DRV_DS1307_CENTURY
@@ -472,8 +474,9 @@ static int ds1307_set_time(struct device *dev, struct 
rtc_time *t)
regs[DS1307_REG_MDAY] = bin2bcd(t->tm_mday);
regs[DS1307_REG_MONTH] = bin2bcd(t->tm_mon + 1);
 
-   /* assume 20YY not 19YY */
-   tmp = t->tm_year - 100;
+   tmp = t->tm_year;
+   if (tmp >= 100 && tmp <= 169)
+   tmp -= 100;
regs[DS1307_REG_YEAR] = bin2bcd(tmp);
 
if (chip->century_enable_bit)
-- 
2.17.0





Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

2018-06-03 Thread 禹舟键
Hi Tetsuo
> Since origin_memcg_name is printed for both memcg OOM and !memcg OOM, it is 
> strange that origin_memcg_name is updated only when memcg != NULL. Have you 
> really tested !memcg OOM case?

if memcg == NULL , origin_memcg_name will also be NULL, so the length
of it is 0. origin_memcg_name will be "(null)". I've tested !memcg OOM
case with CONFIG_MEMCG and !CONFIG_MEMCG, and found nothing wrong.

Thanks
Wind
禹舟键  于2018年6月4日周一 上午9:58写道:
>
> Hi Mike
> > Please keep the brief description of the function actually brief and move 
> > the detailed explanation after the parameters description.
> Thanks for your advice.
>
> > The allocation constraint is detected by the dump_header() callers, why not 
> > just use it here?
> David suggest that constraint need to be printed in the oom report, so
> I add the enum variable in this function.
>
> Thanks
> Wind


[PATCH v2] x86/mce: add CMCI support for Centaur CPUs

2018-06-03 Thread David Wang
New Centaur CPU support CMCI mechanism, which is compatible with INTEL CMCI.

Signed-off-by: David Wang 

Changes from v1 to v2:
*1, add vendor check for Centaur CPU in cmci_supported.
*2, Only call intel_init_cmci for Centaur CPU in mce_intel_feature_init 
function.
---
 arch/x86/Kconfig   | 12 
 arch/x86/kernel/cpu/mcheck/mce.c   |  6 ++
 arch/x86/kernel/cpu/mcheck/mce_intel.c | 21 -
 3 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index dda87a3..1adff5f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1130,6 +1130,18 @@ config X86_MCE_AMD
   Additional support for AMD specific MCE features such as
   the DRAM Error Threshold.
 
+config X86_MCE_CENTAUR
+   def_bool y
+   prompt "CENTAUR MCE features"
+   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
+   help
+  Additional support for Centaur specific MCE features such as
+  MCE broadcasting and CMCI support.
+  New Centaur CPU support MCE broadcasting.
+  New Centaur CPU support CMCI which is fully compliant with Intel 
CMCI.
+
+  If unsure, say N here.
+
 config X86_ANCIENT_MCE
bool "Support for old Pentium 5 / WinChip machine checks"
depends on X86_32 && X86_MCE
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index cd76380..2ebafc7 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct cpuinfo_x86 *c)
}
 }
 
+#ifdef CONFIG_X86_MCE_CENTAUR
 static void mce_centaur_feature_init(struct cpuinfo_x86 *c)
 {
struct mca_config *cfg = &mca_cfg;
@@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct cpuinfo_x86 
*c)
if (cfg->monarch_timeout < 0)
cfg->monarch_timeout = USEC_PER_SEC;
}
+   mce_intel_feature_init(c);
+   mce_adjust_timer = cmci_intel_adjust_timer;
 }
+#else
+static inline void mce_centaur_feature_init(struct cpuinfo_x86 *c) { }
+#endif
 
 static void __mcheck_cpu_init_vendor(struct cpuinfo_x86 *c)
 {
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c 
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index d05be30..5b1b68f 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
 * initialization is vendor keyed and this
 * makes sure none of the backdoors are entered otherwise.
 */
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;
@@ -506,10 +507,20 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
 
 void mce_intel_feature_init(struct cpuinfo_x86 *c)
 {
-   intel_init_thermal(c);
-   intel_init_cmci();
-   intel_init_lmce();
-   intel_ppin_init(c);
+
+   switch (c->x86_vendor) {
+   case X86_VENDOR_INTEL:
+   intel_init_thermal(c);
+   intel_init_cmci();
+   intel_init_lmce();
+   intel_ppin_init(c);
+   break;
+   case X86_VENDOR_CENTAUR:
+   intel_init_cmci();
+   break;
+   default:
+   break;
+   }
 }
 
 void mce_intel_feature_clear(struct cpuinfo_x86 *c)
-- 
1.9.1



Re: About GPL license compliance of Tesla Model S, Linux kernel 4.4

2018-06-03 Thread Geunsik Lim
FYI, https://sfconservancy.org/blog/2018/may/18/tesla-incomplete-ccs/

On Sun, Nov 26, 2017 at 8:23 PM, Geunsik Lim  wrote:
> Here is my next activity.
>
> After reading http://gpl-violations.org/helping/,
> I have reported this issue to solve a potential GPL misuse about the
> Linux kernel open source code
> that is used to deploy Tesla Model S (Linux kernel based commercial product).
>
>
>
>
> BRs,
> Geunsik Lim.
>
>
> On Sat, Nov 25, 2017 at 4:48 PM, Geunsik Lim  wrote:
>> Hi All,
>>
>> I want to talk about a potential GPL misuse of the Linux open source
>> that is used by Tesla Model S. Some months ago, I have read that a
>> version information of Linux kernel that is deployed into the
>> commercial self-driving car such as Tesla Model S via (1) the twitter
>> web page of Tesla CEO Elon Musk  and (2) the presentation material of
>> the Blackhat 2017  presenter Sen Nie as follows.
>>
>> Oct-05-2016, Twitter, "When we upgrade the core Linux OS to 4.4, which
>> is probably December"
>> https://twitter.com/elonmusk/status/783759011724210176
>>
>> Jul-22-2017, Blackhat 2017, "FREE-FALL: HACKING TESLA FROM WIRELESS TO CAN 
>> BUS"
>> https://www.blackhat.com/us-17/briefings.html#free-fall-hacking-tesla-from-wireless-to-can-bus
>>
>>
>> In case of the embedded device vendors, it seems that the most of the
>> global vendors have being uploaded related open source software that
>> are used by commercial products via their open source release center
>> to keep the GPL compliance as following:
>>
>> https://opensource.google.com/
>> https://opensource.microsoft.com/
>> https://opensource.apple.com
>> https://opensource.samsung.com
>> https://opensource.lge.com
>> https://opensource.dell.com/
>> http://opensource.alibaba.com/
>> https://developer.sonymobile.com/knowledge-base/open-source/
>> http://consumer.huawei.com/en/opensource/
>> http://xiaomi.github.io/
>> https://software.intel.com/en-us/open-source
>>
>>
>> Also, we can download related open sources such as Linux kernel, GCC,
>> and so on from their official homepage in case of BMW, GM, Ford, and
>> Toyota cars.
>>
>> BMW - http://www.bmw-carit.de/open-source/
>> GM - http://oss.bosch-cm.com/gm.html
>> Ford - http://corporate.ford.com/ford-open-source.html
>> Toyota - http://www.globaldenso.com/en/opensource/ivi/toyota/
>>
>>
>> BTW, in case of Tesla, where can we find an official open source
>> release center to download their Linux kernel source that is deployed
>> into a commercial self-driving car? I could not find an official web
>> page of Tesla to download Linux Kernel 4.4 (GPLv2) and other open
>> sources that are used by Tesla company. And, I can not find the
>> related Linux kernel source code from https://github.com/teslamotors.
>> Unfortunately, even though I asked a person in charging on this issue,
>> they do not reply me any e-mail for 2 weeks. Anyone that already tried
>> to get their Linux kernel source of Tesla Model S?
>>
>> As we all know, Linus Torvalds has released his Linux Kernel under
>> GPLv2 license via https://www.kernel.org/.
>> For more details, please visit the below web-pages.
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/COPYING?h=v4.4
>> http://www.gnu.org/licenses/gpl-faq.en.html#GPLRequireSourcePostedPublic
>>
>> I wonder if they correctly keep the GPL compliance because I am not a lawyer.
>>
>>
>> Thanks for reading.
>>
>>
>>
>> BRs,
>> Geunsik Lim.
>>
>>
>>
>> 
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
>> 
>
>
>
> --
> 
> Best regards,
> Geunsik Lim, Samsung Electronics
> http://leemgs.fedorapeople.org
> 
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 

Best regards,
Geunsik Lim, Samsung Electronics
http://leemgs.fedorapeople.org

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] scripts/faddr2line: show the code context

2018-06-03 Thread Du, Changbin
On Tue, May 29, 2018 at 06:03:32PM +0200, Peter Zijlstra wrote:
> On Mon, Mar 19, 2018 at 03:23:25PM +0800, changbin...@intel.com wrote:
> > From: Changbin Du 
> > 
> > Inspired by gdb command 'list', show the code context of target lines.
> > Here is a example:
> > 
> > $ scripts/faddr2line vmlinux native_write_msr+0x6
> > native_write_msr+0x6/0x20:
> > arch_static_branch at arch/x86/include/asm/msr.h:105
> > 100 return EAX_EDX_VAL(val, low, high);
> > 101 }
> > 102
> > 103 static inline void notrace __wrmsr(unsigned int msr, u32 low, u32 
> > high)
> > 104 {
> > 105 asm volatile("1: wrmsr\n"
> > 106  "2:\n"
> > 107  _ASM_EXTABLE_HANDLE(1b, 2b, 
> > ex_handler_wrmsr_unsafe)
> > 108  : : "c" (msr), "a"(low), "d" (high) : 
> > "memory");
> > 109 }
> > 110
> > (inlined by) static_key_false at include/linux/jump_label.h:142
> > 137 #define JUMP_TYPE_LINKED2UL
> > 138 #define JUMP_TYPE_MASK  3UL
> > 139
> > 140 static __always_inline bool static_key_false(struct static_key *key)
> > 141 {
> > 142 return arch_static_branch(key, false);
> > 143 }
> > 144
> > 145 static __always_inline bool static_key_true(struct static_key *key)
> > 146 {
> > 147 return !arch_static_branch(key, true);
> > (inlined by) native_write_msr at arch/x86/include/asm/msr.h:150
> > 145 static inline void notrace
> > 146 native_write_msr(unsigned int msr, u32 low, u32 high)
> > 147 {
> > 148 __wrmsr(msr, low, high);
> > 149
> > 150 if (msr_tracepoint_active(__tracepoint_write_msr))
> > 151 do_trace_write_msr(msr, ((u64)high << 32 | low), 0);
> > 152 }
> > 153
> > 154 /* Can be uninlined because referenced by paravirt */
> > 155 static inline int notrace
> 
> Not a fan of this :-/ And you didn't even make it optional. Nor did you
> Cc the original author of the tool.
Yeah, understand your compatibility concern, and thanks for your improvment.
I only added people from 'scripts/get_maintainer.pl'.


-- 
Thanks,
Changbin Du


Re: [PATCH] scripts/faddr2line: show the code context

2018-06-03 Thread Du, Changbin
On Wed, May 30, 2018 at 08:01:48AM +1000, NeilBrown wrote:
> On Tue, May 29 2018, Peter Zijlstra wrote:
> 
> > On Tue, May 29, 2018 at 12:07:10PM -0500, Josh Poimboeuf wrote:
> >> Yeah, this change really should have been an optional arg.  It hurt the
> >> readability and compactness of the output.  The above looks good to me.
> >> 
> >> Care to send a proper patch?  If you send it to Linus he might apply it
> >> directly as he did with my original patches.
> >
> > ---
> > From: Peter Zijlstra (Intel) 
> >
> > Commit 6870c0165feaa5 ("scripts/faddr2line: show the code context")
> > radically altered the output format of the faddr2line tool. And while
> > the new list output format might have merrit it broke my vim usage and
> > was hard to read.
> >
> > Make the new format optional; using a '--list' argument and attempt to
> > make the output slightly easier to read by adding a little whitespace to
> > separate the different files and explicitly mark the line in question.
> 
> Not commenting on your code but on the original patch.
> I've recently noticed that ADDR2LINE sometimes outputs
>   (discriminator 2)
> or similar at the end of the line.  This messes up the parsing.
> 
> I hacked it to work so I could keep debugging with
> 
> - local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed "s; 
> $dir_prefix\(\./\)*; ;")
> + local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed -e 
> "s; $dir_prefix\(\./\)*; ;" -e "s/(discriminator [0-9]*)//")
> 
> but someone should probably find out exactly what sort of messages
> ADDR2LINE produces, and make sure they are all parsed correctly.
> (maybe that someone should be me, but not today).
> 
Hi, I have fixed it by commit 78eb0c6356 ("scripts/faddr2line: fix error when
addr2line output contains discriminator") and it is already in the mainline now.
Thank you!

> Thanks,
> NeilBrown
> 
> 
> >
> > Cc: Changbin Du 
> > Acked-by: Josh Poimboeuf 
> > Fixes: 6870c0165feaa5 ("scripts/faddr2line: show the code context")
> > Signed-off-by: Peter Zijlstra (Intel) 
> > ---
> >  scripts/faddr2line | 18 --
> >  1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/scripts/faddr2line b/scripts/faddr2line
> > index 1876a741087c..a0149db00be7 100755
> > --- a/scripts/faddr2line
> > +++ b/scripts/faddr2line
> > @@ -56,7 +56,7 @@ command -v ${SIZE} >/dev/null 2>&1 || die "size isn't 
> > installed"
> >  command -v ${NM} >/dev/null 2>&1 || die "nm isn't installed"
> >  
> >  usage() {
> > -   echo "usage: faddr2line   ..." 
> > >&2
> > +   echo "usage: faddr2line [--list]   
> > ..." >&2
> > exit 1
> >  }
> >  
> > @@ -166,15 +166,25 @@ __faddr2line() {
> > local file_lines=$(${ADDR2LINE} -fpie $objfile $addr | sed "s; 
> > $dir_prefix\(\./\)*; ;")
> > [[ -z $file_lines ]] && return
> >  
> > +   if [[ $LIST = 0 ]]; then
> > +   echo "$file_lines" | while read -r line
> > +   do
> > +   echo $line
> > +   done
> > +   DONE=1;
> > +   return
> > +   fi
> > +
> > # show each line with context
> > echo "$file_lines" | while read -r line
> > do
> > +   echo
> > echo $line
> > n=$(echo $line | sed 's/.*:\([0-9]\+\).*/\1/g')
> > n1=$[$n-5]
> > n2=$[$n+5]
> > f=$(echo $line | sed 's/.*at \(.\+\):.*/\1/g')
> > -   awk 'NR>=strtonum("'$n1'") && NR<=strtonum("'$n2'") 
> > {printf("%d\t%s\n", NR, $0)}' $f
> > +   awk 'NR>=strtonum("'$n1'") && NR<=strtonum("'$n2'") { 
> > if (NR=='$n') printf(">%d<", NR); else printf(" %d ", NR); printf("\t%s\n", 
> > $0)}' $f
> > done
> >  
> > DONE=1
> > @@ -185,6 +195,10 @@ __faddr2line() {
> >  [[ $# -lt 2 ]] && usage
> >  
> >  objfile=$1
> > +
> > +LIST=0
> > +[[ "$objfile" == "--list" ]] && LIST=1 && shift && objfile=$1
> > +
> >  [[ ! -f $objfile ]] && die "can't find objfile $objfile"
> >  shift
> >  



-- 
Thanks,
Changbin Du


Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs

2018-06-03 Thread David Wang
> -Original Mail-
> Sender: Borislav Petkov [mailto:b...@alien8.de]
> Time: 2018年6月1日 17:38
> Receiver: David Wang 
> CC: tony.l...@intel.com; mi...@redhat.com; t...@linutronix.de;
> h...@zytor.com; gre...@linuxfoudation.org; x...@kernel.org;
> linux-kernel@vger.kernel.org; linux-e...@vger.kernel.org;
> brucech...@via-alliance.com; cooper...@zhaoxin.com;
> qiyuanw...@zhaoxin.com; benjamin...@viatech.com; luke...@viacpu.com;
> tim...@zhaoxin.com
> Topic : Re: [PATCH] x86/mce: add CMCI support for Centaur CPUs
> 
> On Thu, May 31, 2018 at 11:28:58AM +0800, David Wang wrote:
> > Newer Centaur support CMCI mechanism, which is compatible with INTEL
> CMCI.
> >
> > Signed-off-by: David Wang 
> > ---
> >  arch/x86/Kconfig | 12 
> >  arch/x86/kernel/cpu/mcheck/mce.c |  6 ++
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> > dda87a3..1adff5f 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -1130,6 +1130,18 @@ config X86_MCE_AMD
> >Additional support for AMD specific MCE features such as
> >the DRAM Error Threshold.
> >
> > +config X86_MCE_CENTAUR
> > +   def_bool y
> > +   prompt "CENTAUR MCE features"
> > +   depends on CPU_SUP_CENTAUR && X86_MCE_INTEL
> > +   help
> > +  Additional support for Centaur specific MCE features such as
> > +  MCE broadcasting and CMCI support.
> > +  New Centaur CPU support MCE broadcasting.
> > +  New Centaur CPU support CMCI which is fully compliant with Intel
> CMCI.
> > +
> > +  If unsure, say N here.
> > +
> >  config X86_ANCIENT_MCE
> > bool "Support for old Pentium 5 / WinChip machine checks"
> > depends on X86_32 && X86_MCE
> > diff --git a/arch/x86/kernel/cpu/mcheck/mce.c
> > b/arch/x86/kernel/cpu/mcheck/mce.c
> > index cd76380..2ebafc7 100644
> > --- a/arch/x86/kernel/cpu/mcheck/mce.c
> > +++ b/arch/x86/kernel/cpu/mcheck/mce.c
> > @@ -1727,6 +1727,7 @@ static void __mcheck_cpu_init_early(struct
> cpuinfo_x86 *c)
> > }
> >  }
> >
> > +#ifdef CONFIG_X86_MCE_CENTAUR
> >  static void mce_centaur_feature_init(struct cpuinfo_x86 *c)  {
> > struct mca_config *cfg = &mca_cfg;
> > @@ -1740,7 +1741,12 @@ static void mce_centaur_feature_init(struct
> cpuinfo_x86 *c)
> > if (cfg->monarch_timeout < 0)
> > cfg->monarch_timeout = USEC_PER_SEC;
> > }
> > +   mce_intel_feature_init(c);
> > +   mce_adjust_timer = cmci_intel_adjust_timer;
> 
> So far so good but above says "New Centaur CPU[s]" but you're calling
> mce_intel_feature_init() unconditionally here, for *all* centaur CPUs.
> Ditto for setting the CMCI handler.

There is a check for CMCI support or not In cmci_supported() function 
which will be called by mce_intel_feature_init.

return !!(cap & MCG_CMCI_P);
So, I didn't add Family/Model/Stepping check.

But, I am sorry to add another patch just as following:

@@ -85,7 +85,8 @@ static int cmci_supported(int *banks)
 * initialization is vendor keyed and this
 * makes sure none of the backdoors are entered otherwise.
 */
-   if (boot_cpu_data.x86_vendor != X86_VENDOR_INTEL)
+   if ((boot_cpu_data.x86_vendor != X86_VENDOR_INTEL &&
+   boot_cpu_data.x86_vendor != X86_VENDOR_CENTAUR))
return 0;
if (!boot_cpu_has(X86_FEATURE_APIC) || lapic_get_maxlvt() < 6)
return 0;

I will send patch v4 later to include this patch.
Thank you.
> 
> Also mce_intel_feature_init() does more things than init CMCI so I think you
> wanna limit that to only intel_init_cmci(). IOW, something like the hunk 
> below.
> 
> And frankly I'm not crazy about adding centaur code to mce_intel.c but since 
> it
> is copying functionality, I think we should copy the sw support in the kernel 
> too
> instead of adding a mce_centaur.c duplicate. For now at least...
> 
> Thx.
> 
> ---
> diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> index d05be307d081..77d8a9b996a6 100644
> --- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
> +++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
> @@ -506,8 +506,15 @@ static void intel_ppin_init(struct cpuinfo_x86 *c)
> 
>  void mce_intel_feature_init(struct cpuinfo_x86 *c)  {
> - intel_init_thermal(c);
>   intel_init_cmci();
> +
> + /*
> +  * Some Centaur variants support CMCI.
> +  */
> + if (c->x86_vendor == X86_VENDOR_CENTAUR)
> + return;
> +
> + intel_init_thermal(c);
>   intel_init_lmce();
>   intel_ppin_init(c);
>  }
> 
OK. I will send patch V4 to fix this problem, just like:

void mce_intel_feature_init(struct cpuinfo_x86 *c)
 {
-   intel_init_thermal(c);
-   intel_init_cmci();
-   intel_init_lmce();
-   intel_ppin_init(c);
+
+   switch (c->x86_vendor) {
+   case X86_VENDOR_INTEL:
+   intel_init_thermal(c);
+ 

Re: [PATCH v7 2/2] Refactor part of the oom report in dump_header

2018-06-03 Thread 禹舟键
Hi Mike
> Please keep the brief description of the function actually brief and move the 
> detailed explanation after the parameters description.
Thanks for your advice.

> The allocation constraint is detected by the dump_header() callers, why not 
> just use it here?
David suggest that constraint need to be printed in the oom report, so
I add the enum variable in this function.

Thanks
Wind


Re: [PATCH V2 4/4] clk: imx6ul: remove clks_init_on array

2018-06-03 Thread Fabio Estevam
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang  wrote:
> Clock framework will enable those clocks registered
> with CLK_IS_CRITICAL flag, so no need to have
> clks_init_on array during clock initialization now.
>
> ARM clock is busy divider type which has the
> CLK_IS_CRITICAL flag set by default when registered.
>
> Signed-off-by: Anson Huang 

Reviewed-by: Fabio Estevam 


Re: [PATCH V2 3/4] clk: imx6sx: remove clks_init_on array

2018-06-03 Thread Fabio Estevam
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang  wrote:
> Clock framework will enable those clocks registered
> with CLK_IS_CRITICAL flag, so no need to have
> clks_init_on array during clock initialization now.
>
> ARM clock is busy divider type which has the
> CLK_IS_CRITICAL flag set by default when registered.
>
> IPG clock has no clock gate and its parent AHB clock
> is busy divider type, so no need to add CLK_IS_CRITICAL
> flag for IPG clock.
>
> Signed-off-by: Anson Huang 

Reviewed-by: Fabio Estevam 


Re: [PATCH V2 2/4] clk: imx6sl: remove clks_init_on array

2018-06-03 Thread Fabio Estevam
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang  wrote:
> Clock framework will enable those clocks registered
> with CLK_IS_CRITICAL flag, so no need to have
> clks_init_on array during clock initialization now.
>
> ARM clock is busy divider type which has the
> CLK_IS_CRITICAL flag set by default when registered.
>
> IPG clock has no clock gate and its parent AHB clock
> is busy divider type, so no need to add CLK_IS_CRITICAL
> flag for IPG clock.
>
> Signed-off-by: Anson Huang 

Reviewed-by: Fabio Estevam 


Re: [PATCH V2 1/4] clk: imx6q: remove clks_init_on array

2018-06-03 Thread Fabio Estevam
On Sun, Jun 3, 2018 at 10:06 PM, Anson Huang  wrote:
> Clock framework will enable those clocks registered
> with CLK_IS_CRITICAL flag, so no need to have
> clks_init_on array during clock initialization now.
>
> ARM clock is busy divider type which has the
> CLK_IS_CRITICAL flag set by default when registered.

Reviewed-by: Fabio Estevam 


Re: [PATCH] pci: qcom: include gpio/consumer.h

2018-06-03 Thread Bjorn Andersson
On Wed 30 May 14:53 PDT 2018, Arnd Bergmann wrote:

> When CONFIG_GPIOLIB is disabled, we run into a build failure:
> 
> drivers/pci/dwc/pcie-qcom.c: In function 'qcom_pcie_probe':
> drivers/pci/dwc/pcie-qcom.c:1223:16: error: implicit declaration of function 
> 'devm_gpiod_get_optional'; did you mean 'devm_regulator_get_optional'? 
> [-Werror=implicit-function-declaration]
>   pcie->reset = devm_gpiod_get_optional(dev, "perst", GPIOD_OUT_LOW);
> 
> Including gpio/consumer.h directly is the correct fix.
> 
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/pci/dwc/pcie-qcom.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index b65bbf7c284e..17df19db851e 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -10,7 +10,7 @@
>  
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> -- 
> 2.9.0
> 


[git pull] vfs, pile 4

2018-06-03 Thread Al Viro
misc bits and pieces not fitting into anything more specific.
That's probably it for tonight; more to follow tomorrow...

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.misc

for you to fetch changes up to eb915375757cd32c5abf7aea4caa76fe7edf8ef4:

  vfs: delete unnecessary assignment in vfs_listxattr (2018-05-29 13:22:41 
-0400)


Al Viro (7):
  remove rpc_rmdir()
  msdos_rmdir(): kill BS comment
  it's SB_BORN, not MS_BORN...
  get rid of dead code in d_find_alias()
  vfat: simplify checks in vfat_lookup()
  make xattr_getsecurity() static
  __inode_security_revalidate() never gets NULL opt_dentry

Chengguang Xu (1):
  vfs: delete unnecessary assignment in vfs_listxattr

Danilo Krummrich (1):
  vfs: namei: use path_equal() in follow_dotdot()

Li Qiang (1):
  fs.h: fix outdated comment about file flags

Sean Anderson (1):
  Documentation: filesystems: update filesystem locking documentation

Zev Weiss (1):
  fs: avoid fdput() after failed fdget() in vfs_dedupe_file_range()

 Documentation/filesystems/Locking  | 43 +++-
 fs/dcache.c| 83 --
 fs/fat/namei_msdos.c   |  4 --
 fs/fat/namei_vfat.c| 13 +-
 fs/namei.c |  4 +-
 fs/read_write.c|  6 +--
 fs/super.c |  2 +-
 fs/xattr.c |  4 +-
 include/linux/fs.h |  2 +-
 include/linux/sunrpc/rpc_pipe_fs.h |  2 -
 include/linux/xattr.h  |  1 -
 net/sunrpc/rpc_pipe.c  | 16 
 security/selinux/hooks.c   |  7 ++--
 13 files changed, 69 insertions(+), 118 deletions(-)


[git pull] vfs, pile 3

2018-06-03 Thread Al Viro
Christoph's proc_create_... cleanups series.

The following changes since commit 67b8d5c7081221efa252e111cd52532ec6d4266f:

  Linux 4.17-rc5 (2018-05-13 16:15:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git hch.procfs

for you to fetch changes up to 5ef03dbd91855544cd4c7c1910c3ef5226ee87e8:

  xfs, proc: hide unused xfs procfs helpers (2018-05-25 20:43:08 -0400)


Arnd Bergmann (1):
  xfs, proc: hide unused xfs procfs helpers

Christoph Hellwig (43):
  net/can: single_open_net needs to be paired with single_release_net
  proc: introduce a proc_pid_ns helper
  proc: don't detour through seq->private to get the inode
  proc: simplify proc_register calling conventions
  proc: add a proc_create_reg helper
  proc: introduce proc_create_seq{,_data}
  proc: introduce proc_create_seq_private
  proc: introduce proc_create_single{,_data}
  ipv{4,6}/udp{,lite}: simplify proc registration
  ipv{4,6}/tcp: simplify procfs registration
  ipv{4,6}/ping: simplify proc file creation
  ipv{4,6}/raw: simplify ѕeq_file code
  ipv6/flowlabel: simplify pid namespace lookup
  net/kcm: simplify proc registration
  netfilter/x_tables: simplify ѕeq_file code
  net: move seq_file_single_net to 
  proc: introduce proc_create_net{,_data}
  proc: introduce proc_create_net_single
  acpi/battery: simplify procfs code
  sgi-gru: simplify procfs code
  megaraid: simplify procfs code
  sg: simplify procfs code
  afs: simplify procfs code
  ext4: simplify procfs code
  jfs: simplify procfs code
  staging/rtl8192u: simplify procfs code
  resource: switch to proc_create_seq_data
  drbd: switch to proc_create_single
  rtc/proc: switch to proc_create_single_data
  bonding: switch to proc_create_seq_data
  hostap: switch to proc_create_{seq,single}_data
  neigh: switch to proc_create_seq_data
  netfilter/xt_hashlimit: switch to proc_create_{seq,single}_data
  netfilter/x_tables: switch to proc_create_seq_private
  bluetooth: switch to proc_create_seq_data
  atm: simplify procfs code
  atm: switch to proc_create_seq_private
  isdn: replace ->proc_fops with ->proc_show
  ide: remove ide_driver_proc_write
  ide: replace ->proc_fops with ->proc_show
  tty: replace ->proc_fops with ->proc_show
  proc: update SIZEOF_PDE_INLINE_NAME for the new pde fields
  isdn/gigaset: add back gigaset_procinfo assignment

 arch/arm/kernel/dma.c  |  14 +-
 arch/arm/kernel/swp_emulate.c  |  15 +-
 arch/arm/mach-rpc/ecard.c  |  16 +-
 arch/ia64/hp/common/sba_iommu.c|  15 +-
 arch/ia64/hp/sim/simserial.c   |  15 +-
 arch/ia64/kernel/palinfo.c |  16 +-
 arch/ia64/kernel/perfmon.c |  16 +-
 arch/ia64/kernel/salinfo.c |  42 ++---
 arch/ia64/sn/kernel/sn2/prominfo_proc.c|  32 +---
 arch/ia64/sn/kernel/sn2/sn_proc_fs.c   |  62 +--
 arch/m68k/kernel/setup_mm.c|  14 +-
 arch/mips/pci/ops-pmcmsp.c |  28 +---
 arch/mips/sibyte/common/bus_watcher.c  |  16 +-
 arch/parisc/kernel/pci-dma.c   |  17 +-
 arch/parisc/kernel/pdc_chassis.c   |  14 +-
 arch/powerpc/kernel/eeh.c  |  14 +-
 arch/powerpc/kernel/rtas-proc.c|  32 +---
 arch/powerpc/platforms/cell/spufs/sched.c  |  14 +-
 arch/s390/kernel/sysinfo.c |  28 +---
 arch/sh/drivers/dma/dma-api.c  |  14 +-
 arch/sparc/kernel/ioport.c |  19 +--
 arch/um/drivers/ubd_kern.c |  16 +-
 arch/x86/kernel/apm_32.c   |  15 +-
 arch/xtensa/platforms/iss/console.c|  15 +-
 block/genhd.c  |  28 +---
 crypto/proc.c  |  14 +-
 drivers/acpi/ac.c  |  21 +--
 drivers/acpi/battery.c | 121 +++---
 drivers/acpi/button.c  |  19 +--
 drivers/block/DAC960.c |  49 +-
 drivers/block/drbd/drbd_int.h  |   2 +-
 drivers/block/drbd/drbd_main.c |   3 +-
 drivers/block/drbd/drbd_proc.c |  34 +---
 drivers/block/pktcdvd.c|  14 +-
 drivers/block/ps3vram.c|  17 +-
 drivers/char/apm-emulation.c   |  15 +-
 drivers/char/ds1620.c  |  14 +-
 drivers/char/efirtc.c  |  15 +-
 drivers/char/misc.c

[PATCH V2 3/4] clk: imx6sx: remove clks_init_on array

2018-06-03 Thread Anson Huang
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.

ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.

IPG clock has no clock gate and its parent AHB clock
is busy divider type, so no need to add CLK_IS_CRITICAL
flag for IPG clock.

Signed-off-by: Anson Huang 
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag 
for ARM and IPG clocks.
 drivers/clk/imx/clk-imx6sx.c | 40 ++--
 1 file changed, 14 insertions(+), 26 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sx.c b/drivers/clk/imx/clk-imx6sx.c
index 10c771b..aed4391 100644
--- a/drivers/clk/imx/clk-imx6sx.c
+++ b/drivers/clk/imx/clk-imx6sx.c
@@ -92,14 +92,6 @@ static const char *pll7_bypass_sels[] = { "pll7", 
"pll7_bypass_src", };
 static struct clk *clks[IMX6SX_CLK_CLK_END];
 static struct clk_onecell_data clk_data;
 
-static int const clks_init_on[] __initconst = {
-   IMX6SX_CLK_AIPS_TZ1, IMX6SX_CLK_AIPS_TZ2, IMX6SX_CLK_AIPS_TZ3,
-   IMX6SX_CLK_IPMUX1, IMX6SX_CLK_IPMUX2, IMX6SX_CLK_IPMUX3,
-   IMX6SX_CLK_WAKEUP, IMX6SX_CLK_MMDC_P0_FAST, IMX6SX_CLK_MMDC_P0_IPG,
-   IMX6SX_CLK_ROM, IMX6SX_CLK_ARM, IMX6SX_CLK_IPG, IMX6SX_CLK_OCRAM,
-   IMX6SX_CLK_PER2_MAIN, IMX6SX_CLK_PERCLK, IMX6SX_CLK_TZASC1,
-};
-
 static const struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -142,7 +134,6 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 {
struct device_node *np;
void __iomem *base;
-   int i;
 
clks[IMX6SX_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
 
@@ -332,7 +323,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_QSPI1_PODF] = imx_clk_divider("qspi1_podf", 
"qspi1_sel", base + 0x1c, 26,   3);
clks[IMX6SX_CLK_EIM_SLOW_PODF]  = imx_clk_divider("eim_slow_podf",  
"eim_slow_sel",  base + 0x1c, 23,   3);
clks[IMX6SX_CLK_LCDIF2_PODF]= imx_clk_divider("lcdif2_podf",
"lcdif2_pred",   base + 0x1c, 20,   3);
-   clks[IMX6SX_CLK_PERCLK] = imx_clk_divider("perclk", 
"perclk_sel",base + 0x1c, 0,6);
+   clks[IMX6SX_CLK_PERCLK] = imx_clk_divider_flags("perclk", 
"perclk_sel", base + 0x1c, 0, 6, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_VID_PODF]   = imx_clk_divider("vid_podf",   
"vid_sel",   base + 0x20, 24,   2);
clks[IMX6SX_CLK_CAN_PODF]   = imx_clk_divider("can_podf",   
"can_sel",   base + 0x20, 2,6);
clks[IMX6SX_CLK_USDHC4_PODF]= imx_clk_divider("usdhc4_podf",
"usdhc4_sel",base + 0x24, 22,   3);
@@ -380,8 +371,8 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
 
/*name 
parent_name  reg shift */
/* CCGR0 */
-   clks[IMX6SX_CLK_AIPS_TZ1] = imx_clk_gate2("aips_tz1",  "ahb",   
base + 0x68, 0);
-   clks[IMX6SX_CLK_AIPS_TZ2] = imx_clk_gate2("aips_tz2",  "ahb",   
base + 0x68, 2);
+   clks[IMX6SX_CLK_AIPS_TZ1] = imx_clk_gate2_flags("aips_tz1", "ahb", 
base + 0x68, 0, CLK_IS_CRITICAL);
+   clks[IMX6SX_CLK_AIPS_TZ2] = imx_clk_gate2_flags("aips_tz2", "ahb", 
base + 0x68, 2, CLK_IS_CRITICAL);
clks[IMX6SX_CLK_APBH_DMA] = imx_clk_gate2("apbh_dma",  
"usdhc3",base + 0x68, 4);
clks[IMX6SX_CLK_ASRC_MEM] = imx_clk_gate2_shared("asrc_mem", "ahb", 
base + 0x68, 6, &share_count_asrc);
clks[IMX6SX_CLK_ASRC_IPG] = imx_clk_gate2_shared("asrc_ipg", "ahb", 
base + 0x68, 6, &share_count_asrc);
@@ -394,7 +385,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_CAN2_SERIAL]  = imx_clk_gate2("can2_serial",   
"can_podf",  base + 0x68, 20);
clks[IMX6SX_CLK_DCIC1]= imx_clk_gate2("dcic1", 
"display_podf",  base + 0x68, 24);
clks[IMX6SX_CLK_DCIC2]= imx_clk_gate2("dcic2", 
"display_podf",  base + 0x68, 26);
-   clks[IMX6SX_CLK_AIPS_TZ3] = imx_clk_gate2("aips_tz3",  "ahb",   
base + 0x68, 30);
+   clks[IMX6SX_CLK_AIPS_TZ3] = imx_clk_gate2_flags("aips_tz3", "ahb", 
base + 0x68, 30, CLK_IS_CRITICAL);
 
/* CCGR1 */
clks[IMX6SX_CLK_ECSPI1]   = imx_clk_gate2("ecspi1",
"ecspi_podf",base + 0x6c, 0);
@@ -407,7 +398,7 @@ static void __init imx6sx_clocks_init(struct device_node 
*ccm_node)
clks[IMX6SX_CLK_ESAI_EXTAL]   = imx_clk_gate2_shared("esai_extal", 
"esai_podf", base + 0x6c, 16, &share_count_esai);
clks[IMX6SX_CLK_ESAI_IPG] = imx_clk_gate2_shared("esai_ipg",   
"ahb"

[PATCH V2 4/4] clk: imx6ul: remove clks_init_on array

2018-06-03 Thread Anson Huang
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.

ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.

Signed-off-by: Anson Huang 
---
This patch is based on "[V2,1/2] clk: imx6ul: add GPIO clock gates".
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag 
for ARM clock.
 drivers/clk/imx/clk-imx6ul.c | 23 ++-
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6ul.c b/drivers/clk/imx/clk-imx6ul.c
index 3ea2d97..d3f7f4d 100644
--- a/drivers/clk/imx/clk-imx6ul.c
+++ b/drivers/clk/imx/clk-imx6ul.c
@@ -79,12 +79,6 @@ static const char *cko_sels[] = { "cko1", "cko2", };
 static struct clk *clks[IMX6UL_CLK_END];
 static struct clk_onecell_data clk_data;
 
-static int const clks_init_on[] __initconst = {
-   IMX6UL_CLK_AIPSTZ1, IMX6UL_CLK_AIPSTZ2,
-   IMX6UL_CLK_AXI, IMX6UL_CLK_ARM, IMX6UL_CLK_ROM,
-   IMX6UL_CLK_MMDC_P0_FAST, IMX6UL_CLK_MMDC_P0_IPG,
-};
-
 static const struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -129,7 +123,6 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
 {
struct device_node *np;
void __iomem *base;
-   int i;
 
clks[IMX6UL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
 
@@ -336,8 +329,8 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clks[IMX6UL_CLK_AHB]= imx_clk_busy_divider("ahb",   
"periph",   base +  0x14, 10, 3,  base + 0x48, 1);
 
/* CCGR0 */
-   clks[IMX6UL_CLK_AIPSTZ1]= imx_clk_gate2("aips_tz1", "ahb",  
base + 0x68,0);
-   clks[IMX6UL_CLK_AIPSTZ2]= imx_clk_gate2("aips_tz2", "ahb",  
base + 0x68,2);
+   clks[IMX6UL_CLK_AIPSTZ1]= imx_clk_gate2_flags("aips_tz1", 
"ahb", base + 0x68, 0, CLK_IS_CRITICAL);
+   clks[IMX6UL_CLK_AIPSTZ2]= imx_clk_gate2_flags("aips_tz2", 
"ahb", base + 0x68, 2, CLK_IS_CRITICAL);
clks[IMX6UL_CLK_APBHDMA]= imx_clk_gate2("apbh_dma", 
"bch_podf", base + 0x68,4);
clks[IMX6UL_CLK_ASRC_IPG]   = imx_clk_gate2_shared("asrc_ipg",  
"ahb",  base + 0x68,6, &share_count_asrc);
clks[IMX6UL_CLK_ASRC_MEM]   = imx_clk_gate2_shared("asrc_mem",  
"ahb",  base + 0x68,6, &share_count_asrc);
@@ -412,9 +405,9 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clks[IMX6UL_CLK_GPIO4]  = imx_clk_gate2("gpio4","ipg",  
base + 0x74,12);
clks[IMX6UL_CLK_QSPI]   = imx_clk_gate2("qspi1",
"qspi1_podf",   base + 0x74,14);
clks[IMX6UL_CLK_WDOG1]  = imx_clk_gate2("wdog1","ipg",  
base + 0x74,16);
-   clks[IMX6UL_CLK_MMDC_P0_FAST]   = imx_clk_gate("mmdc_p0_fast", 
"mmdc_podf", base + 0x74,20);
-   clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2("mmdc_p0_ipg",  "ipg",  
base + 0x74,24);
-   clks[IMX6UL_CLK_AXI]= imx_clk_gate("axi",   "axi_podf", 
base + 0x74,28);
+   clks[IMX6UL_CLK_MMDC_P0_FAST]   = imx_clk_gate_flags("mmdc_p0_fast", 
"mmdc_podf", base + 0x74,  20, CLK_IS_CRITICAL);
+   clks[IMX6UL_CLK_MMDC_P0_IPG]= imx_clk_gate2_flags("mmdc_p0_ipg",
"ipg",  base + 0x74,24, CLK_IS_CRITICAL);
+   clks[IMX6UL_CLK_AXI]= imx_clk_gate_flags("axi", 
"axi_podf", base + 0x74,28, CLK_IS_CRITICAL);
 
/* CCGR4 */
clks[IMX6UL_CLK_PER_BCH]= imx_clk_gate2("per_bch",  
"bch_podf", base + 0x78,12);
@@ -428,7 +421,7 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clks[IMX6UL_CLK_GPMI_APB]   = imx_clk_gate2("gpmi_apb", 
"bch_podf", base + 0x78,30);
 
/* CCGR5 */
-   clks[IMX6UL_CLK_ROM]= imx_clk_gate2("rom",  "ahb",  
base + 0x7c,0);
+   clks[IMX6UL_CLK_ROM]= imx_clk_gate2_flags("rom","ahb",  
base + 0x7c,0,  CLK_IS_CRITICAL);
clks[IMX6UL_CLK_SDMA]   = imx_clk_gate2("sdma", "ahb",  
base + 0x7c,6);
clks[IMX6UL_CLK_KPP]= imx_clk_gate2("kpp",  "ipg",  
base + 0x7c,8);
clks[IMX6UL_CLK_WDOG2]  = imx_clk_gate2("wdog2","ipg",  
base + 0x7c,10);
@@ -502,10 +495,6 @@ static void __init imx6ul_clocks_init(struct device_node 
*ccm_node)
clk_set_rate(clks[IMX6UL_CLK_ENET2_REF], 5000);
clk_set_rate(clks[IMX6UL_CLK_CSI], 2400);
 
-   /* keep all the clks on just for bringup */
-   for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
-   clk_prepare_enable(clks[clks_init_on[i]]);
-
if (clk_on_imx6ull())
   

RE: [PATCH 1/4] clk: imx6q: remove clks_init_on array

2018-06-03 Thread Anson Huang
Hi, Fabio

Anson Huang
Best Regards!


> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: Sunday, June 3, 2018 8:54 PM
> To: Anson Huang 
> Cc: Shawn Guo ; Sascha Hauer
> ; Fabio Estevam ; Michael
> Turquette ; Stephen Boyd ;
> dl-linux-imx ; moderated list:ARM/FREESCALE IMX / MXC
> ARM ARCHITECTURE ; linux-clk
> ; linux-kernel 
> Subject: Re: [PATCH 1/4] clk: imx6q: remove clks_init_on array
> 
> Hi Anson,
> 
> On Sun, Jun 3, 2018 at 9:48 AM, Anson Huang 
> wrote:
> 
> > As I explain in previous mail, busy divider clk type already include the 
> > flag
> when registered.
> 
> Ok, then please add this information in the commit log to make the review
> process easier.
 
Thanks for the comments, I improved the commit log in V2 patch set.

Anson.



[PATCH V2 1/4] clk: imx6q: remove clks_init_on array

2018-06-03 Thread Anson Huang
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.

ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.

Signed-off-by: Anson Huang 
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag 
for IMX6QDL_CLK_ARM.
 drivers/clk/imx/clk-imx6q.c | 14 ++
 1 file changed, 2 insertions(+), 12 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6q.c b/drivers/clk/imx/clk-imx6q.c
index b9ea703..8754c61 100644
--- a/drivers/clk/imx/clk-imx6q.c
+++ b/drivers/clk/imx/clk-imx6q.c
@@ -96,12 +96,6 @@ static const char *pll7_bypass_sels[] = { "pll7", 
"pll7_bypass_src", };
 static struct clk *clk[IMX6QDL_CLK_END];
 static struct clk_onecell_data clk_data;
 
-static unsigned int const clks_init_on[] __initconst = {
-   IMX6QDL_CLK_MMDC_CH0_AXI,
-   IMX6QDL_CLK_ROM,
-   IMX6QDL_CLK_ARM,
-};
-
 static struct clk_div_table clk_enet_ref_table[] = {
{ .val = 0, .div = 20, },
{ .val = 1, .div = 10, },
@@ -417,7 +411,6 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
 {
struct device_node *np;
void __iomem *anatop_base, *base;
-   int i;
int ret;
 
clk[IMX6QDL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -794,7 +787,7 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb",
"mlb_podf",   base + 0x74, 18);
else
clk[IMX6QDL_CLK_MLB] = imx_clk_gate2("mlb","axi",   
base + 0x74, 18);
-   clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2("mmdc_ch0_axi",  
"mmdc_ch0_axi_podf", base + 0x74, 20);
+   clk[IMX6QDL_CLK_MMDC_CH0_AXI] = imx_clk_gate2_flags("mmdc_ch0_axi",  
"mmdc_ch0_axi_podf", base + 0x74, 20, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_MMDC_CH1_AXI] = imx_clk_gate2("mmdc_ch1_axi",  
"mmdc_ch1_axi_podf", base + 0x74, 22);
clk[IMX6QDL_CLK_OCRAM]= imx_clk_gate2("ocram", "ahb",   
base + 0x74, 28);
clk[IMX6QDL_CLK_OPENVG_AXI]   = imx_clk_gate2("openvg_axi","axi",   
base + 0x74, 30);
@@ -808,7 +801,7 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
clk[IMX6QDL_CLK_GPMI_BCH] = imx_clk_gate2("gpmi_bch",  
"usdhc4",base + 0x78, 26);
clk[IMX6QDL_CLK_GPMI_IO]  = imx_clk_gate2("gpmi_io",   "enfc",  
base + 0x78, 28);
clk[IMX6QDL_CLK_GPMI_APB] = imx_clk_gate2("gpmi_apb",  
"usdhc3",base + 0x78, 30);
-   clk[IMX6QDL_CLK_ROM]  = imx_clk_gate2("rom",   "ahb",   
base + 0x7c, 0);
+   clk[IMX6QDL_CLK_ROM]  = imx_clk_gate2_flags("rom", "ahb",   
base + 0x7c, 0, CLK_IS_CRITICAL);
clk[IMX6QDL_CLK_SATA] = imx_clk_gate2("sata",  "ahb",   
base + 0x7c, 4);
clk[IMX6QDL_CLK_SDMA] = imx_clk_gate2("sdma",  "ahb",   
base + 0x7c, 6);
clk[IMX6QDL_CLK_SPBA] = imx_clk_gate2("spba",  "ipg",   
base + 0x7c, 12);
@@ -878,9 +871,6 @@ static void __init imx6q_clocks_init(struct device_node 
*ccm_node)
 */
clk_set_parent(clk[IMX6QDL_CLK_ENFC_SEL], 
clk[IMX6QDL_CLK_PLL2_PFD2_396M]);
 
-   for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
-   clk_prepare_enable(clk[clks_init_on[i]]);
-
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clk[IMX6QDL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clk[IMX6QDL_CLK_USBPHY2_GATE]);
-- 
2.7.4



[PATCH V2 2/4] clk: imx6sl: remove clks_init_on array

2018-06-03 Thread Anson Huang
Clock framework will enable those clocks registered
with CLK_IS_CRITICAL flag, so no need to have
clks_init_on array during clock initialization now.

ARM clock is busy divider type which has the
CLK_IS_CRITICAL flag set by default when registered.

IPG clock has no clock gate and its parent AHB clock
is busy divider type, so no need to add CLK_IS_CRITICAL
flag for IPG clock.

Signed-off-by: Anson Huang 
---
changes since V1:
improve commit log to explain why no need to add CLK_IS_CRITICAL flag 
for ARM and IPG clocks.
 drivers/clk/imx/clk-imx6sl.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/clk/imx/clk-imx6sl.c b/drivers/clk/imx/clk-imx6sl.c
index 66b1dd1..eb6bcbf 100644
--- a/drivers/clk/imx/clk-imx6sl.c
+++ b/drivers/clk/imx/clk-imx6sl.c
@@ -104,10 +104,6 @@ static struct clk_onecell_data clk_data;
 static void __iomem *ccm_base;
 static void __iomem *anatop_base;
 
-static const u32 clks_init_on[] __initconst = {
-   IMX6SL_CLK_IPG, IMX6SL_CLK_ARM, IMX6SL_CLK_MMDC_ROOT,
-};
-
 /*
  * ERR005311 CCM: After exit from WAIT mode, unwanted interrupt(s) taken
  *   during WAIT mode entry process could cause cache memory
@@ -195,7 +191,6 @@ static void __init imx6sl_clocks_init(struct device_node 
*ccm_node)
 {
struct device_node *np;
void __iomem *base;
-   int i;
int ret;
 
clks[IMX6SL_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
@@ -426,13 +421,6 @@ static void __init imx6sl_clocks_init(struct device_node 
*ccm_node)
pr_warn("%s: failed to set AHB clock rate %d!\n",
__func__, ret);
 
-   /*
-* Make sure those always on clocks are enabled to maintain the correct
-* usecount and enabling/disabling of parent PLLs.
-*/
-   for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
-   clk_prepare_enable(clks[clks_init_on[i]]);
-
if (IS_ENABLED(CONFIG_USB_MXS_PHY)) {
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY1_GATE]);
clk_prepare_enable(clks[IMX6SL_CLK_USBPHY2_GATE]);
-- 
2.7.4



Re: [PATCH v2 21/21] sparc64: use match_string() helper

2018-06-03 Thread Yisheng Xie
Hi Andy,

On 2018/6/1 19:34, Andy Shevchenko wrote:
> On Thu, May 31, 2018 at 2:11 PM, Yisheng Xie  wrote:
>> match_string() returns the index of an array for a matching string,
>> which can be used instead of open coded variant.
> 
>> @@ -512,10 +512,9 @@ static unsigned long __init mdesc_cpu_hwcap_list(void)
>> break;
>> }
>> }
> 
> It seems previous loop also can be replaced.

No, because the there is an NULL in the middle of the array hwcaps:
 static const char *hwcaps[] = {
  "flush", "stbar", "swap", "muldiv", "v9",
  "ultra3", "blkinit", "n2",

  /* These strings are as they appear in the machine description
   * 'hwcap-list' property for cpu nodes.
   */
  "mul32", "div32", "fsmuld", "v8plus", "popc", "vis", "vis2",
  "ASIBlkInit", "fmaf", "vis3", "hpc", "random", "trans", "fjfmau",
  "ima", "cspare", "pause", "cbcond", NULL /*reserved for crypto */,
  "adp",
  };

Thanks
Yisheng
> 
>> -   for (i = 0; i < ARRAY_SIZE(crypto_hwcaps); i++) {
>> -   if (!strcmp(prop, crypto_hwcaps[i]))
>> -   caps |= HWCAP_SPARC_CRYPTO;
>> -   }
>> +   i = match_string(crypto_hwcaps, ARRAY_SIZE(crypto_hwcaps), 
>> prop);
>> +   if (i >= 0)
>> +   caps |= HWCAP_SPARC_CRYPTO;
>>
>> plen = strlen(prop) + 1;
>> prop += plen;
>> --
>> 1.7.12.4
>>
> 
> 
> 



[git pull] vfs, pile 2

2018-06-03 Thread Al Viro
More shrink_dcache_parent()-related stuff - killing the main
source of potentially contended calls of that on large subtrees.

The following changes since commit 4faa99965e027cc057c5145ce45fa772caa04e8d:

  fix io_destroy()/aio_complete() race (2018-05-23 22:53:22 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.rmdir

for you to fetch changes up to 8767712f26d18ac4541e2d0d7be17c40a5911ce4:

  rmdir(),rename(): do shrink_dcache_parent() only on success (2018-05-27 
16:23:51 -0400)


Al Viro (1):
  rmdir(),rename(): do shrink_dcache_parent() only on success

 fs/namei.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)


[git pull] vfs, pile 1

2018-06-03 Thread Al Viro
That pile is the first part of dealing with livelocks, etc. around
shrink_dcache_parent().

The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:

  Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.dcache

for you to fetch changes up to 4fb48871409e2fcd375087d526d07f7600c88f94:

  restore cond_resched() in shrink_dcache_parent() (2018-04-19 23:58:48 -0400)


Al Viro (5):
  d_invalidate(): unhash immediately
  d_walk(): kill 'finish' callback
  dcache: move cond_resched() into the end of __dentry_kill()
  dput(): turn into explicit while() loop
  restore cond_resched() in shrink_dcache_parent()

 fs/dcache.c | 122 +---
 1 file changed, 43 insertions(+), 79 deletions(-)


Re: [PATCH] rpmsg: smd: do not use mananged resources for endpoints and channels

2018-06-03 Thread Bjorn Andersson
On Fri 01 Jun 16:32 PDT 2018, Srinivas Kandagatla wrote:
> @@ -1380,11 +1380,13 @@ static void qcom_smd_edge_release(struct device *dev)
>  {
>   struct qcom_smd_channel *channel;
>   struct qcom_smd_edge *edge = to_smd_edge(dev);
> + struct list_head *this, *tmp;
>  
> - list_for_each_entry(channel, &edge->channels, list) {
> - SET_RX_CHANNEL_INFO(channel, state, SMD_CHANNEL_CLOSED);
> - SET_RX_CHANNEL_INFO(channel, head, 0);
> - SET_RX_CHANNEL_INFO(channel, tail, 0);
> + list_for_each_safe(this, tmp, &edge->channels) {
> + channel = list_entry(this, struct qcom_smd_channel, list);

Is there a reason not to use list_for_each_entry_safe()?

> + list_del(&channel->list);
> + kfree(channel->name);
> + kfree(channel);

Regards,
Bjorn


Re: [PATCH 0/5] rpmsg: Convert to use SPDX license identifiers

2018-06-03 Thread Bjorn Andersson
On Thu 31 May 10:10 PDT 2018, Suman Anna wrote:

> Hi Bjorn,
> 
> The following series switches over the current licensing text in
> various rpmsg drivers to the SPDX licensing format. I see that you
> have already picked up my series for the HwSpinlock drivers, so this
> series does the same for the rpmsg drivers. Please pick these as well
> for 4.18. Patches done on top of latest upstream kernel.
> 
> regards
> Suman

Thanks Summan,
Bjorn

> 
> Suman Anna (5):
>   rpmsg: Switch to SPDX license identifier
>   rpmsg: virtio_rpmsg_bus: Switch to SPDX license identifier
>   rpmsg: smd: Switch to SPDX license identifier
>   rpmsg: glink: Switch to SPDX license identifier
>   rpmsg: char: Switch to SPDX license identifier
> 
>  drivers/rpmsg/Kconfig |  2 ++
>  drivers/rpmsg/qcom_glink_native.c | 10 +-
>  drivers/rpmsg/qcom_glink_native.h | 10 +-
>  drivers/rpmsg/qcom_glink_rpm.c| 10 +-
>  drivers/rpmsg/qcom_glink_smem.c   | 10 +-
>  drivers/rpmsg/qcom_smd.c  | 10 +-
>  drivers/rpmsg/rpmsg_char.c| 10 +-
>  drivers/rpmsg/rpmsg_core.c| 10 +-
>  drivers/rpmsg/rpmsg_internal.h| 10 +-
>  drivers/rpmsg/virtio_rpmsg_bus.c  | 10 +-
>  include/linux/rpmsg.h | 27 +--
>  include/linux/rpmsg/qcom_glink.h  |  2 ++
>  include/uapi/linux/rpmsg.h|  9 -
>  13 files changed, 14 insertions(+), 116 deletions(-)
> 
> -- 
> 2.17.0
> 


RE: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page protection"

2018-06-03 Thread Daniel Sangorrin
> -Original Message-
> From: Naresh Kamboju [mailto:naresh.kamb...@linaro.org]
> Sent: Friday, June 1, 2018 12:55 AM
> To: Daniel Sangorrin 
> Cc: Greg Kroah-Hartman ; open list
> ; linux- stable ;
> Davidlohr Bueso ; Joe Lawrence ;
> Andrea Arcangeli ; Manfred Spraul
> ; Andrew Morton ;
> Linus Torvalds 
> Subject: Re: [PATCH 4.4 011/268] Revert "ipc/shm: Fix shmat mmap nil-page
> protection"
> 
> On 31 May 2018 at 13:06, Daniel Sangorrin
>  wrote:
> >> -Original Message-
> >> From: 'Greg Kroah-Hartman' [mailto:gre...@linuxfoundation.org]
> > ..
> >> Thanks for letting us know, but this was reported already.  See the
> >> emails on lkml with the subject:
> >>   Subject: Re: [PATCH 4.16 000/272] 4.16.13-stable review
> >> from Davidlohr Bueso
> >>   Message-ID: <20180528213039.yy2madue67njkmw5@linux-n805>
> >>
> >> where he discusses that the LTP test is incorrect and that the kernel
> >> change is correct and that LTP is going to be fixed because of this.
> 
> My two cents,
> If you are referring to cve-2017-5669.c
> LTP test case is been fixed few hours ago by Rafael Tinoco,
> 
> - shm_addr = shmat(shm_id, ((void *)1), SHM_RND);
> + shm_addr = shmat(shm_id, ((void *)1), SHM_RND | SHM_REMAP);
> 
> LTP patch pull request and it is been merged.
> https://github.com/linux-test-project/ltp/pull/324

Thanks a lot Naresh.
I confirmed that the latest LTP cve-2017-5669 now PASSes.

Thanks,
Daniel






linux-next: manual merge of the overlayfs tree with Linus' tree

2018-06-03 Thread Stephen Rothwell
Hi Miklos,

Today's linux-next merge of the overlayfs tree got a conflict in:

  fs/open.c

between commit:

  af04fadcaa93 ("Revert "fs: fold open_check_o_direct into do_dentry_open"")

from Linus' tree and commit:

  e0e3f7de6435 ("vfs: simplify dentry_open()")

from the overlayfs tree.

I have no idea how to fix this up ... so I just used the overlayfs
version for now.  I assume that this will need more work before being
merged into Linus' tree.

-- 
Cheers,
Stephen Rothwell


pgpk7mboVyGoF.pgp
Description: OpenPGP digital signature


Re: [PATCH] rcu: Check the range of jiffies_till_{first,next}_fqs when setting them

2018-06-03 Thread Byungchul Park

On 2018-06-04 03:47, Joel Fernandes wrote:

On Sun, Jun 03, 2018 at 04:51:06PM +0900, Byungchul Park wrote:

On Sun, Jun 3, 2018 at 3:23 PM, Joel Fernandes  wrote:

On Sun, Jun 03, 2018 at 02:38:04PM +0900, Byungchul Park wrote:

On Sun, Jun 3, 2018 at 12:58 PM, Joel Fernandes  wrote:

On Fri, Jun 01, 2018 at 11:03:09AM +0900, Byungchul Park wrote:

Currently, the range of jiffies_till_{first,next}_fqs are checked and
adjusted on and on in the loop of rcu_gp_kthread on runtime.

However, it's enough to check them only when setting them, not every
time in the loop. So make them handled on a setting time via sysfs.

Signed-off-by: Byungchul Park 
---
  kernel/rcu/tree.c | 45 -
  1 file changed, 32 insertions(+), 13 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 4e96761..eb54d7d 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -518,8 +518,38 @@ void rcu_all_qs(void)
  static ulong jiffies_till_next_fqs = ULONG_MAX;
  static bool rcu_kick_kthreads;

-module_param(jiffies_till_first_fqs, ulong, 0644);
-module_param(jiffies_till_next_fqs, ulong, 0644);
+static int param_set_first_fqs_jiffies(const char *val, const struct 
kernel_param *kp)
+{
+ ulong j;
+ int ret = kstrtoul(val, 0, &j);
+
+ if (!ret)
+ WRITE_ONCE(*(ulong *)kp->arg, (j > HZ) ? HZ : j);
+ return ret;
+}
+
+static int param_set_next_fqs_jiffies(const char *val, const struct 
kernel_param *kp)
+{
+ ulong j;
+ int ret = kstrtoul(val, 0, &j);
+
+ if (!ret)
+ WRITE_ONCE(*(ulong *)kp->arg, (j > HZ) ? HZ : (j ?: 1));
+ return ret;
+}


Reviewed-by: Joel Fernandes (Google) 

Also, can we not combine the 2 param_set_ handlers as well?

Only thing we would be giving up is that jiffies_till_first_fqs = 0 wouldn't
be allowed (if we go with the param_set_next handler to be the common one)
but don't think that's a useful/valid usecase since jiffies_till_first_fqs is
set to a sane non-0 value anyway at boot up because of rcu_init_geometry
anyway.. Thoughts?


Excuse me. Which code in rcu_init_geometry() makes jiffies_till_first_fqs
be a non-zero in case called with jiffies_till_first_fqs == 0?


What do you mean? I think you misunderstood. I didn't say value of 0 is being
handled at boot up. What I said is its initialized to something sane that's
non-zero:

If you see, jiffies_till_first_fqs is assigned to ULONG_MAX at compile time:
static ulong jiffies_till_first_fqs = ULONG_MAX;

Then in rcu_init_geometry, we have:
 d = RCU_JIFFIES_TILL_FORCE_QS + nr_cpu_ids / RCU_JIFFIES_FQS_DIV;
 if (jiffies_till_first_fqs == ULONG_MAX)
 jiffies_till_first_fqs = d;

On my system, jiffies_till_first_fqs is assigned to 3 because of this at
boot.


Furthermore, what if we want to change the value through sysfs to zero
on runtime?


My patch was just a suggestion. I didn't know if anyone would want to force
it to 0 or not and was wondering what the value in doing so was at the cost
of adding one more function to handle it. It basically says if you set to 0,
that you never want to wait for a timeout before forcing a qs for the first
time? Then why are we calling swait_event_idle_timeout anyway? Wouldn't a
saner timeout be something not zero?


I'm sorry I tried but don't understand your point :(
Did you happen to read the following?

https://lkml.org/lkml/2018/5/29/99


No I did not happen to read that and I am very sorry about that. I see Paul
said jiffies_till_first_fqs = 0 is a useful case in that thread, to record
the idle CPUs quickly, which makes sense.


If yes, it would be appreciated if you let me know what I'm missing.


You are right and not missing anything. I'll be more careful to go through
old threads next time..

Glad to learn something from the discussions. thanks,

BTW one more dumb question - if jiffies_till_first_fqs == 0 is so useful,
then why not default initialize it to 0? I'd think most systems expect
atleast some of the CPUs to idle.


and some others to be busy tho :)

IMHO, although the case of jiffies_till_first_fqs == 0 is sometimes
useful, the other case is much more useful since we normally don't
want to add overhead by the forcing. The reason we don't force
quiescent states immediately but wait several jiffies by default is
because the overhead such as burning barrier, atomic ops and so on
is needed to force it.



- Joel




--
Thanks,
Byungchul


Re: [PATCH v3 0/5] staging: mt7621-spi: Fix C Coding style issues.

2018-06-03 Thread NeilBrown
On Sun, Jun 03 2018, Sankalp Negi wrote:

> This patch series lists different changes for coding style fixes
> as reported by checkpatch.pl, changes can be broken down as :
>
> 1. Indent switch and case labels at the same level.
> 2. Fix a line over 80 columns by refactoring.
> 3. Use tabs for indentation instead of spaces.
> 4. Add a space before open paranthesis in switch.
> 5. Remove unnecessary braces {} from single statement if block.
>
> version 2 changes
> - segregated changes in individual commits as per fix category.
>
> version 3 changes
> - added unique subjects for each patch in the series.
>
>
> Sankalp Negi (5):
>   staging: mt7621-spi: Indent case labels and switch at the same level.
>   staging: mt7621-spi: Fix line over 80 characters by refactoring.
>   staging: mt7621-spi: Use tabs for indentation instead of spaces.
>   staging: mt7621-spi: Add a space before open paranthesis.
>   staging: mt7621-spi: Remove unnecessary braces {} from single
> statement if block.
>

Thanks,
All
  Reviewed-by: NeilBrown 

NeilBrown


signature.asc
Description: PGP signature


Re: [PATCH v3 1/4] seccomp: add a return code to trap to userspace

2018-06-03 Thread Tycho Andersen
Hi Jann,

On Sun, Jun 03, 2018 at 08:41:01PM +0200, Jann Horn wrote:
> On Sun, Jun 3, 2018 at 2:29 PM Tycho Andersen  wrote:
> >
> > This patch introduces a means for syscalls matched in seccomp to notify
> > some other task that a particular filter has been triggered.
> >
> > The motivation for this is primarily for use with containers. For example,
> > if a container does an init_module(), we obviously don't want to load this
> > untrusted code, which may be compiled for the wrong version of the kernel
> > anyway. Instead, we could parse the module image, figure out which module
> > the container is trying to load and load it on the host.
> >
> > As another example, containers cannot mknod(), since this checks
> > capable(CAP_SYS_ADMIN). However, harmless devices like /dev/null or
> > /dev/zero should be ok for containers to mknod, but we'd like to avoid hard
> > coding some whitelist in the kernel. Another example is mount(), which has
> > many security restrictions for good reason, but configuration or runtime
> > knowledge could potentially be used to relax these restrictions.
> >
> > This patch adds functionality that is already possible via at least two
> > other means that I know about, both of which involve ptrace(): first, one
> > could ptrace attach, and then iterate through syscalls via PTRACE_SYSCALL.
> > Unfortunately this is slow, so a faster version would be to install a
> > filter that does SECCOMP_RET_TRACE, which triggers a PTRACE_EVENT_SECCOMP.
> > Since ptrace allows only one tracer, if the container runtime is that
> > tracer, users inside the container (or outside) trying to debug it will not
> > be able to use ptrace, which is annoying. It also means that older
> > distributions based on Upstart cannot boot inside containers using ptrace,
> > since upstart itself uses ptrace to start services.
> >
> > The actual implementation of this is fairly small, although getting the
> > synchronization right was/is slightly complex.
> >
> > Finally, it's worth noting that the classic seccomp TOCTOU of reading
> > memory data from the task still applies here, but can be avoided with
> > careful design of the userspace handler: if the userspace handler reads all
> > of the task memory that is necessary before applying its security policy,
> > the tracee's subsequent memory edits will not be read by the tracer.
> [...]
> > @@ -857,13 +1020,28 @@ static long seccomp_set_mode_filter(unsigned int 
> > flags,
> > if (IS_ERR(prepared))
> > return PTR_ERR(prepared);
> >
> > +   if (flags & SECCOMP_FILTER_FLAG_GET_LISTENER) {
> > +   listener = get_unused_fd_flags(O_RDWR);
> 
> I think you want either 0 or O_CLOEXEC here?

Do we? I suppose it makes sense to be able to set CLOEXEC, but I could
imagine a case where a handler wanted to fork+exec to handle
something. I'm happy to make the change, but it's not obvious to me
that it's what we want by default.

> > +out_put_fd:
> > +   if (flags & SECCOMP_FILTER_FLAG_GET_LISTENER) {
> > +   if (ret < 0) {
> > +   fput(listener_f);
> > +   put_unused_fd(listener);
> > +   } else {
> > +   fd_install(listener, listener_f);
> > +   ret = listener;
> > +   }
> > +   }
> >  out_free:
> > seccomp_filter_free(prepared);
> > return ret;
> [...]
> > +static __poll_t seccomp_notify_poll(struct file *file,
> > +   struct poll_table_struct *poll_tab)
> > +{
> > +   struct seccomp_filter *filter = file->private_data;
> > +   __poll_t ret = 0;
> > +   struct seccomp_knotif *cur;
> > +
> > +   ret = mutex_lock_interruptible(&filter->notify_lock);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   list_for_each_entry(cur, &filter->notifications, list) {
> > +   if (cur->state == SECCOMP_NOTIFY_INIT)
> > +   ret |= EPOLLIN | EPOLLRDNORM;
> > +   if (cur->state == SECCOMP_NOTIFY_SENT)
> > +   ret |= EPOLLOUT | EPOLLWRNORM;
> > +   }
> > +
> > +   mutex_unlock(&filter->notify_lock);
> > +
> > +   return ret;
> > +}
> 
> I don't think f_op->poll handlers work like this. AFAIK you're
> supposed to use something like poll_wait() to connect the caller to
> something like a waitqueue head, so that as soon as the file becomes
> ready for reading/writing, any waiting task is notified. See
> eventfd_poll() in fs/eventfd.c for a simple example. AFAICS in the
> current code, seccomp_notify_poll() only works if an event is pending
> at the time seccomp_notify_poll() is called.

Arg. I was trying to avoid adding yet another piece of
synchronization, but perhaps it's not possible. Thanks for pointing
this out.

Tycho


Re: [PATCH v3 4/4] seccomp: add support for passing fds via USER_NOTIF

2018-06-03 Thread Tycho Andersen
Hi Alban,

On Sat, Jun 02, 2018 at 09:14:09PM +0200, Alban Crequy wrote:
> On Thu, 31 May 2018 at 16:52, Tycho Andersen  wrote:
> >
> > The idea here is that the userspace handler should be able to pass an fd
> > back to the trapped task, for example so it can be returned from socket().
> >
> > I've proposed one API here, but I'm open to other options. In particular,
> > this only lets you return an fd from a syscall, which may not be enough in
> > all cases. For example, if an fd is written to an output parameter instead
> > of returned, the current API can't handle this. Another case is that
> > netlink takes as input fds sometimes (IFLA_NET_NS_FD, e.g.). If netlink
> > ever decides to install an fd and output it, we wouldn't be able to handle
> > this either.
> >
> > Still, the vast majority of interesting cases are covered by this API, so
> > perhaps it is Enough.
> >
> > I've left it as a separate commit for two reasons:
> >   * It illustrates the way in which we would grow struct seccomp_notif and
> > struct seccomp_notif_resp without using netlink
> >   * It shows just how little code is needed to accomplish this :)
> >
> > v2: new in v2
> > v3: no changes
> >
> > Signed-off-by: Tycho Andersen 
> > CC: Kees Cook 
> > CC: Andy Lutomirski 
> > CC: Oleg Nesterov 
> > CC: Eric W. Biederman 
> > CC: "Serge E. Hallyn" 
> > CC: Christian Brauner 
> > CC: Tyler Hicks 
> > CC: Akihiro Suda 
> > ---
> >  include/uapi/linux/seccomp.h  |   2 +
> >  kernel/seccomp.c  |  49 +++-
> >  tools/testing/selftests/seccomp/seccomp_bpf.c | 112 ++
> >  3 files changed, 161 insertions(+), 2 deletions(-)
> >
> > diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
> > index 8160e6cad528..3124427219cb 100644
> > --- a/include/uapi/linux/seccomp.h
> > +++ b/include/uapi/linux/seccomp.h
> > @@ -71,6 +71,8 @@ struct seccomp_notif_resp {
> > __u64 id;
> > __s32 error;
> > __s64 val;
> > +   __u8 return_fd;
> > +   __u32 fd;
> >  };
> >
> >  #endif /* _UAPI_LINUX_SECCOMP_H */
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 6dc99c65c2f4..2ee958b3efde 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -77,6 +77,8 @@ struct seccomp_knotif {
> > /* The return values, only valid when in SECCOMP_NOTIFY_REPLIED */
> > int error;
> > long val;
> > +   struct file *file;
> > +   unsigned int flags;
> >
> > /* Signals when this has entered SECCOMP_NOTIFY_REPLIED */
> > struct completion ready;
> > @@ -780,10 +782,32 @@ static void seccomp_do_user_notification(int 
> > this_syscall,
> > goto remove_list;
> > }
> >
> > -   ret = n.val;
> > -   err = n.error;
> > +   if (n.file) {
> > +   int fd;
> > +
> > +   fd = get_unused_fd_flags(n.flags);
> > +   if (fd < 0) {
> > +   err = fd;
> > +   ret = -1;
> > +   goto remove_list;
> > +   }
> > +
> > +   ret = fd;
> > +   err = 0;
> > +
> > +   fd_install(fd, n.file);
> > +   /* Don't fput, since fd has a reference now */
> > +   n.file = NULL;
> 
> Do we want the cgroup classid and netprio to be applied here, before
> the fd_install? I am looking at similar code in net/core/scm.c
> scm_detach_fds():
> sock = sock_from_file(fp[i], &err);
> if (sock) {
> sock_update_netprioidx(&sock->sk->sk_cgrp_data);
> sock_update_classid(&sock->sk->sk_cgrp_data);
> }
> 
> The listener process might live in a different cgroup with a different
> classid & netprio, so it might not be applied as the app might expect.

Thanks, I hadn't really thought about this. I think doing what
SCM_RIGHTS does makes sense -- the operation is essentially the same.

> Also, should we update the struct sock_cgroup_data of the socket, in
> order to make the BPF helper function bpf_skb_under_cgroup() work wrt
> the cgroup of the target process instead of the listener process? I am
> looking at cgroup_sk_alloc(). I don't know what's the correct
> behaviour we want here.

SCM_RIGHTS seems to omit this (I assume you mean the val field of
struct sock_cgroup_data, which seems to be a pointer to struct
cgroup*), any idea why?

> > +   } else {
> > +   ret = n.val;
> > +   err = n.error;
> > +   }
> > +
> >
> >  remove_list:
> > +   if (n.file)
> > +   fput(n.file);
> > +
> > list_del(&n.list);
> >  out:
> > mutex_unlock(&match->notify_lock);
> > @@ -1598,6 +1622,27 @@ static ssize_t seccomp_notify_write(struct file 
> > *file, const char __user *buf,
> > knotif->state = SECCOMP_NOTIFY_REPLIED;
> > knotif->error = resp.error;
> > knotif->val = resp.val;
> > 

Re: [PATCH 0/7] staging: mt7621-pci: Fix coding style issues

2018-06-03 Thread NeilBrown
On Sun, Jun 03 2018, Abdun Nihaal wrote:

> This patchset fixes the following set of coding style 
> issues found using checkpatch.
>
> ERROR: space prohibited after that open parenthesis '('
> ERROR: trailing whitespace
> ERROR: space required before the open parenthesis '('
> ERROR: space required after that ',' (ctx:VxV)
> ERROR: spaces required around that '=' (ctx:VxW)
> ERROR: spaces required around that '==' (ctx:WxV)
> ERROR: that open brace { should be on the previous line

Hi,
 thanks for contributing these, how ever some of these issues have
 already been address (not all).  I think you must be working from an
 old try.
 When submitting patches to drives/staging, they should be based on
 the staging-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git

 Also, I'd suggest leaving linux-arm-kernel and linux-mediatek off the
 cc list.  They are unlikely to be interested until the driver is ready
 to be moved out of drivers/staging.

Thanks,
NeilBrown


>
> Abdun Nihaal (7):
>   staging: mt7621-pci: Remove space after open parenthesis
>   staging: mt7621-pci: remove trailing whitespace
>   staging: mt7621-pci: add space before open parenthesis
>   staging: mt7621-pci: add space after comma symbol
>   staging: mt7621-pci: add spaces around equal symbol
>   staging: mt7621-pci: add space after '==' symbol
>   staging: mt7621-pci: fix coding style error
>
>  drivers/staging/mt7621-pci/pci-mt7621.c | 114 
>  1 file changed, 56 insertions(+), 58 deletions(-)
>
> -- 
> 2.17.0


signature.asc
Description: PGP signature


There were supposed to be 200 emails a day on this list.

2018-06-03 Thread Jefferson Carpenter

Where are my 200 emails?


[PATCH v1] clk: tegra: Mark Memory Controller clock as critical

2018-06-03 Thread Dmitry Osipenko
Memory Controller should be always-on. Currently the sibling EMC clock is
marked as critical, let's mark MC clock too for consistency.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/clk-divider.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/tegra/clk-divider.c b/drivers/clk/tegra/clk-divider.c
index 16e0aee14773..58874c1bbf5e 100644
--- a/drivers/clk/tegra/clk-divider.c
+++ b/drivers/clk/tegra/clk-divider.c
@@ -194,6 +194,7 @@ static const struct clk_div_table mc_div_table[] = {
 struct clk *tegra_clk_register_mc(const char *name, const char *parent_name,
  void __iomem *reg, spinlock_t *lock)
 {
-   return clk_register_divider_table(NULL, name, parent_name, 0, reg,
- 16, 1, 0, mc_div_table, lock);
+   return clk_register_divider_table(NULL, name, parent_name,
+ CLK_IS_CRITICAL, reg, 16, 1, 0,
+ mc_div_table, lock);
 }
-- 
2.17.0



[PATCH v2 0/5] Tegra20 External Memory Controller driver

2018-06-03 Thread Dmitry Osipenko
Hello,

Couple years ago the Tegra20 EMC driver was removed from the kernel
due to incompatible changes in the Tegra's clock driver. This patchset
introduces a modernized EMC driver. Currently the sole purpose of the
driver is to initialize DRAM frequency to maximum rate during of the
kernels boot-up. Later we may consider implementing dynamic memory
frequency scaling, utilizing functionality provided by this driver.

Changelog:

v2:
- Minor code cleanups like consistent use of writel_relaxed instead
  of non-relaxed version, reworded error messages, etc.

- Factored out use_pllm_ud bit checking into a standalone patch for
  consistency.

Dmitry Osipenko (5):
  dt: bindings: tegra20-emc: Document interrupt property
  ARM: dts: tegra20: Add interrupt to External Memory Controller
  clk: tegra20: Turn EMC clock gate into divider
  clk: tegra20: Check whether direct PLLM sourcing is turned off for EMC
  memory: tegra: Introduce Tegra20 EMC driver

 .../bindings/arm/tegra/nvidia,tegra20-emc.txt |   2 +
 arch/arm/boot/dts/tegra20.dtsi|   1 +
 drivers/clk/tegra/clk-tegra20.c   |  46 +-
 drivers/memory/tegra/Kconfig  |  10 +
 drivers/memory/tegra/Makefile |   1 +
 drivers/memory/tegra/tegra20-emc.c| 586 ++
 6 files changed, 636 insertions(+), 10 deletions(-)
 create mode 100644 drivers/memory/tegra/tegra20-emc.c

-- 
2.17.0



[PATCH v2 5/5] memory: tegra: Introduce Tegra20 EMC driver

2018-06-03 Thread Dmitry Osipenko
Introduce driver for the External Memory Controller (EMC) found on Tegra20
chips, which controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.

Signed-off-by: Dmitry Osipenko 
---
 drivers/memory/tegra/Kconfig   |  10 +
 drivers/memory/tegra/Makefile  |   1 +
 drivers/memory/tegra/tegra20-emc.c | 586 +
 3 files changed, 597 insertions(+)
 create mode 100644 drivers/memory/tegra/tegra20-emc.c

diff --git a/drivers/memory/tegra/Kconfig b/drivers/memory/tegra/Kconfig
index 6d74e499e18d..34e0b70f5c5f 100644
--- a/drivers/memory/tegra/Kconfig
+++ b/drivers/memory/tegra/Kconfig
@@ -6,6 +6,16 @@ config TEGRA_MC
  This driver supports the Memory Controller (MC) hardware found on
  NVIDIA Tegra SoCs.
 
+config TEGRA20_EMC
+   bool "NVIDIA Tegra20 External Memory Controller driver"
+   default y
+   depends on ARCH_TEGRA_2x_SOC
+   help
+ This driver is for the External Memory Controller (EMC) found on
+ Tegra20 chips. The EMC controls the external DRAM on the board.
+ This driver is required to change memory timings / clock rate for
+ external memory.
+
 config TEGRA124_EMC
bool "NVIDIA Tegra124 External Memory Controller driver"
default y
diff --git a/drivers/memory/tegra/Makefile b/drivers/memory/tegra/Makefile
index 94ab16ba075b..3971a6b7c487 100644
--- a/drivers/memory/tegra/Makefile
+++ b/drivers/memory/tegra/Makefile
@@ -10,5 +10,6 @@ tegra-mc-$(CONFIG_ARCH_TEGRA_210_SOC) += tegra210.o
 
 obj-$(CONFIG_TEGRA_MC) += tegra-mc.o
 
+obj-$(CONFIG_TEGRA20_EMC)  += tegra20-emc.o
 obj-$(CONFIG_TEGRA124_EMC) += tegra124-emc.o
 obj-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186.o
diff --git a/drivers/memory/tegra/tegra20-emc.c 
b/drivers/memory/tegra/tegra20-emc.c
new file mode 100644
index ..26a18b5e7941
--- /dev/null
+++ b/drivers/memory/tegra/tegra20-emc.c
@@ -0,0 +1,586 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Tegra20 External Memory Controller driver
+ *
+ * Author: Dmitry Osipenko 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define EMC_INTSTATUS  0x000
+#define EMC_INTMASK0x004
+#define EMC_TIMING_CONTROL 0x028
+#define EMC_RC 0x02c
+#define EMC_RFC0x030
+#define EMC_RAS0x034
+#define EMC_RP 0x038
+#define EMC_R2W0x03c
+#define EMC_W2R0x040
+#define EMC_R2P0x044
+#define EMC_W2P0x048
+#define EMC_RD_RCD 0x04c
+#define EMC_WR_RCD 0x050
+#define EMC_RRD0x054
+#define EMC_REXT   0x058
+#define EMC_WDV0x05c
+#define EMC_QUSE   0x060
+#define EMC_QRST   0x064
+#define EMC_QSAFE  0x068
+#define EMC_RDV0x06c
+#define EMC_REFRESH0x070
+#define EMC_BURST_REFRESH_NUM  0x074
+#define EMC_PDEX2WR0x078
+#define EMC_PDEX2RD0x07c
+#define EMC_PCHG2PDEN  0x080
+#define EMC_ACT2PDEN   0x084
+#define EMC_AR2PDEN0x088
+#define EMC_RW2PDEN0x08c
+#define EMC_TXSR   0x090
+#define EMC_TCKE   0x094
+#define EMC_TFAW   0x098
+#define EMC_TRPAB  0x09c
+#define EMC_TCLKSTABLE 0x0a0
+#define EMC_TCLKSTOP   0x0a4
+#define EMC_TREFBW 0x0a8
+#define EMC_QUSE_EXTRA 0x0ac
+#define EMC_ODT_WRITE  0x0b0
+#define EMC_ODT_READ   0x0b4
+#define EMC_FBIO_CFG5  0x104
+#define EMC_FBIO_CFG6  0x114
+#define EMC_AUTO_CAL_INTERVAL  0x2a8
+#define EMC_CFG_2  0x2b8
+#define EMC_CFG_DIG_DLL0x2bc
+#define EMC_DLL_XFORM_DQS  0x2c0
+#define EMC_DLL_XFORM_QUSE 0x2c4
+#define EMC_ZCAL_REF_CNT   0x2e0
+#define EMC_ZCAL_WAIT_CNT  0x2e4
+#define EMC_CFG_CLKTRIM_0  0x2d0
+#define EMC_CFG_CLKTRIM_1  0x2d4
+#d

[PATCH v2 2/5] ARM: dts: tegra20: Add interrupt to External Memory Controller

2018-06-03 Thread Dmitry Osipenko
Add interrupt entry into the EMC DT node.

Signed-off-by: Dmitry Osipenko 
---
 arch/arm/boot/dts/tegra20.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 983dd5c14794..3cd3cb28cfd9 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -609,6 +609,7 @@
memory-controller@7000f400 {
compatible = "nvidia,tegra20-emc";
reg = <0x7000f400 0x200>;
+   interrupts = ;
#address-cells = <1>;
#size-cells = <0>;
};
-- 
2.17.0



[PATCH v2 1/5] dt: bindings: tegra20-emc: Document interrupt property

2018-06-03 Thread Dmitry Osipenko
EMC has a dedicated interrupt that is used to notify about completion of
HW operations. Document the interrupt property.

Signed-off-by: Dmitry Osipenko 
---
 .../devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt| 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt 
b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt
index 4c33b29dc660..a6fe401d0d48 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-emc.txt
@@ -10,6 +10,7 @@ Properties:
   and chosen using the ramcode board selector. If omitted, only one
   set of tables can be present and said tables will be used
   irrespective of ram-code configuration.
+- interrupts : Should contain EMC General interrupt.
 
 Child device nodes describe the memory settings for different configurations 
and clock rates.
 
@@ -20,6 +21,7 @@ Example:
#size-cells = < 0 >;
compatible = "nvidia,tegra20-emc";
reg = <0x7000f4000 0x200>;
+   interrupts = <0 78 0x04>;
}
 
 
-- 
2.17.0



[PATCH v2 3/5] clk: tegra20: Turn EMC clock gate into divider

2018-06-03 Thread Dmitry Osipenko
Kernel should never gate the EMC clock as it causes immediate lockup, so
removing clk-gate functionality doesn't affect anything. Turning EMC clk
gate into divider allows to implement glitch-less EMC scaling, avoiding
reparenting to a backup clock.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/clk-tegra20.c | 36 -
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index cc857d4d4a86..2bd35418716a 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -578,7 +578,6 @@ static struct tegra_clk tegra20_clks[tegra_clk_max] 
__initdata = {
[tegra_clk_afi] = { .dt_id = TEGRA20_CLK_AFI, .present = true },
[tegra_clk_fuse] = { .dt_id = TEGRA20_CLK_FUSE, .present = true },
[tegra_clk_kfuse] = { .dt_id = TEGRA20_CLK_KFUSE, .present = true },
-   [tegra_clk_emc] = { .dt_id = TEGRA20_CLK_EMC, .present = true },
 };
 
 static unsigned long tegra20_clk_measure_input_freq(void)
@@ -799,6 +798,31 @@ static struct tegra_periph_init_data 
tegra_periph_nodiv_clk_list[] = {
TEGRA_INIT_DATA_NODIV("disp2",  mux_pllpdc_clkm, CLK_SOURCE_DISP2, 30, 
2, 26,  0, TEGRA20_CLK_DISP2),
 };
 
+static void __init tegra20_emc_clk_init(void)
+{
+   struct clk *clk;
+
+   clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
+  ARRAY_SIZE(mux_pllmcp_clkm),
+  CLK_SET_RATE_NO_REPARENT,
+  clk_base + CLK_SOURCE_EMC,
+  30, 2, 0, &emc_lock);
+
+   clk = tegra_clk_register_mc("mc", "emc_mux", clk_base + CLK_SOURCE_EMC,
+   &emc_lock);
+   clks[TEGRA20_CLK_MC] = clk;
+
+   /*
+* Note that 'emc_mux' source and 'emc' rate shouldn't be changed at
+* the same time due to a HW bug, this won't happen because we're
+* defining 'emc_mux' and 'emc' as a distinct clocks.
+*/
+   clk = clk_register_divider(NULL, "emc", "emc_mux", CLK_IS_CRITICAL,
+  clk_base + CLK_SOURCE_EMC, 0, 7,
+  0, &emc_lock);
+   clks[TEGRA20_CLK_EMC] = clk;
+}
+
 static void __init tegra20_periph_clk_init(void)
 {
struct tegra_periph_init_data *data;
@@ -812,15 +836,7 @@ static void __init tegra20_periph_clk_init(void)
clks[TEGRA20_CLK_AC97] = clk;
 
/* emc */
-   clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
-  ARRAY_SIZE(mux_pllmcp_clkm),
-  CLK_SET_RATE_NO_REPARENT,
-  clk_base + CLK_SOURCE_EMC,
-  30, 2, 0, &emc_lock);
-
-   clk = tegra_clk_register_mc("mc", "emc_mux", clk_base + CLK_SOURCE_EMC,
-   &emc_lock);
-   clks[TEGRA20_CLK_MC] = clk;
+   tegra20_emc_clk_init();
 
/* dsi */
clk = tegra_clk_register_periph_gate("dsi", "pll_d", 0, clk_base, 0,
-- 
2.17.0



[PATCH v2 4/5] clk: tegra20: Check whether direct PLLM sourcing is turned off for EMC

2018-06-03 Thread Dmitry Osipenko
Ensure that direct PLLM sourcing is turned off for EMC as we don't support
that configuration in the clk driver.

Signed-off-by: Dmitry Osipenko 
---
 drivers/clk/tegra/clk-tegra20.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 2bd35418716a..ca4eadb9520e 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -800,7 +800,9 @@ static struct tegra_periph_init_data 
tegra_periph_nodiv_clk_list[] = {
 
 static void __init tegra20_emc_clk_init(void)
 {
+   const u32 use_pllm_ud = BIT(29);
struct clk *clk;
+   u32 emc_reg;
 
clk = clk_register_mux(NULL, "emc_mux", mux_pllmcp_clkm,
   ARRAY_SIZE(mux_pllmcp_clkm),
@@ -812,6 +814,14 @@ static void __init tegra20_emc_clk_init(void)
&emc_lock);
clks[TEGRA20_CLK_MC] = clk;
 
+   /* un-divided pll_m_out0 is currently unsupported */
+   emc_reg = readl_relaxed(clk_base + CLK_SOURCE_EMC);
+   if (emc_reg & use_pllm_ud) {
+   pr_err("%s: un-divided PllM_out0 used as clock source\n",
+  __func__);
+   return;
+   }
+
/*
 * Note that 'emc_mux' source and 'emc' rate shouldn't be changed at
 * the same time due to a HW bug, this won't happen because we're
-- 
2.17.0



[PATCH v2] printk: make printk_safe_flush safe in NMI context by skipping flushing

2018-06-03 Thread Hoeun Ryu
From: Hoeun Ryu 

 Make printk_safe_flush() safe in NMI context.
nmi_trigger_cpumask_backtrace() can be called in NMI context. For example the
function is called in watchdog_overflow_callback() if the flag of hardlockup
backtrace (sysctl_hardlockup_all_cpu_backtrace) is true and
watchdog_overflow_callback() function is called in NMI context on some
architectures.
 Calling printk_safe_flush() in nmi_trigger_cpumask_backtrace() eventually tries
to lock logbuf_lock in vprintk_emit() that might be already be part
of another non-nmi context on the same CPU or a soft- or hard-lockup on another
CPU. The example of deadlock can be

 CPU0
 local_irq_save();
 for (;;)
   req = blk_peek_request(q);
   if (unlikely(!scsi_device_online(sdev)))
 printk()
   vprintk_emit()
 console_unlock()
   logbuf_lock_irqsave()
 slow-serial-console-write()// close to watchdog threshold
   watchdog_overflow_callback()
 trigger_allbutself_cpu_backtrace()
   printk_safe_flush()
 vprintk_emit()
   logbuf_lock_irqsave()
    deadlock

and some other cases.
 This patch prevents a deadlock in printk_safe_flush() in NMI context. It makes
sure that we continue and eventually call printk_safe_flush_on_panic() from 
panic()
that has better chances to succeed.
 There is a risk that logbuf_lock was not part of a soft- or dead-lockup and we
might just loose the messages. But then there is a high chance that irq_work 
will
get called and the messages will get flushed the normal way.

Signed-off-by: Hoeun Ryu 
Suggested-by: Petr Mladek 
Suggested-by: Sergey Senozhatsky 
---
 v2: fix comments in commit message and code. no change in code itself.

 kernel/printk/printk_safe.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 3e3c200..3b5c660 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -254,6 +254,17 @@ void printk_safe_flush(void)
 {
int cpu;
 
+   /*
+* Just avoid a deadlock here.
+* It makes sure that we continue and eventually call
+* printk_safe_flush_on_panic() from panic() that has better chances to 
succeed.
+* There is a risk that logbuf_lock was not part of a soft- or 
dead-lockup and
+* we might just loose the messages. But then there is a high chance 
that
+* irq_work will get called and the messages will get flushed the 
normal way.
+*/
+   if (this_cpu_read(printk_context) & PRINTK_NMI_CONTEXT_MASK)
+   return;
+
for_each_possible_cpu(cpu) {
 #ifdef CONFIG_PRINTK_NMI
__printk_safe_flush(&per_cpu(nmi_print_seq, cpu).work);
-- 
2.1.4



Proposal

2018-06-03 Thread Miss.Victoria Mehmet




Hello

I have been trying to contact you. Did you get my business proposal?

Best Regards,
Miss.Victoria Mehmet




Linux 4.17

2018-06-03 Thread Linus Torvalds
So this last week was pretty calm, even if the pattern of most of the
stuff coming in on a Friday made it feel less so as the weekend
approached.

And while I would have liked even less changes, I really didn't get
the feeling that another week would help the release in any way, so
here we are, with 4.17 released.

No, I didn't call it 5.0, even though all the git object count
numerology was in place for that. It will happen in the not _too_
distant future, and I'm told all the release scripts on kernel.org are
ready for it, but I didn't feel there was any real reason for it. I
suspect that around 4.20 - which is I run out of fingers and toes to
keep track of minor releases, and thus start getting mightily confused
- I'll switch over. That was what happened for 4.0, after all.

As for the actual changes since rc7 - the shortlog is appended - it's
mostly drivers, networking, perf tooling, and a set of nds32 fixes.
With some random other stuff thrown in. Again, the shortlog is
obviously only the last calm week, the overall changes since 4.16 are
much too big to list in that format.

The big 4.17 stuff was mentioned in the rc1 email when the merge
window closed, but I guess it's worth repeating how 4.17 is actually a
slightly smaller kernel than 4.16, thanks to the removal of a number
of effectively dead architectures (blackfin, cris, frv, m32r, metag,
mn10300, score, and tile). Obviously all the other changes are much
more important, but it's always nice to see spring cleaning like that.

And with this, the merge window for 4.18 is obviously open. I actually
have some travel the second week of the merge window, which is very
inconvenient for me, but I do hope that we'll get all the big stuff
merged the first week and it won't impact any release scheduling. But
we'll have to see.

  Linus


---

Aaron Ma (1):
  Input: synaptics - add Intertouch support on X1 Carbon 6th and X280

Al Viro (2):
  fix io_destroy()/aio_complete() race
  Revert "fs: fold open_check_o_direct into do_dentry_open"

Alex Williamson (1):
  Revert "vfio/type1: Improve memory pinning process for raw PFN mapping"

Alexander Duyck (1):
  net-sysfs: Fix memory leak in XPS configuration

Alexander Shishkin (2):
  stm class: Use vmalloc for the master map
  intel_th: Use correct device when freeing buffers

Antoine Tenart (1):
  crypto: inside-secure - do not use memset on MMIO

Ard Biesheuvel (1):
  net: netsec: reduce DMA mask to 40 bits

Arnaldo Carvalho de Melo (1):
  perf tools: Fix perf.data format description of NRCPUS header

Arnd Bergmann (1):
  IB: Revert "remove redundant INFINIBAND kconfig dependencies"

Bart Van Assche (1):
  scsi: scsi_transport_srp: Fix shost to rport translation

Benjamin Tissoires (2):
  Input: synaptics - add Lenovo 80 series ids to SMBus
  Input: elan_i2c_smbus - fix corrupted stack

Chris Wilson (3):
  drm/i915/lvds: Move acpi lid notification registration to
registration phase
  drm/i915/query: Protect tainted function pointer lookup
  drm/i915/query: nospec expects no more than an unsigned long

Damien Thébault (1):
  net: dsa: b53: Add BCM5389 support

Dan Carpenter (1):
  net: ethernet: davinci_emac: fix error handling in probe()

Daniel Borkmann (1):
  bpf: fix uapi hole for 32 bit compat applications

Daniele Palmas (1):
  net: usb: cdc_mbim: add flag FLAG_SEND_ZLP

Darrick J. Wong (1):
  fs: clear writeback errors in inode_init_always

David Francis (1):
  drm/amd/display: Make atomic-check validate underscan changes

David Howells (1):
  afs: Fix directory permissions check

Davidlohr Bueso (1):
  sched/headers: Fix typo

Devesh Sharma (1):
  RDMA/bnxt_re: Fix broken RoCE driver due to recent L2 driver changes

Dhinakaran Pandiyan (1):
  drm/psr: Fix missed entry in PSR setup time table.

Dmitry Torokhov (1):
  Input: synaptics - Lenovo Carbon X1 Gen5 (2017) devices should use RMI

Edvard Holst (1):
  Input: synaptics - Lenovo Thinkpad X1 Carbon G5 (2017) with
Elantech trackpoints should use RMI

Eric Dumazet (2):
  xfrm6: avoid potential infinite loop in _decode_session6()
  netfilter: provide correct argument to nla_strlcpy()

Eugen Hristev (2):
  iio: adc: at91-sama5d2_adc: fix channel configuration for
differential channels
  iio: adc: select buffer for at91-sama5d2_adc

Fabrice Gasnier (2):
  iio: adc: stm32-dfsdm: fix successive oversampling settings
  iio: adc: stm32-dfsdm: fix sample rate for div2 spi clock

Federico Vaga (1):
  i2c: ocores: update HDL sources URL

Finn Thain (1):
  net/sonic: Use dma_mapping_error()

George Cherian (1):
  i2c: xlp9xx: Add MAINTAINERS entry

Greentime Hu (12):
  nds32: lib: To use generic lib instead of libgcc to prevent the
symbol undefined issue.
  nds32: Fix building error when CONFIG_FREEZE is enabled.
  nds32: Fix building error of crypto/xor.c by adding xor.h
  nds32:

linux-next: Signed-off-by missing for commits in the drm-msm tree

2018-06-03 Thread Stephen Rothwell
Hi Rob,

Commit

  0c999b56810a ("drm/msm: Refactor complete_commit() to look more the helpers")
  240ca9286fcb ("drm/msm: Move implicit sync handling to prepare_fb")
  a744a6a9e98b ("drm/msm: Issue queued events when disabling crtc")
  efaa2af8b741 ("drm/msm: Remove msm_commit/worker, use atomic helper commit")
  917d7e3c75ec ("drm/msm: Switch to atomic_helper_commit()")

are missing a Signed-off-by from their committer.

-- 
Cheers,
Stephen Rothwell


pgpd7Nj0K1mMa.pgp
Description: OpenPGP digital signature


  1   2   3   >