[PATCH v2 3/3] x86/entry/64: Move #BP from IST to the IRQ stack

[Andy Lutomirski]

There's nothing IST-worthy about #BP/int3.  We don't allow kprobes
in the small handful of places in the kernel that run at CPL0 with
an invalid stack, and 32-bit kernels have used normal interrupt
gates for #BP forever.

Furthermore, we don't allow kprobes in places that have usergs while
in kernel mode, so "paranoid" is also unnecessary.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_64.S |  2 +-
 arch/x86/kernel/traps.c   | 26 +-
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index af3573e75ed4..e353709d1fcc 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1007,7 +1007,7 @@ apicinterrupt3 HYPERVISOR_CALLBACK_VECTOR \
 #endif /* CONFIG_HYPERV */
 
 idtentry debug do_debughas_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
-idtentry int3  do_int3 has_error_code=0
paranoid=1 shift_ist=DEBUG_STACK
+idtentry int3  do_int3 has_error_code=0
irqstack=1
 idtentry stack_segment do_stack_segmenthas_error_code=1
 
 #ifdef CONFIG_XEN
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 8e65d8a9b8db..d823db70f492 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -479,7 +479,7 @@ do_general_protection(struct pt_regs *regs, long error_code)
 }
 NOKPROBE_SYMBOL(do_general_protection);
 
-/* May run on IST stack. */
+/* Runs on IRQ stack. */
 dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
 {
 #ifdef CONFIG_DYNAMIC_FTRACE
@@ -494,7 +494,15 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, 
long error_code)
if (poke_int3_handler(regs))
return;
 
+   /*
+* Use ist_enter despite the fact that we don't use an IST stack.
+* We can be called from a kprobe in non-CONTEXT_KERNEL kernel
+* mode or even during context tracking state changes.
+*
+* This means that we can't schedule.  That's okay.
+*/
ist_enter(regs);
+
CT_WARN_ON(ct_state() != CONTEXT_KERNEL);
 #ifdef CONFIG_KGDB_LOW_LEVEL_TRAP
if (kgdb_ll_trap(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
@@ -511,15 +519,10 @@ dotraplinkage void notrace do_int3(struct pt_regs *regs, 
long error_code)
SIGTRAP) == NOTIFY_STOP)
goto exit;
 
-   /*
-* Let others (NMI) know that the debug stack is in use
-* as we may switch to the interrupt stack.
-*/
-   debug_stack_usage_inc();
preempt_conditional_sti(regs);
do_trap(X86_TRAP_BP, SIGTRAP, "int3", regs, error_code, NULL);
preempt_conditional_cli(regs);
-   debug_stack_usage_dec();
+
 exit:
ist_exit(regs);
 }
@@ -885,19 +888,16 @@ void __init trap_init(void)
cpu_init();
 
/*
-* X86_TRAP_DB and X86_TRAP_BP have been set
-* in early_trap_init(). However, ITS works only after
-* cpu_init() loads TSS. See comments in early_trap_init().
+* X86_TRAP_DB was installed in early_trap_init(). However,
+* IST works only after cpu_init() loads TSS. See comments
+* in early_trap_init().
 */
set_intr_gate_ist(X86_TRAP_DB, , DEBUG_STACK);
-   /* int3 can be called from all */
-   set_system_intr_gate_ist(X86_TRAP_BP, , DEBUG_STACK);
 
x86_init.irqs.trap_init();
 
 #ifdef CONFIG_X86_64
memcpy(_idt_table, _table, IDT_ENTRIES * 16);
set_nmi_gate(X86_TRAP_DB, );
-   set_nmi_gate(X86_TRAP_BP, );
 #endif
 }
-- 
2.4.3

--
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/

[PATCH v2 0/3] x86_64: Make int3 non-magical

[Andy Lutomirski]

int3 uses IST and the paranoid gsbase path.  Neither is necessary,
although the IST stack may currently be necessary to avoid stack
overruns.

Clean up IRQ stacks, make them NMI safe, teach idtentry to use
irqstacks if requested, and move int3 to the IRQ stack.

This prepares us to return from int3 using RET.  While we could,
in principle, return from an IST entry using RET, making that work
seems likely to be much messier and more fragile than this approach.

Changes from v1: Actually NMI-safe

Andy Lutomirski (3):
  x86/entry/64: Refactor IRQ stacks and make them NMI-safe
  x86/entry/64: Teach idtentry to use the IRQ stack
  x86/entry/64: Move #BP from IST to the IRQ stack

 arch/x86/Kconfig.debug   |   2 -
 arch/x86/entry/entry_64.S| 105 ++-
 arch/x86/kernel/process_64.c |   4 ++
 arch/x86/kernel/traps.c  |  26 +--
 4 files changed, 90 insertions(+), 47 deletions(-)

-- 
2.4.3

--
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/

[PATCH v2 1/3] x86/entry/64: Refactor IRQ stacks and make them NMI-safe

[Andy Lutomirski]

This will allow IRQ stacks to nest inside NMIs or similar entries
that can happen during IRQ stack setup or teardown.

The Xen code here has a confusing comment.

The new macros won't work correctly if they're invoked with IRQs on.
Add a check under CONFIG_DEBUG_ENTRY to detect that.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/Kconfig.debug   |  2 -
 arch/x86/entry/entry_64.S| 89 +---
 arch/x86/kernel/process_64.c |  4 ++
 3 files changed, 63 insertions(+), 32 deletions(-)

diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index d8c0d3266173..4196e2325971 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -305,8 +305,6 @@ config DEBUG_ENTRY
  Some of these sanity checks may slow down kernel entries and
  exits or otherwise impact performance.
 
- This is currently used to help test NMI code.
-
  If unsure, say N.
 
 config DEBUG_NMI_SELFTEST
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index d3033183ed70..3227fb6a5b94 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -490,6 +490,56 @@ ENTRY(irq_entries_start)
 .endr
 END(irq_entries_start)
 
+.macro DEBUG_ENTRY_ASSERT_IRQS_OFF
+#ifdef CONFIG_DEBUG_ENTRY
+   pushfq
+   testl $X86_EFLAGS_IF, (%rsp)
+   jz 693f
+   ud2
+693:
+   addq $8, %rsp
+#endif
+.endm
+
+/*
+ * Enters the IRQ stack if we're not already using it.  NMI-safe.  Clobbers
+ * flags and puts old RSP into old_rsp, and leaves all other GPRs alone.
+ * Requires kernel GSBASE.
+ *
+ * The invariant is that, if irq_count != 1, then the IRQ stack is in use.
+ */
+.macro ENTER_IRQ_STACK old_rsp
+   DEBUG_ENTRY_ASSERT_IRQS_OFF
+   movq%rsp, \old_rsp
+   inclPER_CPU_VAR(irq_count)
+
+   /*
+* Right now, if we just incremented irq_count to zero, we've
+* claimed the IRQ stack but we haven't switched to it yet.
+* Anything that can interrupt us here without using IST
+* must be *extremely* careful to limit its stack usage.
+*/
+
+   cmovzq  PER_CPU_VAR(irq_stack_ptr), %rsp
+   pushq   \old_rsp
+.endm
+
+/*
+ * Undoes ENTER_IRQ_STACK.
+ */
+.macro LEAVE_IRQ_STACK
+   DEBUG_ENTRY_ASSERT_IRQS_OFF
+   /* We need to be off the IRQ stack before decrementing irq_count. */
+   popq%rsp
+
+   /*
+* As in ENTER_IRQ_STACK, irq_count == 0, we are still claiming
+* the irq stack but we're not on it.
+*/
+
+   declPER_CPU_VAR(irq_count)
+.endm
+
 /*
  * Interrupt entry/exit.
  *
@@ -518,17 +568,7 @@ END(irq_entries_start)
 #endif
 
 1:
-   /*
-* Save previous stack pointer, optionally switch to interrupt stack.
-* irq_count is used to check if a CPU is already on an interrupt stack
-* or not. While this is essentially redundant with preempt_count it is
-* a little cheaper to use a separate counter in the PDA (short of
-* moving irq_enter into assembly, which would be too much work)
-*/
-   movq%rsp, %rdi
-   inclPER_CPU_VAR(irq_count)
-   cmovzq  PER_CPU_VAR(irq_stack_ptr), %rsp
-   pushq   %rdi
+   ENTER_IRQ_STACK old_rsp=%rdi
/* We entered an interrupt context - irqs are off: */
TRACE_IRQS_OFF
 
@@ -548,10 +588,8 @@ common_interrupt:
 ret_from_intr:
DISABLE_INTERRUPTS(CLBR_NONE)
TRACE_IRQS_OFF
-   declPER_CPU_VAR(irq_count)
 
-   /* Restore saved previous stack */
-   popq%rsp
+   LEAVE_IRQ_STACK
 
testb   $3, CS(%rsp)
jz  retint_kernel
@@ -863,14 +901,9 @@ bad_gs:
 
 /* Call softirq on interrupt stack. Interrupts are off. */
 ENTRY(do_softirq_own_stack)
-   pushq   %rbp
-   mov %rsp, %rbp
-   inclPER_CPU_VAR(irq_count)
-   cmove   PER_CPU_VAR(irq_stack_ptr), %rsp
-   push%rbp/* frame pointer backlink */
+   ENTER_IRQ_STACK old_rsp=%r11
call__do_softirq
-   leaveq
-   declPER_CPU_VAR(irq_count)
+   LEAVE_IRQ_STACK
ret
 END(do_softirq_own_stack)
 
@@ -889,25 +922,21 @@ idtentry xen_hypervisor_callback 
xen_do_hypervisor_callback has_error_code=0
  * So, on entry to the handler we detect whether we interrupted an
  * existing activation in its critical region -- if so, we pop the current
  * activation and restart the handler using the previous one.
+ *
+ * XXX: I have no idea what this comment is talking about.  --luto
  */
 ENTRY(xen_do_hypervisor_callback)  /* 
do_hypervisor_callback(struct *pt_regs) */
-
+   ENTER_IRQ_STACK old_rsp=%r11
 /*
  * Since we don't modify %rdi, evtchn_do_upall(struct *pt_regs) will
  * see the correct pointer to the pt_regs
  */
-   movq%rdi, %rsp  /* we don't return, adjust the 
stack frame */
-11:inclPER_CPU_VAR(irq_count)
-   movq%rsp, %rbp
-   cmovzq  

[PATCH v2 2/3] x86/entry/64: Teach idtentry to use the IRQ stack

[Andy Lutomirski]

We don't specifically need IST for things like kprobes, but we do
want to avoid rare, surprising extra stack usage if a kprobe hits
with a deep stack.

Teach idtentry to use the IRQ stack for selected entries.

This implementation uses the IRQ stack even if we entered from user
mode.  This disallows tricks like ist_begin_non_atomic.  If we ever
need such a trick in one of these entries, we can rework this.  For
now, let's keep it simple.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/entry/entry_64.S | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 3227fb6a5b94..af3573e75ed4 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -756,13 +756,17 @@ apicinterrupt IRQ_WORK_VECTOR 
irq_work_interrupt  smp_irq_work_interrupt
  */
 #define CPU_TSS_IST(x) PER_CPU_VAR(cpu_tss) + (TSS_ist + ((x) - 1) * 8)
 
-.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
+.macro idtentry sym do_sym has_error_code:req irqstack=0 paranoid=0 
shift_ist=-1
 ENTRY(\sym)
/* Sanity check */
.if \shift_ist != -1 && \paranoid == 0
.error "using shift_ist requires paranoid=1"
.endif
 
+   .if \irqstack && \paranoid
+   .error "using irqstack requires !paranoid"
+   .endif
+
ASM_CLAC
PARAVIRT_ADJUST_EXCEPTION_FRAME
 
@@ -804,8 +808,16 @@ ENTRY(\sym)
subq$EXCEPTION_STKSZ, CPU_TSS_IST(\shift_ist)
.endif
 
+   .if \irqstack
+   ENTER_IRQ_STACK old_rsp=%rcx
+   .endif
+
call\do_sym
 
+   .if \irqstack
+   LEAVE_IRQ_STACK
+   .endif
+
.if \shift_ist != -1
addq$EXCEPTION_STKSZ, CPU_TSS_IST(\shift_ist)
.endif
-- 
2.4.3

--
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/

[PATCH v4 2/3] x86/ldt: Make modify_ldt optional

[Andy Lutomirski]

The modify_ldt syscall exposes a large attack surface and is
unnecessary for modern userspace.  Make it optional.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/Kconfig   | 17 +
 arch/x86/include/asm/mmu.h |  2 ++
 arch/x86/include/asm/mmu_context.h | 31 +++
 arch/x86/kernel/Makefile   |  3 ++-
 arch/x86/kernel/cpu/perf_event.c   |  4 
 arch/x86/kernel/process_64.c   |  2 ++
 arch/x86/kernel/step.c |  2 ++
 kernel/sys_ni.c|  1 +
 8 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b3a1a5d77d92..ede52be845db 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1015,6 +1015,7 @@ config VM86
 config X86_16BIT
bool "Enable support for 16-bit segments" if EXPERT
default y
+   depends on MODIFY_LDT_SYSCALL
---help---
  This option is required by programs like Wine to run 16-bit
  protected mode legacy code on x86 processors.  Disabling
@@ -2053,6 +2054,22 @@ config CMDLINE_OVERRIDE
  This is used to work around broken boot loaders.  This should
  be set to 'N' under normal conditions.
 
+config MODIFY_LDT_SYSCALL
+   bool "Enable the LDT (local descriptor table)" if EXPERT
+   default y
+   ---help---
+ Linux can allow user programs to install a per-process x86
+Local Descriptor Table (LDT) using the modify_ldt(2) system
+call.  This is required to run 16-bit or segmented code such as
+DOSEMU or some Wine programs.  It is also used by some very old
+threading libraries.
+
+Enabling this feature adds a small amount of overhead to
+context switches and increases the low-level kernel attack
+surface.  Disabling it removes the modify_ldt(2) system call.
+
+Saying 'N' here may make sense for embedded or server kernels.
+
 source "kernel/livepatch/Kconfig"
 
 endmenu
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 364d27481a52..55234d5e7160 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,7 +9,9 @@
  * we put the segment information here.
  */
 typedef struct {
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
+#endif
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 3fcff70c398e..08094eded318 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -33,6 +33,7 @@ static inline void load_mm_cr4(struct mm_struct *mm)
 static inline void load_mm_cr4(struct mm_struct *mm) {}
 #endif
 
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
 /*
  * ldt_structs can be allocated, used, and freed, but they are never
  * modified while live.
@@ -48,10 +49,24 @@ struct ldt_struct {
int size;
 };
 
+/*
+ * Used for LDT copy/destruction.
+ */
+int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
+void destroy_context(struct mm_struct *mm);
+#else  /* CONFIG_MODIFY_LDT_SYSCALL */
+static inline int init_new_context(struct task_struct *tsk,
+  struct mm_struct *mm)
+{
+   return 0;
+}
+static inline void destroy_context(struct mm_struct *mm) {}
+#endif
+
 static inline void load_mm_ldt(struct mm_struct *mm)
 {
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
struct ldt_struct *ldt;
-   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
 
/* lockless_dereference synchronizes with smp_store_release */
ldt = lockless_dereference(mm->context.ldt);
@@ -74,14 +89,12 @@ static inline void load_mm_ldt(struct mm_struct *mm)
set_ldt(ldt->entries, ldt->size);
else
clear_LDT();
-}
-
-/*
- * Used for LDT copy/destruction.
- */
-int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
-void destroy_context(struct mm_struct *mm);
+#else
+   clear_LDT();
+#endif
 
+   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
+}
 
 static inline void enter_lazy_tlb(struct mm_struct *mm, struct task_struct 
*tsk)
 {
@@ -113,6 +126,7 @@ static inline void switch_mm(struct mm_struct *prev, struct 
mm_struct *next,
/* Load per-mm CR4 state */
load_mm_cr4(next);
 
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
/*
 * Load the LDT, if the LDT is different.
 *
@@ -127,6 +141,7 @@ static inline void switch_mm(struct mm_struct *prev, struct 
mm_struct *next,
 */
if (unlikely(prev->context.ldt != next->context.ldt))
load_mm_ldt(next);
+#endif
}
 #ifdef CONFIG_SMP
  else {
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 0f15af41bd80..2b507befcd3f 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -24,7 +24,8 @@ CFLAGS_irq.o := 

[PATCH v4 3/3] selftests/x86, x86/ldt: Add a selftest for modify_ldt

[Andy Lutomirski]

This tests general modify_ldt behavior (only writes, so far) as
well as synchronous updates via IPI.  It fails on old kernels.

I called this ldt_gdt because I'll add set_thread_area tests to
it at some point.

Signed-off-by: Andy Lutomirski 
---
 tools/testing/selftests/x86/Makefile  |   2 +-
 tools/testing/selftests/x86/ldt_gdt.c | 492 ++
 2 files changed, 493 insertions(+), 1 deletion(-)
 create mode 100644 tools/testing/selftests/x86/ldt_gdt.c

diff --git a/tools/testing/selftests/x86/Makefile 
b/tools/testing/selftests/x86/Makefile
index caa60d56d7d1..4138387b892c 100644
--- a/tools/testing/selftests/x86/Makefile
+++ b/tools/testing/selftests/x86/Makefile
@@ -4,7 +4,7 @@ include ../lib.mk
 
 .PHONY: all all_32 all_64 warn_32bit_failure clean
 
-TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs
+TARGETS_C_BOTHBITS := sigreturn single_step_syscall sysret_ss_attrs ldt_gdt
 TARGETS_C_32BIT_ONLY := entry_from_vm86
 
 TARGETS_C_32BIT_ALL := $(TARGETS_C_BOTHBITS) $(TARGETS_C_32BIT_ONLY)
diff --git a/tools/testing/selftests/x86/ldt_gdt.c 
b/tools/testing/selftests/x86/ldt_gdt.c
new file mode 100644
index ..7723a12d42e1
--- /dev/null
+++ b/tools/testing/selftests/x86/ldt_gdt.c
@@ -0,0 +1,492 @@
+/*
+ * ldt_gdt.c - Test cases for LDT and GDT access
+ * Copyright (c) 2015 Andrew Lutomirski
+ */
+
+#define _GNU_SOURCE
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AR_ACCESSED(1<<8)
+
+#define AR_TYPE_RODATA (0 * (1<<9))
+#define AR_TYPE_RWDATA (1 * (1<<9))
+#define AR_TYPE_RODATA_EXPDOWN (2 * (1<<9))
+#define AR_TYPE_RWDATA_EXPDOWN (3 * (1<<9))
+#define AR_TYPE_XOCODE (4 * (1<<9))
+#define AR_TYPE_XRCODE (5 * (1<<9))
+#define AR_TYPE_XOCODE_CONF(6 * (1<<9))
+#define AR_TYPE_XRCODE_CONF(7 * (1<<9))
+
+#define AR_DPL3(3 * (1<<13))
+
+#define AR_S   (1 << 12)
+#define AR_P   (1 << 15)
+#define AR_AVL (1 << 20)
+#define AR_L   (1 << 21)
+#define AR_DB  (1 << 22)
+#define AR_G   (1 << 23)
+
+static int nerrs;
+
+static void check_invalid_segment(uint16_t index, int ldt)
+{
+   uint32_t has_limit = 0, has_ar = 0, limit, ar;
+   uint32_t selector = (index << 3) | (ldt << 2) | 3;
+
+   asm ("lsl %[selector], %[limit]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_limit]\n\t"
+"1:"
+: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
+: [selector] "r" (selector));
+   asm ("larl %[selector], %[ar]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_ar]\n\t"
+"1:"
+: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
+: [selector] "r" (selector));
+
+   if (has_limit || has_ar) {
+   printf("[FAIL]\t%s entry %hu is valid but should be invalid\n",
+  (ldt ? "LDT" : "GDT"), index);
+   nerrs++;
+   } else {
+   printf("[OK]\t%s entry %hu is invalid\n",
+  (ldt ? "LDT" : "GDT"), index);
+   }
+}
+
+static void check_valid_segment(uint16_t index, int ldt,
+   uint32_t expected_ar, uint32_t expected_limit)
+{
+   uint32_t has_limit = 0, has_ar = 0, limit, ar;
+   uint32_t selector = (index << 3) | (ldt << 2) | 3;
+
+   asm ("lsl %[selector], %[limit]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_limit]\n\t"
+"1:"
+: [limit] "=r" (limit), [has_limit] "+rm" (has_limit)
+: [selector] "r" (selector));
+   asm ("larl %[selector], %[ar]\n\t"
+"jnz 1f\n\t"
+"movl $1, %[has_ar]\n\t"
+"1:"
+: [ar] "=r" (ar), [has_ar] "+rm" (has_ar)
+: [selector] "r" (selector));
+
+   if (!has_limit || !has_ar) {
+   printf("[FAIL]\t%s entry %hu is invalid but should be valid\n",
+  (ldt ? "LDT" : "GDT"), index);
+   nerrs++;
+   return;
+   }
+
+   if (ar != expected_ar) {
+   printf("[FAIL]\t%s entry %hu has AR 0x%08X but expected 
0x%08X\n",
+  (ldt ? "LDT" : "GDT"), index, ar, expected_ar);
+   nerrs++;
+   } else if (limit != expected_limit) {
+   printf("[FAIL]\t%s entry %hu has limit 0x%08X but expected 
0x%08X\n",
+  (ldt ? "LDT" : "GDT"), index, limit, expected_limit);
+   nerrs++;
+   } else {
+   printf("[OK]\t%s entry %hu has AR 0x%08X and limit 0x%08X\n",
+  (ldt ? "LDT" : "GDT"), index, ar, limit);
+   }
+}
+
+static bool install_valid_mode(const struct user_desc *desc, uint32_t ar,
+  bool oldmode)
+{

[PATCH v4 0/3] x86: modify_ldt improvement, test, and config option

[Andy Lutomirski]

Here's v3.  It fixes the "dazed and confused" issue, I hope.  It's also
probably a good general attack surface reduction, and it replaces some
scary code with IMO less scary code.

Also, servers and embedded systems should probably turn off modify_ldt.
This makes that possible.

Xen people, can you take a look at this?

Willy and Kees: I left the config option alone.  The -tiny people will
like it, and we can always add a sysctl of some sort later.

Changes from v3:
 - Hopefully fixed Xen.
 - Fixed 32-bit test case on 32-bit native kernel.
 - Fix bogus vumnap for some LDT sizes.
 - Strengthen test case to check all LDT sizes (catches bogus vunmap).
 - Lots of cleanups, mostly from Borislav.
 - Simplify IPI code using on_each_cpu_mask.

Changes from v2:
 - Allocate ldt_struct and the LDT entries separately.  This should fix Xen.
 - Stop using write_ldt_entry, since I'm pretty sure it's unnecessary now
   that we no longer mutate an in-use LDT.  (Xen people, can you check?)

Changes from v1:
 - The config option is new.
 - The test case is new.
 - Fixed a missing allocation failure check.
 - Fixed a use-after-free on fork().

Andy Lutomirski (3):
  x86/ldt: Make modify_ldt synchronous
  x86/ldt: Make modify_ldt optional
  selftests/x86, x86/ldt: Add a selftest for modify_ldt

 arch/x86/Kconfig  |  17 ++
 arch/x86/include/asm/desc.h   |  15 --
 arch/x86/include/asm/mmu.h|   5 +-
 arch/x86/include/asm/mmu_context.h|  68 -
 arch/x86/kernel/Makefile  |   3 +-
 arch/x86/kernel/cpu/common.c  |   4 +-
 arch/x86/kernel/cpu/perf_event.c  |  16 +-
 arch/x86/kernel/ldt.c | 262 +-
 arch/x86/kernel/process_64.c  |   6 +-
 arch/x86/kernel/step.c|   8 +-
 arch/x86/power/cpu.c  |   3 +-
 kernel/sys_ni.c   |   1 +
 tools/testing/selftests/x86/Makefile  |   2 +-
 tools/testing/selftests/x86/ldt_gdt.c | 492 ++
 14 files changed, 747 insertions(+), 155 deletions(-)
 create mode 100644 tools/testing/selftests/x86/ldt_gdt.c

-- 
2.4.3

--
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/

[PATCH v4 1/3] x86/ldt: Make modify_ldt synchronous

[Andy Lutomirski]

modify_ldt has questionable locking and does not synchronize
threads.  Improve it: redesign the locking and synchronize all
threads' LDTs using an IPI on all modifications.

This will dramatically slow down modify_ldt in multithreaded
programs, but there shouldn't be any multithreaded programs that
care about modify_ldt's performance in the first place.

Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/desc.h|  15 ---
 arch/x86/include/asm/mmu.h |   3 +-
 arch/x86/include/asm/mmu_context.h |  53 +++-
 arch/x86/kernel/cpu/common.c   |   4 +-
 arch/x86/kernel/cpu/perf_event.c   |  12 +-
 arch/x86/kernel/ldt.c  | 262 -
 arch/x86/kernel/process_64.c   |   4 +-
 arch/x86/kernel/step.c |   6 +-
 arch/x86/power/cpu.c   |   3 +-
 9 files changed, 209 insertions(+), 153 deletions(-)

diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a0bf89fd2647..4e10d73cf018 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -280,21 +280,6 @@ static inline void clear_LDT(void)
set_ldt(NULL, 0);
 }
 
-/*
- * load one particular LDT into the current CPU
- */
-static inline void load_LDT_nolock(mm_context_t *pc)
-{
-   set_ldt(pc->ldt, pc->size);
-}
-
-static inline void load_LDT(mm_context_t *pc)
-{
-   preempt_disable();
-   load_LDT_nolock(pc);
-   preempt_enable();
-}
-
 static inline unsigned long get_desc_base(const struct desc_struct *desc)
 {
return (unsigned)(desc->base0 | ((desc->base1) << 16) | ((desc->base2) 
<< 24));
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index 09b9620a73b4..364d27481a52 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -9,8 +9,7 @@
  * we put the segment information here.
  */
 typedef struct {
-   void *ldt;
-   int size;
+   struct ldt_struct *ldt;
 
 #ifdef CONFIG_X86_64
/* True if mm supports a task running in 32 bit compatibility mode. */
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 804a3a6030ca..3fcff70c398e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -34,6 +34,49 @@ static inline void load_mm_cr4(struct mm_struct *mm) {}
 #endif
 
 /*
+ * ldt_structs can be allocated, used, and freed, but they are never
+ * modified while live.
+ */
+struct ldt_struct {
+   /*
+* Xen requires page-aligned LDTs with special permissions.  This is
+* needed to prevent us from installing evil descriptors such as
+* call gates.  On native, we could merge the ldt_struct and LDT
+* allocations, but it's not worth trying to optimize.
+*/
+   struct desc_struct *entries;
+   int size;
+};
+
+static inline void load_mm_ldt(struct mm_struct *mm)
+{
+   struct ldt_struct *ldt;
+   DEBUG_LOCKS_WARN_ON(!irqs_disabled());
+
+   /* lockless_dereference synchronizes with smp_store_release */
+   ldt = lockless_dereference(mm->context.ldt);
+
+   /*
+* Any change to mm->context.ldt is followed by an IPI to all
+* CPUs with the mm active.  The LDT will not be freed until
+* after the IPI is handled by all such CPUs.  This means that,
+* if the ldt_struct changes before we return, the values we see
+* will be safe, and the new values will be loaded before we run
+* any user code.
+*
+* NB: don't try to convert this to use RCU without extreme care.
+* We would still need IRQs off, because we don't want to change
+* the local LDT after an IPI loaded a newer value than the one
+* that we can see.
+*/
+
+   if (unlikely(ldt))
+   set_ldt(ldt->entries, ldt->size);
+   else
+   clear_LDT();
+}
+
+/*
  * Used for LDT copy/destruction.
  */
 int init_new_context(struct task_struct *tsk, struct mm_struct *mm);
@@ -78,12 +121,12 @@ static inline void switch_mm(struct mm_struct *prev, 
struct mm_struct *next,
 * was called and then modify_ldt changed
 * prev->context.ldt but suppressed an IPI to this CPU.
 * In this case, prev->context.ldt != NULL, because we
-* never free an LDT while the mm still exists.  That
-* means that next->context.ldt != prev->context.ldt,
-* because mms never share an LDT.
+* never set context.ldt to NULL while the mm still
+* exists.  That means that next->context.ldt !=
+* prev->context.ldt, because mms never share an LDT.
 */
if (unlikely(prev->context.ldt != next->context.ldt))
-   load_LDT_nolock(>context);
+   load_mm_ldt(next);
}
 #ifdef CONFIG_SMP
  else {
@@ -106,7 +149,7 @@ static inline void 

Re: [PATCH V2 net-next 0/3] ARM BPF JIT features

[David Miller]

From: Nicolas Schichan 
Date: Tue, 21 Jul 2015 14:16:37 +0200

> This serie adds support for more instructions to the ARM BPF JIT

"series"

> namely skb netdevice type retrieval, skb payload offset retrieval, and
> skb packet type retrieval.
> 
> This allows 35 tests to use the JIT instead of 29 before.
> 
> This serie depends on the "BPF JIT fixes for ARM" serie sent earlier.

"series"

But even with that series applied these patches do not apply properly
at all.

davem@greenl8ke:~/src/GIT/net-next$ git am --signoff 
bundle-8569-arm-bpf-next.mbox 
Applying: ARM: net: add support for BPF_ANC | SKF_AD_PKTTYPE in ARM JIT.
error: patch failed: arch/arm/net/bpf_jit_32.c:864
error: arch/arm/net/bpf_jit_32.c: patch does not apply
Patch failed at 0001 ARM: net: add support for BPF_ANC | SKF_AD_PKTTYPE in ARM 
JIT.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

Please respin against net-next, thanks.
--
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 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Andy Lutomirski]

On Fri, Jul 24, 2015 at 9:32 PM, Borislav Petkov  wrote:
> On Fri, Jul 24, 2015 at 09:28:47PM -0700, Andy Lutomirski wrote:
>> Yeah, I'm going to submit v2 with the simple approach.  I admit I'm
>> rather fond of xadd as a way to switch rsp and set a flag at the same
>> time, though :)
>
> I know you are.
>
> But people will rip your head out if you added 60 cycles to the IRQ
> path.

And people will give me five new heads if I ignore Linus and do RET
even with IF=1, saving 300 cycles?

--Andy
--
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 v3 1/3] x86/ldt: Make modify_ldt synchronous

[Andy Lutomirski]

On Fri, Jul 24, 2015 at 9:13 PM, Boris Ostrovsky
 wrote:
>
>
> On 07/22/2015 06:20 PM, Boris Ostrovsky wrote:
>>
>> On 07/22/2015 03:23 PM, Andy Lutomirski wrote:
>>>
>>>
>>> +error = -ENOMEM;
>>> +new_ldt = alloc_ldt_struct(newsize);
>>> +if (!new_ldt)
>>>   goto out_unlock;
>>> -}
>>>   -fill_ldt(, _info);
>>> -if (oldmode)
>>> -ldt.avl = 0;
>>> +if (old_ldt) {
>>> +memcpy(new_ldt->entries, old_ldt->entries,
>>> +   oldsize * LDT_ENTRY_SIZE);
>>> +}
>>> +memset(new_ldt->entries + oldsize * LDT_ENTRY_SIZE, 0,
>>> +   (newsize - oldsize) * LDT_ENTRY_SIZE);
>>
>>
>> We need to zero out full page (probably better in alloc_ldt_struct() with
>> vmzalloc/__GFP_ZERO) --- Xen checks whole page that is assigned to  G/LDT
>> and gets unhappy if an invalid descriptor is found there.
>>
>> This fixes one problem. There is something else that Xen gets upset about,
>> I haven't figured what it is yet (and I am out tomorrow so it may need to
>> wait until Friday).
>>
>
>
> What I thought was another problem turned out not to be one so both 64- and
> 32-bit tests passed on 64-bit PV (when allocated LDT is zeroed out)
>
> However, on 32-bit kernel the test is failing multicpu test, I don't know
> yet what it is.

Test case bug or unrelated kernel bug depending on your point of view.
I forgot that x86_32 and x86_64 have very different handling of IRET
faults.  Wait for v2 :)

--Andy
--
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 v3 1/3] x86/ldt: Make modify_ldt synchronous

[Andy Lutomirski]

On Fri, Jul 24, 2015 at 8:29 AM, Borislav Petkov  wrote:
> Let it stick out:
>
> if (!cpumask_equal(mm_cpumask(current_mm), 
> cpumask_of(smp_processor_id(
> smp_call_function(flush_ldt, current_mm, 1);

I see your wide terminal and raise you a complete rewrite of that
function.  Sigh, why did I assume the old code was the right way to do
it?

>>  #endif
>> - }
>> - if (oldsize) {
>> - paravirt_free_ldt(oldldt, oldsize);
>> - if (oldsize * LDT_ENTRY_SIZE > PAGE_SIZE)
>> - vfree(oldldt);
>> - else
>> - put_page(virt_to_page(oldldt));
>> - }
>> - return 0;
>> + preempt_enable();
>>  }
>>
>> -static inline int copy_ldt(mm_context_t *new, mm_context_t *old)
>> +static void free_ldt_struct(struct ldt_struct *ldt)
>>  {
>> - int err = alloc_ldt(new, old->size, 0);
>> - int i;
>> -
>> - if (err < 0)
>> - return err;
>> -
>> - for (i = 0; i < old->size; i++)
>> - write_ldt_entry(new->ldt, i, old->ldt + i * LDT_ENTRY_SIZE);
>> - return 0;
>> + if (unlikely(ldt)) {
>
> Save an indentation level:
>
> int alloc_size;
>
> if (!ldt)
> return;
>
> alloc_size = sizeof(struct ldt_struct) + ldt->size * LDT_ENTRY_SIZE;
>

Hah¸ we both missed it.  This is wrong.  (Fix your backport!)

> ...
>
>> + paravirt_free_ldt(ldt->entries, ldt->size);
>> + if (alloc_size > PAGE_SIZE)
>> + vfree(ldt->entries);
>> + else
>> + put_page(virt_to_page(ldt->entries));

I'm not sure this is correct, so I changed it to something obviously
correct (kmalloc/kfree).

>>
>> - fill_ldt(, _info);
>> - if (oldmode)
>> - ldt.avl = 0;
>> + if (old_ldt) {
>> + memcpy(new_ldt->entries, old_ldt->entries,
>> +oldsize * LDT_ENTRY_SIZE);
>> + }
>
> Single if-statement doesn't need {} and you don't absolutely need to
> keep 80cols. Just let it stick out.

You read too many of Linus' comments about using wider terminals :)

--Andy
--
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 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Borislav Petkov]

On Fri, Jul 24, 2015 at 09:28:47PM -0700, Andy Lutomirski wrote:
> Yeah, I'm going to submit v2 with the simple approach.  I admit I'm
> rather fond of xadd as a way to switch rsp and set a flag at the same
> time, though :)

I know you are.

But people will rip your head out if you added 60 cycles to the IRQ
path.

:-)

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Andy Lutomirski]

On Fri, Jul 24, 2015 at 9:16 PM, Borislav Petkov  wrote:
> On Fri, Jul 24, 2015 at 11:02:51AM -0700, Andy Lutomirski wrote:
>> So really the only difference between this simple approach (which is
>> more or less what we do now) and my fancy approach is that a kernel
>> instruction breakpoint will cause do_debug to run on the initial stack
>> instead of the IRQ stack.
>
> Sounds ok to me. What would be the worst thing if we limited the #DB
> stack? Some breakpoints will get ignored? In an endless stream of
> breakpoints hammering? Doesn't sound like a valid use case to me, does
> it?
>
>> I'm still tempted to say we should use my overly paranoid atomic
>> approach for now and optimize later,...
>
> But why change it if the simple approach of incrementing irq_count first
> is still fine? I think we want to KISS here exactly because apparently
> complexity in that area is a serious PITA...

Yeah, I'm going to submit v2 with the simple approach.  I admit I'm
rather fond of xadd as a way to switch rsp and set a flag at the same
time, though :)

--Andy
--
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 1/3] x86/entry/64: Refactor IRQ stacks and make then NMI-safe

[Borislav Petkov]

On Fri, Jul 24, 2015 at 11:02:51AM -0700, Andy Lutomirski wrote:
> So really the only difference between this simple approach (which is
> more or less what we do now) and my fancy approach is that a kernel
> instruction breakpoint will cause do_debug to run on the initial stack
> instead of the IRQ stack.

Sounds ok to me. What would be the worst thing if we limited the #DB
stack? Some breakpoints will get ignored? In an endless stream of
breakpoints hammering? Doesn't sound like a valid use case to me, does
it?

> I'm still tempted to say we should use my overly paranoid atomic
> approach for now and optimize later,...

But why change it if the simple approach of incrementing irq_count first
is still fine? I think we want to KISS here exactly because apparently
complexity in that area is a serious PITA...

-- 
Regards/Gruss,
Boris.

ECO tip #101: Trim your mails when you reply.
--
--
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 v3 1/3] x86/ldt: Make modify_ldt synchronous

[Boris Ostrovsky]

On 07/22/2015 06:20 PM, Boris Ostrovsky wrote:

On 07/22/2015 03:23 PM, Andy Lutomirski wrote:


+error = -ENOMEM;
+new_ldt = alloc_ldt_struct(newsize);
+if (!new_ldt)
  goto out_unlock;
-}
  -fill_ldt(, _info);
-if (oldmode)
-ldt.avl = 0;
+if (old_ldt) {
+memcpy(new_ldt->entries, old_ldt->entries,
+   oldsize * LDT_ENTRY_SIZE);
+}
+memset(new_ldt->entries + oldsize * LDT_ENTRY_SIZE, 0,
+   (newsize - oldsize) * LDT_ENTRY_SIZE);


We need to zero out full page (probably better in alloc_ldt_struct() 
with vmzalloc/__GFP_ZERO) --- Xen checks whole page that is assigned 
to  G/LDT and gets unhappy if an invalid descriptor is found there.


This fixes one problem. There is something else that Xen gets upset 
about, I haven't figured what it is yet (and I am out tomorrow so it 
may need to wait until Friday).





What I thought was another problem turned out not to be one so both 64- 
and 32-bit tests passed on 64-bit PV (when allocated LDT is zeroed out)


However, on 32-bit kernel the test is failing multicpu test, I don't 
know yet what it is.


-boris


--
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/

[PATCH v2] power_supply: bq24735: Convert to using managed resources

[Vaishali Thakkar]

Use managed resource functions like devm_kasprintf and
devm_power_supply_register in bq24735_charger_probe. To be
compatible with the change, replace various gotos by direct
returns and drop unneeded labels.

Also, remove bq24735_charger_remove as it is now redundant.

Signed-off-by: Vaishali Thakkar 
---
Changes since v2:
- Use devm_power_supply_register
- Remove bq24735_charger_remove
- Improve commit log
---
 drivers/power/bq24735-charger.c | 51 +++--
 1 file changed, 13 insertions(+), 38 deletions(-)

diff --git a/drivers/power/bq24735-charger.c b/drivers/power/bq24735-charger.c
index b017437..eb2b368 100644
--- a/drivers/power/bq24735-charger.c
+++ b/drivers/power/bq24735-charger.c
@@ -267,8 +267,9 @@ static int bq24735_charger_probe(struct i2c_client *client,
 
name = (char *)charger->pdata->name;
if (!name) {
-   name = kasprintf(GFP_KERNEL, "bq24735@%s",
-dev_name(>dev));
+   name = devm_kasprintf(>dev, GFP_KERNEL,
+ "bq24735@%s",
+ dev_name(>dev));
if (!name) {
dev_err(>dev, "Failed to alloc device name\n");
return -ENOMEM;
@@ -296,23 +297,21 @@ static int bq24735_charger_probe(struct i2c_client 
*client,
if (ret < 0) {
dev_err(>dev, "Failed to read manufacturer id : %d\n",
ret);
-   goto err_free_name;
+   return ret;
} else if (ret != 0x0040) {
dev_err(>dev,
"manufacturer id mismatch. 0x0040 != 0x%04x\n", ret);
-   ret = -ENODEV;
-   goto err_free_name;
+   return -ENODEV;
}
 
ret = bq24735_read_word(client, BQ24735_DEVICE_ID);
if (ret < 0) {
dev_err(>dev, "Failed to read device id : %d\n", ret);
-   goto err_free_name;
+   return ret;
} else if (ret != 0x000B) {
dev_err(>dev,
"device id mismatch. 0x000b != 0x%04x\n", ret);
-   ret = -ENODEV;
-   goto err_free_name;
+   return -ENODEV;
}
 
if (gpio_is_valid(charger->pdata->status_gpio)) {
@@ -331,7 +330,7 @@ static int bq24735_charger_probe(struct i2c_client *client,
ret = bq24735_config_charger(charger);
if (ret < 0) {
dev_err(>dev, "failed in configuring charger");
-   goto err_free_name;
+   return ret;
}
 
/* check for AC adapter presence */
@@ -339,17 +338,17 @@ static int bq24735_charger_probe(struct i2c_client 
*client,
ret = bq24735_enable_charging(charger);
if (ret < 0) {
dev_err(>dev, "Failed to enable charging\n");
-   goto err_free_name;
+   return ret;
}
}
 
-   charger->charger = power_supply_register(>dev, supply_desc,
-_cfg);
+   charger->charger = devm_power_supply_register(>dev, supply_desc,
+ _cfg);
if (IS_ERR(charger->charger)) {
ret = PTR_ERR(charger->charger);
dev_err(>dev, "Failed to register power supply: %d\n",
ret);
-   goto err_free_name;
+   return ret;
}
 
if (client->irq) {
@@ -364,34 +363,11 @@ static int bq24735_charger_probe(struct i2c_client 
*client,
dev_err(>dev,
"Unable to register IRQ %d err %d\n",
client->irq, ret);
-   goto err_unregister_supply;
+   return ret;
}
}
 
return 0;
-err_unregister_supply:
-   power_supply_unregister(charger->charger);
-err_free_name:
-   if (name != charger->pdata->name)
-   kfree(name);
-
-   return ret;
-}
-
-static int bq24735_charger_remove(struct i2c_client *client)
-{
-   struct bq24735 *charger = i2c_get_clientdata(client);
-
-   if (charger->client->irq)
-   devm_free_irq(>client->dev, charger->client->irq,
- >charger);
-
-   power_supply_unregister(charger->charger);
-
-   if (charger->charger_desc.name != charger->pdata->name)
-   kfree(charger->charger_desc.name);
-
-   return 0;
 }
 
 static const struct i2c_device_id bq24735_charger_id[] = {
@@ -412,7 +388,6 @@ static struct i2c_driver bq24735_charger_driver = {
.of_match_table = bq24735_match_ids,
},
.probe = bq24735_charger_probe,
-   .remove = bq24735_charger_remove,
.id_table = bq24735_charger_id,
 };
 
-- 
1.9.1

--
To unsubscribe from this 

[PATCHv2] clk: socfpga: Add a second parent option for the dbg_base_clk

[dinguyen]

From: Dinh Nguyen 

The debug base clock can be bypassed from the main PLL to the OSC1 clock.
The bypass register is the staysoc1(0x10) register that is in the clock
manager.

This patch adds the option to get the correct parent for the debug base
clock.

Signed-off-by: Dinh Nguyen 
---
v2: remove changes to socfpga.dtsi
---
 drivers/clk/socfpga/clk-periph.c | 18 ++
 drivers/clk/socfpga/clk.h|  1 +
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/clk/socfpga/clk-periph.c b/drivers/clk/socfpga/clk-periph.c
index 0c66863..52c883e 100644
--- a/drivers/clk/socfpga/clk-periph.c
+++ b/drivers/clk/socfpga/clk-periph.c
@@ -44,8 +44,17 @@ static unsigned long clk_periclk_recalc_rate(struct clk_hw 
*hwclk,
return parent_rate / div;
 }
 
+static u8 clk_periclk_get_parent(struct clk_hw *hwclk)
+{
+   u32 clk_src;
+
+   clk_src = readl(clk_mgr_base_addr + CLKMGR_DBCTRL);
+   return clk_src & 0x1;
+}
+
 static const struct clk_ops periclk_ops = {
.recalc_rate = clk_periclk_recalc_rate,
+   .get_parent = clk_periclk_get_parent,
 };
 
 static __init void __socfpga_periph_init(struct device_node *node,
@@ -55,7 +64,7 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
struct clk *clk;
struct socfpga_periph_clk *periph_clk;
const char *clk_name = node->name;
-   const char *parent_name;
+   const char *parent_name[SOCFPGA_MAX_PARENTS];
struct clk_init_data init;
int rc;
u32 fixed_div;
@@ -89,9 +98,10 @@ static __init void __socfpga_periph_init(struct device_node 
*node,
init.name = clk_name;
init.ops = ops;
init.flags = 0;
-   parent_name = of_clk_get_parent_name(node, 0);
-   init.parent_names = _name;
-   init.num_parents = 1;
+
+   init.num_parents = of_clk_parent_fill(node, parent_name,
+ SOCFPGA_MAX_PARENTS);
+   init.parent_names = parent_name;
 
periph_clk->hw.hw.init = 
 
diff --git a/drivers/clk/socfpga/clk.h b/drivers/clk/socfpga/clk.h
index aa2741d..814c724 100644
--- a/drivers/clk/socfpga/clk.h
+++ b/drivers/clk/socfpga/clk.h
@@ -22,6 +22,7 @@
 /* Clock Manager offsets */
 #define CLKMGR_CTRL0x0
 #define CLKMGR_BYPASS  0x4
+#define CLKMGR_DBCTRL  0x10
 #define CLKMGR_L4SRC   0x70
 #define CLKMGR_PERPLL_SRC  0xAC
 
-- 
2.4.5

--
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:REGARDS

[Alexander Flockhart]

Dear Friend , 


I have a good business proposal for you , 
it's easy and no risk involve, 
please get back to me for brief details 


Regards
 
Alexander Flockhart 
--
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 v7 4/5] ARM: dts: vf610twr: add NAND flash controller peripherial

[Shawn Guo]

On Fri, Jul 24, 2015 at 03:16:23PM +0200, Stefan Agner wrote:
> This adds the NAND flash controller (NFC) peripherial. The driver
> supports the SLC NAND chips found on Freescale's Vybrid Tower System
> Module. The Micron NAND chip on the module needs 4-bit ECC per 512
> byte page. Use 24-bit ECC per 2k page, which is supported by the
> driver.
> 
> Signed-off-by: Bill Pringlemeir 
> Signed-off-by: Stefan Agner 
> ---
>  arch/arm/boot/dts/vf610-twr.dts | 44 
> +
>  arch/arm/boot/dts/vfxxx.dtsi|  8 
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
> index 375ab23..0b2b932 100644
> --- a/arch/arm/boot/dts/vf610-twr.dts
> +++ b/arch/arm/boot/dts/vf610-twr.dts
> @@ -287,6 +287,50 @@
>   status = "okay";
>  };
>  
> + {
> + vf610-twr {
> + pinctrl_nfc_1: nfcgrp_1 {

The suffix "_1" is meaningless.  Please drop it here as well as patch
#5.

Shawn

> + fsl,pins = <
> + VF610_PAD_PTD31__NF_IO150x28df
> + VF610_PAD_PTD30__NF_IO140x28df
> + VF610_PAD_PTD29__NF_IO130x28df
> + VF610_PAD_PTD28__NF_IO120x28df
> + VF610_PAD_PTD27__NF_IO110x28df
> + VF610_PAD_PTD26__NF_IO100x28df
> + VF610_PAD_PTD25__NF_IO9 0x28df
> + VF610_PAD_PTD24__NF_IO8 0x28df
> + VF610_PAD_PTD23__NF_IO7 0x28df
> + VF610_PAD_PTD22__NF_IO6 0x28df
> + VF610_PAD_PTD21__NF_IO5 0x28df
> + VF610_PAD_PTD20__NF_IO4 0x28df
> + VF610_PAD_PTD19__NF_IO3 0x28df
> + VF610_PAD_PTD18__NF_IO2 0x28df
> + VF610_PAD_PTD17__NF_IO1 0x28df
> + VF610_PAD_PTD16__NF_IO0 0x28df
> + VF610_PAD_PTB24__NF_WE_B0x28c2
> + VF610_PAD_PTB25__NF_CE0_B   0x28c2
> + VF610_PAD_PTB27__NF_RE_B0x28c2
> + VF610_PAD_PTC26__NF_RB_B0x283d
> + VF610_PAD_PTC27__NF_ALE 0x28c2
> + VF610_PAD_PTC28__NF_CLE 0x28c2
> + >;
> + };
> + };
> +};
> +
> + {
> + assigned-clocks = < VF610_CLK_NFC>;
> + assigned-clock-rates = <3300>;
> + nand-bus-width = <16>;
> + nand-ecc-mode = "hw";
> + nand-ecc-step-size = <2048>;
> + nand-ecc-strength = <24>;
> + nand-on-flash-bbt;
> + pinctrl-names = "default";
> + pinctrl-0 = <_nfc_1>;
> + status = "okay";
> +};
> +
>   {
>   pinctrl-names = "default";
>   pinctrl-0 = <_uart1>;
> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> index 4aa3351..2f4b04d 100644
> --- a/arch/arm/boot/dts/vfxxx.dtsi
> +++ b/arch/arm/boot/dts/vfxxx.dtsi
> @@ -520,6 +520,14 @@
>   status = "disabled";
>   };
>  
> + nfc: nand@400e {
> + compatible = "fsl,vf610-nfc";
> + reg = <0x400e 0x4000>;
> + interrupts = <83 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = < VF610_CLK_NFC>;
> + clock-names = "nfc";
> + status = "disabled";
> + };
>   };
>   };
>  };
> -- 
> 2.4.5
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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 v12 4/6] arm/dts/ls1021a: Add DCU dts node

[Shawn Guo]

On Fri, Jul 24, 2015 at 06:34:12PM +0800, Jianwei Wang wrote:
> Add DCU node, DCU is a display controller of Freescale
> named 2D-ACE.
> 
> Signed-off-by: Alison Wang 
> Signed-off-by: Xiubo Li 
> Signed-off-by: Jianwei Wang 

For dts patches sent to me, please use prefix like "ARM: dts: ls1021a:
..." in the subject.

Shawn

> ---
>  arch/arm/boot/dts/ls1021a.dtsi | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
> index c70bb27..6d6e3e2 100644
> --- a/arch/arm/boot/dts/ls1021a.dtsi
> +++ b/arch/arm/boot/dts/ls1021a.dtsi
> @@ -383,6 +383,16 @@
><_clk 1>;
>   };
>  
> + dcu: dcu@2ce {
> + compatible = "fsl,ls1021a-dcu";
> + reg = <0x0 0x2ce 0x0 0x1>;
> + interrupts = ;
> + clocks = <_clk 0>;
> + clock-names = "dcu";
> + big-endian;
> + status = "disabled";
> + };
> +
>   mdio0: mdio@2d24000 {
>   compatible = "gianfar";
>   device_type = "mdio";
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
--
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] mn10300: time: Provide 64-bit persistent clock time

[John Stultz]

On Mon, Jul 20, 2015 at 5:45 PM, Xunlei Pang  wrote:
> From: Xunlei Pang 
>
> As part of addressing the "y2038 problem" for in-kernel uses,
> convert update_persistent_clock() to update_persistent_clock64(),
> read_persistent_clock() to read_persistent_clock64() using
> timespec64 for MN10300.

The arch changes look ok.


> Add the common weak version of update_persistent_clock() to make
> the compiler happy, since we don't have any update_persistent_clock()
> defined for MN10300 after converting it to update_persistent_clock64().

So it wasn't immediately obvious why this was needed (compiler
unhappiness isn't really a good explanation). Looking at it, it seems
that the weak update_persistent_clock64() wants a
update_persistent_clock() call to exist (which probably should have
been added when the weak update_persistent_clock64 was added). So it
looks like even if the arch defines a  update_persistent_clock64(),
the weak one still throws a undefined symbol compiler error, right?

The weak update_persistent_clock() bit should probably be added in a
separate patch,  since its not really tied to this arch change (really
any arch that switches to update_persistent_clock64 would have this
issue, no?).

thanks
-john
--
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 v3 3/3] dt-binding:Documents the mbigen bindings

[majun (F)]

Hi Mark:

在 2015/7/21 0:38, Mark Rutland 写道:
 +The mbigen and devices connect to mbigen have the following properties:
>> The mbigen chip structrue likes below:
>>
>>  mbigen_chip(domain)
>>  ||--|
>> mbigen_node0 mbigen_node1mbigen_node2
>> ||   |   |   |   |
>> dev1 dev2dev3dev4dev5dev6
>>
>> For each mbigen chip, it contains several mbigen nodes.
>> For each mbigen node, it can collect interrupts from different devices.
>>
>> For example, dev1 and dev2 both connect to mbigen node0.Because dev1 and 
>> dev2 are
>> differnt device, they have different device id.
>>
>> The device id is encoded in mbigen chip and can not be changed.
> 
> Thanks for the diagram, that clears up some of my confusion regarding
> nodes.
> 
> Ok, so each device has it's own device ID. That's good. If a device has
> multiple interrupt lines to the mbigen, do these always share the same
> device ID?
> 
yes, for the interrupt lines within a device, they always share the same
device ID.
 +  The 2nd cell is the totall interrupt number of this device?
>>>
>>> I don't follow. What is a "total interrupt number"?
>>>
>> It's the wired interrupt number connected to a device.
>> For the devices connected to mbigen node, the interrupt number  varied from
>> 1 to 100+ .So I have to specifies this value in dts.
>>
 +  The 3rd cell is the hardware pin number of the interrupt.
 +  This value depends on the Soc design.
>>>
>>> This property seems sane.
>>>
 +  The 4th cell is the mbigen node number. This value should refer to the
 +  vendor soc specification.
>>>
>>> What is this, and why do you think you need it?
>>>
>>> Surely the address of the mbigen node is a sufficient unique identifier?
>>>
>>  mbigen_chip(domain)
>>  ||--|
>> mbigen_node0 mbigen_node1mbigen_node2
>> ||   |   |   |   |
>> dev1 dev2dev3dev4dev5dev6
>>
>> To avoid the duplicat hardware irq number problem, the Mbigen node number is 
>> defined here.
>> For example:
>> dev1 has 3 interrupts with pin number from 0 to 2
>> dev3 has 5 interrupts with pin number from 0 to 4
>> For dev3 the interrupt from 0 to 2 would be has same hardware irq number
>> as dev1 if we only use pin number.
>>
>> Because these two devices located in same irq domain(mbigen chip),using same
>> hwirq number is a mistake.
>>
>> In mbigen driver, I will use this value and  the 3rd cell(pin number) to 
>> compose
>> a new hardware irq( (nid<<8) | pin number) for mbigen using.
> 
> Ok. I now see why you need node and pin.
> 
> However, I don't see why you also need the 'total' interrupt number. Why
> isn't node and pin sufficient to uniquely identify an interrupt?
> 
The ITS driver alloc a ITT table for each device.
The table size depends on interrupt number of the device.
So I need to specify the total interrupt number .



> Thanks,
> Mark.
> 
> .
> 

--
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/

[PATCH v2 05/25] arch, drivers: don't include directly, use instead

[Dan Williams]

Preparation for uniform definition of ioremap, ioremap_wc, ioremap_wt,
and ioremap_cache, tree-wide.

Acked-by: Christoph Hellwig 
Signed-off-by: Dan Williams 
---
 arch/arm/mach-shmobile/pm-rcar.c|2 +-
 arch/ia64/kernel/cyclone.c  |2 +-
 drivers/isdn/icn/icn.h  |2 +-
 drivers/mtd/devices/slram.c |2 +-
 drivers/mtd/nand/diskonchip.c   |2 +-
 drivers/mtd/onenand/generic.c   |2 +-
 drivers/scsi/sun3x_esp.c|2 +-
 drivers/staging/comedi/drivers/ii_pci20kc.c |1 +
 drivers/tty/serial/8250/8250_core.c |2 +-
 drivers/video/fbdev/s1d13xxxfb.c|3 +--
 drivers/video/fbdev/stifb.c |1 +
 include/linux/io-mapping.h  |2 +-
 include/linux/mtd/map.h |2 +-
 include/video/vga.h |2 +-
 14 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-shmobile/pm-rcar.c b/arch/arm/mach-shmobile/pm-rcar.c
index 00022ee56f80..9d3dde00c2fe 100644
--- a/arch/arm/mach-shmobile/pm-rcar.c
+++ b/arch/arm/mach-shmobile/pm-rcar.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include "pm-rcar.h"
 
 /* SYSC */
diff --git a/arch/ia64/kernel/cyclone.c b/arch/ia64/kernel/cyclone.c
index 4826ff957a3d..5fa3848ba224 100644
--- a/arch/ia64/kernel/cyclone.c
+++ b/arch/ia64/kernel/cyclone.c
@@ -4,7 +4,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /* IBM Summit (EXA) Cyclone counter code*/
 #define CYCLONE_CBAR_ADDR 0xFEB00CD0
diff --git a/drivers/isdn/icn/icn.h b/drivers/isdn/icn/icn.h
index b713466997a0..f8f2e76d34bf 100644
--- a/drivers/isdn/icn/icn.h
+++ b/drivers/isdn/icn/icn.h
@@ -38,7 +38,7 @@ typedef struct icn_cdef {
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
diff --git a/drivers/mtd/devices/slram.c b/drivers/mtd/devices/slram.c
index 2fc4957cbe7f..a70eb83e68f1 100644
--- a/drivers/mtd/devices/slram.c
+++ b/drivers/mtd/devices/slram.c
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index 7da266a53979..0802158a3f75 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -24,7 +24,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/mtd/onenand/generic.c b/drivers/mtd/onenand/generic.c
index 32a216d31141..ab7bda0bb245 100644
--- a/drivers/mtd/onenand/generic.c
+++ b/drivers/mtd/onenand/generic.c
@@ -18,7 +18,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * Note: Driver name and platform data format have been updated!
diff --git a/drivers/scsi/sun3x_esp.c b/drivers/scsi/sun3x_esp.c
index e26e81de7c45..d50c5ed8f428 100644
--- a/drivers/scsi/sun3x_esp.c
+++ b/drivers/scsi/sun3x_esp.c
@@ -12,9 +12,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/staging/comedi/drivers/ii_pci20kc.c 
b/drivers/staging/comedi/drivers/ii_pci20kc.c
index 0768bc42a5db..14ef1f67dd42 100644
--- a/drivers/staging/comedi/drivers/ii_pci20kc.c
+++ b/drivers/staging/comedi/drivers/ii_pci20kc.c
@@ -28,6 +28,7 @@
  */
 
 #include 
+#include 
 #include "../comedidev.h"
 
 /*
diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 37fff12dd4d0..fe902ff52e58 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -38,11 +38,11 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_SPARC
 #include 
 #endif
 
-#include 
 #include 
 
 #include "8250.h"
diff --git a/drivers/video/fbdev/s1d13xxxfb.c b/drivers/video/fbdev/s1d13xxxfb.c
index 83433cb0dfba..96aa46dc696c 100644
--- a/drivers/video/fbdev/s1d13xxxfb.c
+++ b/drivers/video/fbdev/s1d13xxxfb.c
@@ -32,8 +32,7 @@
 #include 
 #include 
 #include 
-
-#include 
+#include 
 
 #include 
 
diff --git a/drivers/video/fbdev/stifb.c b/drivers/video/fbdev/stifb.c
index 735355b0e023..7df4228e25f0 100644
--- a/drivers/video/fbdev/stifb.c
+++ b/drivers/video/fbdev/stifb.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include   /* for HP-UX compatibility */
 #include 
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index c27dde7215b5..e399029b68c5 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 /*
diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 29975c73a953..366cf77953b5 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -27,9 +27,9 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
-#include 
 #include 
 
 #ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
diff --git a/include/video/vga.h b/include/video/vga.h
index 

[PATCH] fs/char_dev.c: fix incorrect documentation for unregister_chrdev_region

[Partha Pratim Mukherjee]

The current documentation for unregister_chrdev_region says that it
return a range of device numbers which is incorrect. Instead it
unregister a range of device numbers. Fix the documentation to make this
clear.

Signed-off-by: Partha Pratim Mukherjee 
---
 fs/char_dev.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/char_dev.c b/fs/char_dev.c
index ea06a3d..24b1425 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -274,7 +274,7 @@ out2:
 }
 
 /**
- * unregister_chrdev_region() - return a range of device numbers
+ * unregister_chrdev_region() - unregister a range of device numbers
  * @from: the first in the range of numbers to unregister
  * @count: the number of device numbers to unregister
  *
-- 
1.7.10.4
--
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/

[PATCH v2 14/25] toshiba laptop: replace ioremap_cache with ioremap

[Dan Williams]

With ioremap_cache being replaced with memremap there is no longer a
guarantee that a mapping will silently fall back to an uncached mapping.
Explicitly use a vanilla ioremap() for this short lived mapping.

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Jonathan Buzzard 
Signed-off-by: Dan Williams 
---
 drivers/char/toshiba.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/toshiba.c b/drivers/char/toshiba.c
index 014c9d90d297..f5a45d887a37 100644
--- a/drivers/char/toshiba.c
+++ b/drivers/char/toshiba.c
@@ -430,7 +430,7 @@ static int tosh_probe(void)
int i,major,minor,day,year,month,flag;
unsigned char signature[7] = { 0x54,0x4f,0x53,0x48,0x49,0x42,0x41 };
SMMRegisters regs;
-   void __iomem *bios = ioremap_cache(0xf, 0x1);
+   void __iomem *bios = ioremap(0xf, 0x1);
 
if (!bios)
return -ENOMEM;

--
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/

[PATCH v2 15/25] memconsole: fix __iomem mishandling, switch to memremap

[Dan Williams]

The memconsole driver is not using proper accessors for __iomem.  Switch
to memremap to fix this issue, and this also prepares the driver for the
removal of ioremap_cache.

Cc: Mike Waychison 
Signed-off-by: Dan Williams 
---
 drivers/firmware/google/memconsole.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/firmware/google/memconsole.c 
b/drivers/firmware/google/memconsole.c
index 2f569aaed4c7..1b25fba84f32 100644
--- a/drivers/firmware/google/memconsole.c
+++ b/drivers/firmware/google/memconsole.c
@@ -52,14 +52,15 @@ static ssize_t memconsole_read(struct file *filp, struct 
kobject *kobp,
char *memconsole;
ssize_t ret;
 
-   memconsole = ioremap_cache(memconsole_baseaddr, memconsole_length);
+   memconsole = memremap(memconsole_baseaddr, memconsole_length,
+   MEMREMAP_CACHE);
if (!memconsole) {
-   pr_err("memconsole: ioremap_cache failed\n");
+   pr_err("memconsole: memremap failed\n");
return -ENOMEM;
}
ret = memory_read_from_buffer(buf, count, , memconsole,
  memconsole_length);
-   iounmap(memconsole);
+   memunmap(memconsole);
return ret;
 }
 

--
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/

[PATCH v2 09/25] arm: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
arch/arm[64]/ to memremap.

Cc: Russell King 
Signed-off-by: Dan Williams 
---
 arch/arm/include/asm/xen/page.h|4 ++--
 arch/arm64/include/asm/acpi.h  |5 +
 arch/arm64/include/asm/dmi.h   |8 
 arch/arm64/kernel/efi.c|9 +
 arch/arm64/kernel/smp_spin_table.c |   19 +--
 5 files changed, 21 insertions(+), 24 deletions(-)

diff --git a/arch/arm/include/asm/xen/page.h b/arch/arm/include/asm/xen/page.h
index 1bee8ca12494..59c966e51af7 100644
--- a/arch/arm/include/asm/xen/page.h
+++ b/arch/arm/include/asm/xen/page.h
@@ -103,8 +103,8 @@ static inline bool set_phys_to_machine(unsigned long pfn, 
unsigned long mfn)
return __set_phys_to_machine(pfn, mfn);
 }
 
-#define xen_remap(cookie, size) ioremap_cache((cookie), (size))
-#define xen_unmap(cookie) iounmap((cookie))
+#define xen_remap(cookie, size) memremap((cookie), (size), MEMREMAP_CACHE)
+#define xen_unmap(cookie) memunmap((cookie))
 
 bool xen_arch_need_swiotlb(struct device *dev,
   unsigned long pfn,
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 406485ed110a..5d7e46a1efdb 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -33,10 +33,7 @@
 static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
acpi_size size)
 {
-   if (!page_is_ram(phys >> PAGE_SHIFT))
-   return ioremap(phys, size);
-
-   return ioremap_cache(phys, size);
+   return memremap(phys, size, MEMREMAP_CACHE);
 }
 #define acpi_os_ioremap acpi_os_ioremap
 
diff --git a/arch/arm64/include/asm/dmi.h b/arch/arm64/include/asm/dmi.h
index 69d37d87b159..f3dae56c50da 100644
--- a/arch/arm64/include/asm/dmi.h
+++ b/arch/arm64/include/asm/dmi.h
@@ -22,10 +22,10 @@
  * request a virtual mapping for configuration tables such as SMBIOS.
  * This means we have to map them before use.
  */
-#define dmi_early_remap(x, l)  ioremap_cache(x, l)
-#define dmi_early_unmap(x, l)  iounmap(x)
-#define dmi_remap(x, l)ioremap_cache(x, l)
-#define dmi_unmap(x)   iounmap(x)
+#define dmi_early_remap(x, l)  memremap(x, l, MEMREMAP_CACHE)
+#define dmi_early_unmap(x, l)  memunmap(x)
+#define dmi_remap(x, l)memremap(x, l, MEMREMAP_CACHE)
+#define dmi_unmap(x)   memunmap(x)
 #define dmi_alloc(l)   kzalloc(l, GFP_KERNEL)
 
 #endif
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 9d4aa18f2a82..f0d6688cd62c 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -290,8 +291,8 @@ static int __init arm64_enable_runtime_services(void)
pr_info("Remapping and enabling EFI services.\n");
 
mapsize = memmap.map_end - memmap.map;
-   memmap.map = (__force void *)ioremap_cache((phys_addr_t)memmap.phys_map,
-  mapsize);
+   memmap.map = memremap((phys_addr_t) memmap.phys_map, mapsize,
+   MEMREMAP_CACHE);
if (!memmap.map) {
pr_err("Failed to remap EFI memory map\n");
return -1;
@@ -299,8 +300,8 @@ static int __init arm64_enable_runtime_services(void)
memmap.map_end = memmap.map + mapsize;
efi.memmap = 
 
-   efi.systab = (__force void *)ioremap_cache(efi_system_table,
-  sizeof(efi_system_table_t));
+   efi.systab = memremap(efi_system_table, sizeof(efi_system_table_t),
+   MEMREMAP_CACHE);
if (!efi.systab) {
pr_err("Failed to remap EFI System Table\n");
return -1;
diff --git a/arch/arm64/kernel/smp_spin_table.c 
b/arch/arm64/kernel/smp_spin_table.c
index aef3605a8c47..47da614f6215 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -21,11 +21,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 extern void secondary_holding_pen(void);
@@ -73,19 +73,19 @@ static int smp_spin_table_cpu_init(unsigned int cpu)
 
 static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
-   __le64 __iomem *release_addr;
+   __le64 *release_addr;
 
if (!cpu_release_addr[cpu])
return -ENODEV;
 
/*
 * The cpu-release-addr may or may not be inside the linear mapping.
-* As ioremap_cache will either give us a new mapping or reuse the
-* existing linear mapping, we can use it to cover both cases. In
-* either case the memory will be MT_NORMAL.
+* As memremap will either give us a new mapping or reuse the existing
+* linear mapping, we can use it to cover both 

[PATCH v2 19/25] pxa2xx-flash: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
pxa2xx-flash to memremap.

Cc: David Woodhouse 
Cc: Brian Norris 
Signed-off-by: Dan Williams 
---
 drivers/mtd/maps/pxa2xx-flash.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/maps/pxa2xx-flash.c b/drivers/mtd/maps/pxa2xx-flash.c
index 12fa75df5008..758a8a7f86d9 100644
--- a/drivers/mtd/maps/pxa2xx-flash.c
+++ b/drivers/mtd/maps/pxa2xx-flash.c
@@ -71,8 +71,8 @@ static int pxa2xx_flash_probe(struct platform_device *pdev)
   info->map.name);
return -ENOMEM;
}
-   info->map.cached =
-   ioremap_cache(info->map.phys, info->map.size);
+   info->map.cached = memremap(info->map.phys, info->map.size,
+   MEMREMAP_CACHE);
if (!info->map.cached)
printk(KERN_WARNING "Failed to ioremap cached %s\n",
   info->map.name);

--
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/

[PATCH v2 23/25] arch: remove ioremap_cache, replace with arch_memremap

[Dan Williams]

Now that all call sites for ioremap_cache() have been converted to
memremap(MEMREMAP_CACHE) we can now proceed with removing the
implementation in the archs.  This amounts to replacing the per-arch
ioremap_cache() implementation with arch_memremap.

Cc: Arnd Bergmann 
Cc: Russell King 
Cc: Tony Luck 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Signed-off-by: Dan Williams 
---
 arch/arm/Kconfig |1 +
 arch/arm/include/asm/io.h|   11 ---
 arch/arm/mm/ioremap.c|   12 
 arch/arm/mm/nommu.c  |   11 +++
 arch/arm64/Kconfig   |1 +
 arch/arm64/include/asm/io.h  |7 ++-
 arch/arm64/mm/ioremap.c  |   20 +++-
 arch/ia64/Kconfig|1 +
 arch/ia64/include/asm/io.h   |   12 +---
 arch/sh/Kconfig  |1 +
 arch/sh/include/asm/io.h |   21 ++---
 arch/sh/mm/ioremap.c |   10 ++
 arch/x86/Kconfig |1 +
 arch/x86/include/asm/io.h|8 +++-
 arch/x86/mm/ioremap.c|   20 +++-
 arch/xtensa/Kconfig  |1 +
 arch/xtensa/include/asm/io.h |9 ++---
 drivers/nvdimm/Kconfig   |2 +-
 kernel/Makefile  |2 +-
 kernel/memremap.c|   14 +++---
 lib/Kconfig  |5 -
 21 files changed, 112 insertions(+), 58 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1c5021002fe4..1d64aae0a226 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -3,6 +3,7 @@ config ARM
default y
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
+   select ARCH_HAS_MEMREMAP
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_CUSTOM_GPIO_H
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 485982084fe9..989eeaa8dd84 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -355,7 +355,7 @@ static inline void memcpy_toio(volatile void __iomem *to, 
const void *from,
  * FunctionMemory type CacheabilityCache hint
  * ioremap()   Device  n/a n/a
  * ioremap_nocache()   Device  n/a n/a
- * ioremap_cache() Normal  Writeback   Read allocate
+ * memremap(CACHE) Normal  Writeback   Read allocate
  * ioremap_wc()Normal  Non-cacheable   n/a
  * ioremap_wt()Normal  Non-cacheable   n/a
  *
@@ -392,8 +392,8 @@ void __iomem *ioremap(resource_size_t res_cookie, size_t 
size);
 #define ioremap ioremap
 #define ioremap_nocache ioremap
 
-void __iomem *ioremap_cache(resource_size_t res_cookie, size_t size);
-#define ioremap_cache ioremap_cache
+void __iomem *arch_memremap(resource_size_t res_cookie, size_t size,
+   unsigned long flags);
 
 void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
 #define ioremap_wc ioremap_wc
@@ -402,6 +402,11 @@ void __iomem *ioremap_wc(resource_size_t res_cookie, 
size_t size);
 void iounmap(volatile void __iomem *iomem_cookie);
 #define iounmap iounmap
 
+static inline void arch_memunmap(void *addr)
+{
+   iounmap((volatile void __iomem *) addr);
+}
+
 /*
  * io{read,write}{16,32}be() macros
  */
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 0c81056c1dd7..4e64247ba083 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -378,12 +378,16 @@ void __iomem *ioremap(resource_size_t res_cookie, size_t 
size)
 }
 EXPORT_SYMBOL(ioremap);
 
-void __iomem *ioremap_cache(resource_size_t res_cookie, size_t size)
+void *arch_memremap(resource_size_t res_cookie, size_t size,
+   unsigned long flags)
 {
-   return arch_ioremap_caller(res_cookie, size, MT_DEVICE_CACHED,
-  __builtin_return_address(0));
+   if ((flags & MEMREMAP_CACHE) == 0)
+   return NULL;
+
+   return (void __force *) arch_ioremap_caller(res_cookie, size,
+   MT_DEVICE_CACHED, __builtin_return_address(0));
 }
-EXPORT_SYMBOL(ioremap_cache);
+EXPORT_SYMBOL(arch_memremap);
 
 void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size)
 {
diff --git a/arch/arm/mm/nommu.c b/arch/arm/mm/nommu.c
index 1dd10936d68d..ec42be4d6e6e 100644
--- a/arch/arm/mm/nommu.c
+++ b/arch/arm/mm/nommu.c
@@ -366,12 +366,15 @@ void __iomem *ioremap(resource_size_t res_cookie, size_t 
size)
 }
 EXPORT_SYMBOL(ioremap);
 
-void __iomem *ioremap_cache(resource_size_t res_cookie, size_t size)
+void *arch_memremap(resource_size_t res_cookie, size_t size, unsigned long 
flags)
 {
-   return __arm_ioremap_caller(res_cookie, size, MT_DEVICE_CACHED,
-   __builtin_return_address(0));
+   if ((flags & MEMREMAP_CACHE) == 0)
+   return NULL;
+
+   return (void __force *) 

[PATCH v2 25/25] pmem: convert to generic memremap

[Dan Williams]

Update memremap_pmem() to query the architecture for the mapping type of
the given persistent memory range  and then pass those flags to generic
memremap().  arch_memremap_pmem_flags() is provided an address range to
evaluate in the event an arch has a need for different mapping types by
address range.  For example the ACPI NFIT carries EFI mapping types in
its memory range description table.

Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 arch/x86/include/asm/io.h |2 +-
 arch/x86/mm/ioremap.c |   16 ++--
 include/linux/pmem.h  |   26 +++---
 3 files changed, 26 insertions(+), 18 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index bba4e8968bc7..1388d7d27775 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -253,7 +253,7 @@ static inline void flush_write_buffers(void)
 #endif
 }
 
-void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size);
+unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size);
 #endif /* __KERNEL__ */
 
 extern void native_io_delay(void);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 987a58e84e2f..d4a67223f6e9 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -205,6 +205,16 @@ err_free_memtype:
return NULL;
 }
 
+unsigned long arch_memremap_pmem_flags(resource_size_t offset, size_t size)
+{
+   /*
+* TODO: check the mapping type provided by platform firmware,
+* per range.
+*/
+   return MEMREMAP_CACHE;
+}
+EXPORT_SYMBOL(arch_memremap_pmem_flags);
+
 /**
  * ioremap_nocache -   map bus memory into CPU space
  * @phys_addr:bus address of the memory
@@ -310,12 +320,6 @@ void *arch_memremap(resource_size_t phys_addr, size_t size,
 }
 EXPORT_SYMBOL(arch_memremap);
 
-void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size)
-{
-   return (void __pmem *) arch_memremap(offset, size, MEMREMAP_CACHE);
-}
-EXPORT_SYMBOL(arch_memremap_pmem);
-
 void __iomem *ioremap_prot(resource_size_t phys_addr, unsigned long size,
unsigned long prot_val)
 {
diff --git a/include/linux/pmem.h b/include/linux/pmem.h
index 1bf74c735fa0..03f9d73f3e13 100644
--- a/include/linux/pmem.h
+++ b/include/linux/pmem.h
@@ -28,10 +28,10 @@ static inline bool __arch_has_wmb_pmem(void)
return false;
 }
 
-static inline void __pmem *arch_memremap_pmem(resource_size_t offset,
+static inline unsigned long arch_memremap_pmem_flags(resource_size_t offset,
unsigned long size)
 {
-   return NULL;
+   return 0;
 }
 
 static inline void arch_memcpy_to_pmem(void __pmem *dst, const void *src,
@@ -43,8 +43,8 @@ static inline void arch_memcpy_to_pmem(void __pmem *dst, 
const void *src,
 
 /*
  * Architectures that define ARCH_HAS_PMEM_API must provide
- * implementations for arch_memremap_pmem(), arch_memcpy_to_pmem(),
- * arch_wmb_pmem(), and __arch_has_wmb_pmem().
+ * implementations for arch_memremap_pmem_flags(),
+ * arch_memcpy_to_pmem(), arch_wmb_pmem(), and __arch_has_wmb_pmem().
  */
 
 static inline void memcpy_from_pmem(void *dst, void __pmem const *src, size_t 
size)
@@ -54,7 +54,7 @@ static inline void memcpy_from_pmem(void *dst, void __pmem 
const *src, size_t si
 
 static inline void memunmap_pmem(void __pmem *addr)
 {
-   iounmap((void __force __iomem *) addr);
+   memunmap((void __force *) addr);
 }
 
 /**
@@ -85,16 +85,15 @@ static inline bool arch_has_pmem_api(void)
  * default_memremap_pmem + default_memcpy_to_pmem is sufficient for
  * making data durable relative to i/o completion.
  */
-static void default_memcpy_to_pmem(void __pmem *dst, const void *src,
+static inline void default_memcpy_to_pmem(void __pmem *dst, const void *src,
size_t size)
 {
memcpy((void __force *) dst, src, size);
 }
 
-static void __pmem *default_memremap_pmem(resource_size_t offset,
-   unsigned long size)
+static inline unsigned long default_memremap_pmem_flags(void)
 {
-   return (void __pmem *) memremap(offset, size, MEMREMAP_WT);
+   return MEMREMAP_WT;
 }
 
 /**
@@ -112,9 +111,14 @@ static void __pmem *default_memremap_pmem(resource_size_t 
offset,
 static inline void __pmem *memremap_pmem(resource_size_t offset,
unsigned long size)
 {
+   unsigned long flags;
+
if (arch_has_pmem_api())
-   return arch_memremap_pmem(offset, size);
-   return default_memremap_pmem(offset, size);
+   flags = arch_memremap_pmem_flags(offset, size);
+   else
+   flags = default_memremap_pmem_flags();
+
+   return (void __pmem *) memremap(offset, size, flags);
 }
 
 /**

--
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/

[PATCH v2 22/25] pmem: switch from ioremap_wt to memremap

[Dan Williams]

In preparation for deprecating ioremap_wt() convert its usage in
the PMEM API to memremap.

Cc: Ross Zwisler 
Signed-off-by: Dan Williams 
---
 include/linux/pmem.h  |2 +-
 tools/testing/nvdimm/Kbuild   |4 ++--
 tools/testing/nvdimm/test/iomap.c |   34 +-
 3 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/include/linux/pmem.h b/include/linux/pmem.h
index d2114045a6c4..1bf74c735fa0 100644
--- a/include/linux/pmem.h
+++ b/include/linux/pmem.h
@@ -94,7 +94,7 @@ static void default_memcpy_to_pmem(void __pmem *dst, const 
void *src,
 static void __pmem *default_memremap_pmem(resource_size_t offset,
unsigned long size)
 {
-   return (void __pmem __force *)ioremap_wt(offset, size);
+   return (void __pmem *) memremap(offset, size, MEMREMAP_WT);
 }
 
 /**
diff --git a/tools/testing/nvdimm/Kbuild b/tools/testing/nvdimm/Kbuild
index de2912ea78e8..8032a49f7873 100644
--- a/tools/testing/nvdimm/Kbuild
+++ b/tools/testing/nvdimm/Kbuild
@@ -1,7 +1,7 @@
-ldflags-y += --wrap=ioremap_wt
 ldflags-y += --wrap=ioremap_wc
 ldflags-y += --wrap=devm_ioremap_nocache
-ldflags-y += --wrap=arch_memremap_pmem
+ldflags-y += --wrap=memremap
+ldflags-y += --wrap=memunmap
 ldflags-y += --wrap=ioremap_nocache
 ldflags-y += --wrap=iounmap
 ldflags-y += --wrap=__request_region
diff --git a/tools/testing/nvdimm/test/iomap.c 
b/tools/testing/nvdimm/test/iomap.c
index f8486f98f860..21288f34a5ca 100644
--- a/tools/testing/nvdimm/test/iomap.c
+++ b/tools/testing/nvdimm/test/iomap.c
@@ -80,11 +80,20 @@ void __iomem *__wrap_devm_ioremap_nocache(struct device 
*dev,
 }
 EXPORT_SYMBOL(__wrap_devm_ioremap_nocache);
 
-void *__wrap_arch_memremap_pmem(resource_size_t offset, size_t size)
+void *__wrap_memremap(resource_size_t offset, size_t size,
+   unsigned long flags)
 {
-   return __nfit_test_ioremap(offset, size, arch_memremap_pmem);
+   struct nfit_test_resource *nfit_res;
+
+   rcu_read_lock();
+   nfit_res = get_nfit_res(offset);
+   rcu_read_unlock();
+   if (nfit_res)
+   return (void __iomem *) nfit_res->buf + offset
+   - nfit_res->res->start;
+   return memremap(offset, size, flags);
 }
-EXPORT_SYMBOL(__wrap_arch_memremap_pmem);
+EXPORT_SYMBOL(__wrap_memremap);
 
 void __iomem *__wrap_ioremap_nocache(resource_size_t offset, unsigned long 
size)
 {
@@ -92,12 +101,6 @@ void __iomem *__wrap_ioremap_nocache(resource_size_t 
offset, unsigned long size)
 }
 EXPORT_SYMBOL(__wrap_ioremap_nocache);
 
-void __iomem *__wrap_ioremap_wt(resource_size_t offset, unsigned long size)
-{
-   return __nfit_test_ioremap(offset, size, ioremap_wt);
-}
-EXPORT_SYMBOL(__wrap_ioremap_wt);
-
 void __iomem *__wrap_ioremap_wc(resource_size_t offset, unsigned long size)
 {
return __nfit_test_ioremap(offset, size, ioremap_wc);
@@ -117,6 +120,19 @@ void __wrap_iounmap(volatile void __iomem *addr)
 }
 EXPORT_SYMBOL(__wrap_iounmap);
 
+void __wrap_memunmap(void *addr)
+{
+   struct nfit_test_resource *nfit_res;
+
+   rcu_read_lock();
+   nfit_res = get_nfit_res((unsigned long) addr);
+   rcu_read_unlock();
+   if (nfit_res)
+   return;
+   return memunmap(addr);
+}
+EXPORT_SYMBOL(__wrap_memunmap);
+
 struct resource *__wrap___request_region(struct resource *parent,
resource_size_t start, resource_size_t n, const char *name,
int flags)

--
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/

[PATCH v2 21/25] fbdev: switch from ioremap_wt to memremap

[Dan Williams]

In preparation for deprecating ioremap_wt() convert its usage in
drivers/video/fbdev to memremap.

Cc: Jean-Christophe Plagniol-Villard 
Cc: Tomi Valkeinen 
Cc: linux-fb...@vger.kernel.org
Signed-off-by: Dan Williams 
---
 drivers/video/fbdev/amifb.c |5 +++--
 drivers/video/fbdev/atafb.c |5 +++--
 drivers/video/fbdev/hpfb.c  |6 +++---
 3 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/amifb.c b/drivers/video/fbdev/amifb.c
index 1d702e13aaff..0cde451046d0 100644
--- a/drivers/video/fbdev/amifb.c
+++ b/drivers/video/fbdev/amifb.c
@@ -52,6 +52,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -3705,8 +3706,8 @@ default_chipset:
 * access the videomem with writethrough cache
 */
info->fix.smem_start = (u_long)ZTWO_PADDR(videomemory);
-   videomemory = (u_long)ioremap_wt(info->fix.smem_start,
-info->fix.smem_len);
+   videomemory = (u_long)memremap(info->fix.smem_start, info->fix.smem_len,
+   MEMREMAP_WT);
if (!videomemory) {
dev_warn(>dev,
 "Unable to map videomem cached writethrough\n");
diff --git a/drivers/video/fbdev/atafb.c b/drivers/video/fbdev/atafb.c
index d6ce613e12ad..5615e8c31ea2 100644
--- a/drivers/video/fbdev/atafb.c
+++ b/drivers/video/fbdev/atafb.c
@@ -55,12 +55,12 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -3185,7 +3185,8 @@ int __init atafb_init(void)
/* Map the video memory (physical address given) to somewhere
 * in the kernel address space.
 */
-   external_screen_base = ioremap_wt(external_addr, external_len);
+   external_screen_base = memremap(external_addr, external_len,
+   MEMREMAP_WT);
if (external_vgaiobase)
external_vgaiobase =
  (unsigned long)ioremap(external_vgaiobase, 0x1);
diff --git a/drivers/video/fbdev/hpfb.c b/drivers/video/fbdev/hpfb.c
index 9476d196f510..d08c320b06fc 100644
--- a/drivers/video/fbdev/hpfb.c
+++ b/drivers/video/fbdev/hpfb.c
@@ -14,8 +14,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 
 static struct fb_info fb_info = {
@@ -241,8 +241,8 @@ static int hpfb_init_one(unsigned long phys_base, unsigned 
long virt_base)
fb_info.fix.line_length = fb_width;
fb_height = (in_8(fb_regs + HPFB_FBHMSB) << 8) | in_8(fb_regs + 
HPFB_FBHLSB);
fb_info.fix.smem_len = fb_width * fb_height;
-   fb_start = (unsigned long)ioremap_wt(fb_info.fix.smem_start,
-fb_info.fix.smem_len);
+   fb_start = (unsigned long) memremap(fb_info.fix.smem_start,
+fb_info.fix.smem_len, MEMREMAP_WT);
hpfb_defined.xres = (in_8(fb_regs + HPFB_DWMSB) << 8) | in_8(fb_regs + 
HPFB_DWLSB);
hpfb_defined.yres = (in_8(fb_regs + HPFB_DHMSB) << 8) | in_8(fb_regs + 
HPFB_DHLSB);
hpfb_defined.xres_virtual = hpfb_defined.xres;

--
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/

[PATCH v2 24/25] arch: remove ioremap_wt, replace with arch_memremap

[Dan Williams]

Now that all call sites for ioremap_wt() have been converted to
memremap(MEMREMAP_WT) we can now proceed with removing the
implementation in the archs.  This amounts to replacing the per-arch
ioremap_wt() implementation with arch_memremap.

Cc: Arnd Bergmann 
Cc: Russell King 
Cc: Tony Luck 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Signed-off-by: Dan Williams 
---
 arch/arc/include/asm/io.h|1 -
 arch/arm/include/asm/io.h|2 --
 arch/arm64/include/asm/io.h  |1 -
 arch/avr32/include/asm/io.h  |1 -
 arch/frv/Kconfig |1 +
 arch/frv/include/asm/io.h|   17 ++---
 arch/frv/mm/kmap.c   |6 ++
 arch/m32r/include/asm/io.h   |1 -
 arch/m68k/Kconfig|1 +
 arch/m68k/include/asm/io_mm.h|   14 ++
 arch/m68k/include/asm/io_no.h|   12 ++--
 arch/m68k/include/asm/raw_io.h   |4 
 arch/m68k/mm/kmap.c  |   17 -
 arch/m68k/mm/sun3kmap.c  |6 ++
 arch/metag/include/asm/io.h  |3 ---
 arch/microblaze/include/asm/io.h |1 -
 arch/mn10300/include/asm/io.h|1 -
 arch/nios2/include/asm/io.h  |1 -
 arch/s390/include/asm/io.h   |1 -
 arch/sparc/include/asm/io_32.h   |1 -
 arch/sparc/include/asm/io_64.h   |1 -
 arch/tile/include/asm/io.h   |1 -
 arch/x86/include/asm/io.h|2 --
 arch/x86/mm/ioremap.c|   17 -
 arch/xtensa/include/asm/io.h |1 -
 drivers/video/fbdev/Kconfig  |2 +-
 include/asm-generic/io.h |8 
 include/asm-generic/iomap.h  |4 
 28 files changed, 49 insertions(+), 79 deletions(-)

diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h
index 694ece8a0243..00f97a2f5fa6 100644
--- a/arch/arc/include/asm/io.h
+++ b/arch/arc/include/asm/io.h
@@ -20,7 +20,6 @@ extern void iounmap(const void __iomem *addr);
 
 #define ioremap_nocache(phy, sz)   ioremap(phy, sz)
 #define ioremap_wc(phy, sz)ioremap(phy, sz)
-#define ioremap_wt(phy, sz)ioremap(phy, sz)
 
 /* Change struct page to physical address */
 #define page_to_phys(page) (page_to_pfn(page) << PAGE_SHIFT)
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 989eeaa8dd84..89114571cf11 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -357,7 +357,6 @@ static inline void memcpy_toio(volatile void __iomem *to, 
const void *from,
  * ioremap_nocache()   Device  n/a n/a
  * memremap(CACHE) Normal  Writeback   Read allocate
  * ioremap_wc()Normal  Non-cacheable   n/a
- * ioremap_wt()Normal  Non-cacheable   n/a
  *
  * All device mappings have the following properties:
  * - no access speculation
@@ -397,7 +396,6 @@ void __iomem *arch_memremap(resource_size_t res_cookie, 
size_t size,
 
 void __iomem *ioremap_wc(resource_size_t res_cookie, size_t size);
 #define ioremap_wc ioremap_wc
-#define ioremap_wt ioremap_wc
 
 void iounmap(volatile void __iomem *iomem_cookie);
 #define iounmap iounmap
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 305d1c9b3352..a03157daeb1c 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -170,7 +170,6 @@ extern void *arch_memremap(phys_addr_t phys_addr, size_t 
size, unsigned long fla
 #define ioremap(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_nocache(addr, size)__ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_NORMAL_NC))
-#define ioremap_wt(addr, size) __ioremap((addr), (size), 
__pgprot(PROT_DEVICE_nGnRE))
 #define iounmap__iounmap
 
 static inline void memunmap(void *addr)
diff --git a/arch/avr32/include/asm/io.h b/arch/avr32/include/asm/io.h
index e998ff5d8e1a..4f5ec2bb7172 100644
--- a/arch/avr32/include/asm/io.h
+++ b/arch/avr32/include/asm/io.h
@@ -296,7 +296,6 @@ extern void __iounmap(void __iomem *addr);
__iounmap(addr)
 
 #define ioremap_wc ioremap_nocache
-#define ioremap_wt ioremap_nocache
 
 #define cached(addr) P1SEGADDR(addr)
 #define uncached(addr) P2SEGADDR(addr)
diff --git a/arch/frv/Kconfig b/arch/frv/Kconfig
index 34aa19352dc1..b1b4000807fb 100644
--- a/arch/frv/Kconfig
+++ b/arch/frv/Kconfig
@@ -7,6 +7,7 @@ config FRV
select HAVE_UID16
select VIRT_TO_BUS
select GENERIC_IRQ_SHOW
+   select ARCH_HAS_MEMREMAP
select HAVE_DEBUG_BUGVERBOSE
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select GENERIC_CPU_DEVICES
diff --git a/arch/frv/include/asm/io.h b/arch/frv/include/asm/io.h
index a31b63ec4930..3e908abc41cd 100644
--- a/arch/frv/include/asm/io.h
+++ b/arch/frv/include/asm/io.h
@@ -17,8 +17,6 @@
 
 #ifdef 

[PATCH v2 16/25] visorbus: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
visorbus to memremap.

Cc: Benjamin Romer 
Cc: David Kershner 
Cc: Greg Kroah-Hartman 
Signed-off-by: Dan Williams 
---
 drivers/staging/unisys/visorbus/visorchannel.c |   16 +---
 drivers/staging/unisys/visorbus/visorchipset.c |   17 +
 2 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 20b63496e9f2..787e8b98f0b6 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 
 #include "version.h"
 #include "visorbus.h"
@@ -36,7 +37,7 @@ static const uuid_le spar_video_guid = 
SPAR_CONSOLEVIDEO_CHANNEL_PROTOCOL_GUID;
 struct visorchannel {
u64 physaddr;
ulong nbytes;
-   void __iomem *mapped;
+   void *mapped;
bool requested;
struct channel_header chan_hdr;
uuid_le guid;
@@ -93,7 +94,7 @@ visorchannel_create_guts(u64 physaddr, unsigned long 
channel_bytes,
}
}
 
-   channel->mapped = ioremap_cache(physaddr, size);
+   channel->mapped = memremap(physaddr, size, MEMREMAP_CACHE);
if (!channel->mapped) {
release_mem_region(physaddr, size);
goto cleanup;
@@ -113,7 +114,7 @@ visorchannel_create_guts(u64 physaddr, unsigned long 
channel_bytes,
if (uuid_le_cmp(guid, NULL_UUID_LE) == 0)
guid = channel->chan_hdr.chtype;
 
-   iounmap(channel->mapped);
+   memunmap(channel->mapped);
if (channel->requested)
release_mem_region(channel->physaddr, channel->nbytes);
channel->mapped = NULL;
@@ -126,7 +127,8 @@ visorchannel_create_guts(u64 physaddr, unsigned long 
channel_bytes,
}
}
 
-   channel->mapped = ioremap_cache(channel->physaddr, channel_bytes);
+   channel->mapped = memremap(channel->physaddr, channel_bytes,
+   MEMREMAP_CACHE);
if (!channel->mapped) {
release_mem_region(channel->physaddr, channel_bytes);
goto cleanup;
@@ -167,7 +169,7 @@ visorchannel_destroy(struct visorchannel *channel)
if (!channel)
return;
if (channel->mapped) {
-   iounmap(channel->mapped);
+   memunmap(channel->mapped);
if (channel->requested)
release_mem_region(channel->physaddr, channel->nbytes);
}
@@ -241,7 +243,7 @@ visorchannel_read(struct visorchannel *channel, ulong 
offset,
if (offset + nbytes > channel->nbytes)
return -EIO;
 
-   memcpy_fromio(local, channel->mapped + offset, nbytes);
+   memcpy(local, channel->mapped + offset, nbytes);
 
return 0;
 }
@@ -262,7 +264,7 @@ visorchannel_write(struct visorchannel *channel, ulong 
offset,
memcpy(>chan_hdr + offset, local, copy_size);
}
 
-   memcpy_toio(channel->mapped + offset, local, nbytes);
+   memcpy(channel->mapped + offset, local, nbytes);
 
return 0;
 }
diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index bb8087e70127..6d2ee282905d 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -119,7 +119,7 @@ static struct visorchannel *controlvm_channel;
 
 /* Manages the request payload in the controlvm channel */
 struct visor_controlvm_payload_info {
-   u8 __iomem *ptr;/* pointer to base address of payload pool */
+   u8 *ptr;/* pointer to base address of payload pool */
u64 offset; /* offset from beginning of controlvm
 * channel to beginning of payload * pool */
u32 bytes;  /* number of bytes in payload pool */
@@ -401,21 +401,22 @@ parser_init_byte_stream(u64 addr, u32 bytes, bool local, 
bool *retry)
p = __va((unsigned long) (addr));
memcpy(ctx->data, p, bytes);
} else {
-   void __iomem *mapping;
+   void *mapping;
 
if (!request_mem_region(addr, bytes, "visorchipset")) {
rc = NULL;
goto cleanup;
}
 
-   mapping = ioremap_cache(addr, bytes);
+   mapping = memremap(addr, bytes, MEMREMAP_CACHE);
if (!mapping) {
release_mem_region(addr, bytes);
rc = NULL;
goto cleanup;
}
-   memcpy_fromio(ctx->data, mapping, bytes);
+   memcpy(ctx->data, mapping, bytes);
release_mem_region(addr, bytes);
+   memunmap(mapping);
}
 
ctx->byte_stream = true;
@@ -1327,7 +1328,7 @@ 

[PATCH v2 18/25] libnvdimm, pmem: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
libnvdimm and the PMEM API to memremap.

Signed-off-by: Dan Williams 
---
 arch/x86/include/asm/io.h |7 +--
 arch/x86/mm/ioremap.c |6 ++
 tools/testing/nvdimm/Kbuild   |2 +-
 tools/testing/nvdimm/test/iomap.c |6 +++---
 4 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index cc9c61bc1abe..8aeb6456188a 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -248,12 +248,7 @@ static inline void flush_write_buffers(void)
 #endif
 }
 
-static inline void __pmem *arch_memremap_pmem(resource_size_t offset,
-   unsigned long size)
-{
-   return (void __force __pmem *) ioremap_cache(offset, size);
-}
-
+void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size);
 #endif /* __KERNEL__ */
 
 extern void native_io_delay(void);
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 6f759c7c2ab7..7b422e7574b1 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -317,6 +317,12 @@ void __iomem *ioremap_cache(resource_size_t phys_addr, 
unsigned long size)
 }
 EXPORT_SYMBOL(ioremap_cache);
 
+void __pmem *arch_memremap_pmem(resource_size_t offset, size_t size)
+{
+   return (void __force __pmem *) ioremap_cache(offset, size);
+}
+EXPORT_SYMBOL(arch_memremap_pmem);
+
 void __iomem *ioremap_prot(resource_size_t phys_addr, unsigned long size,
unsigned long prot_val)
 {
diff --git a/tools/testing/nvdimm/Kbuild b/tools/testing/nvdimm/Kbuild
index f56914c7929b..de2912ea78e8 100644
--- a/tools/testing/nvdimm/Kbuild
+++ b/tools/testing/nvdimm/Kbuild
@@ -1,7 +1,7 @@
 ldflags-y += --wrap=ioremap_wt
 ldflags-y += --wrap=ioremap_wc
 ldflags-y += --wrap=devm_ioremap_nocache
-ldflags-y += --wrap=ioremap_cache
+ldflags-y += --wrap=arch_memremap_pmem
 ldflags-y += --wrap=ioremap_nocache
 ldflags-y += --wrap=iounmap
 ldflags-y += --wrap=__request_region
diff --git a/tools/testing/nvdimm/test/iomap.c 
b/tools/testing/nvdimm/test/iomap.c
index 64bfaa50831c..f8486f98f860 100644
--- a/tools/testing/nvdimm/test/iomap.c
+++ b/tools/testing/nvdimm/test/iomap.c
@@ -80,11 +80,11 @@ void __iomem *__wrap_devm_ioremap_nocache(struct device 
*dev,
 }
 EXPORT_SYMBOL(__wrap_devm_ioremap_nocache);
 
-void __iomem *__wrap_ioremap_cache(resource_size_t offset, unsigned long size)
+void *__wrap_arch_memremap_pmem(resource_size_t offset, size_t size)
 {
-   return __nfit_test_ioremap(offset, size, ioremap_cache);
+   return __nfit_test_ioremap(offset, size, arch_memremap_pmem);
 }
-EXPORT_SYMBOL(__wrap_ioremap_cache);
+EXPORT_SYMBOL(__wrap_arch_memremap_pmem);
 
 void __iomem *__wrap_ioremap_nocache(resource_size_t offset, unsigned long 
size)
 {

--
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/

[PATCH v2 11/25] gma500: switch from acpi_os_ioremap to ioremap

[Dan Williams]

acpi_os_ioremap uses cached mappings, however it appears that gma500
wants to read dynamic platform state.  Switch to ioremap() to prevent it
reading stale state from cache.

Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/gma500/opregion.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/gma500/opregion.c 
b/drivers/gpu/drm/gma500/opregion.c
index ab696ca7eeec..9809c26ea0cf 100644
--- a/drivers/gpu/drm/gma500/opregion.c
+++ b/drivers/gpu/drm/gma500/opregion.c
@@ -322,7 +322,7 @@ int psb_intel_opregion_setup(struct drm_device *dev)
INIT_WORK(>asle_work, psb_intel_opregion_asle_work);
 
DRM_DEBUG("OpRegion detected at 0x%8x\n", opregion_phy);
-   base = acpi_os_ioremap(opregion_phy, 8*1024);
+   base = ioremap(opregion_phy, 8*1024);
if (!base)
return -ENOMEM;
 

--
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/

[PATCH v2 20/25] sfi: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in sfi
to memremap.  It's a bit awkward that we go and add back a fake __iomem
annotation, but this is to keep consistency with early_ioremap() which
does not have a 'memremap' flavor.

Cc: Len Brown 
Signed-off-by: Dan Williams 
---
 drivers/sfi/sfi_core.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/sfi/sfi_core.c b/drivers/sfi/sfi_core.c
index 296db7a69c27..1cccf31dfccc 100644
--- a/drivers/sfi/sfi_core.c
+++ b/drivers/sfi/sfi_core.c
@@ -101,7 +101,7 @@ static void __iomem * __ref sfi_map_memory(u64 phys, u32 
size)
return NULL;
 
if (sfi_use_ioremap)
-   return ioremap_cache(phys, size);
+   return (void __iomem *) memremap(phys, size, MEMREMAP_CACHE);
else
return early_ioremap(phys, size);
 }
@@ -112,7 +112,7 @@ static void __ref sfi_unmap_memory(void __iomem *virt, u32 
size)
return;
 
if (sfi_use_ioremap)
-   iounmap(virt);
+   memunmap((void __force *) virt);
else
early_iounmap(virt, size);
 }

--
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/

[PATCH v2 10/25] x86: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
arch/x86/ to memremap.

Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Signed-off-by: Dan Williams 
---
 arch/x86/include/asm/efi.h  |3 ++-
 arch/x86/kernel/crash_dump_64.c |6 +++---
 arch/x86/kernel/kdebugfs.c  |8 
 arch/x86/kernel/ksysfs.c|   28 ++--
 arch/x86/mm/ioremap.c   |   10 --
 5 files changed, 27 insertions(+), 28 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 155162ea0e00..755272a8c45f 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -54,7 +54,8 @@ extern unsigned long asmlinkage efi_call_phys(void *, ...);
kernel_fpu_end();   \
 })
 
-#define efi_ioremap(addr, size, type, attr)ioremap_cache(addr, size)
+#define efi_ioremap(addr, size, type, attr)\
+   memremap(addr, size, MEMREMAP_CACHE)
 
 #else /* !CONFIG_X86_32 */
 
diff --git a/arch/x86/kernel/crash_dump_64.c b/arch/x86/kernel/crash_dump_64.c
index afa64adb75ee..b87ca059e5fc 100644
--- a/arch/x86/kernel/crash_dump_64.c
+++ b/arch/x86/kernel/crash_dump_64.c
@@ -31,19 +31,19 @@ ssize_t copy_oldmem_page(unsigned long pfn, char *buf,
if (!csize)
return 0;
 
-   vaddr = ioremap_cache(pfn << PAGE_SHIFT, PAGE_SIZE);
+   vaddr = memremap(pfn << PAGE_SHIFT, PAGE_SIZE, MEMREMAP_CACHE);
if (!vaddr)
return -ENOMEM;
 
if (userbuf) {
if (copy_to_user(buf, vaddr + offset, csize)) {
-   iounmap(vaddr);
+   memunmap(vaddr);
return -EFAULT;
}
} else
memcpy(buf, vaddr + offset, csize);
 
set_iounmap_nonlazy();
-   iounmap(vaddr);
+   memunmap(vaddr);
return csize;
 }
diff --git a/arch/x86/kernel/kdebugfs.c b/arch/x86/kernel/kdebugfs.c
index dc1404bf8e4b..a2248482c14b 100644
--- a/arch/x86/kernel/kdebugfs.c
+++ b/arch/x86/kernel/kdebugfs.c
@@ -49,7 +49,7 @@ static ssize_t setup_data_read(struct file *file, char __user 
*user_buf,
pa = node->paddr + sizeof(struct setup_data) + pos;
pg = pfn_to_page((pa + count - 1) >> PAGE_SHIFT);
if (PageHighMem(pg)) {
-   p = ioremap_cache(pa, count);
+   p = memremap(pa, count, MEMREMAP_CACHE);
if (!p)
return -ENXIO;
} else
@@ -58,7 +58,7 @@ static ssize_t setup_data_read(struct file *file, char __user 
*user_buf,
remain = copy_to_user(user_buf, p, count);
 
if (PageHighMem(pg))
-   iounmap(p);
+   memunmap(p);
 
if (remain)
return -EFAULT;
@@ -128,7 +128,7 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
 
pg = pfn_to_page((pa_data+sizeof(*data)-1) >> PAGE_SHIFT);
if (PageHighMem(pg)) {
-   data = ioremap_cache(pa_data, sizeof(*data));
+   data = memremap(pa_data, sizeof(*data), MEMREMAP_CACHE);
if (!data) {
kfree(node);
error = -ENXIO;
@@ -144,7 +144,7 @@ static int __init create_setup_data_nodes(struct dentry 
*parent)
pa_data = data->next;
 
if (PageHighMem(pg))
-   iounmap(data);
+   memunmap(data);
if (error)
goto err_dir;
no++;
diff --git a/arch/x86/kernel/ksysfs.c b/arch/x86/kernel/ksysfs.c
index c2bedaea11f7..d2670bb75a08 100644
--- a/arch/x86/kernel/ksysfs.c
+++ b/arch/x86/kernel/ksysfs.c
@@ -16,8 +16,8 @@
 #include 
 #include 
 #include 
+#include 
 
-#include 
 #include 
 
 static ssize_t version_show(struct kobject *kobj,
@@ -79,12 +79,12 @@ static int get_setup_data_paddr(int nr, u64 *paddr)
*paddr = pa_data;
return 0;
}
-   data = ioremap_cache(pa_data, sizeof(*data));
+   data = memremap(pa_data, sizeof(*data), MEMREMAP_CACHE);
if (!data)
return -ENOMEM;
 
pa_data = data->next;
-   iounmap(data);
+   memunmap(data);
i++;
}
return -EINVAL;
@@ -97,17 +97,17 @@ static int __init get_setup_data_size(int nr, size_t *size)
u64 pa_data = boot_params.hdr.setup_data;
 
while (pa_data) {
-   data = ioremap_cache(pa_data, sizeof(*data));
+   data = memremap(pa_data, sizeof(*data), MEMREMAP_CACHE);
if (!data)
return -ENOMEM;
if (nr == i) {
*size = data->len;
-   iounmap(data);
+   

[PATCH v2 08/25] arch: introduce memremap()

[Dan Williams]

Existing users of ioremap_cache() are mapping memory that is known in
advance to not have i/o side effects.  These users are forced to cast
away the __iomem annotation, or otherwise neglect to fix the sparse
errors thrown when dereferencing pointers to this memory.  Provide
memremap() as a non __iomem annotated ioremap_*() in the case when
ioremap is otherwise a pointer to memory. Outside of ioremap() and
ioremap_nocache(), the expectation is that most calls to
ioremap_() are seeking memory-like semantics (e.g.  speculative
reads, and prefetching permitted).  These callsites can be moved to
memremap() over time.

memremap() is a break from the ioremap implementation pattern of adding
a new memremap_() for each mapping type and having silent
compatibility fall backs.  Instead, the
implementation defines flags that are passed to the central memremap()
and if a mapping type is not supported by an arch memremap returns NULL.

The behavior change to return NULL on an unsupported request is reserved
for a later patch.  This initial implementation starts off by using
ioremap_cache() directly.  Once all ioremap_cache() and ioremap_wt()
instances have been converted the functionality for establishing these
mappings will be pushed to a per-architecture arch_memremap()
implementation.

Cc: Arnd Bergmann 
Signed-off-by: Dan Williams 
---
 arch/ia64/include/asm/io.h   |1 +
 arch/sh/include/asm/io.h |1 +
 arch/xtensa/include/asm/io.h |1 +
 include/linux/io.h   |9 +
 kernel/Makefile  |2 +
 kernel/memremap.c|   82 ++
 6 files changed, 96 insertions(+)
 create mode 100644 kernel/memremap.c

diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 80a7e34be009..9041bbe2b7b4 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -435,6 +435,7 @@ static inline void __iomem * ioremap_cache (unsigned long 
phys_addr, unsigned lo
 {
return ioremap(phys_addr, size);
 }
+#define ioremap_cache ioremap_cache
 
 
 /*
diff --git a/arch/sh/include/asm/io.h b/arch/sh/include/asm/io.h
index 728c4c571f40..6194e20fccca 100644
--- a/arch/sh/include/asm/io.h
+++ b/arch/sh/include/asm/io.h
@@ -342,6 +342,7 @@ ioremap_cache(phys_addr_t offset, unsigned long size)
 {
return __ioremap_mode(offset, size, PAGE_KERNEL);
 }
+#define ioremap_cache ioremap_cache
 
 #ifdef CONFIG_HAVE_IOREMAP_PROT
 static inline void __iomem *
diff --git a/arch/xtensa/include/asm/io.h b/arch/xtensa/include/asm/io.h
index c39bb6e61911..867840f5400f 100644
--- a/arch/xtensa/include/asm/io.h
+++ b/arch/xtensa/include/asm/io.h
@@ -57,6 +57,7 @@ static inline void __iomem *ioremap_cache(unsigned long 
offset,
else
BUG();
 }
+#define ioremap_cache ioremap_cache
 
 #define ioremap_wc ioremap_nocache
 #define ioremap_wt ioremap_nocache
diff --git a/include/linux/io.h b/include/linux/io.h
index fb5a99800e77..dfed9d608bb3 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -121,4 +121,13 @@ static inline int arch_phys_wc_index(int handle)
 #endif
 #endif
 
+enum {
+   MEMREMAP_WB = 1 << 0,
+   MEMREMAP_WT = 1 << 1,
+   MEMREMAP_CACHE = MEMREMAP_WB,
+};
+
+extern void *memremap(resource_size_t offset, size_t size, unsigned long 
flags);
+extern void memunmap(void *addr);
+
 #endif /* _LINUX_IO_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 43c4c920f30a..92866d36e376 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -99,6 +99,8 @@ obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 obj-$(CONFIG_CONTEXT_TRACKING) += context_tracking.o
 obj-$(CONFIG_TORTURE_TEST) += torture.o
 
+obj-$(CONFIG_HAS_IOMEM) += memremap.o
+
 $(obj)/configs.o: $(obj)/config_data.h
 
 # config_data.h contains the same information as ikconfig.h but gzipped.
diff --git a/kernel/memremap.c b/kernel/memremap.c
new file mode 100644
index ..ba206fd11785
--- /dev/null
+++ b/kernel/memremap.c
@@ -0,0 +1,82 @@
+/*
+ * Copyright(c) 2015 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of version 2 of the GNU General Public License as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+#include 
+#include 
+#include 
+
+#ifndef ioremap_cache
+/* temporary while we convert existing ioremap_cache users to memremap */
+__weak void __iomem *ioremap_cache(resource_size_t offset, unsigned long size)
+{
+   return ioremap(offset, size);
+}
+#endif
+
+/*
+ * memremap() is "ioremap" for cases where it is known that the resource
+ * being mapped does not have i/o side effects and the __iomem
+ * annotation is not applicable.
+ */
+void *memremap(resource_size_t offset, 

[PATCH v2 17/25] intel-iommu: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
intel-iommu to memremap.  This also eliminates the mishandling of the
__iomem annotation in the implementation.

Cc: David Woodhouse 
Cc: Joerg Roedel 
Signed-off-by: Dan Williams 
---
 drivers/iommu/intel-iommu.c |   10 ++
 drivers/iommu/intel_irq_remapping.c |4 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index a98a7b27aca1..028ad0ff6abb 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -2871,7 +2872,8 @@ static int copy_context_table(struct intel_iommu *iommu,
}
 
ret = -ENOMEM;
-   old_ce = ioremap_cache(old_ce_phys, PAGE_SIZE);
+   old_ce = memremap(old_ce_phys, PAGE_SIZE,
+   MEMREMAP_CACHE);
if (!old_ce)
goto out;
 
@@ -2919,7 +2921,7 @@ static int copy_context_table(struct intel_iommu *iommu,
__iommu_flush_cache(iommu, new_ce, VTD_PAGE_SIZE);
 
 out_unmap:
-   iounmap(old_ce);
+   memunmap(old_ce);
 
 out:
return ret;
@@ -2953,7 +2955,7 @@ static int copy_translation_tables(struct intel_iommu 
*iommu)
if (!old_rt_phys)
return -EINVAL;
 
-   old_rt = ioremap_cache(old_rt_phys, PAGE_SIZE);
+   old_rt = memremap(old_rt_phys, PAGE_SIZE, MEMREMAP_CACHE);
if (!old_rt)
return -ENOMEM;
 
@@ -3002,7 +3004,7 @@ static int copy_translation_tables(struct intel_iommu 
*iommu)
ret = 0;
 
 out_unmap:
-   iounmap(old_rt);
+   memunmap(old_rt);
 
return ret;
 }
diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 27cdfa84ec5b..1da158d3b3ce 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -408,7 +408,7 @@ static int iommu_load_old_irte(struct intel_iommu *iommu)
size = INTR_REMAP_TABLE_ENTRIES*sizeof(struct irte);
 
/* Map the old IR table */
-   old_ir_table = ioremap_cache(irt_phys, size);
+   old_ir_table = memremap(irt_phys, size, MEMREMAP_CACHE);
if (!old_ir_table)
return -ENOMEM;
 
@@ -426,7 +426,7 @@ static int iommu_load_old_irte(struct intel_iommu *iommu)
bitmap_set(iommu->ir_table->bitmap, i, 1);
}
 
-   iounmap(old_ir_table);
+   memunmap(old_ir_table);
 
return 0;
 }

--
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/

[PATCH v2 12/25] i915: switch from acpi_os_ioremap to ioremap

[Dan Williams]

acpi_os_ioremap uses cached mappings, however it appears that i915
wants to read dynamic platform state.  Switch to ioremap() to prevent it
reading stale state from cache.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: intel-...@lists.freedesktop.org
Cc: David Airlie 
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Dan Williams 
---
 drivers/gpu/drm/i915/intel_opregion.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
b/drivers/gpu/drm/i915/intel_opregion.c
index 481337436f72..16ba7c67410d 100644
--- a/drivers/gpu/drm/i915/intel_opregion.c
+++ b/drivers/gpu/drm/i915/intel_opregion.c
@@ -863,7 +863,7 @@ int intel_opregion_setup(struct drm_device *dev)
INIT_WORK(>asle_work, asle_work);
 #endif
 
-   base = acpi_os_ioremap(asls, OPREGION_SIZE);
+   base = ioremap(asls, OPREGION_SIZE);
if (!base)
return -ENOMEM;
 

--
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/

[PATCH v2 13/25] acpi: switch from ioremap_cache to memremap

[Dan Williams]

In preparation for deprecating ioremap_cache() convert its usage in
drivers/acpi and include/acpi/ to memremap.  This includes dropping the
__iomem annotation throughout ACPI since the memremap can be treated as
a normal memory pointer.

Finally, memremap automatically handles requests to map normal memory
pages, so this also drops the calls to "should_use_kmap()".

Cc: Bob Moore 
Cc: Lv Zheng 
Cc: Rafael J. Wysocki 
Signed-off-by: Dan Williams 
---
 arch/arm64/include/asm/acpi.h |5 +--
 drivers/acpi/apei/einj.c  |9 +++--
 drivers/acpi/apei/erst.c  |6 ++--
 drivers/acpi/nvs.c|6 ++--
 drivers/acpi/osl.c|   70 +++--
 include/acpi/acpi_io.h|6 ++--
 6 files changed, 35 insertions(+), 67 deletions(-)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 5d7e46a1efdb..d12fc0b932b3 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -30,12 +30,11 @@
 /* Basic configuration for ACPI */
 #ifdef CONFIG_ACPI
 /* ACPI table mapping after acpi_gbl_permanent_mmap is set */
-static inline void __iomem *acpi_os_ioremap(acpi_physical_address phys,
-   acpi_size size)
+static inline void *acpi_os_memremap(acpi_physical_address phys, acpi_size 
size)
 {
return memremap(phys, size, MEMREMAP_CACHE);
 }
-#define acpi_os_ioremap acpi_os_ioremap
+#define acpi_os_memremap acpi_os_memremap
 
 typedef u64 phys_cpuid_t;
 #define PHYS_CPUID_INVALID INVALID_HWID
diff --git a/drivers/acpi/apei/einj.c b/drivers/acpi/apei/einj.c
index a095d4f858da..d4992fea6994 100644
--- a/drivers/acpi/apei/einj.c
+++ b/drivers/acpi/apei/einj.c
@@ -318,7 +318,8 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
sizeof(*trigger_tab) - 1);
goto out;
}
-   trigger_tab = ioremap_cache(trigger_paddr, sizeof(*trigger_tab));
+   trigger_tab = memremap(trigger_paddr, sizeof(*trigger_tab),
+   MEMREMAP_CACHE);
if (!trigger_tab) {
pr_err(EINJ_PFX "Failed to map trigger table!\n");
goto out_rel_header;
@@ -346,8 +347,8 @@ static int __einj_error_trigger(u64 trigger_paddr, u32 type,
   (unsigned long long)trigger_paddr + table_size - 1);
goto out_rel_header;
}
-   iounmap(trigger_tab);
-   trigger_tab = ioremap_cache(trigger_paddr, table_size);
+   memunmap(trigger_tab);
+   trigger_tab = memremap(trigger_paddr, table_size, MEMREMAP_CACHE);
if (!trigger_tab) {
pr_err(EINJ_PFX "Failed to map trigger table!\n");
goto out_rel_entry;
@@ -409,7 +410,7 @@ out_rel_header:
release_mem_region(trigger_paddr, sizeof(*trigger_tab));
 out:
if (trigger_tab)
-   iounmap(trigger_tab);
+   memunmap(trigger_tab);
 
return rc;
 }
diff --git a/drivers/acpi/apei/erst.c b/drivers/acpi/apei/erst.c
index 3670bbab57a3..dc49b0b42d65 100644
--- a/drivers/acpi/apei/erst.c
+++ b/drivers/acpi/apei/erst.c
@@ -77,7 +77,7 @@ static struct acpi_table_erst *erst_tab;
 static struct erst_erange {
u64 base;
u64 size;
-   void __iomem *vaddr;
+   void *vaddr;
u32 attr;
 } erst_erange;
 
@@ -1185,8 +1185,8 @@ static int __init erst_init(void)
goto err_unmap_reg;
}
rc = -ENOMEM;
-   erst_erange.vaddr = ioremap_cache(erst_erange.base,
- erst_erange.size);
+   erst_erange.vaddr = memremap(erst_erange.base, erst_erange.size,
+   MEMREMAP_CACHE);
if (!erst_erange.vaddr)
goto err_release_erange;
 
diff --git a/drivers/acpi/nvs.c b/drivers/acpi/nvs.c
index 85287b8fe3aa..e0e15af93b22 100644
--- a/drivers/acpi/nvs.c
+++ b/drivers/acpi/nvs.c
@@ -136,7 +136,7 @@ void suspend_nvs_free(void)
entry->data = NULL;
if (entry->kaddr) {
if (entry->unmap) {
-   iounmap(entry->kaddr);
+   memunmap(entry->kaddr);
entry->unmap = false;
} else {
acpi_os_unmap_iomem(entry->kaddr,
@@ -180,7 +180,7 @@ int suspend_nvs_save(void)
 
entry->kaddr = acpi_os_get_iomem(phys, size);
if (!entry->kaddr) {
-   entry->kaddr = acpi_os_ioremap(phys, size);
+   entry->kaddr = acpi_os_memremap(phys, size);
entry->unmap = !!entry->kaddr;
}
if (!entry->kaddr) {
@@ -197,7 +197,7 @@ int suspend_nvs_save(void)
  * suspend_nvs_restore - restore NVS memory regions
  *
  * This 

[PATCH v2 04/25] mm: enhance region_is_ram() to distinguish 'unknown' vs 'mixed'

[Dan Williams]

region_is_ram() is used to prevent the establishment of aliased mappings
to physical "System RAM" with incompatible cache settings.  However, it
uses "-1" to indicate both "unknown" memory ranges (ranges not described
by platform firmware) and "mixed" ranges (where the parameters describe
a range that partially overlaps "System RAM").

Fix this up by explicitly tracking the "unknown" vs "mixed" resource
cases. In addition to clarifying that "-1" means the requested spanned
RAM and non-RAM resource, this re-write also adds support for detecting
when the requested range completely covers all of a resource.

Finally, the implementation treats overlaps between "unknown" and RAM as
RAM.

Cc: Toshi Kani 
Signed-off-by: Dan Williams 
---
 kernel/resource.c |   43 +++
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index fed052a1bc9f..119b282985f9 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -493,39 +493,42 @@ int __weak page_is_ram(unsigned long pfn)
 EXPORT_SYMBOL_GPL(page_is_ram);
 
 /*
- * Search for a resouce entry that fully contains the specified region.
- * If found, return 1 if it is RAM, 0 if not.
- * If not found, or region is not fully contained, return -1
+ * Check if the specified region partially overlaps or fully eclipses "System
+ * RAM". Return '0' if the region does not overlap RAM, return '-1' if the
+ * region overlaps RAM and another resource, and return '1' if the region
+ * overlaps RAM and no other defined resource. Note, that '1' is also returned
+ * in the case when the specified region overlaps RAM and undefined memory
+ * holes.
  *
  * Used by the ioremap functions to ensure the user is not remapping RAM and is
  * a vast speed up over walking through the resource table page by page.
  */
 int region_is_ram(resource_size_t start, unsigned long size)
 {
-   struct resource *p;
-   resource_size_t end = start + size - 1;
unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   resource_size_t end = start + size - 1;
const char *name = "System RAM";
-   int ret = -1;
+   int ram = 0; int other = 0;
+   struct resource *p;
 
read_lock(_lock);
for (p = iomem_resource.child; p ; p = p->sibling) {
-   if (p->end < start)
-   continue;
-
-   if (p->start <= start && end <= p->end) {
-   /* resource fully contains region */
-   if ((p->flags != flags) || strcmp(p->name, name))
-   ret = 0;
-   else
-   ret = 1;
-   break;
-   }
-   if (end < p->start)
-   break;  /* not found */
+   bool is_ram = strcmp(p->name, name) == 0 && p->flags == flags;
+
+   if (start >= p->start && start <= p->end)
+   is_ram ? ram++ : other++;
+   if (end >= p->start && end <= p->end)
+   is_ram ? ram++ : other++;
+   if (p->start >= start && p->end <= end)
+   is_ram ? ram++ : other++;
}
read_unlock(_lock);
-   return ret;
+
+   if (other == 0)
+   return !!ram;
+   if (ram)
+   return -1;
+   return 0;
 }
 
 void __weak arch_remove_reservations(struct resource *avail)

--
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/

[PATCH v2 03/25] mm: Fix bugs in region_is_ram()

[Dan Williams]

From: Toshi Kani 

region_is_ram() looks up the iomem_resource table to check if
a target range is in RAM.  However, it always returns with -1
due to invalid range checks.  It always breaks the loop at the
first entry of the table.

Another issue is that it compares p->flags and flags, but it
always fails.  The flags is declared as int, which makes it as
a negative value with IORESOURCE_BUSY (0x8000) set while
p->flags is unsigned long.

Fix the range check and flags so that region_is_ram() works as
advertised.

Signed-off-by: Toshi Kani 
Cc: Mike Travis 
Cc: Luis R. Rodriguez 
Cc: Dan Williams 
Cc: Andrew Morton 
Signed-off-by: Dan Williams 
---
 kernel/resource.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 90552aab5f2d..fed052a1bc9f 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -504,13 +504,13 @@ int region_is_ram(resource_size_t start, unsigned long 
size)
 {
struct resource *p;
resource_size_t end = start + size - 1;
-   int flags = IORESOURCE_MEM | IORESOURCE_BUSY;
+   unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY;
const char *name = "System RAM";
int ret = -1;
 
read_lock(_lock);
for (p = iomem_resource.child; p ; p = p->sibling) {
-   if (end < p->start)
+   if (p->end < start)
continue;
 
if (p->start <= start && end <= p->end) {
@@ -521,7 +521,7 @@ int region_is_ram(resource_size_t start, unsigned long size)
ret = 1;
break;
}
-   if (p->end < start)
+   if (end < p->start)
break;  /* not found */
}
read_unlock(_lock);

--
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/

[PATCH v2 07/25] intel_iommu: fix leaked ioremap mapping

[Dan Williams]

iommu_load_old_irte() appears to leak the old_irte mapping after use.

Cc: Joerg Roedel 
Signed-off-by: Dan Williams 
---
 drivers/iommu/intel_irq_remapping.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index f15692a410c7..27cdfa84ec5b 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -426,6 +426,8 @@ static int iommu_load_old_irte(struct intel_iommu *iommu)
bitmap_set(iommu->ir_table->bitmap, i, 1);
}
 
+   iounmap(old_ir_table);
+
return 0;
 }
 

--
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/

[PATCH v2 06/25] cleanup IORESOURCE_CACHEABLE vs ioremap()

[Dan Williams]

Quoting Arnd:
I was thinking the opposite approach and basically removing all uses
of IORESOURCE_CACHEABLE from the kernel. There are only a handful of
them.and we can probably replace them all with hardcoded
ioremap_cached() calls in the cases they are actually useful.

All existing usages of IORESOURCE_CACHEABLE call ioremap() instead of
ioremap_nocache() if the resource is cacheable, however ioremap() is
uncached by default. Clearly none of the existing usages care about the
cacheability. Particularly devm_ioremap_resource() never worked as
advertised since it always fell back to plain ioremap().

Clean this up as the new direction we want is to convert
ioremap_() usages to memremap(..., flags).

Suggested-by: Arnd Bergmann 
Signed-off-by: Dan Williams 
---
 arch/arm/mach-clps711x/board-cdb89712.c |2 +-
 arch/powerpc/kernel/pci_of_scan.c   |2 +-
 arch/sparc/kernel/pci.c |3 +--
 drivers/pci/probe.c |3 +--
 drivers/pnp/manager.c   |2 --
 drivers/scsi/aic94xx/aic94xx_init.c |7 +--
 drivers/scsi/arcmsr/arcmsr_hba.c|5 +
 drivers/scsi/mvsas/mv_init.c|   15 ---
 drivers/video/fbdev/ocfb.c  |1 -
 lib/devres.c|   13 -
 lib/pci_iomap.c |7 ++-
 11 files changed, 16 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-clps711x/board-cdb89712.c 
b/arch/arm/mach-clps711x/board-cdb89712.c
index 1ec378c334e5..972abdb10028 100644
--- a/arch/arm/mach-clps711x/board-cdb89712.c
+++ b/arch/arm/mach-clps711x/board-cdb89712.c
@@ -95,7 +95,7 @@ static struct physmap_flash_data cdb89712_bootrom_pdata 
__initdata = {
 
 static struct resource cdb89712_bootrom_resources[] __initdata = {
DEFINE_RES_NAMED(CS7_PHYS_BASE, SZ_128, "BOOTROM", IORESOURCE_MEM |
-IORESOURCE_CACHEABLE | IORESOURCE_READONLY),
+IORESOURCE_READONLY),
 };
 
 static struct platform_device cdb89712_bootrom_pdev __initdata = {
diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index 42e02a2d570b..d4726addff0b 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -102,7 +102,7 @@ static void of_pci_parse_addrs(struct device_node *node, 
struct pci_dev *dev)
res = >resource[(i - PCI_BASE_ADDRESS_0) >> 2];
} else if (i == dev->rom_base_reg) {
res = >resource[PCI_ROM_RESOURCE];
-   flags |= IORESOURCE_READONLY | IORESOURCE_CACHEABLE;
+   flags |= IORESOURCE_READONLY;
} else {
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index c928bc64b4ba..04da147e0712 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -231,8 +231,7 @@ static void pci_parse_of_addrs(struct platform_device *op,
res = >resource[(i - PCI_BASE_ADDRESS_0) >> 2];
} else if (i == dev->rom_base_reg) {
res = >resource[PCI_ROM_RESOURCE];
-   flags |= IORESOURCE_READONLY | IORESOURCE_CACHEABLE
- | IORESOURCE_SIZEALIGN;
+   flags |= IORESOURCE_READONLY | IORESOURCE_SIZEALIGN;
} else {
printk(KERN_ERR "PCI: bad cfg reg num 0x%x\n", i);
continue;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cefd636681b6..8ed37dd04056 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -326,8 +326,7 @@ static void pci_read_bases(struct pci_dev *dev, unsigned 
int howmany, int rom)
struct resource *res = >resource[PCI_ROM_RESOURCE];
dev->rom_base_reg = rom;
res->flags = IORESOURCE_MEM | IORESOURCE_PREFETCH |
-   IORESOURCE_READONLY | IORESOURCE_CACHEABLE |
-   IORESOURCE_SIZEALIGN;
+   IORESOURCE_READONLY | IORESOURCE_SIZEALIGN;
__pci_read_base(dev, pci_bar_mem32, res, rom);
}
 }
diff --git a/drivers/pnp/manager.c b/drivers/pnp/manager.c
index 9357aa779048..7ad3295752ef 100644
--- a/drivers/pnp/manager.c
+++ b/drivers/pnp/manager.c
@@ -97,8 +97,6 @@ static int pnp_assign_mem(struct pnp_dev *dev, struct pnp_mem 
*rule, int idx)
/* ??? rule->flags restricted to 8 bits, all tests bogus ??? */
if (!(rule->flags & IORESOURCE_MEM_WRITEABLE))
res->flags |= IORESOURCE_READONLY;
-   if (rule->flags & IORESOURCE_MEM_CACHEABLE)
-   res->flags |= IORESOURCE_CACHEABLE;
if (rule->flags & IORESOURCE_MEM_RANGELENGTH)
res->flags |= IORESOURCE_RANGELENGTH;
if (rule->flags & 

[PATCH v2 02/25] mm, x86: Remove region_is_ram() call from ioremap

[Dan Williams]

From: Toshi Kani 

__ioremap_caller() calls region_is_ram() to walk through the
iomem_resource table to check if a target range is in RAM, which
was added to improve the lookup performance over page_is_ram()
(commit 906e36c5c717 "x86: use optimized ioresource lookup in
ioremap function").  page_is_ram() was no longer used when this
change was added, though.

__ioremap_caller() then calls walk_system_ram_range(), which had
replaced page_is_ram() to improve the lookup performance (commit
c81c8a1eeede "x86, ioremap: Speed up check for RAM pages").

Since both checks walk through the same iomem_resource table for
the same purpose, there is no need to call the two functions.
Furthermore, region_is_ram() always returns with -1, which makes
walk_system_ram_range() as the only check being used at this point.

Therefore, this patch changes __ioremap_caller() to call
walk_system_ram_range() only.

Note, removing the call to region_is_ram() is also necessary to
fix bugs in region_is_ram().  walk_system_ram_range() requires
RAM ranges be page-aligned in the iomem_resource table to work
properly.  This restriction has allowed multiple ioremaps to RAM
(setup_data) which are page-unaligned.  Using fixed region_is_ram()
will cause these callers to start failing.  After all ioremap
callers to setup_data are converted, __ioremap_caller() may call
region_is_ram() instead to remove this restriction.

Signed-off-by: Toshi Kani 
Cc: Roland Dreier 
Cc: Mike Travis 
Cc: Luis R. Rodriguez 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Signed-off-by: Dan Williams 
---
 arch/x86/mm/ioremap.c |   24 ++--
 1 file changed, 6 insertions(+), 18 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index c13f7fdca142..12b1eaeab6b9 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -92,7 +92,6 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
pgprot_t prot;
int retval;
void __iomem *ret_addr;
-   int ram_region;
 
/* Don't allow wraparound or zero size */
last_addr = phys_addr + size - 1;
@@ -115,26 +114,15 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
/*
 * Don't allow anybody to remap normal RAM that we're using..
 */
-   /* First check if whole region can be identified as RAM or not */
-   ram_region = region_is_ram(phys_addr, size);
-   if (ram_region > 0) {
-   WARN_ONCE(1, "ioremap on RAM at 0x%lx - 0x%lx\n",
-   (unsigned long int)phys_addr,
-   (unsigned long int)last_addr);
-   return NULL;
-   }
-
-   /* If could not be identified(-1), check page by page */
-   if (ram_region < 0) {
-   pfn  = phys_addr >> PAGE_SHIFT;
-   last_pfn = last_addr >> PAGE_SHIFT;
-   if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
+   pfn  = phys_addr >> PAGE_SHIFT;
+   last_pfn = last_addr >> PAGE_SHIFT;
+   if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
  __ioremap_check_ram) == 1) {
-   WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n",
+   WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n",
_addr, _addr);
-   return NULL;
-   }
+   return NULL;
}
+
/*
 * Mappings have to be page-aligned
 */

--
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/

[PATCH v2 00/25] replace ioremap_{cache|wt} with memremap

[Dan Williams]

Changes since v1 [1]:

1/ Drop the attempt at unifying ioremap() prototypes, just focus on
   converting ioremap_cache and ioremap_wt over to memremap (Christoph)

2/ Drop the unrelated cleanups to use %pa in __ioremap_caller (Thomas)

3/ Add support for memremap() attempts on "System RAM" to simply return
   the kernel virtual address for that range.  ARM depends on this
   functionality in ioremap_cache() and ACPI was open coding a similar
   solution. (Mark)

4/ Split the conversions of ioremap_{cache|wt} into separate patches per
   driver / arch.

5/ Fix bisection breakage and other reports from 0day-kbuild

---
While developing the pmem driver we noticed that the __iomem annotation
on the return value from ioremap_cache() was being mishandled by several
callers.  We also observed that all of the call sites expected to be
able to treat the return value from ioremap_cache() as normal
(non-__iomem) pointer to memory.

This patchset takes the opportunity to clean up the above confusion as
well as a few issues with the ioremap_{cache|wt} interface, including:

1/ Eliminating the possibility of function prototypes differing between
   architectures by defining a central memremap() prototype that takes
   flags to determine the mapping type.

2/ Returning NULL rather than falling back silently to a different
   mapping-type.  This allows drivers to be stricter about the
   mapping-type fallbacks that are permissible.

[1]: http://marc.info/?l=linux-arm-kernel=143735199029255=2

---

Dan Williams (22):
  mm: enhance region_is_ram() to distinguish 'unknown' vs 'mixed'
  arch, drivers: don't include  directly, use  instead
  cleanup IORESOURCE_CACHEABLE vs ioremap()
  intel_iommu: fix leaked ioremap mapping
  arch: introduce memremap()
  arm: switch from ioremap_cache to memremap
  x86: switch from ioremap_cache to memremap
  gma500: switch from acpi_os_ioremap to ioremap
  i915: switch from acpi_os_ioremap to ioremap
  acpi: switch from ioremap_cache to memremap
  toshiba laptop: replace ioremap_cache with ioremap
  memconsole: fix __iomem mishandling, switch to memremap
  visorbus: switch from ioremap_cache to memremap
  intel-iommu: switch from ioremap_cache to memremap
  libnvdimm, pmem: switch from ioremap_cache to memremap
  pxa2xx-flash: switch from ioremap_cache to memremap
  sfi: switch from ioremap_cache to memremap
  fbdev: switch from ioremap_wt to memremap
  pmem: switch from ioremap_wt to memremap
  arch: remove ioremap_cache, replace with arch_memremap
  arch: remove ioremap_wt, replace with arch_memremap
  pmem: convert to generic memremap

Toshi Kani (3):
  mm, x86: Fix warning in ioremap RAM check
  mm, x86: Remove region_is_ram() call from ioremap
  mm: Fix bugs in region_is_ram()


 arch/arc/include/asm/io.h  |1 
 arch/arm/Kconfig   |1 
 arch/arm/include/asm/io.h  |   13 +++-
 arch/arm/include/asm/xen/page.h|4 +
 arch/arm/mach-clps711x/board-cdb89712.c|2 -
 arch/arm/mach-shmobile/pm-rcar.c   |2 -
 arch/arm/mm/ioremap.c  |   12 +++-
 arch/arm/mm/nommu.c|   11 ++-
 arch/arm64/Kconfig |1 
 arch/arm64/include/asm/acpi.h  |   10 +--
 arch/arm64/include/asm/dmi.h   |8 +--
 arch/arm64/include/asm/io.h|8 ++-
 arch/arm64/kernel/efi.c|9 ++-
 arch/arm64/kernel/smp_spin_table.c |   19 +++---
 arch/arm64/mm/ioremap.c|   20 ++
 arch/avr32/include/asm/io.h|1 
 arch/frv/Kconfig   |1 
 arch/frv/include/asm/io.h  |   17 ++---
 arch/frv/mm/kmap.c |6 ++
 arch/ia64/Kconfig  |1 
 arch/ia64/include/asm/io.h |   11 +++
 arch/ia64/kernel/cyclone.c |2 -
 arch/m32r/include/asm/io.h |1 
 arch/m68k/Kconfig  |1 
 arch/m68k/include/asm/io_mm.h  |   14 +---
 arch/m68k/include/asm/io_no.h  |   12 ++--
 arch/m68k/include/asm/raw_io.h |4 +
 arch/m68k/mm/kmap.c|   17 +
 arch/m68k/mm/sun3kmap.c|6 ++
 arch/metag/include/asm/io.h|3 -
 arch/microblaze/include/asm/io.h   |1 
 arch/mn10300/include/asm/io.h  |1 
 arch/nios2/include/asm/io.h|1 
 arch/powerpc/kernel/pci_of_scan.c  |2 -
 arch/s390/include/asm/io.h |1 
 arch/sh/Kconfig|1 
 arch/sh/include/asm/io.h   |   20 --
 

[PATCH v2 01/25] mm, x86: Fix warning in ioremap RAM check

[Dan Williams]

From: Toshi Kani 

__ioremap_caller() calls __ioremap_check_ram() through
walk_system_ram_range() to check if a target range is in RAM.
__ioremap_check_ram() has WARN_ONCE() in a wrong place where it warns
when the given range is not RAM.  This misplaced warning is not exposed
since walk_system_ram_range() only calls __ioremap_check_ram() for RAM
ranges.

Move the WARN_ONCE() to __ioremap_caller(), and update the message to
include the address range.

Signed-off-by: Toshi Kani 
Cc: Roland Dreier 
Cc: Luis R. Rodriguez 
Cc: Thomas Gleixner 
Cc: H. Peter Anvin 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
[djbw: fix format specifier warnings]
Reported-by: kbuild test robot 
Signed-off-by: Dan Williams 
---
 arch/x86/mm/ioremap.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index cc5ccc415cc0..c13f7fdca142 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -63,8 +63,6 @@ static int __ioremap_check_ram(unsigned long start_pfn, 
unsigned long nr_pages,
!PageReserved(pfn_to_page(start_pfn + i)))
return 1;
 
-   WARN_ONCE(1, "ioremap on RAM pfn 0x%lx\n", start_pfn);
-
return 0;
 }
 
@@ -131,8 +129,11 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
pfn  = phys_addr >> PAGE_SHIFT;
last_pfn = last_addr >> PAGE_SHIFT;
if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1)
+ __ioremap_check_ram) == 1) {
+   WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n",
+   _addr, _addr);
return NULL;
+   }
}
/*
 * Mappings have to be page-aligned

--
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] clk: socfpga: Add a second parent option for the dbg_base_clk

[Dinh Nguyen]

On 7/24/15 4:41 PM, Stephen Boyd wrote:
> On 07/22, dingu...@opensource.altera.com wrote:
>> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
>> index 80f924d..7d5db54 100644
>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> @@ -164,7 +164,7 @@
>>  dbg_base_clk: dbg_base_clk {
>>  #clock-cells = <0>;
>>  compatible = 
>> "altr,socfpga-perip-clk";
>> -clocks = <_pll>;
>> +clocks = <_pll>, 
>> <>;
>>  div-reg = <0xe8 0 9>;
>>  reg = <0x50>;
>>  };
> 
> We don't usually take changes in dts files. Can you split this
> off and take it through arm-soc?
> 

Ah okay..will do.

Thanks,
Dinh
--
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/

sys_pread64 data error: sys_pread64 return success but buffer data wrong with transparent hugepage enabled in multi-thread application

[Jaden Liang]

Hi all,

We have a multi-thread application to read file with pread DIRECT_IO
from file. The buffer and file offset are both 4K aligned. And
sometimes the threads will call system() to do some command while
running.

With some debug, there are some chances sys_pread64 return success,
but the buffer returned was NOT modified at all. This happens when
some other threads call fork() at the same time.

After some tracing jobs, we located this issue is related with
transparent hugepage feature. If we set transparent hugepage policy to
NEVER like below:
echo never > /sys/kernel/mm/transparent_hugepage/enabled
the buffer data issue disappear.

We are still trying to trace deep inside of transparent hugepage to
find out what really happen under transparent hugepage enabled. We
think there might be some related with the COW mechanism in mm module,
but not pretty sure yet.

There is a small test program to reproduce such issue. The test
program will create 384 threads to do pread on one file and check the
returns. All the threads will call system() to simulate fork().

My envirement:
OS: CentOS 7
Kernel Version: 3.10.0-229.7.2.el7.x86_64

Compile:
# gcc pread_test.c -o pread_test -lpthread

Run test:
# dd if=/dev/zero of=pread_test_file bs=1M count=200 oflag=direct
# ./pread_test ./pread_test_file

If output include the message like below, there is pread data wrong issue.
[7fb5e4ff9700][ifkey_exec:153]pread BUG buf:0x7fb5b500c000
offset:10881536 size:92160 ret=92160 errno:Success

Test program source code:

// pread_test.c
#include 
#include 
#include 
#include 
#include 
#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 


#ifndef O_DIRECT
#define O_DIRECT 0004 /* direct disk access hint */
#endif

#ifndef ARRAY_SIZE
#define ARRAY_SIZE(x) (sizeof(x)/sizeof((x)[0]))
#endif

#define errlog(fmt, args...) \
fprintf(stderr, "[%lx][%s:%d]"fmt, pthread_self(),  __FUNCTION__,
__LINE__, ##args)

#define MAX_BRICK 24
#define MAX_USER 16
#define MAX_THREADS (MAX_BRICK * MAX_USER)

enum
{
ifop_en_none,
ifop_en_write,
ifop_en_read,
ifop_en_readmiss,
};

typedef struct
{
int op;

off_t   offset;

size_t  size;
}ifkey_t;

static ifkey_t s_ops[] =
{
{
.op = ifop_en_read,
.offset = 10881536,
.size = 92160,
},
};
static ifkey_t s_read[] =
{
{
.op = ifop_en_read,
.offset = 0,
.size = 10952704,
},
};

static int s_sectors = 8;

static int s_threads_exit = 0;

size_t ifkey_get_size(const ifkey_t *key, int count)
{
int i = 0;
size_t size = 0;

for ( i = 0; i < count; i++ )
{
if ( key[i].offset + key[i].size > size )
size = key[i].offset + key[i].size;
}

return size;
}

static void ifkey_exec(int fd, ifkey_t *key, int count, int init)
{
int i = 0;
ssize_t ret = 0;
void *buf = NULL;
size_t filesize = 0;

if ( s_threads_exit )
return;

filesize = ifkey_get_size(key, count);

buf = memalign(s_sectors * 512, filesize);
if ( !buf )
{
errlog("memalign %lu errno:%s\n", filesize, strerror(errno));
return ;
}

memset(buf, 'A', filesize);

if ( init )
{

ret = pwrite(fd, buf, filesize, 0);
if ( ret != filesize )
errlog("pwrite %ld != %lu\n", ret, filesize);
}

for ( i = 0; i < count; i++ )
{
switch(key[i].op)
{
case ifop_en_write:
memset(buf, 'W', key[i].size);
ret = pwrite(fd, buf, key[i].size, key[i].offset);
if ( ret != key[i].size )
{
errlog("pwrite offset:%ld size:%lu errno:%s\n"
, key[i].offset, key[i].size, strerror(errno));
}

break;
case ifop_en_read:
memset(buf, 'R', key[i].size);
ret = syscall(SYS_pread64, fd, buf, key[i].size, key[i].offset);
if ( ret != key[i].size )
{
errlog("pread offset:%ld size:%lu errno:%s\n"
, key[i].offset, key[i].size, strerror(errno));
}
else if ( !memcmp("", buf, 8) )
{
errlog("pread BUG buf:%p offset:%ld size:%lu "
"ret=%ld errno:%s\n"
, buf, key[i].offset, key[i].size
, ret, strerror(errno));

s_threads_exit = 1;
//abort();
}
break;
default:
errlog("Not support %d op:%d\n", i, key[i].op);
break;
}
}

free(buf);
}

void* ifkey_test(void *arg)
{
int fd = (int)(ulong)arg;

system("echo aaa >/dev/null");

ifkey_exec(fd, s_ops, ARRAY_SIZE(s_ops), 0);
system("echo aaa >/dev/null");

ifkey_exec(fd, s_ops, ARRAY_SIZE(s_ops), 0);
system("echo aaa >/dev/null");

ifkey_exec(fd, s_ops, ARRAY_SIZE(s_ops), 0);
system("echo aaa >/dev/null");

ifkey_exec(fd, s_read, ARRAY_SIZE(s_read), 0);
system("echo aaa >/dev/null");

ifkey_exec(fd, s_read, ARRAY_SIZE(s_read), 0);
system("echo aaa >/dev/null");

return NULL;
}

void file_test(const char *filename)
{
void *buf = NULL;
size_t bs = (1UL<<17);
size_t count = (1UL<<13);
size_t i = 0;
off_t off = 0;
pthread_t tds[MAX_USER];

int fd = 0;

fd = open(filename, O_RDONLY | O_DIRECT);
if ( fd < 0 )
{
fprintf(stderr, "%lx open %s failed:%s\n"
, pthread_self(), filename, strerror(errno));
return ;
}

for ( i = 0; i < MAX_USER; i++ )
{
pthread_create([i], NULL, ifkey_test, (void*)(ulong)fd);
}

for ( i = 0; i < MAX_USER; i++ )
{

Re: [PATCH v2 0/5] bpf: Introduce the new ability of eBPF programs to access hardware PMU counter

[xiakaixu]

于 2015/7/24 7:33, Daniel Borkmann 写道:
> On 07/22/2015 10:09 AM, Kaixu Xia wrote:
>> Previous patch v1 url:
>> https://lkml.org/lkml/2015/7/17/287
> 
> [ Sorry to chime in late, just noticed this series now as I wasn't in Cc for
>   the core BPF changes. More below ... ]

Sorry about this, will add you to the CC list:) Welcome your comments.
> 
>> This patchset allows user read PMU events in the following way:
>>   1. Open the PMU using perf_event_open() (for each CPUs or for
>>  each processes he/she'd like to watch);
>>   2. Create a BPF_MAP_TYPE_PERF_EVENT_ARRAY BPF map;
>>   3. Insert FDs into the map with some key-value mapping scheme
>>  (i.e. cpuid -> event on that CPU);
>>   4. Load and attach eBPF programs as usual;
>>   5. In eBPF program, get the perf_event_map_fd and key (i.e.
>>  cpuid get from bpf_get_smp_processor_id()) then use
>>  bpf_perf_event_read() to read from it.
>>   6. Do anything he/her want.
>>
>> changes in V2:
>>   - put atomic_long_inc_not_zero() between fdget() and fdput();
>>   - limit the event type to PERF_TYPE_RAW and PERF_TYPE_HARDWARE;
>>   - Only read the event counter on current CPU or on current
>> process;
>>   - add new map type BPF_MAP_TYPE_PERF_EVENT_ARRAY to store the
>> pointer to the struct perf_event;
>>   - according to the perf_event_map_fd and key, the function
>> bpf_perf_event_read() can get the Hardware PMU counter value;
>>
>> Patch 5/5 is a simple example and shows how to use this new eBPF
>> programs ability. The PMU counter data can be found in
>> /sys/kernel/debug/tracing/trace(trace_pipe).(the cycles PMU
>> value when 'kprobe/sys_write' sampling)
>>
>>$ cat /sys/kernel/debug/tracing/trace_pipe
>>$ ./tracex6
>> ...
>>   cat-677   [002] d..1   210.299270: : bpf count: CPU-2  5316659
>>   cat-677   [002] d..1   210.299316: : bpf count: CPU-2  5378639
>>   cat-677   [002] d..1   210.299362: : bpf count: CPU-2  5440654
>>   cat-677   [002] d..1   210.299408: : bpf count: CPU-2  5503211
>>   cat-677   [002] d..1   210.299454: : bpf count: CPU-2  5565438
>>   cat-677   [002] d..1   210.299500: : bpf count: CPU-2  5627433
>>   cat-677   [002] d..1   210.299547: : bpf count: CPU-2  5690033
>>   cat-677   [002] d..1   210.299593: : bpf count: CPU-2  5752184
>>   cat-677   [002] d..1   210.299639: : bpf count: CPU-2  5814543
>> <...>-548   [009] d..1   210.299667: : bpf count: CPU-9  
>> 605418074
>> <...>-548   [009] d..1   210.299692: : bpf count: CPU-9  
>> 605452692
>>   cat-677   [002] d..1   210.299700: : bpf count: CPU-2  5896319
>> <...>-548   [009] d..1   210.299710: : bpf count: CPU-9  
>> 605477824
>> <...>-548   [009] d..1   210.299728: : bpf count: CPU-9  
>> 605501726
>> <...>-548   [009] d..1   210.299745: : bpf count: CPU-9  
>> 605525279
>> <...>-548   [009] d..1   210.299762: : bpf count: CPU-9  
>> 605547817
>> <...>-548   [009] d..1   210.299778: : bpf count: CPU-9  
>> 605570433
>> <...>-548   [009] d..1   210.299795: : bpf count: CPU-9  
>> 605592743
>> ...
>>
>> The detail of patches is as follow:
>>
>> Patch 1/5 introduces a new bpf map type. This map only stores the
>> pointer to struct perf_event;
>>
>> Patch 2/5 introduces a map_traverse_elem() function for further use;
>>
>> Patch 3/5 convets event file descriptors into perf_event structure when
>> add new element to the map;
> 
> So far all the map backends are of generic nature, knowing absolutely nothing
> about a particular consumer/subsystem of eBPF (tc, socket filters, etc). The
> tail call is a bit special, but nevertheless generic for each user and [very]
> useful, so it makes sense to inherit from the array map and move the code 
> there.
> 
> I don't really like that we start add new _special_-cased maps here into the
> eBPF core code, it seems quite hacky. :( From your rather terse commit 
> description
> where you introduce the maps, I failed to see a detailed elaboration on this 
> i.e.
> why it cannot be abstracted any different?

It will be very useful that giving the eBPF programs the ablility to access
hardware PMU counter, just as I mentioned in V1 commit message.
Of course, there are some special code when creating the perf_event type map
in V2, but you will find less special code in the next version(V3). I have
reused most of the prog_array map implementation. We can make the perf_event
array map more generic in the future.

BR.
>  
>> Patch 4/5 implement function bpf_perf_event_read() that get the selected
>> hardware PMU conuter;
>>
>> Patch 5/5 give a simple example.
>>
>> Kaixu Xia (5):
>>bpf: Add new bpf map type to store the pointer to struct perf_event
>>bpf: Add function map->ops->map_traverse_elem() to traverse map elems
>>bpf: Save the pointer to struct perf_event to map
>>

Re: [PATCH v2 1/5] clk: qcom: Enable gpll0_vote rate propagation on MSM8916

[Georgi Djakov]

On 24.07.15 20:25, Stephen Boyd wrote:
> On 07/24/2015 09:58 AM, Georgi Djakov wrote:
>> Currently we are missing the SET_RATE_PARENT flag on gpll0_vote and
>> as a result of that, when it has a child with SET_RATE_PARENT flag,
>> the rate of the child is not propagated up to the gpll0. Fix that
>> by adding the SET_RATE_PARENT flag to gpll0_vote.
>>
>> Signed-off-by: Georgi Djakov 
> 
> This doesn't make any sense. GPLL0 doesn't change rate, so having the flag 
> here on the GPLL0 vote clock doesn't help anything.
> 

Right, gpll0 has a fixed rate. Sorry for the confusion.
--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> On 24.07.2015 12:40, Kukjin Kim wrote:
> > On 07/24/15 09:30, Michael Turquette wrote:
> >> Quoting Kukjin Kim (2015-07-07 07:43:31)
> >>> Bartlomiej Zolnierkiewicz wrote:
> >
> > [...]
> >
> > Chanwoo Choi (3):
> >   clk: samsung: exynos3250: Add cpu clock configuration data and 
> > instaniate cpu clock
> >   ARM: dts: Add CPU OPP and regulator supply property for Exynos3250
> >   ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver
> >
> >  arch/arm/boot/dts/exynos3250-monk.dts   |  4 
> >  arch/arm/boot/dts/exynos3250-rinato.dts |  4 
> >  arch/arm/boot/dts/exynos3250.dtsi   | 15 +++
> >  arch/arm/mach-exynos/exynos.c   |  1 +
> >  drivers/clk/samsung/clk-exynos3250.c| 32 
> > ++--
> >  include/dt-bindings/clock/exynos3250.h  |  1 +
> >  6 files changed, 55 insertions(+), 2 deletions(-)
> 
>  Reviewed-by: Bartlomiej Zolnierkiewicz 
> 
>  Thank you for working on this.
> 
> >>> +1 Thanks.
> >>>
> >>> Mike and Sylwester, if you're OK on this series, I'd like to pick up in 
> >>> Samsung
> >>> tree together. And if you want, I could provide topic branch for clk tree.
> >>
> >> Kukjin,
> >>
> >> A topic branch would be great.
> >>
> > Sure, BTW it means you did 'ack' on this clk change? If not, please let
> > em know ;-) I'll let you know once the topic branch is ready.
> 
> Dear Kukjin,
> 
> Will you handle this patchset and dependants (ARM: dts: Add CPU cooling
> binding for Exynos3250-based Rinato/Monk board) for v4.3?
> 
You mean Chanwoo's patch. Yes, I'll. Thanks for your gentle reminder.

- Kukjin

--
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: [GIT PULL] ARM: defconfig: Improvements for 4.3

[Kukjin Kim]

Krzysztof Kozlowski
> 
> 2015-07-17 15:51 GMT+09:00 Krzysztof Kozlowski :
> > Dear Kukjin,
> >
> > Few defconfig related changes.
> >
> > Description along with a tag.
> > You can find them also on the lists with my reviewed-by.
> >
> > Best regards,
> > Krzysztof
> 
> Any comments on this pull request?
> 
Will pick them up, thanks.

> Best regards,
> Krzysztof
> 
> 
> >
> >
> > The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
> >
> >   Merge tag 'ext4_for_linus_stable' of 
> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> (2015-07-05 16:24:54 -0700)

Please don't make a branch based on some random commit, just use 'rc' as a
basis. Note that usually '-rc1' is used if there is no reason to use another
'rc' because of dependency.

- Kukjin

> >
> > are available in the git repository at:
> >
> >
> >   https://github.com/krzk/linux.git tags/samsung-defconfig-4.3
> >
> > for you to fetch changes up to 5efedc7617df7add295702f21f11dd7e7a67b76e:
> >
> >   ARM: multi_v7_defconfig: Enable max77802 regulator (2015-07-16 15:57:31 
> > +0900)
> >
> > 
> > Defconfig changes around Exynos based boards:
> > 1. Enable sound on Odroid XU3 on exynos defconfig.
> > 2. Enable NTC thermistors for Chromebooks on exynos and multi_v7.
> > 3. Enable main PMIC regulator for Chromebooks on multi_v7.
> > 4. Clean up in multi_v7 - remove old (non-existing) configs.
> >
> > 
> > Anand Moon (1):
> >   ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3
> >
> > Javier Martinez Canillas (4):
> >   ARM: multi_v7_defconfig: Remove old Samsung USB PHY configs
> >   ARM: multi_v7_defconfig: Enable NTC Thermistors support
> >   ARM: exynos_defconfig: Enable NTC Thermistors support
> >   ARM: multi_v7_defconfig: Enable max77802 regulator
> >
> >  arch/arm/configs/exynos_defconfig   | 3 +++
> >  arch/arm/configs/multi_v7_defconfig | 5 +++--
> >  2 files changed, 6 insertions(+), 2 deletions(-)
> > --

--
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 2/9] ARM: multi_v7_defconfig: Enable max77802 regulator, rtc and clock drivers

[Kukjin Kim]

Olof Johansson wrote:
> 
> Hi,
> 
Hi,

> On Fri, Jul 17, 2015 at 11:47 AM, Javier Martinez Canillas
>  wrote:
> > Hello Olof,
> >
> > On Fri, Jul 17, 2015 at 6:49 PM, Olof Johansson  wrote:
> >> On Thu, Jul 16, 2015 at 09:42:47AM +0900, Krzysztof Kozlowski wrote:
> >>> On 16.07.2015 00:38, Javier Martinez Canillas wrote:
> >>> > Hello,
> >>> >
> >>> > On Thu, May 14, 2015 at 5:40 PM, Javier Martinez Canillas
> >>> >  wrote:
> >>> >> The Maxim max77802 Power Management IC is used on many Exynos machines.
> >>> >> Besides a bunch of regulators, this chip has a Real-Time-Clock (RTC)
> >>> >> and 2-channel 32kHz clock outputs.
> >>> >>
> >>> >> Enable the kernel config options to have the drivers for these devices
> >>> >> built as a module.
> >>> >>
> >>> >> Signed-off-by: Javier Martinez Canillas 
> >>> >> 
> >>> >> ---
> >>> >>  arch/arm/configs/multi_v7_defconfig | 3 +++
> >>> >>  1 file changed, 3 insertions(+)
> >>> >>
> >>> >> diff --git a/arch/arm/configs/multi_v7_defconfig 
> >>> >> b/arch/arm/configs/multi_v7_defconfig
> >>> >> index 2349584b6e08..080120fe5580 100644
> >>> >> --- a/arch/arm/configs/multi_v7_defconfig
> >>> >> +++ b/arch/arm/configs/multi_v7_defconfig
> >>> >> @@ -373,6 +373,7 @@ CONFIG_POWER_RESET_SYSCON=y
> >>> >>  CONFIG_REGULATOR_MAX8907=y
> >>> >>  CONFIG_REGULATOR_MAX8973=y
> >>> >>  CONFIG_REGULATOR_MAX77686=y
> >>> >> +CONFIG_REGULATOR_MAX77802=m
> >>> >
> >>> > I noticed that the version that landed in 4.2-rc1 as commit
> >>> > f3caa529c6f5 ("ARM: multi_v7_defconfig: Enable max77802 regulator, rtc
> >>> > and clock drivers") doesn't include this symbol. I guess it was caused
> >>> > by a wrong resolved conflict? I'll post a patch to enable the
> >>> > regulator again.
> >>>
> >>> As you can see in mentioned mainline commit Kukjin removed it manually:
> >>> [kg...@kernel.org: removing useless REGULATOR_MAX77802 config]
> >>>
> >>> I wonder why?
> >>
> >> Seems odd. exynos_defconfig still enables it.
> >>
It has been removed when I did 'make savedefconfig' at that time maybe because
of dependency with other configs...

> > Yeah since it is needed for at least the Exynos5420 Peach Pit and
> > Exynos5800 Peach Pi Chromebooks that use this PMIC.
> >
> >> Javier or Krzysztof, please send an incremental fix to enable and I'll pick
> >> it up as a fix.
> >>
> >
> > I already posted an incremental patch [0] and Krzysztof is pushing it
> > through Kukjin for 4.3 [1].
> >
Yes. I'll send it out to arm-soc in this weekend.

> > I guess that's OK and there is no need to add it as a fix for the 4.2
> > -rc cycle since this is not really a regression. I mean, the max77802
> > regulator driver was never enabled for multi_v7_defconfig before.
> 
> Yeah, I came across those emails a little further down. :-) It's all
> good, we'll see it come in later.
> 
Thanks,
Kukjin

--
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] cleanups for crypto/wp512.c

[Herbert Xu]

On Fri, Jul 24, 2015 at 06:50:15PM +0200, Ahmed Mohamed Abd EL Mawgood wrote:
> 
> fixing all errors and warning of checkpatch.pl for
> crypto/wp512.c
> Signed-off-by: Ahmed Mohamed 

Nack.  Please do not generate patches purely based on checkpatch.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] code cleanups for crypto/blkcipher.c

[Herbert Xu]

On Fri, Jul 24, 2015 at 04:04:32PM +0200, Ahmed Mohamed Abd EL Mawgood wrote:
>
> @@ -68,6 +68,7 @@ static inline void blkcipher_unmap_dst(struct 
> blkcipher_walk *walk)
>  static inline u8 *blkcipher_get_spot(u8 *start, unsigned int len)
>  {
>   u8 *end_page = (u8 *)(((unsigned long)(start + len - 1)) & PAGE_MASK);
> +
>   return max(start, end_page);
>  }

Nack.  This makes the code less readable.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: [GIT PULL] Non-critical fixes for v4.3

[Kukjin Kim]

Krzysztof Kozlowski wrote:
> 
> 2015-07-24 20:04 GMT+09:00 Bartlomiej Zolnierkiewicz 
> :
> >
> > Hi,
> >
> > On Friday, July 24, 2015 03:34:55 PM Krzysztof Kozlowski wrote:
> >> Dear Kukjin,
> >>
> >> Previously you did not picked up the fix for cpufreq memory leak.
> >> I am sending it again with respective acks from LKML. Also another
> >> minor improvement in the set.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93:
> >>
> >>   Merge tag 'ext4_for_linus_stable' of 
> >> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
> (2015-07-05 16:24:54 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>
> >>   https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2
> >>
> >> for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d:
> >>
> >>   video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 
> >> +0900)
> >>
> >> 
> >> Improvements for Exynos boards:
> >> 1. Fix memory leak in cpufreq error path.
> >> 2. Constify platform_device_id in video/fbdev/s3c-fb.
> >>
> >> 
> >> Krzysztof Kozlowski (1):
> >>   video: fbdev: s3c-fb: Constify platform_device_id
> >>
> >> Shailendra Verma (1):
> >>   cpufreq: exynos: Fix for memory leak in case SOC name does not match
> >
> > I would suggest merging this fix in v4.2 not v4.3:
> >
> > - it is obvious and touches only error paths
> 
> Indeed, good point, thanks for pointing this. Although these are not
> regressions for issues introduced in current release but they are are
> non-intrusive.
> 
> Kukjin, do you agree? Can you pull them for second round of v4.2 fixes (not 
> 4.3)
> 
Agreed. OK.

> > - (hopefully) in v4.3 the exynos-cpufreq driver will be completely
> >   replaced by using cpufreq-dt for Exynos platforms (thus there will be
> >   no benefits of having this fix in v4.3 but there will be potential
> >   risk of merge conflicts due to exynos-cpufreq driver removal)
> >
> 
> We'll see... The Exynos 4x12 requires OPP patches. Are these ready for 4.3?
> 
I think, if any conflicts based on fixes during -rc, can be handled by
maintainer.

Thanks,
Kukjin

--
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 0/9] Platform support for thermal management on Junoe

[Viresh Kumar]

On 24-07-15, 15:16, Punit Agrawal wrote:
> Hi Viresh,
> 
> Viresh Kumar  writes:
> 
> > On 22-07-15, 15:02, Punit Agrawal wrote:
> >>   cpufreq-dt: Supply power coefficient when registering cooling devices
> >>   cpufreq: arm_big_little: Add support to register a cpufreq cooling
> >> device
> >
> > Acked-by: Viresh Kumar 
> 
> Thanks for the acks.
> 
> Once the device tree property is agreed upon, will you be picking up these
> patches?

Since it is already present in patchwork, Rafael can apply these.

-- 
viresh
--
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/

[PATCH] kselftests/ftrace : Add event trigger testcases

[Masami Hiramatsu]

This adds simple event trigger testcases for ftracetest,
which covers following triggers.
 - traceon-traceoff trigger
 - enable/disable_event trigger
 - snapshot trigger
 - stacktrace trigger
 - trigger filters

Signed-off-by: Masami Hiramatsu 
Cc: Steven Rostedt 
Cc: Ingo Molnar 
Cc: Shuah Khan 
Cc: Namhyung Kim 
Cc: Tom Zanussi 
---
 tools/testing/selftests/ftrace/test.d/functions|9 +++
 .../ftrace/test.d/trigger/trigger-eventonoff.tc|   64 
 .../ftrace/test.d/trigger/trigger-filter.tc|   59 ++
 .../ftrace/test.d/trigger/trigger-snapshot.tc  |   56 ++
 .../ftrace/test.d/trigger/trigger-stacktrace.tc|   53 +
 .../ftrace/test.d/trigger/trigger-traceonoff.tc|   58 ++
 6 files changed, 299 insertions(+)
 create mode 100644 
tools/testing/selftests/ftrace/test.d/trigger/trigger-eventonoff.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/trigger/trigger-filter.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/trigger/trigger-snapshot.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/trigger/trigger-stacktrace.tc
 create mode 100644 
tools/testing/selftests/ftrace/test.d/trigger/trigger-traceonoff.tc

diff --git a/tools/testing/selftests/ftrace/test.d/functions 
b/tools/testing/selftests/ftrace/test.d/functions
index 5d8cd06..36ca18e 100644
--- a/tools/testing/selftests/ftrace/test.d/functions
+++ b/tools/testing/selftests/ftrace/test.d/functions
@@ -14,3 +14,12 @@ enable_tracing() { # start trace recording
 reset_tracer() { # reset the current tracer
 echo nop > current_tracer
 }
+
+reset_trigger() { # reset all current setting triggers
+grep -v ^# events/*/*/trigger |
+while read line; do
+cmd=`echo $line | cut -f2- -d:`
+   echo "!$cmd" > `echo $line | cut -f1 -d:`
+done
+}
+
diff --git 
a/tools/testing/selftests/ftrace/test.d/trigger/trigger-eventonoff.tc 
b/tools/testing/selftests/ftrace/test.d/trigger/trigger-eventonoff.tc
new file mode 100644
index 000..1a94450
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-eventonoff.tc
@@ -0,0 +1,64 @@
+#!/bin/sh
+# description: event trigger - test event enable/disable trigger
+
+do_reset() {
+reset_trigger
+echo > set_event
+clear_trace
+}
+
+fail() { #msg
+do_reset
+echo $1
+exit $FAIL
+}
+
+if [ ! -f set_event -o ! -d events/sched ]; then
+echo "event tracing is not supported"
+exit_unsupported
+fi
+
+if [ ! -f events/sched/sched_process_fork/trigger ]; then
+echo "event trigger is not supported"
+exit_unsupported
+fi
+
+reset_tracer
+do_reset
+
+FEATURE=`grep enable_event events/sched/sched_process_fork/trigger`
+if [ -z "$FEATURE" ]; then
+echo "event enable/disable trigger is not supported"
+exit_unsupported
+fi
+
+echo "Test enable_event trigger"
+echo 0 > events/sched/sched_switch/enable
+echo 'enable_event:sched:sched_switch' > 
events/sched/sched_process_fork/trigger
+( echo "forked")
+if [ `cat events/sched/sched_switch/enable` != '1*' ]; then
+fail "enable_event trigger on sched_process_fork did not work"
+fi
+
+reset_trigger
+
+echo "Test disable_event trigger"
+echo 1 > events/sched/sched_switch/enable
+echo 'disable_event:sched:sched_switch' > 
events/sched/sched_process_fork/trigger
+( echo "forked")
+if [ `cat events/sched/sched_switch/enable` != '0*' ]; then
+fail "disable_event trigger on sched_process_fork did not work"
+fi
+
+reset_trigger
+
+echo "Test semantic error for event enable/disable trigger"
+! echo 'enable_event:nogroup:noevent' > events/sched/sched_process_fork/trigger
+! echo 'disable_event+1' > events/sched/sched_process_fork/trigger
+echo 'enable_event:sched:sched_switch' > 
events/sched/sched_process_fork/trigger
+! echo 'enable_event:sched:sched_switch' > 
events/sched/sched_process_fork/trigger
+! echo 'disable_event:sched:sched_switch' > 
events/sched/sched_process_fork/trigger
+
+do_reset
+
+exit 0
diff --git a/tools/testing/selftests/ftrace/test.d/trigger/trigger-filter.tc 
b/tools/testing/selftests/ftrace/test.d/trigger/trigger-filter.tc
new file mode 100644
index 000..514e466
--- /dev/null
+++ b/tools/testing/selftests/ftrace/test.d/trigger/trigger-filter.tc
@@ -0,0 +1,59 @@
+#!/bin/sh
+# description: event trigger - test trigger filter
+
+do_reset() {
+reset_trigger
+echo > set_event
+clear_trace
+}
+
+fail() { #msg
+do_reset
+echo $1
+exit $FAIL
+}
+
+if [ ! -f set_event -o ! -d events/sched ]; then
+echo "event tracing is not supported"
+exit_unsupported
+fi
+
+if [ ! -f events/sched/sched_process_fork/trigger ]; then
+echo "event trigger is not supported"
+exit_unsupported
+fi
+
+reset_tracer
+do_reset
+
+echo "Test trigger filter"
+echo 1 > tracing_on
+echo 'traceoff if child_pid == 0' > events/sched/sched_process_fork/trigger
+( echo "forked")
+if [ `cat tracing_on` -ne 1 ]; then
+fail "traceoff trigger on 

[GIT PULL] MTD updates for 4.2-rc4

[Brian Norris]

Hi Linus,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-mtd.git tags/for-linus-20150724

for you to fetch changes up to 5f867db63473f32cce1b868e281ebd42a41f8fad:

  mtd: nand: Fix NAND_USE_BOUNCE_BUFFER flag conflict (2015-07-07 13:03:25 
-0700)


MTD updates for 4.2-rc4:

Two trivial updates. I meant to send these much earlier, but I've been
preoccupied.

* Add MAINTAINERS entry for diskonchip g3 driver

* Fix an overlooked conflict in bitfield value assignments

The latter update is a bit overdue, but there's no reason to wait any longer.


Robert Jarzmik (1):
  MAINTAINERS: mtd: docg3: add docg3 maintainer

Scott Wood (1):
  mtd: nand: Fix NAND_USE_BOUNCE_BUFFER flag conflict

 MAINTAINERS  |  6 ++
 include/linux/mtd/nand.h | 10 +-
 2 files changed, 11 insertions(+), 5 deletions(-)
--
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: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

[Michael Ellerman]

On Sat, 2015-07-25 at 10:35 +1000, Finn Thain wrote:
> On Fri, 24 Jul 2015, Christian T. Steigies wrote:
> > 3b5801864975cf23bcacb52f648e74cc  /dev/nvram
> > 3b5801864975cf23bcacb52f648e74cc  /tmp/nvram
> 
> Thanks for helping with this, Christian. I'll add your name in "Tested-by" 
> tags on the relevant patches. These are rudimentary tests but combined 
> with my own testing on m68k, ppc32 and x86, coverage is quite good. Some 
> testing on ppc64 is still lacking though.

*Blush*

I'll try and get to it next week promise!

cheers


--
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] drivers/of/fdt.c: replace pr_warning by pr_warn

[long.wanglong]

On 2015/7/25 3:00, Rob Herring wrote:
> On Tue, Jul 21, 2015 at 3:01 AM, Wang Long  wrote:
>> Update the last pr_warning callsite in drivers/of.
> 
> That is obvious in the diff, but can you tell me why?

Hi Rob,

When we use script "./scripts/checkpatch.pl" to check a patch, using pr_warning
will produce WARNING:

WARNING: Prefer pr_warn(... to pr_warning(...
#22: FILE: drivers/of/fdt.c:428:
+   pr_warning("End of tree marker overwritten: %08x\n",

So,we should convert pr_warning to pr_warn.


Best Regards
Wang Long


> 
> Rob
> 
>> Signed-off-by: Wang Long 
>> ---
>>  drivers/of/fdt.c | 10 +-
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 0749656..e1f61b8 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -425,7 +425,7 @@ static void __unflatten_device_tree(const void *blob,
>> start = 0;
>> unflatten_dt_node(blob, mem, , NULL, mynodes, 0, false);
>> if (be32_to_cpup(mem + size) != 0xdeadbeef)
>> -   pr_warning("End of tree marker overwritten: %08x\n",
>> +   pr_warn("End of tree marker overwritten: %08x\n",
>>be32_to_cpup(mem + size));
>>
>> pr_debug(" <- unflatten_device_tree()\n");
>> @@ -985,24 +985,24 @@ void __init __weak early_init_dt_add_memory_arch(u64 
>> base, u64 size)
>> size &= PAGE_MASK;
>>
>> if (base > MAX_PHYS_ADDR) {
>> -   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory block 0x%llx - 0x%llx\n",
>> base, base + size);
>> return;
>> }
>>
>> if (base + size - 1 > MAX_PHYS_ADDR) {
>> -   pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory range 0x%llx - 0x%llx\n",
>> ((u64)MAX_PHYS_ADDR) + 1, base + size);
>> size = MAX_PHYS_ADDR - base + 1;
>> }
>>
>> if (base + size < phys_offset) {
>> -   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory block 0x%llx - 0x%llx\n",
>>base, base + size);
>> return;
>> }
>> if (base < phys_offset) {
>> -   pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
>> +   pr_warn("Ignoring memory range 0x%llx - 0x%llx\n",
>>base, phys_offset);
>> size -= phys_offset - base;
>> base = phys_offset;
>> --
>> 1.8.3.4
>>
> 
> .
> 


--
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 v2 2/5] mtd: nand: Qualcomm NAND controller driver

[Stephen Boyd]

On 07/21/2015 03:34 AM, Archit Taneja wrote:
> diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
> index 5b2806a..31951fc 100644
> --- a/drivers/mtd/nand/Kconfig
> +++ b/drivers/mtd/nand/Kconfig
> @@ -538,4 +538,11 @@ config MTD_NAND_HISI504
>   help
> Enables support for NAND controller on Hisilicon SoC Hip04.
>  
> +config MTD_NAND_QCOM
> + tristate "Support for NAND on QCOM SoCs"
> + depends on ARCH_QCOM && QCOM_ADM

This is sort of annoying that the menu won't show up unless the ADM
driver is also enabled (which would be in a completely different area of
the configurator). Perhaps drop that requirement because it isn't
required to build?

> + help
> +   Enables support for NAND flash chips on SoCs containing the EBI2 NAND
> +   controller. This controller is found on IPQ806x SoC.
> +
>  endif # MTD_NAND
> diff --git a/drivers/mtd/nand/qcom_nandc.c b/drivers/mtd/nand/qcom_nandc.c
> new file mode 100644
> index 000..51c284c
> --- /dev/null
> +++ b/drivers/mtd/nand/qcom_nandc.c
> @@ -0,0 +1,2019 @@
> +/*
> + * Copyright (c) 2015, The Linux Foundation. All rights reserved.
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License version 2, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 

Where is this used?

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
[..]
> +/*
> + * the NAND controller performs reads/writes with ECC in 516 byte chunks.
> + * the driver calls the chunks 'step' or 'codeword' interchangeably
> + */
> +#define NANDC_STEP_SIZE  512
> +
> +/*
> + * the largest page size we support is 8K, this will have 16 steps/codewords
> + * of 512 bytes each
> + */
> +#define  MAX_NUM_STEPS   (SZ_8K / NANDC_STEP_SIZE)
> +
> +/* we read at most 3 registers per codeword scan */
> +#define MAX_REG_RD   (3 * MAX_NUM_STEPS)
> +
> +/* ECC modes */
> +#define ECC_NONE BIT(0)
> +#define ECC_RS_4BIT  BIT(1)
> +#define  ECC_BCH_4BITBIT(2)
> +#define  ECC_BCH_8BITBIT(3)
> +
> +struct desc_info {
> + struct list_head list;
> +
> + enum dma_transfer_direction dir;
> + struct scatterlist sgl;
> + struct dma_async_tx_descriptor *dma_desc;
> +};
> +
> +/*
> + * holds the current register values that we want to write. acts as a 
> contiguous
> + * chunk of memory which we use to write the controller registers through 
> DMA.
> + */
> +struct nandc_regs {
> + u32 cmd;
> + u32 addr0;
> + u32 addr1;
> + u32 chip_sel;
> + u32 exec;
> +
> + u32 cfg0;
> + u32 cfg1;
> + u32 ecc_bch_cfg;
> +
> + u32 clrflashstatus;
> + u32 clrreadstatus;
> +
> + u32 cmd1;
> + u32 vld;
> +
> + u32 orig_cmd1;
> + u32 orig_vld;
> +
> + u32 ecc_buf_cfg;
> +};
> +
> +/*
> + * @cmd_crci:ADM DMA CRCI for command flow control
> + * @data_crci:   ADM DMA CRCI for data flow control
> + * @list:DMA descriptor list (list of desc_infos)
> + * @dma_done:completion param to denote end of last
> + *   descriptor in the list
> + * @data_buffer: our local DMA buffer for page read/writes,
> + *   used when we can't use the buffer provided
> + *   by upper layers directly
> + * @buf_size/count/start:markers for chip->read_buf/write_buf functions
> + * @reg_read_buf:buffer for reading register data via DMA
> + * @reg_read_pos:marker for data read in reg_read_buf
> + * @cfg0, cfg1, cfg0_raw..:  NANDc register configurations needed for
> + *   ecc/non-ecc mode for the current nand flash
> + *   device
> + * @regs:a contiguous chunk of memory for DMA register
> + *   writes
> + * @ecc_strength:4 bit or 8 bit ecc, received via DT
> + * @bus_width:   8 bit or 16 bit NAND bus width, 
> received via DT
> + * @ecc_modes:   supported ECC modes by the current 
> controller,
> + *   initialized via DT match data
> + * @cw_size: the number of bytes in a single step/codeword
> + *   of a page, consisting of all data, ecc, spare
> + *   and reserved bytes
> + * @cw_data: the number of bytes within a codeword protected
> + *  

Re: [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support

[Masami Hiramatsu]

On 2015/07/25 0:52, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 24, 2015 at 04:55:19PM +0900, Namhyung Kim escreveu:
>> On Fri, Jul 24, 2015 at 01:24:53AM +0900, Masami Hiramatsu wrote:
>>> On 2015/07/23 23:01, Arnaldo Carvalho de Melo wrote:
 Em Thu, Jul 23, 2015 at 10:13:22PM +0900, Masami Hiramatsu escreveu:
> 
>>> The following patterns we've discussed.
>>>
>>>  - :
>>> simple, but could easily clash with others.
>>>  - probe_:
>>>  - sdt_:
>>> also simple and similar to current solution. but fragile against
>>> clash among SDTs.
>>>  - probe_:_
>>> also simple, but if provider or/and name has '_', it is hard to
>>> split the provider and name. and fragile against clash among SDTs too.
>>>  - _/
>>> possible, but ugly since buildid is a random long xdigits(maybe cut up
>>> to 8 or 12 bytes).
>  
>> As I said, we might allow name clashes as they're rare.  I don't want
>> to make it complex just for an uncommon case.  I think such a
>> duplicate name is fine as long as 'perf list' indicates it and 'perf
>> record' enable them all.
> 
> I made some comments about enabling it all by default, look below.
>  
>> If we agreed to extend the event format, I'd like to keep it simple
>> and to make it optional to add more info (separated by colon?).
> 
> Reading this again after writing what is below: my suggestion is to use
> @, see rationale below.
>  
>> Maybe something like below.  Suppose we have 3 SDT events with a same
>> name:
>>
>>  /some/where/dir1/libfoo1.so (build-id: 0x1234...) -->  foo:bar
>>  /some/where/dir2/libfoo1.so (build-id: 0x5678...) -->  foo:bar
>>  /some/where/dir2/libfoo2.so (build-id: 0xabcd...) -->  foo:bar
>>
>> So perf list shows the single name, but also says it has 3 events.
>>
>>   $ perf list sdt_foo:bar
>>   
>>   sdt_foo:bar (total 3 events)[User SDT event]
> 
> I would show what desambiguates them in non verbose mode, i.e., the
> above would be:
> 
>$ perf list sdt_foo:bar
> 
>sdt_foo:bar:dir1/libfoo1.so   [User SDT event]
>sdt_foo:bar:dir2/libfoo1.so   [User SDT event]
>sdt_foo:bar:libfoo2.so[User SDT event]
> 
>  The -v one would should both the full path and the buildid, but this
> is just polishing up the default output a bit to make it more
> informative.

I agree that the short path is useful, but we know only full path
how to make it short? (only show the differences?)

> 
>   Now what should be the default when one does:
> 
>perf record -e sdt_foo:bar
> 
> Will it enable all events or bail out and state that multiple
> events with that name matches, requiring a '--all-matches' to really
> apply it to all events with the same name?

OK, but the problem is that the k/uprobe_event doesn't support multiple
probe on one event yet. This means that if we set those 3 events, it will
be translated to "sdt_foo:bar", "sdt_foo:bar_1", and "sdt_foo:bar_2".
So we need to enhance k/uprobe_event too. Note that, if the event-name
clash happens among events with different type of arguments, we can not
bail it out... It is better to warn user if that happened.

>   Humm, this probably will not be that common, so perhaps just
> use all matches by default while telling the user that all those places
> were used and if the user wants just one of them, be more precise,
> adding somehow a disambiguator.
> 
>   That would be something like this:
> 
> perf record -e sdt_foo:bar:0x1234
> 
>   Or perhaps:
> 
> perf record -e sdt_foo:bar@0x1234
> 
>   Because in this case the 'at' meaning of '@' makes sense, i.e.
> use the std_foo:bar event at the DSO with a 0x1234 buildid?

Ah, that's nice :) I like '@'.

>   Additionally, for people that don't want to mess with buildids
> because its environment is deemed well controlled and this works and is
> unambiguous, looking at the LD_LIBRARY_PATH or equivalent:
> 
> perf record -e sdt_foo:bar@libfoo2
> 
>   Full paths could be used as well.
>>
>>   $ perf list -v sdt_foo:bar
>>   
>>   sdt_foo:bar:libfoo1.so:0x1234...[User SDT event]
>>   sdt_foo:bar:libfoo1.so:0x5678...[User SDT event]
>>   sdt_foo:bar:libfoo2.so:0xabcd...[User SDT event]
> 
>>
>> Now perf record can accept any of these forms..
>>
>>   # record all 3 events
>>   $ perf record -e 'sdt_foo:bar'
>>
>>   # record 2 events from libfoo1.so
>>   $ perf record -e 'sdt_foo:bar:libfoo1.so'
>>
>>   # record only 1 event
>>   $ perf record -e 'sdt_foo:bar:libfoo1.so:0x1234...'
>>
>>
>> What do you think?
> 
> If nothing prevents using @ with the meaning of "event at LOCATION"
> where LOCATION is a buildid (noticed because it starts with 0x) or
> a library name or pathname, then that looks more natural.

BTW, will we show it as  "[User SDT event]" instead of "[Tracepoint]"?
In that case, after setting the event, same name event will appear
under tracefs/events/. I guess it conflicts with above SDT event.
e.g.

   $ perf list sdt_foo:bar

   

Re: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

[Michael Schmitz]

Hi Christian,

good to know this worked - for the record (Finn), this is the kernel 
with Finn's patch applied.


I'll build the missing LVM module so Christian can run the tests on the 
unpatched kernel as well.


Thanks for testing!

Michael


Am 25.07.15 um 07:07 schrieb Christian T. Steigies:

Moin,
On Fri, Jul 24, 2015 at 02:56:26PM +1200, Michael Schmitz wrote:

here's what Finn asked me to run as tests:

# dmesg | grep this_id > nvram.out
# cat /proc/driver/nvram >> nvram.out
# hexdump -C /dev/nvram >> nvram.out
# cp /dev/nvram /tmp/nvram
# cp /tmp/nvram /dev/nvram
# md5sum /dev/nvram /tmp/nvram >> nvram.out

It seems I could successfully reset the nvram under TOS with bootconf.
Here is nvram.out, using the new kernel you sent me:

root@garkin:~>uname -a
Linux garkin 4.2.0-rc2-atari-269994-gc1e9d12 #327 Fri Jul 24 19:34:44 NZST 2015 
m68k GNU/Linux

PS it seems LVM is working with this kernel as well!

Christian


[7.00] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 
0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { }, 
options { REAL_DMA SUPPORT_TAGS }
Checksum status  : valid
Boot preference  : unspecified
SCSI arbitration : on
SCSI host ID : 7
OS language  : English (US)
Keyboard language: English (UK)
Date format  : YYÿDDÿMM, 24h clock
Boot delay   : 10s
Video mode   : ?? colors, 80 columns, VGA PAL monitor
overscan, compat. mode off, line doubling
  00 00 ff ff ff ff 00 03  13 ff 0a ff ff ff 01 7f  ||
0010  87 ff 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
0030  e1 1e |..|
0032
3b5801864975cf23bcacb52f648e74cc  /dev/nvram
3b5801864975cf23bcacb52f648e74cc  /tmp/nvram


--
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: [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c

[Finn Thain]

On Fri, 24 Jul 2015, Christian T. Steigies wrote:

> Moin,
> On Fri, Jul 24, 2015 at 02:56:26PM +1200, Michael Schmitz wrote:
> > 
> > here's what Finn asked me to run as tests:
> > 
> > # dmesg | grep this_id > nvram.out
> > # cat /proc/driver/nvram >> nvram.out
> > # hexdump -C /dev/nvram >> nvram.out
> > # cp /dev/nvram /tmp/nvram
> > # cp /tmp/nvram /dev/nvram
> > # md5sum /dev/nvram /tmp/nvram >> nvram.out
> 
> It seems I could successfully reset the nvram under TOS with bootconf.
> Here is nvram.out, using the new kernel you sent me:
> 
> root@garkin:~>uname -a
> Linux garkin 4.2.0-rc2-atari-269994-gc1e9d12 #327 Fri Jul 24 19:34:44 NZST 
> 2015 m68k GNU/Linux
> 
> PS it seems LVM is working with this kernel as well!
> 
> Christian
> 
> 
> [7.00] scsi host0: Atari native SCSI, io_port 0x0, n_io_port 0, base 
> 0x0, irq 15, can_queue 8, cmd_per_lun 1, sg_tablesize 0, this_id 7, flags { 
> }, options { REAL_DMA SUPPORT_TAGS } 
> Checksum status  : valid
> Boot preference  : unspecified
> SCSI arbitration : on
> SCSI host ID : 7
> OS language  : English (US)
> Keyboard language: English (UK)
> Date format  : YY?DD?MM, 24h clock
> Boot delay   : 10s
> Video mode   : ?? colors, 80 columns, VGA PAL monitor
>overscan, compat. mode off, line doubling
>   00 00 ff ff ff ff 00 03  13 ff 0a ff ff ff 01 7f  ||
> 0010  87 ff 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  ||
> 0030  e1 1e |..|
> 0032
> 3b5801864975cf23bcacb52f648e74cc  /dev/nvram
> 3b5801864975cf23bcacb52f648e74cc  /tmp/nvram


Thanks for helping with this, Christian. I'll add your name in "Tested-by" 
tags on the relevant patches. These are rudimentary tests but combined 
with my own testing on m68k, ppc32 and x86, coverage is quite good. Some 
testing on ppc64 is still lacking though.

-- 
--
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/

[PATCH] Documentation: add new description of path-name lookup.

[NeilBrown]

This document is based on three recent lwn.net articles.
Some of the introductory material and linkage between articles
has been removed, and some time-based descriptions have been
revised.

Also all links to code have been removed as the code is very close by.

Signed-off-by: NeilBrown 

---
I'm open to comments on the filename.  There is already a 'path-lookup.txt'.
I made this 'path-lookup.md' as it is written for markdown processing.
Is that confusing or helpful?


diff --git a/Documentation/filesystems/path-lookup.md 
b/Documentation/filesystems/path-lookup.md
new file mode 100644
index ..eedf31c737ed
--- /dev/null
+++ b/Documentation/filesystems/path-lookup.md
@@ -0,0 +1,1297 @@
+
+ p { max-width:50em} ol, ul {max-width: 40em}
+
+
+Pathname lookup in Linux.
+=
+
+This write-up is based on three articles published at lwn.net:
+
+-  Pathname lookup in Linux
+-  RCU-walk: faster pathname lookup in Linux
+-  A walk among the symlinks
+
+Written by Neil Brown with help from Al Viro and Jon Corbet.
+
+Introduction
+
+
+The most obvious aspect of pathname lookup, which very little
+exploration is needed to discover, is that it is complex.  There are
+many rules, special cases, and implementation alternatives that all
+combine to confuse the unwary reader.  Computer science has long been
+acquainted with such complexity and has tools to help manage it.  One
+tool that we will make extensive use of is "divide and conquer".  For
+the early parts of the analysis we will divide off symlinks - leaving
+them until the final part.  Well before we get to symlinks we have
+another major division based on the VFS's approach to locking which
+will allow us to review "REF-walk" and "RCU-walk" separately.  But we
+are getting ahead of ourselves.  There are some important low level
+distinctions we need to clarify first.
+
+There are two sorts of ...
+--
+
+[`openat()`]: http://man7.org/linux/man-pages/man2/openat.2.html
+
+Pathnames (sometimes "file names"), used to identify objects in the
+filesystem, will be familiar to most readers.  They contain two sorts
+of elements: "slashes" that are sequences of one or more "`/`"
+characters, and "components" that are sequences of one or more
+non-"`/`" characters.  These form two kinds of paths.  Those that
+start with slashes are "absolute" and start from the filesystem root.
+The others are "relative" and start from the current directory, or
+from some other location specified by a file descriptor given to a
+"xxx`at`" system call such as "[`openat()`]".
+
+[`execveat()`]: http://man7.org/linux/man-pages/man2/execveat.2.html
+
+It is tempting to describe the second kind as starting with a
+component, but that isn't always accurate: a pathname can lack both
+slashes and components, it can be empty, in other words.  This is
+generally forbidden in POSIX, but some of those "xxx`at`" system calls
+in Linux permit it when the `AT_EMPTY_PATH` flag is given.  For
+example, if you have an open file descriptor on an executable file you
+can execute it by calling [`execveat()`] passing the file descriptor,
+an empty path, and the `AT_EMPTY_PATH` flag.
+
+These paths can be divided into two sections: the final component and
+everything else.  The "everything else" is the easy bit.  In all cases
+it must identify a directory that already exists, otherwise an error
+such as `ENOENT` or `ENOTDIR` will be reported.
+
+The final component is not so simple.  Not only do different system
+calls interpret it quite differently (e.g. some create it, some do
+not), but it might not even exist: neither the empty pathname nor the
+pathname that is just slashes have a final component.  If it does
+exist, it could be "`.`" or "`..`" which are handled quite differently
+from other components.
+
+[POSIX]: 
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_12
+
+If a pathname ends with a slash, such as "`/tmp/foo/`" it might be
+tempting to consider that to have an empty final component.  In many
+ways that would lead to correct results, but not always.  In
+particular, `mkdir()` and `rmdir()` each create or remove a directory named
+by the final component, and they are required to work with pathnames
+ending in "`/`".  According to [POSIX]
+
+> A pathname that contains at least one non- slash> character and
+> that ends with one or more trailing slash> characters shall not
+> be resolved successfully unless the last pathname component before
+> the trailing  characters names an existing directory or a
+> directory entry that is to be created for a directory immediately
+> after the pathname is resolved.
+
+The Linux pathname walking code (mostly in `fs/namei.c`) deals with
+all of these issues: breaking the path into components, handling the
+"everything else" quite separately from the final component, 

[PATCH] serial: etraxfs-uart: use mctrl_gpio helpers for handling modem signals

[Niklas Cassel]

In order to use the mctrl_gpio helpers, we change the DT bindings:
ri-gpios renamed to rng-gpios. cd-gpios renamed to dcd-gpios.
However, no in-tree dts/dtsi specifies these, so no worries.

Signed-off-by: Niklas Cassel 
---
 .../bindings/serial/axis,etraxfs-uart.txt  |  6 +++-
 drivers/tty/serial/Kconfig |  1 +
 drivers/tty/serial/etraxfs-uart.c  | 40 ++
 3 files changed, 16 insertions(+), 31 deletions(-)

diff --git a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt 
b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
index ebcbb62..51b3c9e 100644
--- a/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
+++ b/Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
@@ -6,7 +6,7 @@ Required properties:
 - interrupts: device interrupt
 
 Optional properties:
-- {dtr,dsr,ri,cd}-gpios: specify a GPIO for DTR/DSR/RI/CD
+- {dtr,dsr,rng,dcd}-gpios: specify a GPIO for DTR/DSR/RI/DCD
   line respectively.
 
 Example:
@@ -16,4 +16,8 @@ serial@b0026 {
reg = <0xb0026000 0x1000>;
interrupts = <68>;
status = "disabled";
+   dtr-gpios = < 0 GPIO_ACTIVE_LOW>;
+   dsr-gpios = < 1 GPIO_ACTIVE_LOW>;
+   rng-gpios = < 2 GPIO_ACTIVE_LOW>;
+   dcd-gpios = < 3 GPIO_ACTIVE_LOW>;
 };
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 15b4079..8a4b62e 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1067,6 +1067,7 @@ config SERIAL_ETRAXFS
bool "ETRAX FS serial port support"
depends on ETRAX_ARCH_V32 && OF
select SERIAL_CORE
+   select SERIAL_MCTRL_GPIO if GPIOLIB
 
 config SERIAL_ETRAXFS_CONSOLE
bool "ETRAX FS serial console support"
diff --git a/drivers/tty/serial/etraxfs-uart.c 
b/drivers/tty/serial/etraxfs-uart.c
index a647605..382d434 100644
--- a/drivers/tty/serial/etraxfs-uart.c
+++ b/drivers/tty/serial/etraxfs-uart.c
@@ -10,6 +10,8 @@
 #include 
 #include 
 
+#include "serial_mctrl_gpio.h"
+
 #define DRV_NAME "etraxfs-uart"
 #define UART_NR CONFIG_ETRAX_SERIAL_PORTS
 
@@ -28,10 +30,7 @@ struct uart_cris_port {
 
void __iomem *regi_ser;
 
-   struct gpio_desc *dtr_pin;
-   struct gpio_desc *dsr_pin;
-   struct gpio_desc *ri_pin;
-   struct gpio_desc *cd_pin;
+   struct mctrl_gpios *gpios;
 
int write_ongoing;
 };
@@ -396,21 +395,9 @@ static unsigned int etraxfs_uart_get_mctrl(struct 
uart_port *port)
ret = 0;
if (crisv32_serial_get_rts(up))
ret |= TIOCM_RTS;
-   /* DTR is active low */
-   if (up->dtr_pin && !gpiod_get_raw_value(up->dtr_pin))
-   ret |= TIOCM_DTR;
-   /* CD is active low */
-   if (up->cd_pin && !gpiod_get_raw_value(up->cd_pin))
-   ret |= TIOCM_CD;
-   /* RI is active low */
-   if (up->ri_pin && !gpiod_get_raw_value(up->ri_pin))
-   ret |= TIOCM_RI;
-   /* DSR is active low */
-   if (up->dsr_pin && !gpiod_get_raw_value(up->dsr_pin))
-   ret |= TIOCM_DSR;
if (crisv32_serial_get_cts(up))
ret |= TIOCM_CTS;
-   return ret;
+   return mctrl_gpio_get(up->gpios, );
 }
 
 static void etraxfs_uart_set_mctrl(struct uart_port *port, unsigned int mctrl)
@@ -418,15 +405,7 @@ static void etraxfs_uart_set_mctrl(struct uart_port *port, 
unsigned int mctrl)
struct uart_cris_port *up = (struct uart_cris_port *)port;
 
crisv32_serial_set_rts(up, mctrl & TIOCM_RTS ? 1 : 0, 0);
-   /* DTR is active low */
-   if (up->dtr_pin)
-   gpiod_set_raw_value(up->dtr_pin, mctrl & TIOCM_DTR ? 0 : 1);
-   /* RI is active low */
-   if (up->ri_pin)
-   gpiod_set_raw_value(up->ri_pin, mctrl & TIOCM_RNG ? 0 : 1);
-   /* CD is active low */
-   if (up->cd_pin)
-   gpiod_set_raw_value(up->cd_pin, mctrl & TIOCM_CD ? 0 : 1);
+   mctrl_gpio_set(up->gpios, mctrl);
 }
 
 static void etraxfs_uart_break_ctl(struct uart_port *port, int break_state)
@@ -920,11 +899,12 @@ static int etraxfs_uart_probe(struct platform_device 
*pdev)
 
up->irq = irq_of_parse_and_map(np, 0);
up->regi_ser = of_iomap(np, 0);
-   up->dtr_pin = devm_gpiod_get_optional(>dev, "dtr");
-   up->dsr_pin = devm_gpiod_get_optional(>dev, "dsr");
-   up->ri_pin = devm_gpiod_get_optional(>dev, "ri");
-   up->cd_pin = devm_gpiod_get_optional(>dev, "cd");
up->port.dev = >dev;
+
+   up->gpios = mctrl_gpio_init(>dev, 0);
+   if (IS_ERR(up->gpios))
+   return PTR_ERR(up->gpios);
+
cris_serial_port_init(>port, dev_id);
 
etraxfs_uart_ports[dev_id] = up;
-- 
2.4.6

--
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/

[PATCH] serial: etraxfs-uart: remove empty functions

[Niklas Cassel]

Implementing enable_ms is optional by serial_core.
check_modem_status is just an empty local function.

Signed-off-by: Niklas Cassel 
---
 drivers/tty/serial/etraxfs-uart.c | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/tty/serial/etraxfs-uart.c 
b/drivers/tty/serial/etraxfs-uart.c
index 679709f..a647605 100644
--- a/drivers/tty/serial/etraxfs-uart.c
+++ b/drivers/tty/serial/etraxfs-uart.c
@@ -373,14 +373,6 @@ static void etraxfs_uart_stop_rx(struct uart_port *port)
REG_WR(ser, regi_ser, rw_rec_ctrl, rec_ctrl);
 }
 
-static void etraxfs_uart_enable_ms(struct uart_port *port)
-{
-}
-
-static void check_modem_status(struct uart_cris_port *up)
-{
-}
-
 static unsigned int etraxfs_uart_tx_empty(struct uart_port *port)
 {
struct uart_cris_port *up = (struct uart_cris_port *)port;
@@ -598,7 +590,6 @@ ser_interrupt(int irq, void *dev_id)
receive_chars_no_dma(up);
handled = 1;
}
-   check_modem_status(up);
 
if (masked_intr.tr_rdy) {
transmit_chars_no_dma(up);
@@ -862,7 +853,6 @@ static const struct uart_ops etraxfs_uart_pops = {
.start_tx = etraxfs_uart_start_tx,
.send_xchar = etraxfs_uart_send_xchar,
.stop_rx = etraxfs_uart_stop_rx,
-   .enable_ms = etraxfs_uart_enable_ms,
.break_ctl = etraxfs_uart_break_ctl,
.startup = etraxfs_uart_startup,
.shutdown = etraxfs_uart_shutdown,
-- 
2.4.6

--
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/

[RFCv2 2/3] dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.

[Moritz Fischer]

Signed-off-by: Moritz Fischer 
---
 arch/arm/boot/dts/zynq-7000.dtsi| 43 -
 arch/arm/boot/dts/zynq-parallella.dts   |  2 +-
 arch/arm/boot/dts/zynq-zc702.dts|  2 +-
 arch/arm/boot/dts/zynq-zc706.dts|  2 +-
 arch/arm/boot/dts/zynq-zed.dts  |  2 +-
 arch/arm/boot/dts/zynq-zybo.dts |  2 +-
 include/dt-bindings/reset/xlnx,zynq-reset.h | 94 +
 7 files changed, 141 insertions(+), 6 deletions(-)
 create mode 100644 include/dt-bindings/reset/xlnx,zynq-reset.h

diff --git a/arch/arm/boot/dts/zynq-7000.dtsi b/arch/arm/boot/dts/zynq-7000.dtsi
index b429e1d..1d4faa2 100644
--- a/arch/arm/boot/dts/zynq-7000.dtsi
+++ b/arch/arm/boot/dts/zynq-7000.dtsi
@@ -1,5 +1,6 @@
 /*
  *  Copyright (C) 2011 - 2014 Xilinx
+ *  Copyright (C) 2015 National Instruments Corp.
  *
  * This software is licensed under the terms of the GNU General Public
  * License version 2, as published by the Free Software Foundation, and
@@ -10,7 +11,8 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  */
-/include/ "skeleton.dtsi"
+#include "skeleton.dtsi"
+#include 
 
 / {
compatible = "xlnx,zynq-7000";
@@ -77,6 +79,8 @@
status = "disabled";
clocks = < 19>, < 36>;
clock-names = "can_clk", "pclk";
+   resets = < CAN0_RESET>, < CAN0_REF_RESET>;
+   reset-names = "reset", "ref_reset";
reg = <0xe0008000 0x1000>;
interrupts = <0 28 4>;
interrupt-parent = <>;
@@ -89,6 +93,8 @@
status = "disabled";
clocks = < 20>, < 37>;
clock-names = "can_clk", "pclk";
+   resets = < CAN1_RESET>, < CAN1_REF_RESET>;
+   reset-names = "reset", "ref_reset";
reg = <0xe0009000 0x1000>;
interrupts = <0 51 4>;
interrupt-parent = <>;
@@ -100,6 +106,8 @@
compatible = "xlnx,zynq-gpio-1.0";
#gpio-cells = <2>;
clocks = < 42>;
+   resets = < GPIO_RESET>;
+   reset-names = "reset";
gpio-controller;
interrupt-parent = <>;
interrupts = <0 20 4>;
@@ -110,6 +118,8 @@
compatible = "cdns,i2c-r1p10";
status = "disabled";
clocks = < 38>;
+   reset = < I2C0_RESET>;
+   reset-names = "reset";
interrupt-parent = <>;
interrupts = <0 25 4>;
reg = <0xe0004000 0x1000>;
@@ -121,6 +131,8 @@
compatible = "cdns,i2c-r1p10";
status = "disabled";
clocks = < 39>;
+   resets = < I2C1_RESET>;
+   reset-names = "reset";
interrupt-parent = <>;
interrupts = <0 48 4>;
reg = <0xe0005000 0x1000>;
@@ -148,6 +160,8 @@
mc: memory-controller@f8006000 {
compatible = "xlnx,zynq-ddrc-a05";
reg = <0xf8006000 0x1000>;
+   resets = < DDR_RESET>;
+   reset-names = "reset";
};
 
uart0: serial@e000 {
@@ -155,6 +169,8 @@
status = "disabled";
clocks = < 23>, < 40>;
clock-names = "uart_clk", "pclk";
+   resets = < UART0_RESET>, < UART0_REF_RESET>;
+   reset-names = "reset", "ref_reset";
reg = <0xE000 0x1000>;
interrupts = <0 27 4>;
};
@@ -164,6 +180,8 @@
status = "disabled";
clocks = < 24>, < 41>;
clock-names = "uart_clk", "pclk";
+   resets = < UART1_RESET>, < UART1_REF_RESET>;
+   reset-names = "reset", "ref_reset";
reg = <0xE0001000 0x1000>;
interrupts = <0 50 4>;
};
@@ -176,6 +194,8 @@
interrupts = <0 26 4>;
clocks = < 25>, < 34>;
clock-names = "ref_clk", "pclk";
+   resets = < SPI0_RESET>, < SPI0_REF_RESET>;
+   reset-names = "reset", "ref_reset";
#address-cells = <1>;
#size-cells = <0>;
};
@@ -188,6 +208,8 @@
interrupts = <0 49 4>;
clocks = 

[RFCv2 3/3] reset: reset-zynq: Adding support for Xilinx Zynq reset controller.

[Moritz Fischer]

This adds a reset controller driver to control the Xilinx Zynq
SoC's various resets.

Signed-off-by: Moritz Fischer 
---
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-zynq.c | 142 +
 2 files changed, 143 insertions(+)
 create mode 100644 drivers/reset/reset-zynq.c

diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 157d421..3fe50e7 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
+obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
diff --git a/drivers/reset/reset-zynq.c b/drivers/reset/reset-zynq.c
new file mode 100644
index 000..05e37f8
--- /dev/null
+++ b/drivers/reset/reset-zynq.c
@@ -0,0 +1,142 @@
+/*
+ * Copyright (c) 2015, National Instruments Corp.
+ *
+ * Xilinx Zynq Reset controller driver
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Offsets into SLCR regmap */
+#define SLCR_RST_CTRL_OFFSET   0x200 /* FPGA Software Reset Control */
+
+#define NBANKS 18
+
+struct zynq_reset_data {
+   struct regmap *slcr;
+   struct reset_controller_dev rcdev;
+};
+
+#define to_zynq_reset_data(p)  \
+   container_of((p), struct zynq_reset_data, rcdev)
+
+static int zynq_reset_assert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
+
+   int bank = id / BITS_PER_LONG;
+   int offset = id % BITS_PER_LONG;
+
+   regmap_update_bits(priv->slcr,
+  SLCR_RST_CTRL_OFFSET + (bank * 4),
+  BIT(offset),
+  BIT(offset));
+
+   return 0;
+}
+
+static int zynq_reset_deassert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
+
+   int bank = id / BITS_PER_LONG;
+   int offset = id % BITS_PER_LONG;
+
+   regmap_update_bits(priv->slcr,
+  SLCR_RST_CTRL_OFFSET + (bank * 4),
+  BIT(offset),
+  ~BIT(offset));
+
+   return 0;
+}
+
+static int zynq_reset_status(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct zynq_reset_data *priv = to_zynq_reset_data(rcdev);
+
+   int bank = id / BITS_PER_LONG;
+   int offset = id % BITS_PER_LONG;
+   u32 reg;
+
+   regmap_read(priv->slcr, SLCR_RST_CTRL_OFFSET + (bank * 4), );
+
+   return !(reg & BIT(offset));
+}
+
+static const struct reset_control_ops zynq_reset_ops = {
+   .assert = zynq_reset_assert,
+   .deassert   = zynq_reset_deassert,
+   .status = zynq_reset_status,
+};
+
+static int zynq_reset_probe(struct platform_device *pdev)
+{
+   struct zynq_reset_data *priv;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+   platform_set_drvdata(pdev, priv);
+
+   priv->slcr = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
+   "syscon");
+   if (IS_ERR(priv->slcr)) {
+   dev_err(>dev, "unable to get zynq-slcr regmap");
+   return PTR_ERR(priv->slcr);
+   }
+
+   priv->rcdev.owner = THIS_MODULE;
+   priv->rcdev.nr_resets = NBANKS * BITS_PER_LONG;
+   priv->rcdev.ops = _reset_ops;
+   priv->rcdev.of_node = pdev->dev.of_node;
+   reset_controller_register(>rcdev);
+
+   return 0;
+}
+
+static int zynq_reset_remove(struct platform_device *pdev)
+{
+   struct zynq_reset_data *priv = platform_get_drvdata(pdev);
+
+   reset_controller_unregister(>rcdev);
+
+   return 0;
+}
+
+static const struct of_device_id zynq_reset_dt_ids[] = {
+   { .compatible = "xlnx,zynq-reset", },
+   { /* sentinel */ },
+};
+
+static struct platform_driver zynq_reset_driver = {
+   .probe  = zynq_reset_probe,
+   .remove = zynq_reset_remove,
+   .driver = {
+   .name   = "zynq-pl-reset",
+   .of_match_table = zynq_reset_dt_ids,
+   },
+};
+module_platform_driver(zynq_reset_driver);
+
+MODULE_LICENSE("GPL v2");
+MODULE_AUTHOR("Moritz Fischer ");
+MODULE_DESCRIPTION("Zynq Reset Controller Driver");
-- 
2.4.3

--
To unsubscribe from this list: 

[RFCv2 0/3] Adding support for Zynq Reset Controller

[Moritz Fischer]

Hi all,

I went ahead and generalized it to support all the resets I could
find in the TRM. I don't know if all of them are sensible, so we 
need to carfully double check that. I also tried to add in the stuff
that was pointed out in v1.

If this looks good enough for a patch let me know.

Thanks for your feedback,

Moritz

Moritz Fischer (3):
  docs: dts: Added documentation for Xilinx Zynq Reset Controller
bindings.
  dts: zynq: Add devicetree entry for Xilinx Zynq reset controller.
  reset: reset-zynq: Adding support for Xilinx Zynq reset controller.

 .../devicetree/bindings/reset/zynq-reset-pl.txt|  13 ++
 arch/arm/boot/dts/zynq-7000.dtsi   |  43 ++-
 arch/arm/boot/dts/zynq-parallella.dts  |   2 +-
 arch/arm/boot/dts/zynq-zc702.dts   |   2 +-
 arch/arm/boot/dts/zynq-zc706.dts   |   2 +-
 arch/arm/boot/dts/zynq-zed.dts |   2 +-
 arch/arm/boot/dts/zynq-zybo.dts|   2 +-
 drivers/reset/Makefile |   1 +
 drivers/reset/reset-zynq.c | 142 +
 include/dt-bindings/reset/xlnx,zynq-reset.h|  94 ++
 10 files changed, 297 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
 create mode 100644 drivers/reset/reset-zynq.c
 create mode 100644 include/dt-bindings/reset/xlnx,zynq-reset.h

-- 
2.4.3

--
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/

[RFCv2 1/3] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.

[Moritz Fischer]

Signed-off-by: Moritz Fischer 
---
 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt | 13 +
 1 file changed, 13 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/reset/zynq-reset-pl.txt

diff --git a/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt 
b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
new file mode 100644
index 000..ac4499e
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/zynq-reset-pl.txt
@@ -0,0 +1,13 @@
+Xilinx Zynq PL Reset Manager
+
+Required properties:
+- compatible: "xlnx,zynq-reset-pl"
+- syscon <>;
+- #reset-cells: 1
+
+Example:
+   rstc: rstc@240 {
+   #reset-cells = <1>;
+   compatible = "xlnx,zynq-reset-pl";
+   syscon = <>;
+   };
-- 
2.4.3

--
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 V5 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.

[vikasm]

Hi Graham,

On 07/24/2015 10:17 AM, Graham Moore wrote:
> Signed-off-by: Graham Moore 
> ---
> V2: use NULL instead of modalias in spi_nor_scan call
> V3: Use existing property is-decoded-cs instead of creating duplicate.
> V4: Support Micron quad mode by snooping command stream for EVCR command
> and subsequently configuring Cadence controller for quad mode.
> V5: Clean up sparse and smatch complaints.  Remove snooping of Micron
> quad mode.  Add comment on XIP mode bit and dummy clock cycles.  Set
> up SRAM partition at 1:1 during init.
> ---
>  arch/arm/boot/dts/socfpga.dtsi   |1 +
>  arch/arm/boot/dts/socfpga_cyclone5_socdk.dts |1 -
>  drivers/mtd/spi-nor/Kconfig  |6 +
>  drivers/mtd/spi-nor/Makefile |1 +
>  drivers/mtd/spi-nor/cadence-quadspi.c| 1261 
> ++
>  5 files changed, 1269 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/mtd/spi-nor/cadence-quadspi.c
>
> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
> index c71a705..e9ecdce 100644
> --- a/arch/arm/boot/dts/socfpga.dtsi
> +++ b/arch/arm/boot/dts/socfpga.dtsi
> @@ -695,6 +695,7 @@
> is-decoded-cs = <1>;
> fifo-depth = <128>;
> status = "disabled";
> +   m25p,fast-read;

This patch is not applicable to l2-mtd master or linus master repo, might need 
to rebase it.
   
> };
>
> /* Local timer */
> diff --git a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts 
> b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> index 9886728..1792c43 100644
> --- a/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> +++ b/arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
> @@ -98,7 +98,6 @@
> compatible = "n25q00", "n25q512a", "n25q512ax3";
> reg = <0>;
> spi-max-frequency = <1>;
> -   m25p,fast-read;
>
> cdns,page-size = <256>;
> cdns,block-size = <16>;
> diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
> index 64a4f0e..9485481 100644
> --- a/drivers/mtd/spi-nor/Kconfig
> +++ b/drivers/mtd/spi-nor/Kconfig
> @@ -28,4 +28,10 @@ config SPI_FSL_QUADSPI
>   This enables support for the Quad SPI controller in master mode.
>   We only connect the NOR to this controller now.
>
> +config SPI_CADENCE_QUADSPI
> +   tristate "Cadence Quad SPI controller"
> +   depends on ARCH_SOCFPGA
> +   help
> + This enables support for the Cadence Quad SPI controller and NOR 
> flash.
> +
>  endif # MTD_SPI_NOR
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 6a7ce14..372628c 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
> +obj-$(CONFIG_SPI_CADENCE_QUADSPI)  += cadence-quadspi.o
>  obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
> diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
> b/drivers/mtd/spi-nor/cadence-quadspi.c
> new file mode 100644
> index 000..4881db5
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/cadence-quadspi.c
> @@ -0,0 +1,1261 @@
> +/*
> + * Driver for Cadence QSPI Controller
> + *
> + * Copyright Altera Corporation (C) 2012-2014. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define CQSPI_NAME "cadence-qspi"

replace space with tabs.

> +#define CQSPI_MAX_CHIPSELECT   16

replace space with tabs.

> +
> +struct cqspi_flash_pdata {
> +   struct mtd_info mtd;

replace space with tabs at all relevant code locations in the file, most of the 
code is using spaces instead of tabs.

> +   struct spi_nor nor;
> +   u32 clk_rate;
> +   unsigned int read_delay;
> +   unsigned int tshsl_ns;
> +   unsigned int tsd2d_ns;
> +   unsigned int tchsh_ns;
> +   unsigned int tslch_ns;
> +};
> +
> +struct cqspi_st {
> +   struct platform_device *pdev;
> +
> +   struct clk *clk;
> +   unsigned int sclk;
> +
> +   void __iomem 

Re: X-Gene: Unhandled fault: synchronous external abort in pci_generic_config_read32

[Duc Dang]

Hi Bjorn,

On Fri, Jul 24, 2015 at 3:42 PM, Bjorn Helgaas  wrote:
>
> I regularly see faults like this on an APM X-Gene:
>
>   U-Boot 2013.04-mustang_sw_1.14.14 (Dec 16 2014 - 15:59:33)
>   CPU0: APM ARM 64-bit Potenza Rev B0 2400MHz PCP 2400MHz
>32 KB ICACHE, 32 KB DCACHE
>SOC 2000MHz IOBAXI 400MHz AXI 250MHz AHB 200MHz GFC 125MHz
>   ...
>   Unhandled fault: synchronous external abort (0x9610) at 
> 0xff8000110034
>   Internal error: : 9610 [#1] SMP
>   Modules linked in:
>   CPU: 0 PID: 3723 Comm: ... 4.1.0-smp-DEV #3
>   Hardware name: APM X-Gene Mustang board (DT)
>   task: ffc7dc1a4140 ti: ffc7dc118000 task.ti: ffc7dc118000
>   PC is at pci_generic_config_read32+0x4c/0xb8
>   LR is at pci_generic_config_read32+0x40/0xb8
>   pc : [] lr : [] pstate: 61c5
>   ...
>   Call trace:
>   [] pci_generic_config_read32+0x4c/0xb8
>   [] pci_user_read_config_byte+0x60/0xc4
>   [] pci_read_config+0x15c/0x238
>   [] sysfs_kf_bin_read+0x68/0xa0
>   [] kernfs_fop_read+0x9c/0x1ac
>   [] __vfs_read+0x44/0x128
>   [] vfs_read+0x84/0x144
>   [] SyS_read+0x50/0xb0

The log shows kernel gets an exception when trying to access Mellanox
card configuration space. This is usually due to suboptimal PCIe
SerDes parameters are using in your board, which will cause bad link
quality.
The PCIe SerDes programming is done in U-Boot, so I suggest you do a
U-Boot upgrade to our latest X-Gene U-Boot release.

In order to access latest X-Gene U-Boot release, please use APM
official support channel:
https://myapm.apm.com

Please register an account at myapm.apm.com if you don't have one
using following link:
https://myapm.apm.com/user/register

>
>   # lspci
>   00:00.0 PCI bridge: Applied Micro Circuits Corp. Device e004 (rev 04)
>   01:00.0 Ethernet controller: Mellanox Technologies MT27520 Family
>
> I first saw this on an ancient kernel and thought it was likely specific to
> my environment, but I'm now using an almost unmodified v4.1 kernel and
> still seeing it.  Does anybody else see this?  The box does have a PCI card
> installed, but I haven't yet worked out what device's config space we're
> trying to read.
>
> Is there anything I can do to debug this?  I'm not an arm64 guy, but my
> impression is that this is a page fault, and the address seems to be in the
> "cfg" area ioremapped by xgene_pcie_map_reg(), so I'm not sure this is
> really a PCI issue -- maybe that page mapping got trashed by somebody else?
>
> Bjorn


-- 
Regards,
Duc Dang.
--
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/

[PATCH] staging/xgifb: fix dumpVGAReg compile error if DEBUG is set

[Peter Huewe]

If DEBUG is set dumpVGAReg is called and tries to access
XGISR which is defined as (xgifb_info->dev_info.P3c4)
which is not known within this function.

-> add as parameter to dumpVGAReg so xgifb_info becomes known

Signed-off-by: Peter Huewe 
---
 drivers/staging/xgifb/XGI_main_26.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/xgifb/XGI_main_26.c 
b/drivers/staging/xgifb/XGI_main_26.c
index 943d463cf193..f3738400acd0 100644
--- a/drivers/staging/xgifb/XGI_main_26.c
+++ b/drivers/staging/xgifb/XGI_main_26.c
@@ -29,7 +29,7 @@ static unsigned int refresh_rate;
 /*  Macro definitions  */
 
 #ifdef DEBUG
-static void dumpVGAReg(void)
+static void dumpVGAReg(struct xgifb_video_info *xgifb_info)
 {
u8 i, reg;
 
@@ -48,7 +48,7 @@ static void dumpVGAReg(void)
}
 }
 #else
-static inline void dumpVGAReg(void)
+static inline void dumpVGAReg(struct xgifb_video_info *xgifb_info)
 {
 }
 #endif
@@ -1073,7 +1073,7 @@ static int XGIfb_do_set_var(struct fb_var_screeninfo 
*var, int isactive,
}
XGIfb_bpp_to_var(xgifb_info, var); /*update ARGB info*/
 
-   dumpVGAReg();
+   dumpVGAReg(xgifb_info);
return 0;
 }
 
@@ -2019,7 +2019,7 @@ static int xgifb_probe(struct pci_dev *pdev,
goto error_mtrr;
}
 
-   dumpVGAReg();
+   dumpVGAReg(xgifb_info);
 
return 0;
 
-- 
2.3.6

--
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: Dealing with the NMI mess

[Linus Torvalds]

On Fri, Jul 24, 2015 at 1:51 PM, Peter Zijlstra  wrote:
>
> do_debug()
>   send_sigtrap()
> force_sig_info()
>   spin_lock_irqsave()
>
> Now, I don't pretend to understand the condition before send_sigtrap(),
> so it _might_ be ok, but it sure as heck could do with a comment.

Ugh. As Andy said, I think that's ok, because it's actually the
single-step case, and won't trigger for kernel mode. So we should be
ok. Although the code I agree is not good.

I'd personally be more worried about the usual crazy "notify_die()"
crap. I absoluely detest those notifier chain things. They are hooks
for random crap that shouldn't be hooked into, but whatever. It's not
a problem in practice, it's just a sign of a certain kind of diseased
mind.

On the whole I think we're ok. I'd love to get rid of things, and yes,
I think we should probably explicitly handle the in-kernel case first
and just return without doing anything, just to make the code more
obviously safe. But it doesn't look like a fundamental problem spot.

  Linus
--
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/

[PATCH V8 4/5] arm64: apei: implement arch_apei_get_mem_attributes()

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
memory types to MAIR attribute encodings for arm64.

If the physical address has memory attributes defined by EFI
memmap as EFI_MEMORY_[UC|WC|WT], return approprate page protection
type. Otherwise, return PAGE_KERNEL.

Change-Id: I7f836cae0fb3e74a34e27ac695c2637ffc4cddc6
Acked-by: Hanjun Guo 
Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 arch/arm64/include/asm/acpi.h | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index 1ff9e6eb5e02..04720f819f0a 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -19,6 +19,11 @@
 #include 
 #include 
 
+#ifdef CONFIG_ACPI_APEI
+#include 
+#include 
+#endif
+
 /* Macros for consistency checks of the GICC subtable of MADT */
 #define ACPI_MADT_GICC_LENGTH  \
(acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
@@ -91,4 +95,26 @@ static inline const char *acpi_get_enable_method(int cpu)
 {
return acpi_psci_present() ? "psci" : NULL;
 }
+
+#ifdef CONFIG_ACPI_APEI
+/*
+ * According to "Table 8 Map: EFI memory types to AArch64 memory types"
+ * of UEFI 2.5 section 2.3.6.1, each EFI memory type is mapped to
+ * corresponding MAIR attribute encoding.
+ */
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+   u64 attr;
+
+   attr = efi_mem_attributes(addr);
+   if (attr & EFI_MEMORY_UC)
+   return PROT_DEVICE_nGnRnE;
+   if (attr & EFI_MEMORY_WC)
+   return PROT_NORMAL_NC;
+   if (attr & EFI_MEMORY_WT)
+   return PROT_NORMAL_WT;
+   return PAGE_KERNEL;
+}
+#endif
+
 #endif /*_ASM_ACPI_H*/
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/

[PATCH V8 2/5] x86: acpi: implement arch_apei_get_mem_attributes()

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

... to allow arch specific implementation of getting page
protection type associated with a physical address.

On x86, we currently have no way to lookup the EFI memory map
attributes for a region in a consistent way because the
memmap is discarded after efi_free_boot_services(). So if
you call efi_mem_attributes() during boot and at runtime,
you could theoretically see different attributes.

Since we are yet to see any x86 platforms that require
anything other than PAGE_KERNEL (some arm64 platforms
require the equivalent of PAGE_KERNEL_NOCACHE), return that
until we know differently.

Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 arch/x86/kernel/acpi/apei.c | 19 +++
 include/acpi/apei.h |  1 +
 2 files changed, 20 insertions(+)

diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
index c280df6b2aa2..675bd46c4e17 100644
--- a/arch/x86/kernel/acpi/apei.c
+++ b/arch/x86/kernel/acpi/apei.c
@@ -60,3 +60,22 @@ void arch_apei_flush_tlb_one(unsigned long addr)
 {
__flush_tlb_one(addr);
 }
+
+static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
+{
+
+   /*
+* We currently have no way to lookup the EFI memory map
+* attributes for a region in a consistent way because the
+* memmap is discarded after efi_free_boot_services(). So if
+* you call efi_mem_attributes() during boot and at runtime,
+* you could theoretically see different attributes.
+*
+* Since we are yet to see any x86 platforms that require
+* anything other than PAGE_KERNEL (some arm64 platforms
+* require the equivalent of PAGE_KERNEL_NOCACHE), return that
+* until we know differently.
+*/
+
+   return PAGE_KERNEL;
+}
diff --git a/include/acpi/apei.h b/include/acpi/apei.h
index 284801ac7042..64a12ce9880b 100644
--- a/include/acpi/apei.h
+++ b/include/acpi/apei.h
@@ -46,6 +46,7 @@ int erst_clear(u64 record_id);
 int arch_apei_enable_cmcff(struct acpi_hest_header *hest_hdr, void *data);
 void arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err);
 void arch_apei_flush_tlb_one(unsigned long addr);
+pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
 
 #endif
 #endif
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/

[PATCH V8 5/5] acpi, apei: use appropriate pgprot_t to map GHES memory

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

With ACPI APEI firmware first handling, generic hardware error
record is updated by firmware in GHES memory region. On an arm64
platform, firmware updates GHES memory region with uncached
access attribute, and then Linux reads stale data from cache.

GHES memory region should be mapped with page protection type
according to what is returned from arch_apei_get_mem_attribute(),
instead of always with PAGE_KERNEL (eg. cached attribute).

Change-Id: Ie63440381e0f68100d4387e268058a2e2f9d63c6
Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 drivers/acpi/apei/ghes.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index b979b5dbe5bc..98609b404dae 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -173,8 +173,10 @@ static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
unsigned long vaddr;
 
vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
-   ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
-  pfn << PAGE_SHIFT, PAGE_KERNEL);
+   ioremap_page_range(vaddr,
+  vaddr + PAGE_SIZE,
+  pfn << PAGE_SHIFT,
+  arch_apei_get_mem_attribute(pfn << PAGE_SHIFT));
 
return (void __iomem *)vaddr;
 }
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/

[PATCH V8 3/5] arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

UEFI spec 2.5 section 2.3.6.1 defines that EFI_MEMORY_[UC|WC|WT|WB] are
possible EFI memory types for AArch64. Each of those EFI memory types
is mapped to a corresponding AArch64 memory type. So we need to define
PROT_DEVICE_nGnRnE and PROT_NORMWL_WT additionaly.

MT_NORMAL_WT is defined, and its encoding is added to MAIR_EL1 when
initializing cpu.

Change-Id: I20ac71ddf74c17e41769ecbb5f8c60eeefbb398a
Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 arch/arm64/include/asm/memory.h  | 1 +
 arch/arm64/include/asm/pgtable.h | 2 ++
 arch/arm64/mm/proc.S | 4 +++-
 3 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index f800d45ea226..4112b3d7468e 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -100,6 +100,7 @@
 #define MT_DEVICE_GRE  2
 #define MT_NORMAL_NC   3
 #define MT_NORMAL  4
+#define MT_NORMAL_WT   5
 
 /*
  * Memory types for Stage-2 translation
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 800ec0e87ed9..5c108ad13558 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -61,8 +61,10 @@ extern void __pgd_error(const char *file, int line, unsigned 
long val);
 #define PROT_SECT_DEFAULT  (PMD_TYPE_SECT | PMD_SECT_AF)
 #endif
 
+#define PROT_DEVICE_nGnRnE (PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_ATTRINDX(MT_DEVICE_nGnRnE))
 #define PROT_DEVICE_nGnRE  (PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_ATTRINDX(MT_DEVICE_nGnRE))
 #define PROT_NORMAL_NC (PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_ATTRINDX(MT_NORMAL_NC))
+#define PROT_NORMAL_WT (PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_ATTRINDX(MT_NORMAL_WT))
 #define PROT_NORMAL(PROT_DEFAULT | PTE_PXN | PTE_UXN | 
PTE_ATTRINDX(MT_NORMAL))
 
 #define PROT_SECT_DEVICE_nGnRE (PROT_SECT_DEFAULT | PMD_SECT_PXN | 
PMD_SECT_UXN | PMD_ATTRINDX(MT_DEVICE_nGnRE))
diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S
index 838266f5b056..dfcc05804665 100644
--- a/arch/arm64/mm/proc.S
+++ b/arch/arm64/mm/proc.S
@@ -303,12 +303,14 @@ ENTRY(__cpu_setup)
 *   DEVICE_GRE 010 1100
 *   NORMAL_NC  011 01000100
 *   NORMAL 100 
+*   NORMAL_WT  101 10111011
 */
ldr x5, =MAIR(0x00, MT_DEVICE_nGnRnE) | \
 MAIR(0x04, MT_DEVICE_nGnRE) | \
 MAIR(0x0c, MT_DEVICE_GRE) | \
 MAIR(0x44, MT_NORMAL_NC) | \
-MAIR(0xff, MT_NORMAL)
+MAIR(0xff, MT_NORMAL) | \
+MAIR(0xbb, MT_NORMAL_WT)
msr mair_el1, x5
/*
 * Prepare SCTLR
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/

[PATCH V8 1/5] efi: x86: rearrange efi_mem_attributes()

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

x86 and ia64 implement efi_mem_attributes() differently. This
function needs to be available for other arch (such as arm64)
as well, such as for the purpose of ACPI/APEI.

ia64 efi does not setup memmap variable and does not set
EFI_MEMMAP flag, so it needs to have its unique implementation
of efi_mem_attributes().

Move efi_mem_attributes() implementation from x86 to efi, and
declare it with __weak. It is recommended that other archs
should not override the default implementation.

Change-Id: I73e5fd173dd68ae6f0fe6ef53b365b274627bec1
Reviewed-by: Matt Fleming 
Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 arch/x86/platform/efi/efi.c | 18 --
 drivers/firmware/efi/efi.c  | 31 +++
 2 files changed, 31 insertions(+), 18 deletions(-)

diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index dbc8627a5cdf..88b3ebaeb72f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -917,24 +917,6 @@ u32 efi_mem_type(unsigned long phys_addr)
return 0;
 }
 
-u64 efi_mem_attributes(unsigned long phys_addr)
-{
-   efi_memory_desc_t *md;
-   void *p;
-
-   if (!efi_enabled(EFI_MEMMAP))
-   return 0;
-
-   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
-   md = p;
-   if ((md->phys_addr <= phys_addr) &&
-   (phys_addr < (md->phys_addr +
- (md->num_pages << EFI_PAGE_SHIFT
-   return md->attribute;
-   }
-   return 0;
-}
-
 static int __init arch_parse_efi_cmdline(char *str)
 {
if (parse_option_str(str, "old_map"))
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 3061bb8629dc..bf4190a4f3f5 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -517,3 +517,34 @@ char * __init efi_md_typeattr_format(char *buf, size_t 
size,
 attr & EFI_MEMORY_UC  ? "UC"  : "");
return buf;
 }
+
+/*
+ * efi_mem_attributes - lookup memmap attributes for physical address
+ * @phys_addr: the physical address to lookup
+ *
+ * Search in the EFI memory map for the region covering
+ * @phys_addr. Returns the EFI memory attributes if the region
+ * was found in the memory map, 0 otherwise.
+ *
+ * Despite being marked __weak, most architectures should *not*
+ * override this function. It is __weak solely for the benefit
+ * of ia64 which has a funky EFI memory map that doesn't work
+ * the same way as other architectures.
+ */
+u64 __weak efi_mem_attributes(unsigned long phys_addr)
+{
+   efi_memory_desc_t *md;
+   void *p;
+
+   if (!efi_enabled(EFI_MEMMAP))
+   return 0;
+
+   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+   md = p;
+   if ((md->phys_addr <= phys_addr) &&
+   (phys_addr < (md->phys_addr +
+   (md->num_pages << EFI_PAGE_SHIFT
+   return md->attribute;
+   }
+   return 0;
+}
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
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/

[PATCH V8 0/5] map GHES memory region according to EFI memory map

[Jonathan (Zhixiong) Zhang]

From: "Jonathan (Zhixiong) Zhang" 

On a platform with APEI (ACPI Platform Error Interface) enabled, firmware
updates a memory region with hardware error record using nocache
attribute. When OS reads the region, since it maps the region with
cacahed attribute even though EFI memory map defines this region as
uncached, OS gets stale data and errorneously reports there is no new
HW error.

When ghes driver maps the memory region, it uses the cache attribute
according to EFI memory map, if EFI memory map feature is enabled
at runtime.

Since both arch/x86 and arch/ia64 implemented architecture agnostic EFI
memory map attribue lookup function efi_memattributes(), the code is
moved from arch/x86 into EFI subsystem and is declared as __weak; archs
other than ia64 should not override the default implementation.

V8:
1. For x86, always return PAGE_KERNEL for arch_apei_get_mem_attribute().
   The rational is explained in comment.
2. Rebased to arm64-upstream-14201 of arm64/master,
   next-20150724 of linux-next/master.
V7:
1. Added PROT_DEVICE_nGnRnE and PROT_NORMAL_WT to support all
   possible UEFI memory types for arm64.
V6:
1. Implemented arch_apei_get_mem_attributes() for arm64 as inline
   function.
2. Rebased to efi-next-14364 of efi/next, pm+acpi-4.2-rc3 of
   linux-pm/master, arm64-upstream-13521 of arm64/master,
   next-20150720 of linux-next/master.
V5:
1. Rebased to next-20150713 of linux-next/master, efi-next-14359 of
   efi/next, pm+acpi-4.2-rc2 of linux-pm/master,
   arm64-fixes-1215 of arm64/master.
2. Added comment for efi_mem_attributes(), explained why it is marked
   as __weak at the function definition site.
V4:
1. Introduced arch_apei_get_mem_attributes() to allow arch specific
   implementation of getting pgprot_t appropriate for a physical
   address.
2. Implemented arch_apei_get_mem_attributes() for x86 and for arm64.
V3:
1. Rebased to v4.1-rc7.
2. Moved efi_mem_attributes() from arch/x86 to drivers/firmware/efi
   and declared it as __weak.
3. Introduced ARCH_APEI_PAGE_KERNEL_UC to allow arch specific page
   protection type for UC.
4. Removed efi_ioremap(). It can not be used for GHES memory region
   mapping purpose since ioremap can not be used in atomic context.
V2:
1. Rebased to v4.1-rc5.
2. Split removal of efi_mem_attributes() and creation of efi_ioremap()
   into two patches.

Jonathan (Zhixiong) Zhang (5):
  efi: x86: rearrange efi_mem_attributes()
  x86: acpi: implement arch_apei_get_mem_attributes()
  arm64: mm: add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT
  arm64: apei: implement arch_apei_get_mem_attributes()
  acpi, apei: use appropriate pgprot_t to map GHES memory

 arch/arm64/include/asm/acpi.h| 26 ++
 arch/arm64/include/asm/memory.h  |  1 +
 arch/arm64/include/asm/pgtable.h |  2 ++
 arch/arm64/mm/proc.S |  4 +++-
 arch/x86/kernel/acpi/apei.c  | 19 +++
 arch/x86/platform/efi/efi.c  | 18 --
 drivers/acpi/apei/ghes.c |  6 --
 drivers/firmware/efi/efi.c   | 31 +++
 include/acpi/apei.h  |  1 +
 9 files changed, 87 insertions(+), 21 deletions(-)

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

--
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 1/1] toshiba_acpi: Add set_fan_status function

[Azael Avalos]

Hi Darren,

2015-07-24 16:45 GMT-06:00 Darren Hart :
> On Wed, Jul 22, 2015 at 07:37:48PM -0600, Azael Avalos wrote:
>> This patch adds a new function named "set_fan_status" to complement
>> its get* counterpart, as well as to avoid code duplication between
>> "fan_proc_write" and "fan_store".
>
> It also appears to change the error codes returned via sysfs?
>
> Also adds some pr_ statements.
>
>>
>> Signed-off-by: Azael Avalos 
>> ---
>>  drivers/platform/x86/toshiba_acpi.c | 55 
>> -
>>  1 file changed, 36 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/platform/x86/toshiba_acpi.c 
>> b/drivers/platform/x86/toshiba_acpi.c
>> index 6013a11..08fc867 100644
>> --- a/drivers/platform/x86/toshiba_acpi.c
>> +++ b/drivers/platform/x86/toshiba_acpi.c
>> @@ -1422,12 +1422,33 @@ static const struct file_operations video_proc_fops 
>> = {
>>   .write  = video_proc_write,
>>  };
>>
>> +/* Fan status */
>>  static int get_fan_status(struct toshiba_acpi_dev *dev, u32 *status)
>>  {
>> - u32 hci_result;
>> + u32 result = hci_read(dev, HCI_FAN, status);
>>
>> - hci_result = hci_read(dev, HCI_FAN, status);
>> - return hci_result == TOS_SUCCESS ? 0 : -EIO;
>> + if (result == TOS_FAILURE)
>> + pr_err("ACPI call to get Fan status failed\n");
>
> s/Fan/fan/
>
> Below too.
>
>> + else if (result == TOS_NOT_SUPPORTED)
>> + return -ENODEV;
>
> This condition would have returned -EIO previously correct?

Yes, we were returning -EIO for all error codes, with this patch we are at
least informing userspace that such feature is not supported with
-ENODEV instead of just returnning -EIO all the time.

With the pr_ message we are informing that an ACPI error happened,
which might (or might not) be the drivers fault, and this will be
on par with the rest of the HCI/SCI functions of the driver.

>
> I agree this new one is the right change, but it does pose a risk to 
> userspace.
> There is a slim chance we will have to revert if someone complains and can't
> work around it, so we need to be clear about this in the commit message at the
> very least.

Ok, I spotted a few "issues" on the latter patches, I'll wait for your comments
and send a v2 afterwards with an expanded commit message.

> --
> Darren Hart
> Intel Open Source Technology Center


Cheers
Azael


-- 
-- El mundo apesta y vosotros apestais tambien --
--
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/

[PATCH] staging: unisys: avoid format string parsing

[Kees Cook]

This makes sure the kthread name can't be parsed as a format string.

Signed-off-by: Kees Cook 
---
 drivers/staging/unisys/visornic/visornic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index 710074437737..9af4ed8d6f10 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -296,7 +296,7 @@ static int visor_thread_start(struct visor_thread_info 
*thrinfo,
 {
/* used to stop the thread */
init_completion(>has_stopped);
-   thrinfo->task = kthread_run(threadfn, thrcontext, name);
+   thrinfo->task = kthread_run(threadfn, thrcontext, "%s", name);
if (IS_ERR(thrinfo->task)) {
thrinfo->id = 0;
return -EINVAL;
-- 
1.9.1


-- 
Kees Cook
Chrome OS Security
--
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/

[PATCH] ntb: avoid format string in dev_set_name

[Kees Cook]

Avoid any chance of format string expansion when calling dev_set_name.

Signed-off-by: Kees Cook 
---
 drivers/ntb/ntb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ntb/ntb.c b/drivers/ntb/ntb.c
index 23435f2a5486..2e2530743831 100644
--- a/drivers/ntb/ntb.c
+++ b/drivers/ntb/ntb.c
@@ -114,7 +114,7 @@ int ntb_register_device(struct ntb_dev *ntb)
ntb->dev.bus = _bus;
ntb->dev.parent = >pdev->dev;
ntb->dev.release = ntb_dev_release;
-   dev_set_name(>dev, pci_name(ntb->pdev));
+   dev_set_name(>dev, "%s", pci_name(ntb->pdev));
 
ntb->ctx = NULL;
ntb->ctx_ops = NULL;
-- 
1.9.1


-- 
Kees Cook
Chrome OS Security
--
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/

[PATCH] iommu: avoid format string leaks into iommu_device_create

[Kees Cook]

This makes sure it won't be possible to accidentally leak format
strings into iommu device names. Current name allocations are safe,
but this makes the "%s" explicit.

Signed-off-by: Kees Cook 
---
 drivers/iommu/dmar.c| 2 +-
 drivers/iommu/intel-iommu.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index c9db04d4ef39..8757f8dfc4e5 100644
--- a/drivers/iommu/dmar.c
+++ b/drivers/iommu/dmar.c
@@ -1068,7 +1068,7 @@ static int alloc_iommu(struct dmar_drhd_unit *drhd)
if (intel_iommu_enabled)
iommu->iommu_dev = iommu_device_create(NULL, iommu,
   intel_iommu_groups,
-  iommu->name);
+  "%s", iommu->name);
 
return 0;
 
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 0649b94f5958..0be23c589d3b 100644
--- a/drivers/iommu/intel-iommu.c
+++ b/drivers/iommu/intel-iommu.c
@@ -4533,7 +4533,7 @@ int __init intel_iommu_init(void)
for_each_active_iommu(iommu, drhd)
iommu->iommu_dev = iommu_device_create(NULL, iommu,
   intel_iommu_groups,
-  iommu->name);
+  "%s", iommu->name);
 
bus_set_iommu(_bus_type, _iommu_ops);
bus_register_notifier(_bus_type, _nb);
-- 
1.9.1


-- 
Kees Cook
Chrome OS Security
--
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 2/3] Docs: dt: Add PCI MSI map bindings

[Chalamarla, Tirumalesh]

looks good. possible to describe the chip we have.
> On Jul 23, 2015, at 9:52 AM, Mark Rutland  wrote:
> 
> Currently msi-parent is used by a few bindings to describe the
> relationship between a PCI root complex and a single MSI controller, but
> this property does not have a generic binding document.
> 
> Additionally, msi-parent is insufficient to describe more complex
> relationships between MSI controllers and devices under a root complex,
> where devices may be able to target multiple MSI controllers, or where
> MSI controllers use (non-probeable) sideband information to distinguish
> devices.
> 
> This patch adds a generic binding for mapping PCI devices to MSI
> controllers. This document covers msi-parent, and a new msi-map property
> (specific to PCI*) which may be used to map devices (identified by their
> Requester ID) to sideband data for each MSI controller that they may
> target.
> 
> Signed-off-by: Mark Rutland 
> ---
> Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
> 1 file changed, 220 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt 
> b/Documentation/devicetree/bindings/pci/pci-msi.txt
> new file mode 100644
> index 000..9b3cc81
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
> @@ -0,0 +1,220 @@
> +This document describes the generic device tree binding for describing the
> +relationship between PCI devices and MSI controllers.
> +
> +Each PCI device under a root complex is uniquely identified by its Requester 
> ID
> +(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
> +Function number.
> +
> +For the purpose of this document, when treated as a numeric value, a RID is
> +formatted such that:
> +
> +* Bits [15:8] are the Bus number.
> +* Bits [7:3] are the Device number.
> +* Bits [2:0] are the Function number.
> +* Any other bits required for padding must be zero.
> +
> +MSIs may be distinguished in part through the use of sideband data 
> accompanying
> +writes. In the case of PCI devices, this sideband data may be derived from 
> the
> +Requester ID. A mechanism is required to associate a device with both the MSI
> +controllers it can address, and the sideband data that will be associated 
> with
> +its writes to those controllers.
> +
> +For generic MSI bindings, see
> +Documentation/devicetree/bindings/interrupt-controller/msi.txt.
> +
> +
> +PCI root complex
> +
> +
> +Optional properties
> +---
> +
> +- msi-map: Maps a Requester ID to an MSI controller and associated
> +  msi-specifier data. The property is an arbitrary number of tuples of
> +  (rid-base,msi-controller,msi-base,length), where:
> +
> +  * rid-base is a single cell describing the first RID matched by the entry.
> +
> +  * msi-controller is a single phandle to an MSI controller
> +
> +  * msi-base is an msi-specifier describing the msi-specifier produced for 
> the
> +first RID matched by the entry.
> +
> +  * length is a single cell describing how many consecutive RIDs are matched
> +following the rid-base.
> +
> +  Any RID r in the interval [rid-base, rid-base + length) is associated with
> +  the listed msi-controller, with the msi-specifier (r - rid-base + 
> msi-base).
> +
> +- msi-map-mask: A mask to be applied to each Requester ID prior to being 
> mapped
> +  to an msi-specifier per the msi-map property.
> +
> +- msi-parent: Describes the MSI parent of the root complex itself. Where
> +  the root complex and MSI controller do not pass sideband data with MSI
> +  writes, this property may be used to describe the MSI controller(s)
> +  used by PCI devices under the root complex, if defined as such in the
> +  binding for the root complex.
> +
> +
> +Example (1)
> +===
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + msi: msi-controller@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-controller";
> + msi-controller;
> + #msi-cells = <1>;
> + };
> +
> + pci: pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + /*
> +  * The sideband data provided to the MSI controller is
> +  * the RID, identity-mapped.
> +  */
> + msi-map = <0x0 _a 0x0 0x1>,
> + };
> +};
> +
> +
> +Example (2)
> +===
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + msi: msi-controller@a {
> + reg = <0xa 0x1>;
> + compatible = "vendor,some-controller";
> + msi-controller;
> + #msi-cells = <1>;
> + };
> +
> + pci: pci@f {
> + reg = <0xf 0x1>;
> + compatible = "vendor,pcie-root-complex";
> + device_type = "pci";
> +
> + /*
> 

Re: [Xen-devel] [PATCHv2 10/10] xen/balloon: pre-allocate p2m entries for ballooned pages

[Julien Grall]

Hi David,

On 24/07/2015 12:47, David Vrabel wrote:

Pages returned by alloc_xenballooned_pages() will be used for grant
mapping which will call set_phys_to_machine() (in PV guests).

Ballooned pages are set as INVALID_P2M_ENTRY in the p2m and thus may
be using the (shared) missing tables and a subsequent
set_phys_to_machine() will need to allocate new tables.

Since the grant mapping may be done from a context that cannot sleep,
the p2m entries must already be allocated.

Signed-off-by: David Vrabel 
---
  drivers/xen/balloon.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index fd6970f3..8932d10 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -541,6 +541,7 @@ int alloc_xenballooned_pages(int nr_pages, struct page 
**pages)
  {
int pgno = 0;
struct page *page;
+   int ret = -ENOMEM;

mutex_lock(_mutex);

@@ -550,6 +551,11 @@ int alloc_xenballooned_pages(int nr_pages, struct page 
**pages)
page = balloon_retrieve(true);
if (page) {
pages[pgno++] = page;
+#ifdef CONFIG_XEN_HAVE_PVMMU
+   ret = xen_alloc_p2m_entry(page_to_pfn(page));


Don't you want to call this function only when the guest is not using 
auto-translated physmap?



+   if (ret < 0)
+   goto out_undo;
+#endif
} else {
enum bp_state st;

@@ -576,7 +582,7 @@ int alloc_xenballooned_pages(int nr_pages, struct page 
**pages)
   out_undo:
mutex_unlock(_mutex);
free_xenballooned_pages(pgno, pages);
-   return -ENOMEM;
+   return ret;
  }
  EXPORT_SYMBOL(alloc_xenballooned_pages);




Regards,

--
Julien Grall
--
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/

[PATCH] clk_register_clkdev: handle callers needing format string

[Kees Cook]

Many callers either use NULL or const strings for the third argument of
clk_register_clkdev. For those that do not, this is a risk for format
strings being accidentally processed (for example in device names). This
adds the missing "%s" arguments to make sure format strings will not leak
into the clkdev.

Signed-off-by: Kees Cook 
---
 arch/arm/mach-vexpress/spc.c  | 2 +-
 arch/powerpc/platforms/512x/clock-commonclk.c | 4 ++--
 drivers/acpi/acpi_apd.c   | 3 ++-
 drivers/acpi/acpi_lpss.c  | 2 +-
 drivers/clk/clk-mb86s7x.c | 2 +-
 drivers/clk/clk-moxart.c  | 4 ++--
 drivers/clk/samsung/clk-pll.c | 2 +-
 drivers/clk/samsung/clk.c | 9 +
 drivers/clk/tegra/clk-tegra-pmc.c | 2 +-
 drivers/clk/tegra/clk.c   | 2 +-
 10 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/arch/arm/mach-vexpress/spc.c b/arch/arm/mach-vexpress/spc.c
index 5766ce2be32b..b9e953824775 100644
--- a/arch/arm/mach-vexpress/spc.c
+++ b/arch/arm/mach-vexpress/spc.c
@@ -577,7 +577,7 @@ static int __init ve_spc_clk_init(void)
pr_warn("failed to register cpu%d clock\n", cpu);
continue;
}
-   if (clk_register_clkdev(clk, NULL, dev_name(cpu_dev))) {
+   if (clk_register_clkdev(clk, NULL, "%s", dev_name(cpu_dev))) {
pr_warn("failed to register cpu%d clock lookup\n", cpu);
continue;
}
diff --git a/arch/powerpc/platforms/512x/clock-commonclk.c 
b/arch/powerpc/platforms/512x/clock-commonclk.c
index f691bcabd710..8f35949e3365 100644
--- a/arch/powerpc/platforms/512x/clock-commonclk.c
+++ b/arch/powerpc/platforms/512x/clock-commonclk.c
@@ -992,9 +992,9 @@ static void mpc5121_clk_provide_migration_support(void)
clk = of_clk_get_by_name(np, clkname); \
if (IS_ERR(clk)) { \
clk = clkitem; \
-   clk_register_clkdev(clk, clkname, devname); \
+   clk_register_clkdev(clk, clkname, "%s", devname); \
if (regnode) \
-   clk_register_clkdev(clk, clkname, np->name); \
+   clk_register_clkdev(clk, clkname, "%s", np->name); \
did_register |= DID_REG_ ## regflag; \
pr_debug("clock alias name '%s' for dev '%s' pointer %p\n", \
 clkname, devname, clk); \
diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index 3984ea96e5f7..c6af5d0da99f 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -65,7 +65,8 @@ static int acpi_apd_setup(struct apd_private_data *pdata)
dev_name(>adev->dev),
NULL, CLK_IS_ROOT,
dev_desc->fixed_clk_rate);
-   clk_register_clkdev(clk, NULL, dev_name(>adev->dev));
+   clk_register_clkdev(clk, NULL, "%s",
+   dev_name(>adev->dev));
pdata->clk = clk;
}
 
diff --git a/drivers/acpi/acpi_lpss.c b/drivers/acpi/acpi_lpss.c
index 46b58abb08c5..abea2b14cf90 100644
--- a/drivers/acpi/acpi_lpss.c
+++ b/drivers/acpi/acpi_lpss.c
@@ -316,7 +316,7 @@ out:
return PTR_ERR(clk);
 
pdata->clk = clk;
-   clk_register_clkdev(clk, dev_desc->clk_con_id, devname);
+   clk_register_clkdev(clk, dev_desc->clk_con_id, "%s", devname);
return 0;
 }
 
diff --git a/drivers/clk/clk-mb86s7x.c b/drivers/clk/clk-mb86s7x.c
index f39c25a22f43..1e2d8fca3daf 100644
--- a/drivers/clk/clk-mb86s7x.c
+++ b/drivers/clk/clk-mb86s7x.c
@@ -370,7 +370,7 @@ static int mb86s7x_clclk_of_init(void)
pr_err("failed to register cpu%d clock\n", cpu);
continue;
}
-   if (clk_register_clkdev(clk, NULL, dev_name(cpu_dev))) {
+   if (clk_register_clkdev(clk, NULL, "%s", dev_name(cpu_dev))) {
pr_err("failed to register cpu%d clock lookup\n", cpu);
continue;
}
diff --git a/drivers/clk/clk-moxart.c b/drivers/clk/clk-moxart.c
index 5181b89c3cb2..1928c9e2f005 100644
--- a/drivers/clk/clk-moxart.c
+++ b/drivers/clk/clk-moxart.c
@@ -47,7 +47,7 @@ static void __init moxart_of_pll_clk_init(struct device_node 
*node)
return;
}
 
-   clk_register_clkdev(clk, NULL, name);
+   clk_register_clkdev(clk, NULL, "%s", name);
of_clk_add_provider(node, of_clk_src_simple_get, clk);
 }
 CLK_OF_DECLARE(moxart_pll_clock, "moxa,moxart-pll-clock",
@@ -90,7 +90,7 @@ static void __init moxart_of_apb_clk_init(struct device_node 
*node)
return;
}
 
-   clk_register_clkdev(clk, NULL, name);
+   clk_register_clkdev(clk, NULL, "%s", name);

Re: [PATCH] kthread: Export kthread functions

[Neil Horman]

On Fri, Jul 24, 2015 at 06:45:20PM -0400, David Kershner wrote:
> The s-Par visornic driver, currently in staging, processes a queue
> being serviced by the an s-Par service partition. We can get a message
> that something has happened with the Service Partition, when that
> happens, we must not access the channel until we get a message that the
> service partition is back again.
> 
> The visornic driver has a thread for processing the channel, when we
> get the message, we need to be able to park the thread and then resume
> it when the problem clears.
> 
> We can do this with kthread_park and unpark but they are not exported
> from the kernel, this patch exports the needed functions.
> 
> Signed-off-by: David Kershner 

Given that these functions are visible in the header and part of the
kthread_api, I think it makes good sense to do this

Acked-by: Neil Horman 

> ---
>  kernel/kthread.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 10e489c..bad80c1 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -97,6 +97,7 @@ bool kthread_should_park(void)
>  {
>   return test_bit(KTHREAD_SHOULD_PARK, _kthread(current)->flags);
>  }
> +EXPORT_SYMBOL(kthread_should_park);
>  
>  /**
>   * kthread_freezable_should_stop - should this freezable kthread return now?
> @@ -171,6 +172,7 @@ void kthread_parkme(void)
>  {
>   __kthread_parkme(to_kthread(current));
>  }
> +EXPORT_SYMBOL(kthread_parkme);
>  
>  static int kthread(void *_create)
>  {
> @@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *k)
>   if (kthread)
>   __kthread_unpark(k, kthread);
>  }
> +EXPORT_SYMBOL(kthread_unpark);
>  
>  /**
>   * kthread_park - park a thread created by kthread_create().
> @@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
>   }
>   return ret;
>  }
> +EXPORT_SYMBOL(kthread_park);
>  
>  /**
>   * kthread_stop - stop a thread created by kthread_create().
> -- 
> 1.9.1
> 
--
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: linux-next: build failure after merge of the akpm-current tree

[Paul E. McKenney]

On Fri, Jul 24, 2015 at 01:16:05PM -0700, Davidlohr Bueso wrote:
> On Fri, 2015-07-24 at 15:33 +1000, Stephen Rothwell wrote:
> > Hi Andrew,
> > 
> > After merging the akpm-current tree, today's linux-next build (powerpc
> > allnoconfig) failed like this:
> > 
> > mm/built-in.o: In function `shrink_slab.part.73.constprop.83':
> > vmscan.c:(.text+0xf760): undefined reference to `__srcu_read_lock'
> > vmscan.c:(.text+0xf924): undefined reference to `__srcu_read_unlock'
> > mm/built-in.o: In function `unregister_shrinker':
> > (.text+0xfa60): undefined reference to `synchronize_srcu'
> > mm/built-in.o:(.data+0x1e8): undefined reference to `process_srcu'
> > 
> > Caused by commit
> > 
> >   dab937da82f9 ("mm: srcu-ify shrinkers")
> > 
> > I have reverted that commit for today.
> 
> Adding paulmck.
> 
> I'm not entirely sure what is the fix here. Paul G also reported it
> failing for arm. I was able to reproduce with powerpc, and the following
> fixes the issue, but I doubt it is the correct way to address this. The
> idea was based on how we do it for x86.
> 
> Also, having SRCU in mm is, lets say, more than convenient, beyond
> MMU_NOTIFIERS which explicitly selects SRCU.
> 
> Paul?

SRCU was made optional as part of the kernel tinification project,
so adding Josh on CC.  The hope would be that the feature needing SRCU
could add the "select" rather than having major architectures doing so.

I guess if SRCU is needed everywhere, it is needed everywhere, but...

Thanx, Paul

> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 5ef2711..774207e 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -124,6 +124,7 @@ config PPC
> select GENERIC_IRQ_SHOW
> select GENERIC_IRQ_SHOW_LEVEL
> select IRQ_FORCED_THREADING
> +   select SRCU
> select HAVE_RCU_TABLE_FREE if SMP
> select HAVE_SYSCALL_TRACEPOINTS
> select HAVE_BPF_JIT
> 
> Thanks,
> Davidlohr
> 

--
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: [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE

[David Rientjes]

On Fri, 24 Jul 2015, Vlastimil Babka wrote:

> > I assume you looked at the collapse_huge_page() case and decided that it 
> > needs no modification since the gfp mask is used later for other calls?
> 
> Yeah. Not that the memcg charge parts would seem to care about __GFP_THISNODE,
> though.
> 

Hmm, not sure that memcg would ever care about __GFP_THISNODE.  I wonder 
if it make more sense to remove setting __GFP_THISNODE in 
collapse_huge_page()?  khugepaged_alloc_page() seems fine with the new 
alloc_pages_exact_node() semantics.

> >> diff --git a/mm/migrate.c b/mm/migrate.c
> >> index f53838f..d139222 100644
> >> --- a/mm/migrate.c
> >> +++ b/mm/migrate.c
> >> @@ -1554,10 +1554,8 @@ static struct page *alloc_misplaced_dst_page(struct 
> >> page *page,
> >>struct page *newpage;
> >>  
> >>newpage = alloc_pages_exact_node(nid,
> >> -   (GFP_HIGHUSER_MOVABLE |
> >> -__GFP_THISNODE | __GFP_NOMEMALLOC |
> >> -__GFP_NORETRY | __GFP_NOWARN) &
> >> -   ~GFP_IOFS, 0);
> >> +  (GFP_HIGHUSER_MOVABLE | __GFP_NOMEMALLOC |
> >> +   __GFP_NORETRY | __GFP_NOWARN) & ~GFP_IOFS, 0);
> >>  
> >>return newpage;
> >>  }
> > [snip]
> > 
> > What about the alloc_pages_exact_node() in new_page_node()?
> 
> Oops, seems I missed that one. So the API seems ok otherwise?
> 

Yup!  And I believe that this patch doesn't cause any regression after the 
new_page_node() issue is fixed.
--
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: [RFC v2 4/4] mm: fallback for offline nodes in alloc_pages_node

[David Rientjes]

On Fri, 24 Jul 2015, Vlastimil Babka wrote:

> >>> diff --git a/include/linux/gfp.h b/include/linux/gfp.h
> >>> index 531c72d..104a027 100644
> >>> --- a/include/linux/gfp.h
> >>> +++ b/include/linux/gfp.h
> >>> @@ -321,8 +321,12 @@ static inline struct page *alloc_pages_node(int nid, 
> >>> gfp_t gfp_mask,
> >>>   unsigned int order)
> >>>  {
> >>>   /* Unknown node is current (or closest) node */
> >>> - if (nid == NUMA_NO_NODE)
> >>> + if (nid == NUMA_NO_NODE) {
> >>>   nid = numa_mem_id();
> >>> + } else if (!node_online(nid)) {
> >>> + VM_WARN_ON(!node_online(nid));
> >>> + nid = numa_mem_id();
> >>> + }
> >>
> >> I would think you would only want this for debugging purposes. The
> >> overwhelming majority of hardware out there has no memory
> >> onlining/offlining capability after all and this adds the overhead to each
> >> call to alloc_pages_node.
> >>
> >> Make this dependo n CONFIG_VM_DEBUG or some such thing?
> >>
> > 
> > Yeah, the suggestion was for VM_WARN_ON() in the conditional, but the 
> > placement has changed somewhat because of the new __alloc_pages_node().  I 
> > think
> > 
> > else if (VM_WARN_ON(!node_online(nid)))
> > nid = numa_mem_id();
> > 
> > should be fine since it only triggers for CONFIG_DEBUG_VM.
> 
> Um, so on your original suggestion I thought that you assumed that the 
> condition
> inside VM_WARN_ON is evaluated regardless of CONFIG_DEBUG_VM, it just will or
> will not generate a warning. Which is how BUG_ON works, but VM_WARN_ON (and
> VM_BUG_ON) doesn't. IIUC VM_WARN_ON() with !CONFIG_DEBUG_VM will always be 
> false.

Right, that's what Christoph is also suggesting.  VM_WARN_ON without 
CONFIG_DEBUG_VM should permit the compiler to check the expression but not 
generate any code and we don't want to check node_online() here for every 
allocation, it's only a debugging measure.

> Because I didn't think you would suggest the "nid = numa_mem_id()" for
> !node_online(nid) fixup would happen only for CONFIG_DEBUG_VM kernels. But it
> seems that you do suggest that? I would understand if the fixup (correcting an
> offline node to some that's online) was done regardless of DEBUG_VM, and
> DEBUG_VM just switched between silent and noisy fixup. But having a debug 
> option
> alter the outcome seems wrong?

Hmm, not sure why this is surprising, I don't expect people to deploy 
production kernels with CONFIG_DEBUG_VM enabled, it's far too expensive.  
I was expecting they would enable it for, well... debug :)

In that case, if nid is a valid node but offline, then the nid = 
numa_mem_id() fixup seems fine to allow the kernel to continue debugging.

When a node is offlined as a result of memory hotplug, the pgdat doesn't 
get freed so it can be onlined later.  Thus, alloc_pages_node() with an 
offline node and !CONFIG_DEBUG_VM may not panic.  If it does, this can 
probably be removed because we're covered.
--
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/

[PATCH] kthread: Export kthread functions

[David Kershner]

The s-Par visornic driver, currently in staging, processes a queue
being serviced by the an s-Par service partition. We can get a message
that something has happened with the Service Partition, when that
happens, we must not access the channel until we get a message that the
service partition is back again.

The visornic driver has a thread for processing the channel, when we
get the message, we need to be able to park the thread and then resume
it when the problem clears.

We can do this with kthread_park and unpark but they are not exported
from the kernel, this patch exports the needed functions.

Signed-off-by: David Kershner 
---
 kernel/kthread.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index 10e489c..bad80c1 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -97,6 +97,7 @@ bool kthread_should_park(void)
 {
return test_bit(KTHREAD_SHOULD_PARK, _kthread(current)->flags);
 }
+EXPORT_SYMBOL(kthread_should_park);
 
 /**
  * kthread_freezable_should_stop - should this freezable kthread return now?
@@ -171,6 +172,7 @@ void kthread_parkme(void)
 {
__kthread_parkme(to_kthread(current));
 }
+EXPORT_SYMBOL(kthread_parkme);
 
 static int kthread(void *_create)
 {
@@ -411,6 +413,7 @@ void kthread_unpark(struct task_struct *k)
if (kthread)
__kthread_unpark(k, kthread);
 }
+EXPORT_SYMBOL(kthread_unpark);
 
 /**
  * kthread_park - park a thread created by kthread_create().
@@ -441,6 +444,7 @@ int kthread_park(struct task_struct *k)
}
return ret;
 }
+EXPORT_SYMBOL(kthread_park);
 
 /**
  * kthread_stop - stop a thread created by kthread_create().
-- 
1.9.1

--
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 v2] thermal: consistently use int for temperatures

[Guenter Roeck]

On 07/24/2015 03:11 PM, Pavel Machek wrote:

On Fri 2015-07-24 06:59:26, Guenter Roeck wrote:

On 07/23/2015 11:29 PM, Sascha Hauer wrote:

On Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote:

On Tue 2015-07-21 09:21:32, Sascha Hauer wrote:

The thermal code uses int, long and unsigned long for temperatures
in different places.

Using an unsigned type limits the thermal framework to positive
temperatures without need. Also several drivers currently will report
temperatures near UINT_MAX for temperatures below 0°C. This will probably
immediately shut the machine down due to overtemperature if started below
0°C.

'long' is 64bit on several architectures. This is not needed since INT_MAX °mC
is above the melting point of all known materials.


Can we do something like

typedef millicelsius_t int;

...to document the units?


I am not very fond of typedefs and I am not sure this adds any value. I
could change it when more people ask for it, but I just sent the new
version without this.



I thought we are supposed to not introduce new typedefs anyway.


You are not supposed to typedef struct, but typedef for millicelsius_t
would be ok. And it is your only chance if you want people to pay
attention. If you make it int, someone will pass it to long or
something else..


Seems to me that would be just lazyness. The same person might use 'long'
even if millicelsius_t is defined. A typedef doesn't preclude people
from ignoring it.

Guenter

--
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 1/1] toshiba_acpi: Add set_fan_status function

[Darren Hart]

On Wed, Jul 22, 2015 at 07:37:48PM -0600, Azael Avalos wrote:
> This patch adds a new function named "set_fan_status" to complement
> its get* counterpart, as well as to avoid code duplication between
> "fan_proc_write" and "fan_store".

It also appears to change the error codes returned via sysfs?

Also adds some pr_ statements.

> 
> Signed-off-by: Azael Avalos 
> ---
>  drivers/platform/x86/toshiba_acpi.c | 55 
> -
>  1 file changed, 36 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/platform/x86/toshiba_acpi.c 
> b/drivers/platform/x86/toshiba_acpi.c
> index 6013a11..08fc867 100644
> --- a/drivers/platform/x86/toshiba_acpi.c
> +++ b/drivers/platform/x86/toshiba_acpi.c
> @@ -1422,12 +1422,33 @@ static const struct file_operations video_proc_fops = 
> {
>   .write  = video_proc_write,
>  };
>  
> +/* Fan status */
>  static int get_fan_status(struct toshiba_acpi_dev *dev, u32 *status)
>  {
> - u32 hci_result;
> + u32 result = hci_read(dev, HCI_FAN, status);
>  
> - hci_result = hci_read(dev, HCI_FAN, status);
> - return hci_result == TOS_SUCCESS ? 0 : -EIO;
> + if (result == TOS_FAILURE)
> + pr_err("ACPI call to get Fan status failed\n");

s/Fan/fan/

Below too.

> + else if (result == TOS_NOT_SUPPORTED)
> + return -ENODEV;

This condition would have returned -EIO previously correct?

I agree this new one is the right change, but it does pose a risk to userspace.
There is a slim chance we will have to revert if someone complains and can't
work around it, so we need to be clear about this in the commit message at the
very least.
-- 
Darren Hart
Intel Open Source Technology Center
--
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/