[tip:x86/asm] ftrace/x86: Implement HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

2016-08-24 Thread tip-bot for Josh Poimboeuf
Commit-ID:  471bd10f5e2880bd91a2627d887f6062494cfe9c
Gitweb: http://git.kernel.org/tip/471bd10f5e2880bd91a2627d887f6062494cfe9c
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:00 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

ftrace/x86: Implement HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

Use the more reliable version of ftrace_graph_ret_addr() so we no longer
have to worry about the unwinder getting out of sync with the function
graph ret_stack index, which can happen if the unwinder skips any frames
before calling ftrace_graph_ret_addr().

This fixes this issue (and several others like it):

  $ cat /proc/self/stack
  [] save_stack_trace_tsk+0x22/0x40
  [] proc_pid_stack+0xb9/0x110
  [] proc_single_show+0x54/0x80
  [] seq_read+0x108/0x3e0
  [] __vfs_read+0x37/0x140
  [] vfs_read+0x99/0x140
  [] SyS_read+0x58/0xc0
  [] entry_SYSCALL_64_fastpath+0x1f/0xbd
  [] 0x

  $ echo function_graph > /sys/kernel/debug/tracing/current_tracer

  $ cat /proc/self/stack
  [] return_to_handler+0x0/0x27
  [] print_context_stack+0xfc/0x100
  [] return_to_handler+0x0/0x27
  [] dump_trace+0x12b/0x350
  [] return_to_handler+0x0/0x27
  [] save_stack_trace_tsk+0x22/0x40
  [] return_to_handler+0x0/0x27
  [] proc_pid_stack+0xb9/0x110
  [] return_to_handler+0x0/0x27
  [] proc_single_show+0x54/0x80
  [] return_to_handler+0x0/0x27
  [] seq_read+0x108/0x3e0
  [] return_to_handler+0x0/0x27
  [] __vfs_read+0x37/0x140
  [] return_to_handler+0x0/0x27
  [] vfs_read+0x99/0x140
  [] 0x

Enabling function graph tracing causes the stack trace to change in two
ways:

First, the real call addresses are confusingly interspersed with
'return_to_handler' addresses.  This issue will be fixed by the next
patch.

Second, the stack trace is offset by two frames, because the unwinder
skipped the first two frames and got out of sync with the ret_stack
index.  This patch fixes this issue.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/a6d623e36f8d08f9a17bd74d804d201177a23afd.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/ftrace.h | 2 ++
 arch/x86/kernel/ftrace.c  | 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
index 37f67cb..eccd0ac 100644
--- a/arch/x86/include/asm/ftrace.h
+++ b/arch/x86/include/asm/ftrace.h
@@ -14,6 +14,8 @@
 #define ARCH_SUPPORTS_FTRACE_OPS 1
 #endif
 
+#define HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
+
 #ifndef __ASSEMBLY__
 extern void mcount(void);
 extern atomic_t modifying_ftrace_code;
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index ae3b1fb..8639bb2 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -1029,7 +1029,7 @@ void prepare_ftrace_return(unsigned long self_addr, 
unsigned long *parent,
}
 
if (ftrace_push_return_trace(old, self_addr, &trace.depth,
-frame_pointer, NULL) == -EBUSY) {
+frame_pointer, parent) == -EBUSY) {
*parent = old;
return;
}


[tip:x86/asm] sched/x86: Pass kernel thread parameters in 'struct fork_frame'

2016-08-24 Thread tip-bot for Brian Gerst
Commit-ID:  616d24835eeafa8ef3466479db028abfdfc77531
Gitweb: http://git.kernel.org/tip/616d24835eeafa8ef3466479db028abfdfc77531
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:20 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:50 +0200

sched/x86: Pass kernel thread parameters in 'struct fork_frame'

Instead of setting up a fake pt_regs context, put the kernel thread
function pointer and arg into the unused callee-restored registers
of 'struct fork_frame'.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-6-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_32.S| 31 +++
 arch/x86/entry/entry_64.S| 37 +
 arch/x86/include/asm/switch_to.h |  2 ++
 arch/x86/kernel/process_32.c | 18 --
 arch/x86/kernel/process_64.c | 12 +++-
 5 files changed, 41 insertions(+), 59 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index bf8f221..b75a8bc 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -240,35 +240,34 @@ END(__switch_to_asm)
  * A newly forked process directly context switches into this address.
  *
  * eax: prev task we switched from
+ * ebx: kernel thread func (NULL for user thread)
+ * edi: kernel thread arg
  */
 ENTRY(ret_from_fork)
pushl   %eax
callschedule_tail
popl%eax
 
+   testl   %ebx, %ebx
+   jnz 1f  /* kernel threads are uncommon */
+
+2:
/* When we fork, we trace the syscall return in the child, too. */
movl%esp, %eax
callsyscall_return_slowpath
jmp restore_all
-END(ret_from_fork)
-
-ENTRY(ret_from_kernel_thread)
-   pushl   %eax
-   callschedule_tail
-   popl%eax
-   movlPT_EBP(%esp), %eax
-   call*PT_EBX(%esp)
-   movl$0, PT_EAX(%esp)
 
+   /* kernel thread */
+1: movl%edi, %eax
+   call*%ebx
/*
-* Kernel threads return to userspace as if returning from a syscall.
-* We should check whether anything actually uses this path and, if so,
-* consider switching it over to ret_from_fork.
+* A kernel thread is allowed to return here after successfully
+* calling do_execve().  Exit to userspace to complete the execve()
+* syscall.
 */
-   movl%esp, %eax
-   callsyscall_return_slowpath
-   jmp restore_all
-ENDPROC(ret_from_kernel_thread)
+   movl$0, PT_EAX(%esp)
+   jmp 2b
+END(ret_from_fork)
 
 /*
  * Return to user mode is not as complex as all this looks,
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index c1af8ac..c0373d6 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -407,37 +407,34 @@ END(__switch_to_asm)
  * A newly forked process directly context switches into this address.
  *
  * rax: prev task we switched from
+ * rbx: kernel thread func (NULL for user thread)
+ * r12: kernel thread arg
  */
 ENTRY(ret_from_fork)
movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
-   testb   $3, CS(%rsp)/* from kernel_thread? */
-   jnz 1f
-
-   /*
-* We came from kernel_thread.  This code path is quite twisted, and
-* someone should clean it up.
-*
-* copy_thread_tls stashes the function pointer in RBX and the
-* parameter to be passed in RBP.  The called function is permitted
-* to call do_execve and thereby jump to user mode.
-*/
-   movqRBP(%rsp), %rdi
-   call*RBX(%rsp)
-   movl$0, RAX(%rsp)
-
-   /*
-* Fall through as though we're exiting a syscall.  This makes a
-* twisted sort of sense if we just called do_execve.
-*/
+   testq   %rbx, %rbx  /* from kernel_thread? */
+   jnz 1f  /* kernel threads are uncommon 
*/
 
-1:
+2:
movq%rsp, %rdi
callsyscall_return_slowpath /* returns with IRQs disabled */
TRACE_IRQS_ON   /* user mode is traced as IRQS on */
SWAPGS
jmp restore_regs_and_iret
+
+1:
+   /* kernel thread */
+   movq%r12, %rdi
+   call*%rbx
+   /*
+* A kernel thread is allowed to return here after successfully
+* calling do_execve().  Exit to userspace to complete the execve()
+* syscall.
+*/
+   movq$0, RAX(%rsp)
+   jmp 2b
 END(ret_from_fork)
 
 /*
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index 886d5ea..5cb436a 100644
--- a/a

Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

2016-08-24 Thread Eric Dumazet
On Wed, 2016-08-24 at 12:36 +0200, Christophe Leroy wrote:
> Initially, a NAPI TX routine has been implemented separately from
> NAPI RX, as done on the freescale/gianfar driver.
> 
> By merging NAPI RX and NAPI TX, we reduce the amount of TX completion
> interrupts.
> 
> Handling of the budget in association with TX interrupts is based on
> indications provided at https://wiki.linuxfoundation.org/networking/napi
> 
> At the same time, we fix an issue in the handling of fep->tx_free:
> 
> It is only when fep->tx_free goes up to MAX_SKB_FRAGS that
> we need to wake up the queue. There is no need to call
> netif_wake_queue() at every packet successfully transmitted.
> 
> Signed-off-by: Christophe Leroy 
> ---
>  .../net/ethernet/freescale/fs_enet/fs_enet-main.c  | 259 
> +
>  drivers/net/ethernet/freescale/fs_enet/fs_enet.h   |  16 +-
>  drivers/net/ethernet/freescale/fs_enet/mac-fcc.c   |  57 ++---
>  drivers/net/ethernet/freescale/fs_enet/mac-fec.c   |  57 ++---
>  drivers/net/ethernet/freescale/fs_enet/mac-scc.c   |  57 ++---
>  5 files changed, 153 insertions(+), 293 deletions(-)
> 
> diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c 
> b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> index 61fd486..7cd3ef9 100644
> --- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> +++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
> @@ -79,8 +79,8 @@ static void skb_align(struct sk_buff *skb, int align)
>   skb_reserve(skb, align - off);
>  }
>  
> -/* NAPI receive function */
> -static int fs_enet_rx_napi(struct napi_struct *napi, int budget)
> +/* NAPI function */
> +static int fs_enet_napi(struct napi_struct *napi, int budget)
>  {
>   struct fs_enet_private *fep = container_of(napi, struct 
> fs_enet_private, napi);
>   struct net_device *dev = fep->ndev;
> @@ -90,9 +90,100 @@ static int fs_enet_rx_napi(struct napi_struct *napi, int 
> budget)
>   int received = 0;
>   u16 pkt_len, sc;
>   int curidx;
> + int dirtyidx, do_wake, do_restart;
>  
> - if (budget <= 0)
> - return received;
> + spin_lock(&fep->tx_lock);
> + bdp = fep->dirty_tx;
> +
> + /* clear status bits for napi*/
> + (*fep->ops->napi_clear_event)(dev);
> +
> + do_wake = do_restart = 0;
> + while (((sc = CBDR_SC(bdp)) & BD_ENET_TX_READY) == 0) {

I am afraid you could live lock here on SMP.

You should make sure you do not loop forever, not assuming cpu is faster
than NIC.



> + dirtyidx = bdp - fep->tx_bd_base;
> +
> + if (fep->tx_free == fep->tx_ring)
> + break;
> +
> + skb = fep->tx_skbuff[dirtyidx];
> +
> + /*
> +  * Check for errors.
> +  */
> + if (sc & (BD_ENET_TX_HB | BD_ENET_TX_LC |
> +   BD_ENET_TX_RL | BD_ENET_TX_UN | BD_ENET_TX_CSL)) {
> +
> + if (sc & BD_ENET_TX_HB) /* No heartbeat */
> + fep->stats.tx_heartbeat_errors++;
> + if (sc & BD_ENET_TX_LC) /* Late collision */
> + fep->stats.tx_window_errors++;
> + if (sc & BD_ENET_TX_RL) /* Retrans limit */
> + fep->stats.tx_aborted_errors++;
> + if (sc & BD_ENET_TX_UN) /* Underrun */
> + fep->stats.tx_fifo_errors++;
> + if (sc & BD_ENET_TX_CSL)/* Carrier lost */
> + fep->stats.tx_carrier_errors++;
> +
> + if (sc & (BD_ENET_TX_LC | BD_ENET_TX_RL | 
> BD_ENET_TX_UN)) {
> + fep->stats.tx_errors++;
> + do_restart = 1;
> + }
> + } else
> + fep->stats.tx_packets++;
> +
> + if (sc & BD_ENET_TX_READY) {
> + dev_warn(fep->dev,
> +  "HEY! Enet xmit interrupt and TX_READY.\n");
> + }
> +
> + /*
> +  * Deferred means some collisions occurred during transmit,
> +  * but we eventually sent the packet OK.
> +  */
> + if (sc & BD_ENET_TX_DEF)
> + fep->stats.collisions++;
> +
> + /* unmap */
> + if (fep->mapped_as_page[dirtyidx])
> + dma_unmap_page(fep->dev, CBDR_BUFADDR(bdp),
> +CBDR_DATLEN(bdp), DMA_TO_DEVICE);
> + else
> + dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
> +  CBDR_DATLEN(bdp), DMA_TO_DEVICE);
> +
> + /*
> +  * Free the sk buffer associated with this last transmit.
> +  */
> + if (skb) {
> + dev_kfree_skb(skb);
> + fep->tx_skbuff[dirtyidx] = NULL;
> + }
> +
> +   

[tip:x86/asm] sched/x86: Rewrite the switch_to() code

2016-08-24 Thread tip-bot for Brian Gerst
Commit-ID:  0100301bfdf56a2a370c7157b5ab0fbf9313e1cd
Gitweb: http://git.kernel.org/tip/0100301bfdf56a2a370c7157b5ab0fbf9313e1cd
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:19 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:41 +0200

sched/x86: Rewrite the switch_to() code

Move the low-level context switch code to an out-of-line asm stub instead of
using complex inline asm.  This allows constructing a new stack frame for the
child process to make it seamlessly flow to ret_from_fork without an extra
test and branch in __switch_to().  It also improves code generation for
__schedule() by using the C calling convention instead of clobbering all
registers.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-5-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_32.S  |  37 ++
 arch/x86/entry/entry_64.S  |  41 ++-
 arch/x86/include/asm/processor.h   |   3 -
 arch/x86/include/asm/switch_to.h   | 139 ++---
 arch/x86/include/asm/thread_info.h |   2 -
 arch/x86/kernel/asm-offsets.c  |   6 ++
 arch/x86/kernel/asm-offsets_32.c   |   5 ++
 arch/x86/kernel/asm-offsets_64.c   |   5 ++
 arch/x86/kernel/process_32.c   |   9 ++-
 arch/x86/kernel/process_64.c   |   9 ++-
 arch/x86/kernel/smpboot.c  |   1 -
 11 files changed, 125 insertions(+), 132 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 0b5..bf8f221 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -204,6 +204,43 @@
POP_GS_EX
 .endm
 
+/*
+ * %eax: prev task
+ * %edx: next task
+ */
+ENTRY(__switch_to_asm)
+   /*
+* Save callee-saved registers
+* This must match the order in struct inactive_task_frame
+*/
+   pushl   %ebp
+   pushl   %ebx
+   pushl   %edi
+   pushl   %esi
+
+   /* switch stack */
+   movl%esp, TASK_threadsp(%eax)
+   movlTASK_threadsp(%edx), %esp
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+   movlTASK_stack_canary(%edx), %ebx
+   movl%ebx, PER_CPU_VAR(stack_canary)+stack_canary_offset
+#endif
+
+   /* restore callee-saved registers */
+   popl%esi
+   popl%edi
+   popl%ebx
+   popl%ebp
+
+   jmp __switch_to
+END(__switch_to_asm)
+
+/*
+ * A newly forked process directly context switches into this address.
+ *
+ * eax: prev task we switched from
+ */
 ENTRY(ret_from_fork)
pushl   %eax
callschedule_tail
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index f6b40e5..c1af8ac 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -368,13 +368,48 @@ END(ptregs_\func)
 #include 
 
 /*
+ * %rdi: prev task
+ * %rsi: next task
+ */
+ENTRY(__switch_to_asm)
+   /*
+* Save callee-saved registers
+* This must match the order in inactive_task_frame
+*/
+   pushq   %rbp
+   pushq   %rbx
+   pushq   %r12
+   pushq   %r13
+   pushq   %r14
+   pushq   %r15
+
+   /* switch stack */
+   movq%rsp, TASK_threadsp(%rdi)
+   movqTASK_threadsp(%rsi), %rsp
+
+#ifdef CONFIG_CC_STACKPROTECTOR
+   movqTASK_stack_canary(%rsi), %rbx
+   movq%rbx, PER_CPU_VAR(irq_stack_union)+stack_canary_offset
+#endif
+
+   /* restore callee-saved registers */
+   popq%r15
+   popq%r14
+   popq%r13
+   popq%r12
+   popq%rbx
+   popq%rbp
+
+   jmp __switch_to
+END(__switch_to_asm)
+
+/*
  * A newly forked process directly context switches into this address.
  *
- * rdi: prev task we switched from
+ * rax: prev task we switched from
  */
 ENTRY(ret_from_fork)
-   LOCK ; btr $TIF_FORK, TI_flags(%r8)
-
+   movq%rax, %rdi
callschedule_tail   /* rdi: 'prev' task parameter */
 
testb   $3, CS(%rsp)/* from kernel_thread? */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 63def95..6fee863 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -389,9 +389,6 @@ struct thread_struct {
unsigned short  fsindex;
unsigned short  gsindex;
 #endif
-#ifdef CONFIG_X86_32
-   unsigned long   ip;
-#endif
 #ifdef CONFIG_X86_64
unsigned long   fsbase;
unsigned long   gsbase;
diff --git a/arch/x86/include/asm/switch_to.h b/arch/x86/include/asm/switch_to.h
index ec689c6..886d5ea 100644
--- a/arch/x86/include/asm/switch_to.h
+++ b/arch/x86/include/asm/switch_to.h
@@ -2,8 +2,12 @@
 #define _ASM_X86_SWITCH_TO_H
 
 struct task_struct; /* one of the stranger aspects of C forward d

[tip:x86/asm] sched/x86: Fix thread_saved_pc()

2016-08-24 Thread tip-bot for Brian Gerst
Commit-ID:  ffcb043ba524d3fbd979a9dac2c9ce8ad352000d
Gitweb: http://git.kernel.org/tip/ffcb043ba524d3fbd979a9dac2c9ce8ad352000d
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:21 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:51 +0200

sched/x86: Fix thread_saved_pc()

thread_saved_pc() was using a completely bogus method to get the return
address.  Since switch_to() was previously inlined, there was no sane way
to know where on the stack the return address was stored.  Now with the
frame of a sleeping thread well defined, this can be implemented correctly.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-7-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/include/asm/processor.h | 10 ++
 arch/x86/kernel/process.c| 11 +++
 arch/x86/kernel/process_32.c |  8 
 3 files changed, 13 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 6fee863..b22fb5a 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -721,8 +721,6 @@ static inline void spin_lock_prefetch(const void *x)
.addr_limit = KERNEL_DS,  \
 }
 
-extern unsigned long thread_saved_pc(struct task_struct *tsk);
-
 /*
  * TOP_OF_KERNEL_STACK_PADDING reserves 8 bytes on top of the ring0 stack.
  * This is necessary to guarantee that the entire "struct pt_regs"
@@ -773,17 +771,13 @@ extern unsigned long thread_saved_pc(struct task_struct 
*tsk);
.addr_limit = KERNEL_DS,\
 }
 
-/*
- * Return saved PC of a blocked thread.
- * What is this good for? it will be always the scheduler or ret_from_fork.
- */
-#define thread_saved_pc(t) READ_ONCE_NOCHECK(*(unsigned long 
*)((t)->thread.sp - 8))
-
 #define task_pt_regs(tsk)  ((struct pt_regs *)(tsk)->thread.sp0 - 1)
 extern unsigned long KSTK_ESP(struct task_struct *task);
 
 #endif /* CONFIG_X86_64 */
 
+extern unsigned long thread_saved_pc(struct task_struct *tsk);
+
 extern void start_thread(struct pt_regs *regs, unsigned long new_ip,
   unsigned long new_sp);
 
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index 0115a4a..c1fa790 100644
--- a/arch/x86/kernel/process.c
+++ b/arch/x86/kernel/process.c
@@ -514,6 +514,17 @@ unsigned long arch_randomize_brk(struct mm_struct *mm)
 }
 
 /*
+ * Return saved PC of a blocked thread.
+ * What is this good for? it will be always the scheduler or ret_from_fork.
+ */
+unsigned long thread_saved_pc(struct task_struct *tsk)
+{
+   struct inactive_task_frame *frame =
+   (struct inactive_task_frame *) READ_ONCE(tsk->thread.sp);
+   return READ_ONCE_NOCHECK(frame->ret_addr);
+}
+
+/*
  * Called from fs/proc with a reference on @p to find the function
  * which called into schedule(). This needs to be done carefully
  * because the task might wake up and we might look at a stack
diff --git a/arch/x86/kernel/process_32.c b/arch/x86/kernel/process_32.c
index 18714a1..404efdf 100644
--- a/arch/x86/kernel/process_32.c
+++ b/arch/x86/kernel/process_32.c
@@ -55,14 +55,6 @@
 #include 
 #include 
 
-/*
- * Return saved PC of a blocked thread.
- */
-unsigned long thread_saved_pc(struct task_struct *tsk)
-{
-   return ((unsigned long *)tsk->thread.sp)[3];
-}
-
 void __show_regs(struct pt_regs *regs, int all)
 {
unsigned long cr0 = 0L, cr2 = 0L, cr3 = 0L, cr4 = 0L;


[PATCH] pstore/core: drop cmpxchg based updates

2016-08-24 Thread Sebastian Andrzej Siewior
I have here a FPGA behind PCIe which exports SRAM which I use for
pstore. Now it seems that the FPGA no longer supports cmpxchg based
updates and writes back 0xff…ff and returns the same.  This leads to
crash during crash rendering pstore useless.
Since I doubt that there is much benefit from using cmpxchg() here, I am
dropping this atomic access and use the spinlock based version.

Cc: Anton Vorontsov 
Cc: Colin Cross 
Cc: Kees Cook 
Cc: Tony Luck 
Signed-off-by: Sebastian Andrzej Siewior 
---
 fs/pstore/ram_core.c | 43 ++-
 1 file changed, 2 insertions(+), 41 deletions(-)

diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 76c3f80efdfa..4bae54bb61cd 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -47,39 +47,6 @@ static inline size_t buffer_start(struct persistent_ram_zone 
*prz)
return atomic_read(&prz->buffer->start);
 }
 
-/* increase and wrap the start pointer, returning the old value */
-static size_t buffer_start_add_atomic(struct persistent_ram_zone *prz, size_t 
a)
-{
-   int old;
-   int new;
-
-   do {
-   old = atomic_read(&prz->buffer->start);
-   new = old + a;
-   while (unlikely(new >= prz->buffer_size))
-   new -= prz->buffer_size;
-   } while (atomic_cmpxchg(&prz->buffer->start, old, new) != old);
-
-   return old;
-}
-
-/* increase the size counter until it hits the max size */
-static void buffer_size_add_atomic(struct persistent_ram_zone *prz, size_t a)
-{
-   size_t old;
-   size_t new;
-
-   if (atomic_read(&prz->buffer->size) == prz->buffer_size)
-   return;
-
-   do {
-   old = atomic_read(&prz->buffer->size);
-   new = old + a;
-   if (new > prz->buffer_size)
-   new = prz->buffer_size;
-   } while (atomic_cmpxchg(&prz->buffer->size, old, new) != old);
-}
-
 static DEFINE_RAW_SPINLOCK(buffer_lock);
 
 /* increase and wrap the start pointer, returning the old value */
@@ -124,9 +91,6 @@ static void buffer_size_add_locked(struct 
persistent_ram_zone *prz, size_t a)
raw_spin_unlock_irqrestore(&buffer_lock, flags);
 }
 
-static size_t (*buffer_start_add)(struct persistent_ram_zone *, size_t) = 
buffer_start_add_atomic;
-static void (*buffer_size_add)(struct persistent_ram_zone *, size_t) = 
buffer_size_add_atomic;
-
 static void notrace persistent_ram_encode_rs8(struct persistent_ram_zone *prz,
uint8_t *data, size_t len, uint8_t *ecc)
 {
@@ -338,9 +302,9 @@ int notrace persistent_ram_write(struct persistent_ram_zone 
*prz,
c = prz->buffer_size;
}
 
-   buffer_size_add(prz, c);
+   buffer_size_add_locked(prz, c);
 
-   start = buffer_start_add(prz, c);
+   start = buffer_start_add_locked(prz, c);
 
rem = prz->buffer_size - start;
if (unlikely(rem < c)) {
@@ -426,9 +390,6 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t 
size,
return NULL;
}
 
-   buffer_start_add = buffer_start_add_locked;
-   buffer_size_add = buffer_size_add_locked;
-
if (memtype)
va = ioremap(start, size);
else
-- 
2.9.3



[PATCH v2] perf/x86/amd: Make HW_CACHE_REFERENCES and HW_CACHE_MISSES measure L2

2016-08-24 Thread Matt Fleming
While the Intel PMU monitors the LLC when perf enables the
HW_CACHE_REFERENCES and HW_CACHE_MISSES events, these events monitor
L1 instruction cache fetches (0x0080) and instruction cache misses
(0x0081) on the AMD PMU.

This is extremely confusing when monitoring the same workload across
Intel and AMD machines, since parameters like,

  $ perf stat -e cache-references,cache-misses

measure completely different things.

Instead, make the AMD PMU measure instruction/data cache and TLB fill
requests to the L2 and instruction/data cache and TLB misses in the L2
when HW_CACHE_REFERENCES and HW_CACHE_MISSES are enabled,
respectively. That way the events measure unified caches on both
platforms.

Signed-off-by: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: 
---

Changes in v2:
  - Update the KVM AMD PMU code
  - Also measure TLB hits/misses in the L2

 arch/x86/events/amd/core.c | 4 ++--
 arch/x86/kvm/pmu_amd.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c
index e07a22bb9308..f5f4b3fbbbc2 100644
--- a/arch/x86/events/amd/core.c
+++ b/arch/x86/events/amd/core.c
@@ -119,8 +119,8 @@ static const u64 amd_perfmon_event_map[PERF_COUNT_HW_MAX] =
 {
   [PERF_COUNT_HW_CPU_CYCLES]   = 0x0076,
   [PERF_COUNT_HW_INSTRUCTIONS] = 0x00c0,
-  [PERF_COUNT_HW_CACHE_REFERENCES] = 0x0080,
-  [PERF_COUNT_HW_CACHE_MISSES] = 0x0081,
+  [PERF_COUNT_HW_CACHE_REFERENCES] = 0x077d,
+  [PERF_COUNT_HW_CACHE_MISSES] = 0x077e,
   [PERF_COUNT_HW_BRANCH_INSTRUCTIONS]  = 0x00c2,
   [PERF_COUNT_HW_BRANCH_MISSES]= 0x00c3,
   [PERF_COUNT_HW_STALLED_CYCLES_FRONTEND]  = 0x00d0, /* "Decoder empty" 
event */
diff --git a/arch/x86/kvm/pmu_amd.c b/arch/x86/kvm/pmu_amd.c
index 39b91127ef07..cd944435dfbd 100644
--- a/arch/x86/kvm/pmu_amd.c
+++ b/arch/x86/kvm/pmu_amd.c
@@ -23,8 +23,8 @@
 static struct kvm_event_hw_type_mapping amd_event_mapping[] = {
[0] = { 0x76, 0x00, PERF_COUNT_HW_CPU_CYCLES },
[1] = { 0xc0, 0x00, PERF_COUNT_HW_INSTRUCTIONS },
-   [2] = { 0x80, 0x00, PERF_COUNT_HW_CACHE_REFERENCES },
-   [3] = { 0x81, 0x00, PERF_COUNT_HW_CACHE_MISSES },
+   [2] = { 0x7d, 0x07, PERF_COUNT_HW_CACHE_REFERENCES },
+   [3] = { 0x7e, 0x07, PERF_COUNT_HW_CACHE_MISSES },
[4] = { 0xc2, 0x00, PERF_COUNT_HW_BRANCH_INSTRUCTIONS },
[5] = { 0xc3, 0x00, PERF_COUNT_HW_BRANCH_MISSES },
[6] = { 0xd0, 0x00, PERF_COUNT_HW_STALLED_CYCLES_FRONTEND },
-- 
2.7.3



Re: [PATCH V2 linux-next] hwrng: update Freescale i.MX RNGA Random Number Generator

2016-08-24 Thread Herbert Xu
On Tue, Aug 16, 2016 at 09:49:45PM +0200, Fabian Frederick wrote:
> We can directly depend on SOC_IMX31 since commit c9ee94965dce
> ("ARM: imx: deconstruct mxc_rnga initialization")
> 
> Since that commit, CONFIG_HW_RANDOM_MXC_RNGA could not be switched on
> with unknown symbol ARCH_HAS_RNGA and mxc-rnga.o can't be generated with
> ARCH=arm make M=drivers/char/hw_random
> Previously, HW_RANDOM_MXC_RNGA required ARCH_HAS_RNGA
> which was based on IMX_HAVE_PLATFORM_MXC_RNGA  && ARCH_MXC.
> IMX_HAVE_PLATFORM_MXC_RNGA  was based on SOC_IMX31.
> 
> Fixes: c9ee94965dce ("ARM: imx: deconstruct mxc_rnga initialization")
> Signed-off-by: Fabian Frederick 
> ---
> -Cc to linux-crypto (suggested by Herbert Xu)
> -Adding "Fixes:" (suggested by Arnd Bergmann)
> -This patch appeared in 4.8-rc1 (not in stable yet)
> -Improving patch description

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[tip:perf/urgent] perf/core: Use this_cpu_ptr() when stopping AUX events

2016-08-24 Thread tip-bot for Will Deacon
Commit-ID:  8b6a3fe8fab97716990a3abde1a01fb5a34552a3
Gitweb: http://git.kernel.org/tip/8b6a3fe8fab97716990a3abde1a01fb5a34552a3
Author: Will Deacon 
AuthorDate: Wed, 24 Aug 2016 10:07:14 +0100
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 15:03:10 +0200

perf/core: Use this_cpu_ptr() when stopping AUX events

When tearing down an AUX buf for an event via perf_mmap_close(),
__perf_event_output_stop() is called on the event's CPU to ensure that
trace generation is halted before the process of unmapping and
freeing the buffer pages begins.

The callback is performed via cpu_function_call(), which ensures that it
runs with interrupts disabled and is therefore not preemptible.
Unfortunately, the current code grabs the per-cpu context pointer using
get_cpu_ptr(), which unnecessarily disables preemption and doesn't pair
the call with put_cpu_ptr(), leading to a preempt_count() imbalance and
a BUG when freeing the AUX buffer later on:

  WARNING: CPU: 1 PID: 2249 at kernel/events/ring_buffer.c:539 
__rb_free_aux+0x10c/0x120
  Modules linked in:
  [...]
  Call Trace:
   [] dump_stack+0x4f/0x72
   [] __warn+0xc6/0xe0
   [] warn_slowpath_null+0x18/0x20
   [] __rb_free_aux+0x10c/0x120
   [] rb_free_aux+0x13/0x20
   [] perf_mmap_close+0x29e/0x2f0
   [] ? perf_iterate_ctx+0xe0/0xe0
   [] remove_vma+0x25/0x60
   [] exit_mmap+0x106/0x140
   [] mmput+0x1c/0xd0
   [] do_exit+0x253/0xbf0
   [] do_group_exit+0x3e/0xb0
   [] get_signal+0x249/0x640
   [] do_signal+0x23/0x640
   [] ? _raw_write_unlock_irq+0x12/0x30
   [] ? _raw_spin_unlock_irq+0x9/0x10
   [] ? __schedule+0x2c6/0x710
   [] exit_to_usermode_loop+0x74/0x90
   [] prepare_exit_to_usermode+0x26/0x30
   [] retint_user+0x8/0x10

This patch uses this_cpu_ptr() instead of get_cpu_ptr(), since preemption is
already disabled by the caller.

Signed-off-by: Will Deacon 
Reviewed-by: Alexander Shishkin 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Vince Weaver 
Fixes: 95ff4ca26c49 ("perf/core: Free AUX pages in unmap path")
Link: http://lkml.kernel.org/r/20160824091905.ga16...@arm.com
Signed-off-by: Ingo Molnar 
---
 kernel/events/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/events/core.c b/kernel/events/core.c
index 5650f53..3cfabdf 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6166,7 +6166,7 @@ static int __perf_pmu_output_stop(void *info)
 {
struct perf_event *event = info;
struct pmu *pmu = event->pmu;
-   struct perf_cpu_context *cpuctx = get_cpu_ptr(pmu->pmu_cpu_context);
+   struct perf_cpu_context *cpuctx = this_cpu_ptr(pmu->pmu_cpu_context);
struct remote_output ro = {
.rb = event->rb,
};


Re: [PATCH] hw_random: Improve description of the ->read() interface

2016-08-24 Thread Herbert Xu
On Thu, Aug 18, 2016 at 01:37:21PM +0100, Daniel Thompson wrote:
> Currently, very few RNG drivers support single byte reads using the
> ->read() interface. Of the 14 drivers in drivers/char/hw_random that
> support this interface only three of these actually support max == 1.
> The other behaviours vary between return 0, return 2, return 4 and return
> -EIO).
> 
> This is not a problem in practice because the core hw_random code never
> performs a read shorter than 16 bytes. The documentation for this function
> already contrains the alignment of the buffer pointer, so let's also
> guarantee that the buffer is at least as large as its alignment.
> 
> This constraint is intended to be the weakest guarantee neccessary to
> allow driver writers to safely simplify their code.
> 
> Signed-off-by: Daniel Thompson 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [BUGFIX, 1/2] brcmfmac: Check rtnl_lock is locked when removing interface

2016-08-24 Thread Kalle Valo
mhira...@kernel.org wrote:
> Check rtnl_lock is locked in brcmf_p2p_ifp_removed() by passing
> rtnl_locked flag. Actually the caller brcmf_del_if() checks whether
> the rtnl_lock is locked, but doesn't pass it to brcmf_p2p_ifp_removed().
> 
> Without this fix, wpa_supplicant goes softlockup with rtnl_lock
> holding (this means all other process using netlink are locked up too)
> 
> e.g.
> [ 4495.876627] INFO: task wpa_supplicant:7307 blocked for more than 10 
> seconds.
> [ 4495.876632]   Tainted: GW   4.8.0-rc1+ #8
> [ 4495.876635] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables 
> this message.
> [ 4495.876638] wpa_supplicant  D 974c647b39a0 0  7307  1 
> 0x
> [ 4495.876644]  974c647b39a0  974c 
> 974c7dc59c58
> [ 4495.876651]  974c6b7417c0 974c645017c0 974c647b4000 
> 86f16c08
> [ 4495.876657]  974c645017c0 0246  
> 974c647b39b8
> [ 4495.876664] Call Trace:
> [ 4495.876671]  [] schedule+0x3c/0x90
> [ 4495.876676]  [] schedule_preempt_disabled+0x15/0x20
> [ 4495.876682]  [] mutex_lock_nested+0x176/0x3b0
> [ 4495.876686]  [] ? rtnl_lock+0x17/0x20
> [ 4495.876690]  [] rtnl_lock+0x17/0x20
> [ 4495.876720]  [] brcmf_p2p_ifp_removed+0x4d/0x70 
> [brcmfmac]
> [ 4495.876741]  [] brcmf_remove_interface+0x196/0x1b0 
> [brcmfmac]
> [ 4495.876760]  [] brcmf_p2p_del_vif+0x111/0x220 [brcmfmac]
> [ 4495.876777]  [] brcmf_cfg80211_del_iface+0x21b/0x270 
> [brcmfmac]
> [ 4495.876820]  [] nl80211_del_interface+0xfe/0x3a0 
> [cfg80211]
> [ 4495.876825]  [] genl_family_rcv_msg+0x1b5/0x370
> [ 4495.876832]  [] ? trace_hardirqs_on+0xd/0x10
> [ 4495.876836]  [] genl_rcv_msg+0x7d/0xb0
> [ 4495.876839]  [] ? genl_family_rcv_msg+0x370/0x370
> [ 4495.876846]  [] netlink_rcv_skb+0x97/0xb0
> [ 4495.876849]  [] genl_rcv+0x28/0x40
> [ 4495.876854]  [] netlink_unicast+0x1d3/0x2f0
> [ 4495.876860]  [] ? netlink_unicast+0x14b/0x2f0
> [ 4495.876866]  [] netlink_sendmsg+0x2eb/0x3a0
> [ 4495.876870]  [] sock_sendmsg+0x38/0x50
> [ 4495.876874]  [] ___sys_sendmsg+0x27f/0x290
> [ 4495.876882]  [] ? mntput_no_expire+0x5/0x3f0
> [ 4495.876888]  [] ? mntput_no_expire+0x8e/0x3f0
> [ 4495.876894]  [] ? mntput_no_expire+0x5/0x3f0
> [ 4495.876899]  [] ? mntput+0x24/0x40
> [ 4495.876904]  [] ? __fput+0x190/0x200
> [ 4495.876909]  [] __sys_sendmsg+0x45/0x80
> [ 4495.876914]  [] SyS_sendmsg+0x12/0x20
> [ 4495.876918]  [] entry_SYSCALL_64_fastpath+0x23/0xc1
> [ 4495.876924]  [] ? trace_hardirqs_off_caller+0x1f/0xc0
> 
> Signed-off-by: Masami Hiramatsu 
> Acked-by: Rafał Miłecki 

Thanks, 2 patches applied to wireless-drivers.git:

15dacf880e49 brcmfmac: Check rtnl_lock is locked when removing interface
b64abcb7dae6 brcmfmac: Change vif_event_lock to spinlock

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9280681/



Re: [PATCH 1/3] net: fs_enet: merge NAPI RX and NAPI TX

2016-08-24 Thread Eric Dumazet
On Wed, 2016-08-24 at 06:07 -0700, Eric Dumazet wrote:

> I am afraid you could live lock here on SMP.
> 
> You should make sure you do not loop forever, not assuming cpu is faster
> than NIC.

You are protected by the tx_lock spinlock, but this is fragile as you
could very well remove this spinlock in the future to get lockless
transmit, like many other drivers.




Re: [PATCH] hw_random: omap3-rom-rng.c: Remove obsoleted functions

2016-08-24 Thread Herbert Xu
On Sat, Aug 20, 2016 at 09:31:06PM +0530, PrasannaKumar Muralidharan wrote:
> Remove omap3_rom_rng_data_present method as it was returning 1 always.
> Use .read callback instead of .data_read callback. This avoids use of
> obsolete callbacks.
> 
> This patch is not tested with hardware as I don't have access to it.
> 
> Signed-off-by: PrasannaKumar Muralidharan 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


[PATCH v3 2/5] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

2016-08-24 Thread Milo Kim
This patch enables getting a HPD GPIO descriptor quickly.
The exynos-hdmi driver uses "hpd" for HDMI hot plug detection.

static int hdmi_resources_init(struct hdmi_context *hdata)
{
...
hdata->hpd_gpio = devm_gpiod_get(dev, "hpd", GPIOD_IN);
...
}

This calls 'of_find_gpio()' and it generates the GPIO consumer ID by referring
GPIO suffix. So 'hpd-gpios' is preferred on getting a GPIO descriptor.

However, if the device tree uses 'hpd-gpio', then the exynos-hdmi driver
always retries to get a GPIO descriptor because the first GPIO suffix is not
'gpio' but 'gpios'. So you always see the debug message below.

of_get_named_gpiod_flags: can't parse 'hpd-gpios' property of node 
'/soc/hdmi@1453[0]'

Use the preferred property, 'hpd-gpios' instead of 'hpd-gpio'.

Acked-by: Rob Herring 
Reviewed-by: Andrzej Hajda 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim 
---
 Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt | 4 ++--
 arch/arm/boot/dts/exynos4210-universal_c210.dts  | 2 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi  | 2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts | 2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts| 2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi| 2 +-
 arch/arm/boot/dts/exynos5250-spring.dts  | 2 +-
 arch/arm/boot/dts/exynos5420-peach-pit.dts   | 2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts| 2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi   | 2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts| 2 +-
 11 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt 
b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
index a2ec4c1..6394ea9 100644
--- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt
@@ -9,7 +9,7 @@ Required properties:
 - reg: physical base address of the hdmi and length of memory mapped
region.
 - interrupts: interrupt number to the cpu.
-- hpd-gpio: following information about the hotplug gpio pin.
+- hpd-gpios: following information about the hotplug gpio pin.
a) phandle of the gpio controller node.
b) pin number within the gpio controller.
c) optional flags and pull up/down.
@@ -56,7 +56,7 @@ Example:
compatible = "samsung,exynos4212-hdmi";
reg = <0x1453 0x10>;
interrupts = <0 95 0>;
-   hpd-gpio = <&gpx3 7 1>;
+   hpd-gpios = <&gpx3 7 1>;
ddc = <&hdmi_ddc_node>;
phy = <&hdmi_phy_node>;
samsung,syscon-phandle = <&pmu_system_controller>;
diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts 
b/arch/arm/boot/dts/exynos4210-universal_c210.dts
index 9a75e3e..cf95202 100644
--- a/arch/arm/boot/dts/exynos4210-universal_c210.dts
+++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts
@@ -269,7 +269,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
hdmi-en-supply = <&hdmi_en>;
diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi 
b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
index 58ad48e7..be644fe 100644
--- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
+++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi
@@ -227,7 +227,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&hdmi_hpd>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-arndale.dts 
b/arch/arm/boot/dts/exynos5250-arndale.dts
index ea70603..3d981f3 100644
--- a/arch/arm/boot/dts/exynos5250-arndale.dts
+++ b/arch/arm/boot/dts/exynos5250-arndale.dts
@@ -152,7 +152,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_LOW>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_LOW>;
vdd_osc-supply = <&ldo10_reg>;
vdd_pll-supply = <&ldo8_reg>;
vdd-supply = <&ldo8_reg>;
diff --git a/arch/arm/boot/dts/exynos5250-smdk5250.dts 
b/arch/arm/boot/dts/exynos5250-smdk5250.dts
index 381af13..7f27263 100644
--- a/arch/arm/boot/dts/exynos5250-smdk5250.dts
+++ b/arch/arm/boot/dts/exynos5250-smdk5250.dts
@@ -116,7 +116,7 @@
 };
 
 &hdmi {
-   hpd-gpio = <&gpx3 7 GPIO_ACTIVE_HIGH>;
+   hpd-gpios = <&gpx3 7 GPIO_ACTIVE_HIGH>;
 };
 
 &i2c_0 {
diff --git a/arch/arm/boot/dts/exynos5250-snow-common.dtsi 
b/arch/arm/boo

Re: [PATCH] crypto: rockchip - use devm_add_action_or_reset()

2016-08-24 Thread Herbert Xu
On Tue, Aug 23, 2016 at 08:28:54PM +0530, Sudip Mukherjee wrote:
> If devm_add_action() fails we are explicitly calling the cleanup to free
> the resources allocated.  Lets use the helper devm_add_action_or_reset()
> and return directly in case of error, as we know that the cleanup function
> has been already called by the helper if there was any error.
> 
> Signed-off-by: Sudip Mukherjee 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: perf: fuzzer crashes immediately on AMD system

2016-08-24 Thread Vince Weaver
On Wed, 24 Aug 2016, Ingo Molnar wrote:
> If there's no progress finding the root cause I'd be happy to exchange a 
> crash for 
> a leak ...

It's actually a crash of the program doing the perf_event_open() call, not 
a crash of the system (at least in my experience).

However, it's possible that if you have bad luck and if the kfree'd space 
is reused with just the right combination of values you could potentially 
end up crashing the system.

Vince


[PATCH v3 3/5] gpu: drm: exynos_hdmi: Move DDC logic into single function

2016-08-24 Thread Milo Kim
Paring DT properties and getting the I2C adapter in one function.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 46 
 1 file changed, 25 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 2275efe..8d99b5d 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1760,16 +1760,34 @@ static const struct component_ops hdmi_component_ops = {
.unbind = hdmi_unbind,
 };
 
-static struct device_node *hdmi_legacy_ddc_dt_binding(struct device *dev)
+static int hdmi_get_ddc_adapter(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4210-hdmiddc";
struct device_node *np;
+   struct i2c_adapter *adpt;
 
np = of_find_compatible_node(NULL, NULL, compatible_str);
if (np)
-   return of_get_next_parent(np);
+   np = of_get_next_parent(np);
+   else
+   np = of_parse_phandle(hdata->dev->of_node, "ddc", 0);
+
+   if (!np) {
+   DRM_ERROR("Failed to find ddc node in device tree\n");
+   return -ENODEV;
+   }
 
-   return NULL;
+   adpt = of_find_i2c_adapter_by_node(np);
+   if (!adpt) {
+   DRM_ERROR("Failed to get ddc i2c adapter by node\n");
+   of_node_put(np);
+   return -EPROBE_DEFER;
+   }
+
+   hdata->ddc_adpt = adpt;
+   of_node_put(np);
+
+   return 0;
 }
 
 static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
@@ -1781,7 +1799,7 @@ static struct device_node 
*hdmi_legacy_phy_dt_binding(struct device *dev)
 
 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *ddc_node, *phy_node;
+   struct device_node *phy_node;
struct device *dev = &pdev->dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1811,23 +1829,9 @@ static int hdmi_probe(struct platform_device *pdev)
return ret;
}
 
-   ddc_node = hdmi_legacy_ddc_dt_binding(dev);
-   if (ddc_node)
-   goto out_get_ddc_adpt;
-
-   ddc_node = of_parse_phandle(dev->of_node, "ddc", 0);
-   if (!ddc_node) {
-   DRM_ERROR("Failed to find ddc node in device tree\n");
-   return -ENODEV;
-   }
-   of_node_put(dev->of_node);
-
-out_get_ddc_adpt:
-   hdata->ddc_adpt = of_find_i2c_adapter_by_node(ddc_node);
-   if (!hdata->ddc_adpt) {
-   DRM_ERROR("Failed to get ddc i2c adapter by node\n");
-   return -EPROBE_DEFER;
-   }
+   ret = hdmi_get_ddc_adapter(hdata);
+   if (ret)
+   return ret;
 
phy_node = hdmi_legacy_phy_dt_binding(dev);
if (phy_node)
-- 
1.9.1



[PATCH v3 1/5] ARM: dts: exynos: Enable HDMI for Arndale Octa board

2016-08-24 Thread Milo Kim
* GPIO for HDMI hot plug detect
  GPX3_7 is used. The HPD awareness is done when the GPIO is active high and
  single ended.

* Enable HDMI block in Exynos5420
  HDMI VDD and PLL consume 1.0V LDO6 (PVDD_ANAIP_1V0) and HDMI oscillator
  requires 1.8V LDO7 (PVDD_ANAIP_1V8).

* Support HDMI display data channel
  I2C #2 is assigned for the HDMI DDC. It enables the EDID access.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Rob Herring 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Milo Kim 
---
 arch/arm/boot/dts/exynos5420-arndale-octa.dts | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420-arndale-octa.dts 
b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
index 39a3b81..2fb5708 100644
--- a/arch/arm/boot/dts/exynos5420-arndale-octa.dts
+++ b/arch/arm/boot/dts/exynos5420-arndale-octa.dts
@@ -70,6 +70,19 @@
status = "disabled";
 };
 
+&hdmi {
+   hpd-gpios = <&gpx3 7 GPIO_OPEN_SOURCE>;
+   vdd_osc-supply = <&ldo7_reg>;
+   vdd_pll-supply = <&ldo6_reg>;
+   vdd-supply = <&ldo6_reg>;
+   ddc = <&i2c_2>;
+   status = "okay";
+};
+
+&i2c_2 {
+   status = "okay";
+};
+
 &hsi2c_4 {
status = "okay";
 
-- 
1.9.1



Re: [PATCH 8/8] arm64: Work around systems with mismatched cache line sizes

2016-08-24 Thread Suzuki K Poulose

On 22/08/16 14:02, Will Deacon wrote:

On Thu, Aug 18, 2016 at 02:10:32PM +0100, Suzuki K Poulose wrote:

Systems with differing CPU i-cache/d-cache line sizes can cause
problems with the cache management by software when the execution
is migrated from one to another. Usually, the application reads
the cache size on a CPU and then uses that length to perform cache
operations. However, if it gets migrated to another CPU with a smaller
cache line size, things could go completely wrong. To prevent such
cases, always use the smallest cache line size among the CPUs. The
kernel CPU feature infrastructure already keeps track of the safe
value for all CPUID registers including CTR. This patch works around
the problem by :

For kernel, dynamically patch the kernel to read the cache size
from the system wide copy of CTR_EL0.


Is it only CTR that is mismatched in practice, or do we need to worry
about DCZID_EL0 too?


A mismatched DCZID_EL0 is quite possible. However, there is no way to
trap accesses to DCZID_EL0. Rather, we can trap DC ZVA if we clear
SCTLR_EL1.DZE. But then clearing the SCTLR_EL1.DZE implies reading DCZID.DZP
returns 1, indicating DC ZVA is not supported. So if a proper application
checks the DZP before issuing a DC ZVA, we may never be able to emulate it.
Or in other words, if there is a mismatch, the work around is to disable
the DC ZVA operations (which could possibly affect existing (incorrect) 
userspace
applications assuming DC ZVA is supported without checking the DZP bit).
 

 static void update_cpu_ftr_reg(struct arm64_ftr_reg *reg, u64 new)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 93c5287..db2d6cb 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -480,6 +480,14 @@ static void user_cache_maint_handler(unsigned int esr, 
struct pt_regs *regs)
regs->pc += 4;
 }

+static void ctr_read_handler(unsigned int esr, struct pt_regs *regs)
+{
+   int rt = (esr & ESR_ELx_SYS64_ISS_RT_MASK) >> 
ESR_ELx_SYS64_ISS_RT_SHIFT;
+
+   regs->regs[rt] = sys_ctr_ftr->sys_val;
+   regs->pc += 4;
+}


Whilst this is correct, I wonder if there's any advantage in reporting a
*larger* size to userspace and avoid incurring additional trap overhead?


Combining the trapping of user space dc operations for Errata work around for
clean cache, we could possibly report a larger size and emulate it properly
in the kernel. But I think that can be a enhancement on top of this series.



Any idea what sort of size typical JITs are using?


I have no clue about it. I have Cc-ed Rodolph and Stuart, who may have better
idea about the JIT's usage.

Suzuki



[PATCH v3 5/5] gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator bulk consumer

2016-08-24 Thread Milo Kim
The helper, devm_regulator_bulk_get() initializes the consumer as NULL,
so this code can be ignored.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 249cb23..4e17877f 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1669,10 +1669,9 @@ static int hdmi_resources_init(struct hdmi_context 
*hdata)
if (ret)
return ret;
 
-   for (i = 0; i < ARRAY_SIZE(supply); ++i) {
+   for (i = 0; i < ARRAY_SIZE(supply); ++i)
hdata->regul_bulk[i].supply = supply[i];
-   hdata->regul_bulk[i].consumer = NULL;
-   }
+
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(supply), 
hdata->regul_bulk);
if (ret) {
if (ret != -EPROBE_DEFER)
-- 
1.9.1



[PATCH v3 4/5] gpu: drm: exynos_hdmi: Move PHY logic into single function

2016-08-24 Thread Milo Kim
Paring DT properties and getting PHY IO (memory mapped or I2C) in one function.

Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: David Airlie 
Cc: Inki Dae 
Cc: Joonyoung Shim 
Cc: Seung-Woo Kim 
Cc: Kyungmin Park 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Milo Kim 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c | 63 +++-
 1 file changed, 33 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 8d99b5d..249cb23 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1790,16 +1790,44 @@ static int hdmi_get_ddc_adapter(struct hdmi_context 
*hdata)
return 0;
 }
 
-static struct device_node *hdmi_legacy_phy_dt_binding(struct device *dev)
+static int hdmi_get_phy_io(struct hdmi_context *hdata)
 {
const char *compatible_str = "samsung,exynos4212-hdmiphy";
+   struct device_node *np;
+   int ret = 0;
+
+   np = of_find_compatible_node(NULL, NULL, compatible_str);
+   if (!np) {
+   np = of_parse_phandle(hdata->dev->of_node, "phy", 0);
+   if (!np) {
+   DRM_ERROR("Failed to find hdmiphy node in device 
tree\n");
+   return -ENODEV;
+   }
+   }
+
+   if (hdata->drv_data->is_apb_phy) {
+   hdata->regs_hdmiphy = of_iomap(np, 0);
+   if (!hdata->regs_hdmiphy) {
+   DRM_ERROR("failed to ioremap hdmi phy\n");
+   ret = -ENOMEM;
+   goto out;
+   }
+   } else {
+   hdata->hdmiphy_port = of_find_i2c_device_by_node(np);
+   if (!hdata->hdmiphy_port) {
+   DRM_ERROR("Failed to get hdmi phy i2c client\n");
+   ret = -EPROBE_DEFER;
+   goto out;
+   }
+   }
 
-   return of_find_compatible_node(NULL, NULL, compatible_str);
+out:
+   of_node_put(np);
+   return ret;
 }
 
 static int hdmi_probe(struct platform_device *pdev)
 {
-   struct device_node *phy_node;
struct device *dev = &pdev->dev;
struct hdmi_context *hdata;
struct resource *res;
@@ -1833,34 +1861,9 @@ static int hdmi_probe(struct platform_device *pdev)
if (ret)
return ret;
 
-   phy_node = hdmi_legacy_phy_dt_binding(dev);
-   if (phy_node)
-   goto out_get_phy_port;
-
-   phy_node = of_parse_phandle(dev->of_node, "phy", 0);
-   if (!phy_node) {
-   DRM_ERROR("Failed to find hdmiphy node in device tree\n");
-   ret = -ENODEV;
+   ret = hdmi_get_phy_io(hdata);
+   if (ret)
goto err_ddc;
-   }
-   of_node_put(dev->of_node);
-
-out_get_phy_port:
-   if (hdata->drv_data->is_apb_phy) {
-   hdata->regs_hdmiphy = of_iomap(phy_node, 0);
-   if (!hdata->regs_hdmiphy) {
-   DRM_ERROR("failed to ioremap hdmi phy\n");
-   ret = -ENOMEM;
-   goto err_ddc;
-   }
-   } else {
-   hdata->hdmiphy_port = of_find_i2c_device_by_node(phy_node);
-   if (!hdata->hdmiphy_port) {
-   DRM_ERROR("Failed to get hdmi phy i2c client\n");
-   ret = -EPROBE_DEFER;
-   goto err_ddc;
-   }
-   }
 
INIT_DELAYED_WORK(&hdata->hotplug_work, hdmi_hotplug_work_func);
 
-- 
1.9.1



Re: [PATCH v3] pwm: sun4i: fix a possible NULL dereference

2016-08-24 Thread Thierry Reding
On Wed, Aug 24, 2016 at 01:43:58PM +0200, LABBE Corentin wrote:
> of_match_device could return NULL, and so cause a NULL pointer
> dereference later.
> 
> For fixing this problem, we use of_device_get_match_data(), this will
> simplify the code a little by using a standard function for
> getting the match data.
> 
> Testing the return value of of_device_get_match_data is also necessary
> for avoiding a second NULL deref on pwm->data.
> 
> Reported-by: coverity (CID 1324139)
> Signed-off-by: LABBE Corentin 
> ---
> Changes since v2:
>  - Add a test on pwm->data for avoiding a second NULL deref.
> Changes since v1:
>  - Use of_device_get_match_data()
> 
>  drivers/pwm/pwm-sun4i.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..fb76c55 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -309,9 +309,6 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>   struct resource *res;
>   u32 val;
>   int i, ret;
> - const struct of_device_id *match;
> -
> - match = of_match_device(sun4i_pwm_dt_ids, &pdev->dev);
>  
>   pwm = devm_kzalloc(&pdev->dev, sizeof(*pwm), GFP_KERNEL);
>   if (!pwm)
> @@ -326,7 +323,9 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
>   if (IS_ERR(pwm->clk))
>   return PTR_ERR(pwm->clk);
>  
> - pwm->data = match->data;
> + pwm->data = of_device_get_match_data(&pdev->dev);
> + if (!pwm->data)
> + return -EINVAL;

I don't see how this would ever be NULL. You'd have to add an entry to
the table that has a NULL data field, which is very unlikely to happen.
If you really want to check for this, which I think isn't necessary,
please wrap this in a WARN_ON() or something to make more noise when
this completely unexpected case happens.

Thierry


signature.asc
Description: PGP signature


[PATCH 01/10] reset: ath79: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Alban Bedel 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 7 +++
 drivers/reset/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 7dfe8d8..9da0507 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -14,6 +14,13 @@ menuconfig RESET_CONTROLLER
 
 if RESET_CONTROLLER
 
+config RESET_ATH79
+   bool "AR71xx Reset Driver" if COMPILE_TEST
+   default ATH79
+   help
+ This enables the ATH79 reset controller driver that supports the
+ AR71xx SoC reset controller.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 9b45dcf..e3fc337 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -9,7 +9,7 @@ obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
-obj-$(CONFIG_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH 04/10] reset: meson: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Neil Armstrong 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 8e33de2..fdf942d 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -34,6 +34,12 @@ config RESET_LPC18XX
  This enables the LPC18xx/43 reset driver that supports the reset
  controllers on AR71xx SoCs.
 
+config RESET_MESON
+   bool "Meson Reset Driver" if COMPILE_TEST
+   default ARCH_MESON
+   help
+ This enables the reset driver for Amlogic Meson SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 25aa05a..1408cba 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
-obj-$(CONFIG_ARCH_MESON) += reset-meson.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
+obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH 07/10] reset: stm32: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Maxime Coquelin 
Cc: Gabriel Fernandez 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 354e281..3a54a66 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -55,6 +55,12 @@ config RESET_SOCFPGA
help
  This enables the reset driver for Altera SoC FPGAs.
 
+config RESET_STM32
+   bool "STM32 Reset Driver" if COMPILE_TEST
+   default ARCH_STM32
+   help
+ This enables the RCC reset controller driver for STM32 MCUs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 61e4c64..6276f82 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
+obj-$(CONFIG_RESET_STM32) += reset-stm32.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH 09/10] reset: zynq: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Moritz Fischer 
Cc: Michal Simek 
Cc: Sören Brinkmann 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 17030e2..86b49a2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -67,6 +67,12 @@ config RESET_SUNXI
help
  This enables the reset driver for Allwinner SoCs.
 
+config RESET_ZYNQ
+   bool "ZYNQ Reset Driver" if COMPILE_TEST
+   default ARCH_ZYNQ
+   help
+ This enables the reset driver for Xilinx Zynq FPGAs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 4a163c7..56f90ea 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
-obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
@@ -13,3 +12,4 @@ obj-$(CONFIG_RESET_STM32) += reset-stm32.o
 obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
+obj-$(CONFIG_RESET_ZYNQ) += reset-zynq.o
-- 
2.8.1



[PATCH 10/10] reset: hi6220: allow to compile test driver on other architectures

2016-08-24 Thread Philipp Zabel
Also remove the RESET_CONTROLLER dependency, this Kconfig file is
included inside the menuconfig already.

Cc: Chen Feng 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/hisilicon/Kconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/hisilicon/Kconfig b/drivers/reset/hisilicon/Kconfig
index 26bf95a..1ff8b0c 100644
--- a/drivers/reset/hisilicon/Kconfig
+++ b/drivers/reset/hisilicon/Kconfig
@@ -1,5 +1,6 @@
 config COMMON_RESET_HI6220
tristate "Hi6220 Reset Driver"
-   depends on (ARCH_HISI && RESET_CONTROLLER)
+   depends on ARCH_HISI || COMPILE_TEST
+   default ARCH_HISI
help
  Build the Hisilicon Hi6220 reset driver.
-- 
2.8.1



[PATCH v3 0/5] ARM: dts: exynos: Enable HDMI in Arndale Octa board

2016-08-24 Thread Milo Kim
This patch-set enables HDMI in Arndale Octa board and fixes HPD DT property.
It also includes code refactoring on ddc and phy.

v3:
  Add 'vdd-supply' property in dts.
  Use generic 'ddc' property instead of legacy property.
  Clean up DDC and PHY logic in _probe().
  Remove duplicate code of regulator consumer initialization.

v2:
  Include DRM and Exynos maintainers and resend the patch-set.
  Add Rob's ack for the patch,
[PATCH 2/4] ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'

Milo Kim (5):
  ARM: dts: exynos: Enable HDMI for Arndale Octa board
  ARM: dts: exynos: Use 'hpd-gpios' instead of 'hpd-gpio'
  gpu: drm: exynos_hdmi: Move DDC logic into single function
  gpu: drm: exynos_hdmi: Move PHY logic into single function
  gpu: drm: exynos_hdmi: Remove duplicate initialization of regulator
bulk consumer

 .../bindings/display/exynos/exynos_hdmi.txt|   4 +-
 arch/arm/boot/dts/exynos4210-universal_c210.dts|   2 +-
 arch/arm/boot/dts/exynos4412-odroid-common.dtsi|   2 +-
 arch/arm/boot/dts/exynos5250-arndale.dts   |   2 +-
 arch/arm/boot/dts/exynos5250-smdk5250.dts  |   2 +-
 arch/arm/boot/dts/exynos5250-snow-common.dtsi  |   2 +-
 arch/arm/boot/dts/exynos5250-spring.dts|   2 +-
 arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  13 +++
 arch/arm/boot/dts/exynos5420-peach-pit.dts |   2 +-
 arch/arm/boot/dts/exynos5420-smdk5420.dts  |   2 +-
 arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |   2 +-
 arch/arm/boot/dts/exynos5800-peach-pi.dts  |   2 +-
 drivers/gpu/drm/exynos/exynos_hdmi.c   | 112 +++--
 13 files changed, 84 insertions(+), 65 deletions(-)

-- 
1.9.1



[PATCH 02/10] reset: berlin: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Antoine Tenart 
Cc: Sebastian Hesselbarth 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 9da0507..1194cbe 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -21,6 +21,12 @@ config RESET_ATH79
  This enables the ATH79 reset controller driver that supports the
  AR71xx SoC reset controller.
 
+config RESET_BERLIN
+   bool "Berlin Reset Driver" if COMPILE_TEST
+   default ARCH_BERLIN
+   help
+ This enables the reset controller driver for Marvell Berlin SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index e3fc337..34c0b23 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,7 +1,6 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_ARCH_BERLIN) += reset-berlin.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_ARCH_MESON) += reset-meson.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
+obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH 06/10] reset: socfpga: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Dinh Nguyen 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 6ac631e..354e281 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -49,6 +49,12 @@ config RESET_PISTACHIO
help
  This enables the reset driver for ImgTec Pistachio SoCs.
 
+config RESET_SOCFPGA
+   bool "SoC FPGA Reset Driver" if COMPILE_TEST
+   default ARCH_SOCFPGA
+   help
+ This enables the reset driver for Altera SoC FPGAs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index c796a14..61e4c64 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
+obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH 03/10] reset: lpc18xx: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Joachim Eastwood 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 7 +++
 drivers/reset/Makefile | 2 +-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 1194cbe..8e33de2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -27,6 +27,13 @@ config RESET_BERLIN
help
  This enables the reset controller driver for Marvell Berlin SoCs.
 
+config RESET_LPC18XX
+   bool "LPC18xx/43xx Reset Driver" if COMPILE_TEST
+   default ARCH_LPC18XX
+   help
+ This enables the LPC18xx/43 reset driver that supports the reset
+ controllers on AR71xx SoCs.
+
 config RESET_OXNAS
bool
 
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 34c0b23..25aa05a 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_ARCH_MESON) += reset-meson.o
@@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
 obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
 obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
+obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH 08/10] reset: sunxi: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index 3a54a66..17030e2 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -61,6 +61,12 @@ config RESET_STM32
help
  This enables the RCC reset controller driver for STM32 MCUs.
 
+config RESET_SUNXI
+   bool "Allwinner SoCs Reset Driver" if COMPILE_TEST
+   default ARCH_SUNXI
+   help
+ This enables the reset driver for Allwinner SoCs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 6276f82..4a163c7 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,5 +1,4 @@
 obj-y += core.o
-obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
 obj-$(CONFIG_ARCH_HISI) += hisilicon/
 obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
 obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
 obj-$(CONFIG_RESET_STM32) += reset-stm32.o
+obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



[PATCH] reset: ath79: add missing include

2016-08-24 Thread Philipp Zabel
The driver uses readl/writel, so it should include linux/io.h.

Signed-off-by: Philipp Zabel 
---
 drivers/reset/reset-ath79.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/reset/reset-ath79.c b/drivers/reset/reset-ath79.c
index 16d410c..6b97631 100644
--- a/drivers/reset/reset-ath79.c
+++ b/drivers/reset/reset-ath79.c
@@ -12,6 +12,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
-- 
2.8.1



[PATCH 05/10] reset: pistachio: add driver Kconfig option

2016-08-24 Thread Philipp Zabel
Visible only if COMPILE_TEST is enabled, this allows to include the
driver in build tests.

Cc: Damien Horsley 
Cc: James Hartley 
Signed-off-by: Philipp Zabel 
---
 drivers/reset/Kconfig  | 6 ++
 drivers/reset/Makefile | 2 +-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
index fdf942d..6ac631e 100644
--- a/drivers/reset/Kconfig
+++ b/drivers/reset/Kconfig
@@ -43,6 +43,12 @@ config RESET_MESON
 config RESET_OXNAS
bool
 
+config RESET_PISTACHIO
+   bool "Pistachio Reset Driver" if COMPILE_TEST
+   default MACH_PISTACHIO
+   help
+ This enables the reset driver for ImgTec Pistachio SoCs.
+
 config TI_SYSCON_RESET
tristate "TI SYSCON Reset Driver"
depends on HAS_IOMEM
diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
index 1408cba..c796a14 100644
--- a/drivers/reset/Makefile
+++ b/drivers/reset/Makefile
@@ -1,6 +1,5 @@
 obj-y += core.o
 obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
-obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
 obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
 obj-$(CONFIG_ARCH_STI) += sti/
@@ -11,5 +10,6 @@ obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
 obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
 obj-$(CONFIG_RESET_MESON) += reset-meson.o
 obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
+obj-$(CONFIG_RESET_PISTACHIO) += reset-pistachio.o
 obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
 obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
-- 
2.8.1



Re: [PATCH 04/10] reset: meson: add driver Kconfig option

2016-08-24 Thread Neil Armstrong
On 08/24/2016 03:28 PM, Philipp Zabel wrote:
> Visible only if COMPILE_TEST is enabled, this allows to include the
> driver in build tests.
> 
> Cc: Neil Armstrong 
> Signed-off-by: Philipp Zabel 
> ---
>  drivers/reset/Kconfig  | 6 ++
>  drivers/reset/Makefile | 2 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 8e33de2..fdf942d 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -34,6 +34,12 @@ config RESET_LPC18XX
> This enables the LPC18xx/43 reset driver that supports the reset
> controllers on AR71xx SoCs.
>  
> +config RESET_MESON
> + bool "Meson Reset Driver" if COMPILE_TEST
> + default ARCH_MESON
> + help
> +   This enables the reset driver for Amlogic Meson SoCs.
> +
>  config RESET_OXNAS
>   bool
>  
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 25aa05a..1408cba 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -1,7 +1,6 @@
>  obj-y += core.o
>  obj-$(CONFIG_ARCH_SOCFPGA) += reset-socfpga.o
>  obj-$(CONFIG_MACH_PISTACHIO) += reset-pistachio.o
> -obj-$(CONFIG_ARCH_MESON) += reset-meson.o
>  obj-$(CONFIG_ARCH_STM32) += reset-stm32.o
>  obj-$(CONFIG_ARCH_SUNXI) += reset-sunxi.o
>  obj-$(CONFIG_ARCH_STI) += sti/
> @@ -10,6 +9,7 @@ obj-$(CONFIG_ARCH_ZYNQ) += reset-zynq.o
>  obj-$(CONFIG_RESET_ATH79) += reset-ath79.o
>  obj-$(CONFIG_RESET_BERLIN) += reset-berlin.o
>  obj-$(CONFIG_RESET_LPC18XX) += reset-lpc18xx.o
> +obj-$(CONFIG_RESET_MESON) += reset-meson.o
>  obj-$(CONFIG_RESET_OXNAS) += reset-oxnas.o
>  obj-$(CONFIG_TI_SYSCON_RESET) += reset-ti-syscon.o
>  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
> 


Acked-by: Neil Armstrong 


Re: [PATCH 2/2] reset: uniphier: use of_device_get_match_data() to get matched data

2016-08-24 Thread Philipp Zabel
Am Mittwoch, den 24.08.2016, 21:29 +0900 schrieb Masahiro Yamada:
[...]
> >> @@ -285,6 +286,45 @@ static const struct reset_control_ops 
> >> uniphier_reset_ops = {
> >>   .status = uniphier_reset_status,
> >>  };
> >>
> >> +static int uniphier_reset_probe(struct platform_device *pdev)
> >> +{
> >> + struct device *dev = &pdev->dev;
> >> + struct uniphier_reset_priv *priv;
> >> + const struct uniphier_reset_data *p, *data;
> >> + struct regmap *regmap;
> >> + struct device_node *parent;
> >> + unsigned int nr_resets = 0;
> >> +
> >> + data = of_device_get_match_data(dev);
> >> + WARN_ON(!data);
> >
> > I know right now this can't happen anyway, but you did return -EINVAL
> > here before. Maybe use:
> >
> > if (WARN_ON(!data))
> > return -EINVAL;
> >
> > instead? I can fix it up if you agree.
> 
> I agree.
> 
> Please fix it up.  Thanks!

Ok, done.

regards
Philipp



Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

2016-08-24 Thread Jani Nikula
On Wed, 24 Aug 2016, Stephen Rothwell  wrote:
> Hi all,
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
>   drivers/gpu/drm/i915/intel_display.c
>
> between commits from the drm-intel-fixes tree (some of which are
> cherry-picked from the drm-intel tree) and teh same and other commits
> from the drm-inte tree.  These are just going to cause new conflicts
> every time you touch this file again in either tree (which happens a
> lot :-().
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider only putting
> the fix patches into the drm-intel-fixes tree and then getting them
> into the drm-intel tree by merging the -fixes tree instead of
> cherry-picking them the other way.

We used to do that, but switched to the current model instead. The main
reason was that we wanted our development branch to always get the fixes
first, without delay. We have several committers, and we want to make it
efficient and hassle free for them to get fixes applied.

The drm-intel tree is a fast moving target. If we fix something in
-fixes, there's no guarantee the fix applies to -next. It is more
important that we get the fix in -next, and all future kernels. If the
fix is important for current and stable kernels, we can do the
backport. This way, we can always resolve conflicts with the code in
-next, and be sure it contains all the fixes. If only -fixes had the
fixes, we'd have nightmare conflict resolutions trying to ensure none of
the fixes get dropped while merging.

Finally, you don't always know in advance whether the patch should be
applied to -next or -fixes. We'd end up with cherry-picks like this
anyway. Now we can do QA on the fixes in -next, and choose the ones to
backport.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center


Re: [PATCH 4.7 146/186] floppy: fix open(O_ACCMODE) for ioctl-only open

2016-08-24 Thread Mark Hounschell

On 08/18/2016 09:59 AM, Greg Kroah-Hartman wrote:

4.7-stable review patch.  If anyone has any objections, please let me know.

--

From: Jiri Kosina 

commit ff06db1efb2ad6db06eb5b99b88a0c15a9cc9b0e upstream.

Commit 09954bad4 ("floppy: refactor open() flags handling"), as a
side-effect, causes open(/dev/fdX, O_ACCMODE) to fail. It turns out that
this is being used setfdprm userspace for ioctl-only open().

Reintroduce back the original behavior wrt !(FMODE_READ|FMODE_WRITE)
modes, while still keeping the original O_NDELAY bug fixed.

Reported-by: Wim Osterholt 
Tested-by: Wim Osterholt 
Signed-off-by: Jiri Kosina 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/block/floppy.c |   21 +
 1 file changed, 9 insertions(+), 12 deletions(-)

--- a/drivers/block/floppy.c
+++ b/drivers/block/floppy.c
@@ -3663,11 +3663,6 @@ static int floppy_open(struct block_devi

opened_bdev[drive] = bdev;

-   if (!(mode & (FMODE_READ|FMODE_WRITE))) {
-   res = -EINVAL;
-   goto out;
-   }
-
res = -ENXIO;

if (!floppy_track_buffer) {
@@ -3711,13 +3706,15 @@ static int floppy_open(struct block_devi
if (UFDCS->rawcmd == 1)
UFDCS->rawcmd = 2;

-   UDRS->last_checked = 0;
-   clear_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags);
-   check_disk_change(bdev);
-   if (test_bit(FD_DISK_CHANGED_BIT, &UDRS->flags))
-   goto out;
-   if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags))
-   goto out;
+   if (mode & (FMODE_READ|FMODE_WRITE)) {
+   UDRS->last_checked = 0;
+   clear_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags);
+   check_disk_change(bdev);
+   if (test_bit(FD_DISK_CHANGED_BIT, &UDRS->flags))
+   goto out;
+   if (test_bit(FD_OPEN_SHOULD_FAIL_BIT, &UDRS->flags))
+   goto out;
+   }

res = -EROFS;






I have a problem with this patch. It only fixes one of the regressions 
caused by the original change to the floppy driver. It does not address 
the user land breakage of removing the NODELAY flag checks.


Thanks
Mark


[PATCH] reset: warn on invalid input to reset_control_reset/assert/deassert/status

2016-08-24 Thread Philipp Zabel
Instead of potentially crashing, dump a backtrace and return -EINVAL if
rstc is NULL or an error code.

Signed-off-by: Philipp Zabel 
---
 drivers/reset/core.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/reset/core.c b/drivers/reset/core.c
index 395dc9c..b8ae1db 100644
--- a/drivers/reset/core.c
+++ b/drivers/reset/core.c
@@ -138,7 +138,8 @@ EXPORT_SYMBOL_GPL(devm_reset_controller_register);
  */
 int reset_control_reset(struct reset_control *rstc)
 {
-   if (WARN_ON(rstc->shared))
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)) ||
+   WARN_ON(rstc->shared))
return -EINVAL;
 
if (rstc->rcdev->ops->reset)
@@ -161,6 +162,9 @@ EXPORT_SYMBOL_GPL(reset_control_reset);
  */
 int reset_control_assert(struct reset_control *rstc)
 {
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)))
+   return -EINVAL;
+
if (!rstc->rcdev->ops->assert)
return -ENOTSUPP;
 
@@ -184,6 +188,9 @@ EXPORT_SYMBOL_GPL(reset_control_assert);
  */
 int reset_control_deassert(struct reset_control *rstc)
 {
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)))
+   return -EINVAL;
+
if (!rstc->rcdev->ops->deassert)
return -ENOTSUPP;
 
@@ -204,6 +211,9 @@ EXPORT_SYMBOL_GPL(reset_control_deassert);
  */
 int reset_control_status(struct reset_control *rstc)
 {
+   if (WARN_ON(IS_ERR_OR_NULL(rstc)))
+   return -EINVAL;
+
if (rstc->rcdev->ops->status)
return rstc->rcdev->ops->status(rstc->rcdev, rstc->id);
 
-- 
2.8.1



[PATCH] arm64: dts: hikey: extend default cma size to 128MB

2016-08-24 Thread Guodong Xu
To support display in Debian on HiKey, cma heap is used to allocate
graphic buffers. The default size of CMA is 16 MB which is not enought.

Increase the default CMA size to 128 MB.

cc: Rob Herring 
cc: Fathi Boudra 
cc: John Stultz 
cc: Xinliang Liu 
Signed-off-by: Guodong Xu 
---
 arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts 
b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
index 4a51058..abb3434 100644
--- a/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
+++ b/arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts
@@ -45,6 +45,20 @@
  <0x 0x2200 0x 0x1c00>;
};
 
+   reserved-memory {
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+
+   /* global autoconfigured region for contiguous allocations */
+   linux,cma {
+   compatible = "shared-dma-pool";
+   reusable;
+   size = <0x 0x0800>;
+   linux,cma-default;
+   };
+   };
+
pstore: pstore@0x21f0 {
no-map;
reg = <0x0 0x21f0 0x0 0x0010>;  /* pstore/ramoops 
buffer */
-- 
1.9.1



[PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

Document the devicetree bindings for the Generic Memory Interface (GMI)
bus driver found on Tegra SOCs.

Signed-off-by: Mirza Krak 
---
Changes in v2:
- Updated examples and some information based on comments from Jon Hunter.

 .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 +
 1 file changed, 132 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt

diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt 
b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
new file mode 100644
index 000..8c1e15f
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
@@ -0,0 +1,132 @@
+Device tree bindings for NVIDIA Tegra Generic Memory Interface bus
+
+The Generic Memory Interface bus enables memory transfers between internal and
+external memory. Can be used to attach various high speed devices such as
+synchronous/asynchronous NOR, FPGA, UARTS and more.
+
+The actual devices are instantiated from the child nodes of a GMI node.
+
+Required properties:
+ - compatible : Should contain one of the following:
+For Tegra20 must contain "nvidia,tegra20-gmi".
+For Tegra30 must contain "nvidia,tegra30-gmi".
+ - reg: Should contain GMI controller registers location and length.
+ - clocks: Must contain an entry for each entry in clock-names.
+ - clock-names: Must include the following entries: "gmi"
+ - resets : Must contain an entry for each entry in reset-names.
+ - reset-names : Must include the following entries: "gmi"
+ - #address-cells: The number of cells used to represent physical base
+   addresses in the GMI address space. Should be 1.
+ - #size-cells: The number of cells used to represent the size of an address
+   range in the GMI address space. Should be 1.
+ - ranges: Must be set up to reflect the memory layout with three integer 
values
+   for each chip-select line in use (only one entry is supported, see below
+   comments):
+ 
+
+Note that the GMI controller does not have any internal chip-select address
+decoding, because of that chip-selects either need to be managed via software
+or by employing external chip-select decoding logic.
+
+If external chip-select logic is used to support multiple devices it is assumed
+that the devices use the same timing and so are probably the same type. It also
+assumes that they can fit in the 256MB address range. In this case only one
+child device is supported which represents the active chip-select line, see
+examples for more insight.
+
+Required child cs node properties:
+ - reg: First entry should contain the active chip-select number
+
+Optional child cs node properties:
+
+ - nvidia,snor-data-width-32bit: Use 32bit data-bus, default is 16bit.
+ - nvidia,snor-mux-mode: Enable address/data MUX mode.
+ - nvidia,snor-rdy-active-before-data: Assert RDY signal one cycle before data.
+   If omitted it will be asserted with data.
+ - nvidia,snor-rdy-inv: RDY signal is active high
+ - nvidia,snor-adv-inv: ADV signal is active high
+ - nvidia,snor-oe-inv: WE/OE signal is active high
+ - nvidia,snor-cs-inv: CS signal is active high
+
+  Note that there is some special handling for the timing values.
+  From Tegra TRM:
+  Programming 0 means 1 clock cycle: actual cycle = programmed cycle + 1
+
+ - nvidia,snor-muxed-width: Number of cycles MUX address/data asserted on the
+   bus. Valid values are 0-15, default is 1
+ - nvidia,snor-hold-width: Number of cycles CE stays asserted after the
+   de-assertion of WR_N (in case of SLAVE/MASTER Request) or OE_N
+   (in case of MASTER Request). Valid values are 0-15, default is 1
+ - nvidia,snor-adv-width: Number of cycles during which ADV stays asserted.
+   Valid values are 0-15, default is 1.
+ - nvidia,snor-ce-width: Number of cycles before CE is asserted.
+   Valid values are 0-15, default is 4
+ - nvidia,snor-we-width: Number of cycles during which WE stays asserted.
+   Valid values are 0-15, default is 1
+ - nvidia,snor-oe-width: Number of cycles during which OE stays asserted.
+   Valid values are 0-255, default is 1
+ - nvidia,snor-wait-width: Number of cycles before READY is asserted.
+   Valid values are 0-255, default is 3
+
+Example with two SJA1000 CAN controllers connected to the GMI bus. We wrap the
+controllers with a simple-bus node since they are all connected to the same
+chip-select (CS4), in this example external address decoding is provided:
+
+gmi@7009 {
+   compatible = "nvidia,tegra20-gmi";
+   reg = <0x70009000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = <&tegra_car TEGRA20_CLK_NOR>;
+   clock-names = "gmi";
+   resets = <&tegra_car 42>;
+   reset-names = "gmi";
+   ranges = <4 0x4800 0x7ff>;
+
+   status = "disabled";
+
+   bus@4 {
+   compatible = "simple-bus";
+   reg = <4>;
+   #address-cells = <1>;
+   #size-cells 

[PATCH v2 6/6] bus: Add support for Tegra Generic Memory Interface

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

The Generic Memory Interface bus can be used to connect high-speed
devices such as NOR flash, FPGAs, DSPs...

Signed-off-by: Mirza Krak 
---
Changes in v2:
- Fixed some checkpatch errors
- Re-ordered probe to get rid of local variables
- Moved of_platform_default_populate call to the end of probe
- Use the timing and configuration properties from the child device
- Added warning if more then 1 child device exist


 drivers/bus/Kconfig |   8 ++
 drivers/bus/Makefile|   1 +
 drivers/bus/tegra-gmi.c | 231 
 3 files changed, 240 insertions(+)
 create mode 100644 drivers/bus/tegra-gmi.c

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 4ed7d26..2e75a7f 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -141,6 +141,14 @@ config TEGRA_ACONNECT
  Driver for the Tegra ACONNECT bus which is used to interface with
  the devices inside the Audio Processing Engine (APE) for Tegra210.

+config TEGRA_GMI
+   tristate "Tegra Generic Memory Interface bus driver"
+   depends on ARCH_TEGRA
+   help
+ Driver for the Tegra Generic Memory Interface bus which can be used
+ to attach devices such as NOR, UART, FPGA and more.
+
+
 config UNIPHIER_SYSTEM_BUS
tristate "UniPhier System Bus driver"
depends on ARCH_UNIPHIER && OF
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index ac84cc4..34e2bab 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -18,5 +18,6 @@ obj-$(CONFIG_OMAP_OCP2SCP)+= omap-ocp2scp.o
 obj-$(CONFIG_SUNXI_RSB)+= sunxi-rsb.o
 obj-$(CONFIG_SIMPLE_PM_BUS)+= simple-pm-bus.o
 obj-$(CONFIG_TEGRA_ACONNECT)   += tegra-aconnect.o
+obj-$(CONFIG_TEGRA_GMI)+= tegra-gmi.o
 obj-$(CONFIG_UNIPHIER_SYSTEM_BUS)  += uniphier-system-bus.o
 obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o
diff --git a/drivers/bus/tegra-gmi.c b/drivers/bus/tegra-gmi.c
new file mode 100644
index 000..b068ef9
--- /dev/null
+++ b/drivers/bus/tegra-gmi.c
@@ -0,0 +1,231 @@
+/*
+ * Driver for NVIDIA Generic Memory Interface
+ *
+ * Copyright (C) 2016 Host Mobility AB. All rights reserved.
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define TEGRA_GMI_CONFIG   0x00
+#define TEGRA_GMI_CONFIG_GOBIT(31)
+#define TEGRA_GMI_BUS_WIDTH_32BIT  BIT(30)
+#define TEGRA_GMI_MUX_MODE BIT(28)
+#define TEGRA_GMI_RDY_BEFORE_DATA  BIT(24)
+#define TEGRA_GMI_RDY_ACTIVE_HIGH  BIT(23)
+#define TEGRA_GMI_ADV_ACTIVE_HIGH  BIT(22)
+#define TEGRA_GMI_OE_ACTIVE_HIGH   BIT(21)
+#define TEGRA_GMI_CS_ACTIVE_HIGH   BIT(20)
+#define TEGRA_GMI_CS_SELECT(x) ((x & 0x7) << 4)
+
+#define TEGRA_GMI_TIMING0  0x10
+#define TEGRA_GMI_MUXED_WIDTH(x)   ((x & 0xf) << 12)
+#define TEGRA_GMI_HOLD_WIDTH(x)((x & 0xf) << 8)
+#define TEGRA_GMI_ADV_WIDTH(x) ((x & 0xf) << 4)
+#define TEGRA_GMI_CE_WIDTH(x)  (x & 0xf)
+
+#define TEGRA_GMI_TIMING1  0x14
+#define TEGRA_GMI_WE_WIDTH(x)  ((x & 0xff) << 16)
+#define TEGRA_GMI_OE_WIDTH(x)  ((x & 0xff) << 8)
+#define TEGRA_GMI_WAIT_WIDTH(x)(x & 0xff)
+
+struct tegra_gmi_priv {
+   void __iomem *base;
+   struct reset_control *rst;
+   struct clk *clk;
+
+   u32 snor_config;
+   u32 snor_timing0;
+   u32 snor_timing1;
+};
+
+static void tegra_gmi_init(struct device *dev, struct tegra_gmi_priv *priv)
+{
+   writel(priv->snor_timing0, priv->base + TEGRA_GMI_TIMING0);
+   writel(priv->snor_timing1, priv->base + TEGRA_GMI_TIMING1);
+
+   priv->snor_config |= TEGRA_GMI_CONFIG_GO;
+   writel(priv->snor_config, priv->base + TEGRA_GMI_CONFIG);
+}
+
+static void tegra_gmi_parse_dt(struct device *dev, struct tegra_gmi_priv *priv)
+{
+   struct device_node *child = of_get_next_available_child(dev->of_node,
+   NULL);
+   u32 property;
+
+   if (!child) {
+   dev_warn(dev, "no child nodes found\n");
+   return;
+   }
+
+   /*
+* We currently only support one child device due to lack of
+* chip-select address decoding. Which means that we only have one
+* chip-select line from the GMI controller.
+*/
+   if (of_get_child_count(dev->of_node) > 1)
+   dev_warn(dev, "only one child device is supported.");
+
+   if (of_property_read_bool(child, "nvidia,snor-data-width-32bit"))
+   priv->snor_config |= TEGRA_GMI_BUS_WIDTH_32BIT;
+
+   if (of_property_read_bool(child, "nvidia,snor-mux-mode"))
+   priv->snor_config |= TEGRA_GMI_MUX_MODE;
+
+   if (of_property_read_bool(child, "nvidia,snor-rdy-active-before-da

[PATCH v2 1/6] clk: tegra: add TEGRA20_CLK_NOR to init table

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

Add TEGRA20_CLK_NOR to init tabel and set default rate to 92 MHz which
is max rate.

Signed-off-by: Mirza Krak 
---
Changes in v2:
- no changes

 drivers/clk/tegra/clk-tegra20.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/tegra/clk-tegra20.c b/drivers/clk/tegra/clk-tegra20.c
index 837e5cb..13d3b5a 100644
--- a/drivers/clk/tegra/clk-tegra20.c
+++ b/drivers/clk/tegra/clk-tegra20.c
@@ -1047,6 +1047,7 @@ static struct tegra_clk_init_table init_table[] 
__initdata = {
{ TEGRA20_CLK_SDMMC3, TEGRA20_CLK_PLL_P, 4800, 0 },
{ TEGRA20_CLK_SDMMC4, TEGRA20_CLK_PLL_P, 4800, 0 },
{ TEGRA20_CLK_SPI, TEGRA20_CLK_PLL_P, 2000, 0 },
+   { TEGRA20_CLK_NOR, TEGRA20_CLK_PLL_P, 9200, 0 },
{ TEGRA20_CLK_SBC1, TEGRA20_CLK_PLL_P, 1, 0 },
{ TEGRA20_CLK_SBC2, TEGRA20_CLK_PLL_P, 1, 0 },
{ TEGRA20_CLK_SBC3, TEGRA20_CLK_PLL_P, 1, 0 },
--
2.1.4



[PATCH v2 0/6] Add support for Tegra GMI bus controller

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

Hi.

This is a follow up to my previous RFC to add support for Tegra GMI bus
controller.

I have tested this series on a Tegra30 using a Colibri T30 SOM on a custom
carrier board which has multiple CAN controllers (SJA1000) connected to the
GMI bus.

I have rebased on top of latest tegra/for-next in V2. Also see individual
patches for changes in V2.

See below links for previous discussions.

Comments on RFC:
https://marc.info/?l=linux-clk&m=146893557629903&w=2
https://marc.info/?l=linux-tegra&m=146893541829801&w=2
https://marc.info/?l=linux-tegra&m=146893542429814&w=2

Comments on V1:
https://marc.info/?l=linux-arm-kernel&m=147051551821122&w=2
https://marc.info/?l=linux-arm-kernel&m=147051553121150&w=2
https://marc.info/?l=linux-arm-kernel&m=147194856600627&w=2
https://marc.info/?l=linux-arm-kernel&m=147072742432211&w=2


Mirza Krak (6):
  clk: tegra: add TEGRA20_CLK_NOR to init table
  clk: tegra: add TEGRA30_CLK_NOR to init table
  dt/bindings: Add bindings for Tegra GMI controller
  ARM: tegra: Add Tegra30 GMI support
  ARM: tegra: Add Tegra20 GMI support
  bus: Add support for Tegra Generic Memory Interface

 .../devicetree/bindings/bus/nvidia,tegra20-gmi.txt | 132 
 arch/arm/boot/dts/tegra20.dtsi |  13 ++
 arch/arm/boot/dts/tegra30.dtsi |  12 ++
 drivers/bus/Kconfig|   8 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/tegra-gmi.c| 231 +
 drivers/clk/tegra/clk-tegra20.c|   1 +
 drivers/clk/tegra/clk-tegra30.c|   1 +
 8 files changed, 399 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/nvidia,tegra20-gmi.txt
 create mode 100644 drivers/bus/tegra-gmi.c

--
2.1.4



[PATCH v2 5/6] ARM: tegra: Add Tegra20 GMI support

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

Add a device node for the GMI controller found on Tegra20.

Signed-off-by: Mirza Krak 
---
Changes in v2:
- added address-cells, size-cells and ranges properties

 arch/arm/boot/dts/tegra20.dtsi | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/tegra20.dtsi b/arch/arm/boot/dts/tegra20.dtsi
index 2207c08..03eb029 100644
--- a/arch/arm/boot/dts/tegra20.dtsi
+++ b/arch/arm/boot/dts/tegra20.dtsi
@@ -376,6 +376,20 @@
status = "disabled";
};

+
+   gmi@70009000 {
+   compatible = "nvidia,tegra20-gmi";
+   reg = <70009000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x4800 0x7ff>;
+   clocks = <&tegra_car TEGRA20_CLK_NOR>;
+   clock-names = "gmi";
+   resets = < &tegra_car 42>;
+   reset-names = "gmi";
+   status = "disabled";
+   };
+
pwm: pwm@7000a000 {
compatible = "nvidia,tegra20-pwm";
reg = <0x7000a000 0x100>;
--
2.1.4



[PATCH v2 4/6] ARM: tegra: Add Tegra30 GMI support

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

Add a device node for the GMI controller found on Tegra30.

Signed-off-by: Mirza Krak 
---
Changes in v2:
- added address-cells, size-cells and ranges properties

 arch/arm/boot/dts/tegra30.dtsi | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index 5030065..1b26308 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -439,6 +439,19 @@
status = "disabled";
};

+   gmi@70009000 {
+   compatible = "nvidia,tegra30-gmi";
+   reg = <0x70009000 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0 0x4800 0x7ff>;
+   clocks = <&tegra_car TEGRA30_CLK_NOR>;
+   clock-names = "gmi";
+   resets = <&tegra_car 42>;
+   reset-names = "gmi";
+   status = "disabled";
+   };
+
pwm: pwm@7000a000 {
compatible = "nvidia,tegra30-pwm", "nvidia,tegra20-pwm";
reg = <0x7000a000 0x100>;
--
2.1.4



[PATCH v2 2/6] clk: tegra: add TEGRA30_CLK_NOR to init table

2016-08-24 Thread Mirza Krak
From: Mirza Krak 

Add TEGRA30_CLK_NOR to init table and set default rate to 127 MHz which
is max rate.

Signed-off-by: Mirza Krak 
---
Changes in v2:
- no changes

 drivers/clk/tegra/clk-tegra30.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/tegra/clk-tegra30.c b/drivers/clk/tegra/clk-tegra30.c
index 8e2db5e..67f1677 100644
--- a/drivers/clk/tegra/clk-tegra30.c
+++ b/drivers/clk/tegra/clk-tegra30.c
@@ -1252,6 +1252,7 @@ static struct tegra_clk_init_table init_table[] 
__initdata = {
{ TEGRA30_CLK_SDMMC1, TEGRA30_CLK_PLL_P, 4800, 0 },
{ TEGRA30_CLK_SDMMC2, TEGRA30_CLK_PLL_P, 4800, 0 },
{ TEGRA30_CLK_SDMMC3, TEGRA30_CLK_PLL_P, 4800, 0 },
+   { TEGRA30_CLK_NOR, TEGRA30_CLK_PLL_P, 12700, 0 },
{ TEGRA30_CLK_PLL_M, TEGRA30_CLK_CLK_MAX, 0, 1 },
{ TEGRA30_CLK_PCLK, TEGRA30_CLK_CLK_MAX, 0, 1 },
{ TEGRA30_CLK_CSITE, TEGRA30_CLK_CLK_MAX, 0, 1 },
--
2.1.4



[PATCH v2] Documentation: devicetree: changesets do locking on their own meanwhile

2016-08-24 Thread Wolfram Sang
Since commit 183223770ae862 ("drivers/of: Export OF changeset functions"),
the mentioned functions do all necessary locking.

Signed-off-by: Wolfram Sang 
Fixes: 183223770ae862 ("drivers/of: Export OF changeset functions")
---

V2: corrected the "Fixes" tag

 Documentation/devicetree/changesets.txt | 19 +--
 1 file changed, 5 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/changesets.txt 
b/Documentation/devicetree/changesets.txt
index 935ba5acc34e6c..cb488eeb635372 100644
--- a/Documentation/devicetree/changesets.txt
+++ b/Documentation/devicetree/changesets.txt
@@ -21,20 +21,11 @@ a set of changes. No changes to the active tree are made at 
this point.
 All the change operations are recorded in the of_changeset 'entries'
 list.
 
-3. mutex_lock(of_mutex) - starts a changeset; The global of_mutex
-ensures there can only be one editor at a time.
-
-4. of_changeset_apply() - Apply the changes to the tree. Either the
+3. of_changeset_apply() - Apply the changes to the tree. Either the
 entire changeset will get applied, or if there is an error the tree will
-be restored to the previous state
-
-5. mutex_unlock(of_mutex) - All operations complete, release the mutex
+be restored to the previous state. The core ensures proper serialization
+through locking. An unlocked version __of_changeset_apply is available,
+if needed.
 
 If a successfully applied changeset needs to be removed, it can be done
-with the following sequence.
-
-1. mutex_lock(of_mutex)
-
-2. of_changeset_revert()
-
-3. mutex_unlock(of_mutex)
+with of_changeset_revert().
-- 
2.9.3



Re: [REGRESSION] Select hang with zero sized UDP packets

2016-08-24 Thread One Thousand Gnomes
On Wed, 24 Aug 2016 11:22:09 +0300
"Dan Akunis"  wrote:

> When select wakes up on a UDP socket, user is expecting to get data. Getting 
> 0 from recvfrom() or whatever read function she uses, is a wrong attitude.
> I agree with David.
> 
> The unit test that expects select to wake up is wrong and should be changed.

The unit test is correct.

The behaviour of a 0 byte frame is actually well established and a 0 byte
data frame is a meaningful message is several protocols. It is distinct
from no pending data because that would report EWOULDBLOCK. It's more fun
with regard to EOF but UDP has no EOF semantics. If you want to
understand how to handle zero length datagrams in a connection oriented
protocol the old DECnet documentation covers it in all its pain 8)

Alan


[tip:x86/asm] x86/dumpstack/ftrace: Mark function graph handler function as unreliable

2016-08-24 Thread tip-bot for Josh Poimboeuf
Commit-ID:  6f727b84e23421721025f4eb1b4f6cea1d4d723a
Gitweb: http://git.kernel.org/tip/6f727b84e23421721025f4eb1b4f6cea1d4d723a
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:01 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

x86/dumpstack/ftrace: Mark function graph handler function as unreliable

When function graph tracing is enabled for a function, its return
address on the stack is replaced with the address of an ftrace handler
(return_to_handler).

Currently 'return_to_handler' can be reported as reliable.  That's not
ideal, and can actually be misleading.  When saving or dumping the
stack, you normally only care about what led up to that point (the call
path), rather than what will happen in the future (the return path).

That's especially true in the non-oops stack trace case, which isn't
used for debugging.  For example, in a perf profiling operation,
reporting return_to_handler() in the trace would just be confusing.

And in the oops case, where debugging is important, "unreliable" is also
more appropriate there because it serves as a hint that graph tracing
was involved, instead of trying to imply that return_to_handler() was
the real caller.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/f8af15749c7d632d3e7f815995831d5b7f82950d.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 9bf3d02..6aad8d4 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -87,12 +87,21 @@ print_context_stack(struct task_struct *task,
bp = (unsigned long) frame;
}
 
-   ops->address(data, addr, reliable);
-
+   /*
+* When function graph tracing is enabled for a
+* function, its return address on the stack is
+* replaced with the address of an ftrace handler
+* (return_to_handler).  In that case, before printing
+* the "real" address, we want to print the handler
+* address as an "unreliable" hint that function graph
+* tracing was involved.
+*/
real_addr = ftrace_graph_ret_addr(task, graph, addr,
  stack);
if (real_addr != addr)
-   ops->address(data, real_addr, 1);
+   ops->address(data, addr, 0);
+
+   ops->address(data, real_addr, reliable);
}
stack++;
}
@@ -116,12 +125,11 @@ print_context_stack_bp(struct task_struct *task,
if (!__kernel_text_address(addr))
break;
 
-   if (ops->address(data, addr, 1))
-   break;
-
real_addr = ftrace_graph_ret_addr(task, graph, addr, retp);
-   if (real_addr != addr)
-   ops->address(data, real_addr, 1);
+   if (real_addr != addr && ops->address(data, addr, 0))
+   break;
+   if (ops->address(data, real_addr, 1))
+   break;
 
frame = frame->next_frame;
retp = &frame->return_address;


[tip:locking/core] locking/hung_task: Show all locks

2016-08-24 Thread tip-bot for Vegard Nossum
Commit-ID:  b2d4c2edb2e4f89aaf85449dee3b87fbf0f8a4d4
Gitweb: http://git.kernel.org/tip/b2d4c2edb2e4f89aaf85449dee3b87fbf0f8a4d4
Author: Vegard Nossum 
AuthorDate: Thu, 18 Aug 2016 18:41:00 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:16:13 +0200

locking/hung_task: Show all locks

When we get a hung task it can often be valuable to see _all_ the held
locks on the system (in case we are being blocked on trying to acquire
one), e.g. with this patch we can immediately see where the problem is
below:

INFO: task trinity-c3:14933 blocked for more than 120 seconds.
  Not tainted 4.8.0-rc1+ #135
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
trinity-c3  D 88010c16fc88 0 14933  1 0x00080004
 88010c16fc88 3b9aca00  0296
 776cdf88 88011a520ae0 88011a520b08 88011a520198
 867d7f00 88011942c080 880116841580 88010c168000
Call Trace:
 [] schedule+0x77/0x230
 [] __lock_sock+0x129/0x250
 [] ? __sk_destruct+0x450/0x450
 [] ? wake_bit_function+0x2e0/0x2e0
 [] lock_sock_nested+0xeb/0x120
 [] irda_setsockopt+0x65/0xb40
 [] SyS_setsockopt+0x139/0x230
 [] ? SyS_recv+0x20/0x20
 [] ? trace_event_raw_event_sys_enter+0xb90/0xb90
 [] ? __this_cpu_preempt_check+0x13/0x20
 [] ? __context_tracking_exit.part.3+0x30/0x1b0
 [] ? SyS_recv+0x20/0x20
 [] do_syscall_64+0x1b3/0x4b0
 [] entry_SYSCALL64_slow_path+0x25/0x25

Showing all locks held in the system:
2 locks held by khungtaskd/563:
 #0:  (rcu_read_lock){..}, at: [] watchdog+0x106/0x910
 #1:  (tasklist_lock){..}, at: [] 
debug_show_all_locks+0x74/0x360
1 lock held by trinity-c0/19280:
 #0:  (sk_lock-AF_IRDA){..}, at: [] 
irda_accept+0x176/0x10f0
1 lock held by trinity-c0/12865:
 #0:  (sk_lock-AF_IRDA){..}, at: [] 
irda_accept+0x176/0x10f0

Signed-off-by: Vegard Nossum 
Cc: Andrew Morton 
Cc: Linus Torvalds 
Cc: Mandeep Singh Baines 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471538460-7505-1-git-send-email-vegard.nos...@oracle.com
Signed-off-by: Ingo Molnar 
---
 kernel/hung_task.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/hung_task.c b/kernel/hung_task.c
index d234022..432c3d7 100644
--- a/kernel/hung_task.c
+++ b/kernel/hung_task.c
@@ -117,7 +117,7 @@ static void check_hung_task(struct task_struct *t, unsigned 
long timeout)
pr_err("\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\""
" disables this message.\n");
sched_show_task(t);
-   debug_show_held_locks(t);
+   debug_show_all_locks();
 
touch_nmi_watchdog();
 


[tip:x86/asm] x86/dumpstack/ftrace: Convert dump_trace() callbacks to use ftrace_graph_ret_addr()

2016-08-24 Thread tip-bot for Josh Poimboeuf
Commit-ID:  408fe5de2f2767059a9561e0ae6d4385d1b39dac
Gitweb: http://git.kernel.org/tip/408fe5de2f2767059a9561e0ae6d4385d1b39dac
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:52:59 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:14 +0200

x86/dumpstack/ftrace: Convert dump_trace() callbacks to use 
ftrace_graph_ret_addr()

Convert print_context_stack() and print_context_stack_bp() to use the
arch-independent ftrace_graph_ret_addr() helper.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/56ec97cafc1bf2e34d1119e6443d897db406da86.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 65 +++--
 1 file changed, 22 insertions(+), 43 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 5f49c04..9bf3d02 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -38,38 +38,6 @@ void printk_address(unsigned long address)
pr_cont(" [<%p>] %pS\n", (void *)address, (void *)address);
 }
 
-#ifdef CONFIG_FUNCTION_GRAPH_TRACER
-static void
-print_ftrace_graph_addr(unsigned long addr, void *data,
-   const struct stacktrace_ops *ops,
-   struct task_struct *task, int *graph)
-{
-   unsigned long ret_addr;
-   int index;
-
-   if (addr != (unsigned long)return_to_handler)
-   return;
-
-   index = task->curr_ret_stack;
-
-   if (!task->ret_stack || index < *graph)
-   return;
-
-   index -= *graph;
-   ret_addr = task->ret_stack[index].ret;
-
-   ops->address(data, ret_addr, 1);
-
-   (*graph)++;
-}
-#else
-static inline void
-print_ftrace_graph_addr(unsigned long addr, void *data,
-   const struct stacktrace_ops *ops,
-   struct task_struct *task, int *graph)
-{ }
-#endif
-
 /*
  * x86-64 can have up to three kernel stacks:
  * process stack
@@ -107,18 +75,24 @@ print_context_stack(struct task_struct *task,
stack = (unsigned long *)task_stack_page(task);
 
while (valid_stack_ptr(task, stack, sizeof(*stack), end)) {
-   unsigned long addr;
+   unsigned long addr = *stack;
 
-   addr = *stack;
if (__kernel_text_address(addr)) {
+   unsigned long real_addr;
+   int reliable = 0;
+
if ((unsigned long) stack == bp + sizeof(long)) {
-   ops->address(data, addr, 1);
+   reliable = 1;
frame = frame->next_frame;
bp = (unsigned long) frame;
-   } else {
-   ops->address(data, addr, 0);
}
-   print_ftrace_graph_addr(addr, data, ops, task, graph);
+
+   ops->address(data, addr, reliable);
+
+   real_addr = ftrace_graph_ret_addr(task, graph, addr,
+ stack);
+   if (real_addr != addr)
+   ops->address(data, real_addr, 1);
}
stack++;
}
@@ -133,19 +107,24 @@ print_context_stack_bp(struct task_struct *task,
   unsigned long *end, int *graph)
 {
struct stack_frame *frame = (struct stack_frame *)bp;
-   unsigned long *ret_addr = &frame->return_address;
+   unsigned long *retp = &frame->return_address;
 
-   while (valid_stack_ptr(task, ret_addr, sizeof(*ret_addr), end)) {
-   unsigned long addr = *ret_addr;
+   while (valid_stack_ptr(task, retp, sizeof(*retp), end)) {
+   unsigned long addr = *retp;
+   unsigned long real_addr;
 
if (!__kernel_text_address(addr))
break;
 
if (ops->address(data, addr, 1))
break;
+
+   real_addr = ftrace_graph_ret_addr(task, graph, addr, retp);
+   if (real_addr != addr)
+   ops->address(data, real_addr, 1);
+
frame = frame->next_frame;
-   ret_addr = &frame->return_address;
-   print_ftrace_graph_addr(addr, data, ops, task, graph);
+   retp = &frame->return_address;
}
 
return (unsigned long)frame;


[tip:x86/asm] sched/x86/64, kgdb: Clear GDB_PS on 64-bit

2016-08-24 Thread tip-bot for Brian Gerst
Commit-ID:  163630191ecb0dd9e4146d3c910045aba1cfeec1
Gitweb: http://git.kernel.org/tip/163630191ecb0dd9e4146d3c910045aba1cfeec1
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:17 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:27:40 +0200

sched/x86/64, kgdb: Clear GDB_PS on 64-bit

switch_to() no longer saves EFLAGS, so it's bogus to look for it on the
stack.  Set it to zero like 32-bit.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jason Wessel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-3-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/kgdb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index fe649a5..5e3f294 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -176,7 +176,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_FS]= 0x;
gdb_regs[GDB_GS]= 0x;
 #else
-   gdb_regs32[GDB_PS]  = *(unsigned long *)(p->thread.sp + 8);
+   gdb_regs32[GDB_PS]  = 0;
gdb_regs32[GDB_CS]  = __KERNEL_CS;
gdb_regs32[GDB_SS]  = __KERNEL_DS;
gdb_regs[GDB_R8]= 0;


[tip:x86/asm] x86/dumpstack/ftrace: Don't print unreliable addresses in print_context_stack_bp()

2016-08-24 Thread tip-bot for Josh Poimboeuf
Commit-ID:  13e25bab7e51bdd4ba7df1ef2388961294bb565e
Gitweb: http://git.kernel.org/tip/13e25bab7e51bdd4ba7df1ef2388961294bb565e
Author: Josh Poimboeuf 
AuthorDate: Fri, 19 Aug 2016 06:53:02 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:15:15 +0200

x86/dumpstack/ftrace: Don't print unreliable addresses in 
print_context_stack_bp()

When function graph tracing is enabled, print_context_stack_bp() can
report return_to_handler() as an unreliable address, which is confusing
and misleading: return_to_handler() is really only useful as a hint for
debugging, whereas print_context_stack_bp() users only care about the
actual 'reliable' call path.

Signed-off-by: Josh Poimboeuf 
Acked-by: Steven Rostedt 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/c51aef578d8027791b38d2ad9bac0c7f499fde91.1471607358.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/dumpstack.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/x86/kernel/dumpstack.c b/arch/x86/kernel/dumpstack.c
index 6aad8d4..01072e9 100644
--- a/arch/x86/kernel/dumpstack.c
+++ b/arch/x86/kernel/dumpstack.c
@@ -126,8 +126,6 @@ print_context_stack_bp(struct task_struct *task,
break;
 
real_addr = ftrace_graph_ret_addr(task, graph, addr, retp);
-   if (real_addr != addr && ops->address(data, addr, 0))
-   break;
if (ops->address(data, real_addr, 1))
break;
 


[tip:x86/asm] sched/x86/32, kgdb: Don't use thread.ip in sleeping_thread_to_gdb_regs()

2016-08-24 Thread tip-bot for Brian Gerst
Commit-ID:  4e047aa7f267c3449b6d323510d35864829aca70
Gitweb: http://git.kernel.org/tip/4e047aa7f267c3449b6d323510d35864829aca70
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:16 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:27:40 +0200

sched/x86/32, kgdb: Don't use thread.ip in sleeping_thread_to_gdb_regs()

Match 64-bit and set gdb_regs[GDB_PC] to zero.  thread.ip is always the
same point in the scheduler (except for newly forked processes), and will
be removed in a future patch.

Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Jason Wessel 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-2-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/kgdb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/arch/x86/kernel/kgdb.c b/arch/x86/kernel/kgdb.c
index 04cde52..fe649a5 100644
--- a/arch/x86/kernel/kgdb.c
+++ b/arch/x86/kernel/kgdb.c
@@ -172,7 +172,6 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_ES]= __KERNEL_DS;
gdb_regs[GDB_PS]= 0;
gdb_regs[GDB_CS]= __KERNEL_CS;
-   gdb_regs[GDB_PC]= p->thread.ip;
gdb_regs[GDB_SS]= __KERNEL_DS;
gdb_regs[GDB_FS]= 0x;
gdb_regs[GDB_GS]= 0x;
@@ -180,7 +179,6 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs32[GDB_PS]  = *(unsigned long *)(p->thread.sp + 8);
gdb_regs32[GDB_CS]  = __KERNEL_CS;
gdb_regs32[GDB_SS]  = __KERNEL_DS;
-   gdb_regs[GDB_PC]= 0;
gdb_regs[GDB_R8]= 0;
gdb_regs[GDB_R9]= 0;
gdb_regs[GDB_R10]   = 0;
@@ -190,6 +188,7 @@ void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, 
struct task_struct *p)
gdb_regs[GDB_R14]   = 0;
gdb_regs[GDB_R15]   = 0;
 #endif
+   gdb_regs[GDB_PC]= 0;
gdb_regs[GDB_SP]= p->thread.sp;
 }
 


[tip:x86/asm] sched: Remove __schedule() non-standard frame annotation

2016-08-24 Thread tip-bot for Brian Gerst
Commit-ID:  01175255fd8e3e993353a779f819ec8c0c59137e
Gitweb: http://git.kernel.org/tip/01175255fd8e3e993353a779f819ec8c0c59137e
Author: Brian Gerst 
AuthorDate: Sat, 13 Aug 2016 12:38:22 -0400
Committer:  Ingo Molnar 
CommitDate: Wed, 24 Aug 2016 12:31:51 +0200

sched: Remove __schedule() non-standard frame annotation

Now that the x86 switch_to() uses the standard C calling convention,
the STACK_FRAME_NON_STANDARD() annotation is no longer needed.

Suggested-by: Josh Poimboeuf 
Signed-off-by: Brian Gerst 
Reviewed-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1471106302-10159-8-git-send-email-brge...@gmail.com
Signed-off-by: Ingo Molnar 
---
 kernel/sched/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 2a906f2..3d91b63dd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -3381,7 +3381,6 @@ static void __sched notrace __schedule(bool preempt)
 
balance_callback(rq);
 }
-STACK_FRAME_NON_STANDARD(__schedule); /* switch_to() */
 
 static inline void sched_submit_work(struct task_struct *tsk)
 {


Re: [PATCH 1/2] tty: serial_core: convert uart_open to use tty_port_open

2016-08-24 Thread One Thousand Gnomes
On Mon, 22 Aug 2016 17:39:09 -0500
Rob Herring  wrote:

> tty_port_open handles much of the common parts of tty opening. Convert
> uart_open to use it and move the serial_core specific parts into
> tty_port.activate function. This will be needed to use tty_port functions
> directly from in kernel clients.
> 
> The tricky part is uart_port_startup can return positive values to allow
> setserial to configure the port. We now return the positive value to
> tty_port_open so that the tty is not marked as initialized and then set the
> return value in uart_open to 0.
> 
> Cc: Alan Cox 
> Cc: Peter Hurley 
> Signed-off-by: Rob Herring 
> ---
> In looking at using tty_port for uart slaves, this is the first thing I 
> hit. serial_core doesn't even use the 2 functions that already exist for 
> tty_port and are needed.
> 
> I've tested this on QEMU with pl011 and 8250 UARTs using setserial, but 
> I'm not sure what are all the tricky cases to handle.
> 
> Greg, Don't apply these without comment from Alan and Peter.

Originally I didn't convert them because the lockign was incompatible.
That looks to have been fixed by other changes. This is definitely the
right direction irrespective of the uart slave discussion.

Acked-by: Alan Cox 


[PATCH v2 6/7] arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board

2016-08-24 Thread Chanwoo Choi
This patch adds the Device Tree source for Exynos5433-based Samsung TM2 board.
This board fully support the all things for mobile target.

This patch supports the following devices:
1. basic SoC
- Initial booting for Samsung Exynos5433 SoC
- DRAM LPDDR3 (3GB)
- eMMC (32GB)
- ARM architecture timer

2. power management devices
- Sasmung S2MPS13 PMIC for the power supply
- CPUFREQ for big.LITTLE cores
- TMU for big.LITTLE cores and GPU
- ADC with thermistor to measure the temperature of AP/Battery/Charger
- Maxim MAX77843 Interface PMIC (MUIC/Haptic/Regulator)

3. sound devices
- I2S for sound bus
- LPASS for sound power control
- Wolfson WM5110 for sound codec
- Maxim MAX98504 for speaker amplifier
- TM2 ASoC Machine device driver node

3. display devices
- DECON, DSI and MIC for the panel output

4. usb devices
- USB 3.0 DRD (Dual Role Device)
- USB 3.0 Host controller

5. storage devices
- MSHC (Mobile Storae Host Controller) for eMMC device

6. misc devices
- gpio-keys (power, volume up/down, home key)
- PWM (Pulse Width Modulation Timer)

Signed-off-by: Chanwoo Choi 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Jonghwa Lee 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Inha Song 
Signed-off-by: Ingi kim 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Sylwester Nawrocki 
---
 .../bindings/arm/samsung/samsung-boards.txt|   1 +
 arch/arm64/boot/dts/exynos/Makefile|   5 +-
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  | 985 +
 3 files changed, 990 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index 0ea7f14ef294..c704b4bf6137 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -15,6 +15,7 @@ Required root node properties:
- "samsung,xyref5260"   - for Exynos5260-based Samsung board.
- "samsung,smdk5410"- for Exynos5410-based Samsung SMDK5410 eval 
board.
- "samsung,smdk5420"- for Exynos5420-based Samsung SMDK5420 eval 
board.
+   - "samsung,tm2" - for Exynos5333-based Samsung TM2 board.
- "samsung,sd5v1"   - for Exynos5440-based Samsung board.
- "samsung,ssdk5440"- for Exynos5440-based Samsung board.
 
diff --git a/arch/arm64/boot/dts/exynos/Makefile 
b/arch/arm64/boot/dts/exynos/Makefile
index 50c9b9383cfa..7ddea53769a7 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -1,4 +1,7 @@
-dtb-$(CONFIG_ARCH_EXYNOS) += exynos7-espresso.dtb
+dtb-$(CONFIG_ARCH_EXYNOS) += \
+   exynos5433-tm2.dtb  \
+   exynos5433-tm2e.dtb \
+   exynos7-espresso.dtb
 
 always := $(dtb-y)
 subdir-y   := $(dts-dirs)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
new file mode 100644
index ..f31528f829e1
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -0,0 +1,985 @@
+/*
+ * SAMSUNG Exynos5433 TM2 board device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * Device tree source file for Samsung's TM2 board which is based on
+ * Samsung Exynos5433 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/dts-v1/;
+#include "exynos5433.dtsi"
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Samsung TM2 board";
+   compatible = "samsung,exynos5433-tm2", "samsung,exynos5433";
+
+   aliases {
+   pinctrl0 = &pinctrl_alive;
+   pinctrl1 = &pinctrl_aud;
+   pinctrl2 = &pinctrl_cpif;
+   pinctrl3 = &pinctrl_ese;
+   pinctrl4 = &pinctrl_finger;
+   pinctrl5 = &pinctrl_fsys;
+   pinctrl6 = &pinctrl_imem;
+   pinctrl7 = &pinctrl_nfc;
+   pinctrl8 = &pinctrl_peric;
+   pinctrl9 = &pinctrl_touch;
+   serial0 = &serial_0;
+   serial1 = &serial_1;
+   serial2 = &serial_2;
+   serial3 = &serial_3;
+   spi0 = &spi_0;
+   spi1 = &spi_1;
+   spi2 = &spi_2;
+   spi3 = &spi_3;
+   spi4 = &spi_4;
+   };
+
+   chosen {
+   stdout-path = &serial_1;
+   };
+
+   memory@2000 {
+   device_type = "memory";
+   reg = <0x0 0x2000 0x0 0xc000>;
+   };
+
+   gpio-keys {
+   compatible = "gp

[PATCH v2 7/7] arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board

2016-08-24 Thread Chanwoo Choi
This patch adds the Device Tree source for Exynos5433-based Samsung TM2E
board. TM2E board is the most similar with TM2 board. The exynos5433-tm2e.dts
include the difference between TM2 and TM2E.

Signed-off-by: Chanwoo Choi 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Jonghwa Lee 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Inha Song 
Signed-off-by: Ingi kim 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Sylwester Nawrocki 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Rob Herring 
---
 .../bindings/arm/samsung/samsung-boards.txt|  1 +
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 41 ++
 2 files changed, 42 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts

diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt 
b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
index c704b4bf6137..c1bda8d3674c 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.txt
@@ -16,6 +16,7 @@ Required root node properties:
- "samsung,smdk5410"- for Exynos5410-based Samsung SMDK5410 eval 
board.
- "samsung,smdk5420"- for Exynos5420-based Samsung SMDK5420 eval 
board.
- "samsung,tm2" - for Exynos5333-based Samsung TM2 board.
+   - "samsung,tm2e"- for Exynos5333-based Samsung TM2E board.
- "samsung,sd5v1"   - for Exynos5440-based Samsung board.
- "samsung,ssdk5440"- for Exynos5440-based Samsung board.
 
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts 
b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
new file mode 100644
index ..283b4fd19d5a
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -0,0 +1,41 @@
+/*
+ * SAMSUNG Exynos5433 TM2E board device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * Device tree source file for Samsung's TM2E(TM2 EDGE) board which is based on
+ * Samsung Exynos5433 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "exynos5433-tm2.dts"
+
+/ {
+   model = "Samsung TM2E board";
+   compatible = "samsung,exynos5433-tm2e", "samsung,exynos5433";
+};
+
+&ldo23_reg {
+   regulator-name = "CAM_SEN_CORE_1.025V_AP";
+   regulator-max-microvolt = <105>;
+};
+
+&ldo25_reg {
+   regulator-name = "UNUSED_LDO25";
+   regulator-always-off;
+};
+
+&ldo31_reg {
+   regulator-name = "TSP_VDD_1.8V_AP";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+};
+
+&ldo38_reg {
+   regulator-name = "VCC_3.3V_MOTOR_AP";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+};
-- 
1.9.1



Re: [PATCH] [media] v4l2-async: Always unregister the subdev on failure

2016-08-24 Thread Alban Bedel
On Fri, 1 Jul 2016 13:55:44 +0200
Hans Verkuil  wrote:

> On 05/11/2016 06:32 PM, Alban Bedel wrote:
> > On Wed, 11 May 2016 12:22:44 -0400
> > Javier Martinez Canillas  wrote:
> >   
> >> Hello Alban,
> >>
> >> On 05/11/2016 11:40 AM, Alban Bedel wrote:  
> >>> In v4l2_async_test_notify() if the registered_async callback or the
> >>> complete notifier returns an error the subdev is not unregistered.
> >>> This leave paths where v4l2_async_register_subdev() can fail but
> >>> leave the subdev still registered.
> >>>
> >>> Add the required calls to v4l2_device_unregister_subdev() to plug
> >>> these holes.
> >>>
> >>> Signed-off-by: Alban Bedel 
> >>> ---
> >>>  drivers/media/v4l2-core/v4l2-async.c | 10 --
> >>>  1 file changed, 8 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/media/v4l2-core/v4l2-async.c 
> >>> b/drivers/media/v4l2-core/v4l2-async.c
> >>> index ceb28d4..43393f8 100644
> >>> --- a/drivers/media/v4l2-core/v4l2-async.c
> >>> +++ b/drivers/media/v4l2-core/v4l2-async.c
> >>> @@ -121,13 +121,19 @@ static int v4l2_async_test_notify(struct 
> >>> v4l2_async_notifier *notifier,
> >>>  
> >>>   ret = v4l2_subdev_call(sd, core, registered_async);
> >>>   if (ret < 0 && ret != -ENOIOCTLCMD) {
> >>> + v4l2_device_unregister_subdev(sd);
> >>>   if (notifier->unbind)
> >>>   notifier->unbind(notifier, sd, asd);
> >>>   return ret;
> >>>   }
> >>>  
> >>> - if (list_empty(¬ifier->waiting) && notifier->complete)
> >>> - return notifier->complete(notifier);
> >>> + if (list_empty(¬ifier->waiting) && notifier->complete) {
> >>> + ret = notifier->complete(notifier);
> >>> + if (ret < 0) {
> >>> + v4l2_device_unregister_subdev(sd);  
> >>
> >> Isn't a call to notifier->unbind() missing here as well?
> >>
> >> Also, I think the error path is becoming too duplicated and complex, so
> >> maybe we can have a single error path and use goto labels as is common
> >> in Linux? For example something like the following (not tested) can be
> >> squashed on top of your change:  
> > 
> > Yes, that look better. I'll test it and report tomorrow.  
> 
> I haven't heard anything back about this. Did you manage to test it?

Yes, that's working fine. Sorry for the delay, I'm sending the v2 patch.

Alban



pgpXTq6f3KCYt.pgp
Description: OpenPGP digital signature


Re: [PATCH 3/5] hwrng: amd: Be consitent with the driver name

2016-08-24 Thread LABBE Corentin
On Wed, Aug 24, 2016 at 06:58:11PM +0800, Herbert Xu wrote:
> On Fri, Aug 19, 2016 at 03:42:55PM +0200, LABBE Corentin wrote:
> > The driver name is displayed each time differently.
> > This patch make use of the same name everywhere.
> > 
> > Signed-off-by: LABBE Corentin 
> > ---
> >  drivers/char/hw_random/amd-rng.c | 13 ++---
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/char/hw_random/amd-rng.c 
> > b/drivers/char/hw_random/amd-rng.c
> > index d0042f5..d0a806a 100644
> > --- a/drivers/char/hw_random/amd-rng.c
> > +++ b/drivers/char/hw_random/amd-rng.c
> > @@ -31,7 +31,7 @@
> >  #include 
> >  #include 
> >  
> > -#define PFXKBUILD_MODNAME ": "
> > +#define DRV_NAME "AMD768-HWRNG"
> >  
> >  /*
> >   * Data for PCI driver interface
> > @@ -98,7 +98,7 @@ static void amd_rng_cleanup(struct hwrng *rng)
> >  }
> >  
> >  static struct hwrng amd_rng = {
> > -   .name   = "amd",
> > +   .name   = DRV_NAME,
> 
> Hmm, this changes a sysfs-exported name which has the potential
> to break user-space.  So I think you'd need to a stronger argument
> to do it other than just cleaning it up.
> 

amd is really really too generic.

But if you still NACK that (and I understand perfectly why), I will update my 
series.

Regards



Re: Why do we need reset_control_get_optional() ?

2016-08-24 Thread Philipp Zabel
Am Dienstag, den 16.08.2016, 18:41 +0900 schrieb Masahiro Yamada:
> Hi Arnd,
>
> 2016-08-06 0:35 GMT+09:00 Arnd Bergmann :
> 
> >
> > config RESET_FOO
> > bool "FOO reset controller" if COMPILE_TEST && !ARCH_FOO
> > default ARCH_FOO
> >
> > then I think we get both: you won't be able to turn it off
> > but also get the build testing.
>
> This looks good to me, too.
> I do not know if we need "&& !ARCH_FOO", though.
> 
> When we are compile-testing, we do not care if it works on run-time,
> so perhaps it makes sense to allow to enable/disable RESET_FOO
> regardless ARCH_FOO.

I'll send a few patches to add the Kconfig symbols. Turning around the
RESET_CONTROLLER selection can be done in a second step.

regards
Philipp



[PATCH v2 2/7] Documentation: bindings: Add Exynos5433 PMU compatible

2016-08-24 Thread Chanwoo Choi
This patch adds the exynos5433 PMU compatible to support the access
of PMU (Power Management Unit) block.

Signed-off-by: Chanwoo Choi 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/arm/samsung/pmu.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt 
b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index 2d6356d8daf4..bf5fc59a6938 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -10,6 +10,7 @@ Properties:
   - "samsung,exynos5260-pmu" - for Exynos5260 SoC.
   - "samsung,exynos5410-pmu" - for Exynos5410 SoC,
   - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+  - "samsung,exynos5433-pmu" - for Exynos5433 SoC.
   - "samsung,exynos7-pmu" - for Exynos7 SoC.
second value must be always "syscon".
 
-- 
1.9.1



[PATCH v2 5/7] arm64: dts: exynos: Add dts files for Samsung Exynos5433 64bit SoC

2016-08-24 Thread Chanwoo Choi
This patch adds new Exynos5433 dtsi to support 64-bit Exynos5433 SoC based on
Octa-core CPUs (quad Cortex-A57 and quad Cortex-A53). And Exynos5433 supports
PSCI (Power State Coordination Interface) v0.1.

This patch includes following Device Tree node to support Exynos5433 SoC:
1. Octa cores for big.LITTLE architecture
- Cortex-A53 LITTLE Quad-core
- Cortex-A57 big Quad-core
- Support PSCI v0.1

2. Clock controller node
- CMU_TOP   : clocks for IMEM/FSYS/G3D/GSCL/HEVC/MSCL/G2D/MFC/PERIC/PERIS
- CMU_CPIF  : clocks for LLI (Low Latency Interface)
- CMU_MIF   : clocks for DRAM Memory Controller
- CMU_PERIC : clocks for UART/I2C/SPI/I2S/PCM/SPDIF/PWM/SLIMBUS
- CMU_PERIS : clocks for PMU/TMU/MCT/WDT/RTC/SECKEY/TZPC
- CMU_FSYS  : clocks for USB/UFS/SDMMC/TSI/PDMA
- CMU_G2D   : clocks for G2D/MDMA
- CMU_DISP  : clocks for DECON/HDMI/DSIM/MIXER
- CMU_AUD   : clocks for Cortex-A5/BUS/AUDIO
- CMU_BUS{0|1|2} : clocks for global data buses and global peripheral buses
- CMU_G3D   : clocks for 3D Graphics Engine
- CMU_GSCL  : clocks for GSCALER
- CMU_APOLLO: clocks for Cortex-A53 Quad-core processor.
- CMU_ATLAS : clocks for Cortex-A57 Quad-core processor,
  CoreSight and L2 cache controller.
- CMU_MSCL  : clocks for M2M (Memory to Memory) scaler and JPEG IPs.
- CMU_MFC   : clocks for MFC (Multi-Format Codec) IP.
- CMU_HEVC  : clocks for HEVC(High Efficiency Video Codec) decoder IP.
- CMU_ISP   : clocks for FIMC-ISP/DRC/SCLC/DIS/3DNR IPs.
- CMU_CAM0  : clocks for MIPI_CSIS{0|1}/FIMC_LITE_{A|B|D}/FIMC_3AA{0|1} IPs.
- CMU_CAM1  : clocks for COrtex-A5/MIPI_CSIS2/FIMC_LITE_C/FIMC-FD IPs.

3. pinctrl node for GPIO
- alive/aud/cpif/ese/finger/fsys/imem/nfc/peric/touch pad

4. Timer
- ARM architecture timer (armv8-timer)
- MCT (Multi Core Timer) timer

5. Interrupt controller (GIC-400)

6. BUS devices
- HS-I2C (High-Speed I2C) device
- SPI (Serial Peripheral Interface) device

7. Sound devices
- I2S bus
- LPASS (Low Power Audio Subsystem)

8. Power management devices
- CPUFREQ for for Cortex-A53/A57
- TMU (Thermal Management Unit) for Cortex-A53/A57, G3D, ISP

9. Display controller devices
- DECON (Display and enhancement controller) for panel output
- DSI (Display Serial Interface)
- MIC (Mobile Image Compressor)

10. USB
- USB 3.0 DRD (Dual Role Device) controller
- USB 3.0 Host controller

11. Storage devices
- MSHC (Mobile Stoarage Host Controller)

12. Misc devices
- UART device
- ADC (Analog Digital Converter)
- PWM (Pulse Width Modulation)
- ADMA (Advanced DMA) and PDMA (Peripheral DMA)

Signed-off-by: Chanwoo Choi 
Signed-off-by: Jaehoon Chung 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Jonghwa Lee 
Signed-off-by: Beomho Seo 
Signed-off-by: Jaewon Kim 
Signed-off-by: Hyungwon Hwang 
Signed-off-by: Inha Song 
Signed-off-by: Ingi kim 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Marek Szyprowski 
Signed-off-by: Andrzej Hajda 
Signed-off-by: Sylwester Nawrocki 
---
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  792 
 .../dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi |   23 +
 .../dts/exynos/exynos5433-tmu-sensor-conf.dtsi |   22 +
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi |  306 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1327 
 5 files changed, 2470 insertions(+)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
 create mode 100644 
arch/arm64/boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi

diff --git a/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi 
b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
new file mode 100644
index ..409bfb488b0b
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
@@ -0,0 +1,792 @@
+/*
+ * Samsung's Exynos5433 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ * Chanwoo Choi 
+ *
+ * Samsung's Exynos5433 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define PIN_PULL_NONE  0
+#define PIN_PULL_DOWN  1
+#define PIN_PULL_UP3
+
+#define PIN_DRV_LV10
+#define PIN_DRV_LV22
+#define PIN_DRV_LV31
+#define PIN_DRV_LV43
+
+#define PIN_IN 0
+#define PIN_OUT1
+#define PIN_FUNC1  2
+
+#define PIN(_func, _pin, _pull, _drv)  \
+   _pin {  \
+   samsung,pins = #_pin;   \
+  

[PATCH v2 4/7] pinctrl: samsung: Add GPF support for Exynos5433

2016-08-24 Thread Chanwoo Choi
From: Joonyoung Shim 

This patch add the support of GPF[1-5] pin of Exynos5433 SoC. The GPFx need
to support the multiple memory map because the registers of GPFx are located
in the different domain.

Cc: Linus Walleij 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Kukjin Kim 
Cc: linux-g...@vger.kernel.org
Signed-off-by: Joonyoung Shim 
Signed-off-by: Chanwoo Choi 
[robh : Acked for binding documentation]
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt | 1 +
 drivers/pinctrl/samsung/pinctrl-exynos.c  | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 37bc692445d4..499fb3484915 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -19,6 +19,7 @@ Required Properties:
   - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller.
   - "samsung,exynos5410-pinctrl": for Exynos5410 compatible pin-controller.
   - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
+  - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller.
   - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller.
 
 - reg: Base address of the pin controller hardware module and length of
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 12fa9d3f1113..b9605b8282be 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1360,6 +1360,11 @@ static const struct samsung_pin_bank_data 
exynos5433_pin_banks0[] = {
EXYNOS_PIN_BANK_EINTW(8, 0x020, "gpa1", 0x04),
EXYNOS_PIN_BANK_EINTW(8, 0x040, "gpa2", 0x08),
EXYNOS_PIN_BANK_EINTW(8, 0x060, "gpa3", 0x0c),
+   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x020, "gpf1", 0x1004, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x040, "gpf2", 0x1008, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(4, 0x060, "gpf3", 0x100c, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x080, "gpf4", 0x1010, 1, 0),
+   EXYNOS_PIN_BANK_EINTW_EXT(8, 0x0a0, "gpf5", 0x1014, 1, 0),
 };
 
 /* pin banks of exynos5433 pin-controller - AUD */
@@ -1441,6 +1446,7 @@ const struct samsung_pin_ctrl exynos5433_pin_ctrl[] = {
.eint_wkup_init = exynos_eint_wkup_init,
.suspend= exynos_pinctrl_suspend,
.resume = exynos_pinctrl_resume,
+   .nr_ext_resources = 1,
}, {
/* pin-controller instance 1 data */
.pin_banks  = exynos5433_pin_banks1,
-- 
1.9.1



[PATCH v2 0/7] arm64: dts: Add the dts file for Exynos5433 and TM/TM2E board

2016-08-24 Thread Chanwoo Choi
This patchset adds the Device Tree file for Samsung 64-bit Exynos5433 SoC
and TM/TM2E board based on Exynos5433. The Exynos5433 has Octa-core CPUs
(quad Cortex-A57 and quad Cortex-A53). The TM2 and TM2E are the Samsung board
based on Exynos5433 SoC.

I sent the Exynos5433 patches[2]. But it was not merged because of sending
the only SoC dtsi patch without board patches. So, I again send the Exynos5433
SoC patches with TM2/TM2E board dts files.

When making the patches, I get the guide from Krzysztof (Exynos SoC maintainer).
The maintainer requires that already developed and verified work should merge
them as one patch. So, this patchset include only three patches for Exynos5433
dtsi, TM2 dts and TM2E dts file.

I tested the display controller by using the modetest tool.
But, Samsung s6e3ha2 panel driver has not yet posted. So, the TM2 dts file
don't include the panel Device Tree node. I'll post the s6e3ha2 panel driver
on separate patch with a dt patch.

Changes from v1:
(https://lkml.org/lkml/2016/8/16/61)
- Merge the cpufreq patch for exynos5433[3] on PM/cpufreq tree.
- Add new patch to support the multiple IORESOURCE_MAP for samsung pinctrl 
driver.
- Drop the SYSMMU Device-Tree node which will be posted by Marek Szyprowski.
- Fix the code clean issue by Krzysztof Kozlowski and Rob Herring's comment.
- Delete the unnecessary alias from exynos5433-tm2.dts.
- Expand the range of cooling level of CPU device.
- Update the binding method of 'Exynos5433 audio subsystem'

Depends on:
This patchset are based on v4.8-rc3[1] and TM2 sound patches[2].

[1] v4.8-rc3
[2] http://lkml.org/lkml/2015/3/17/843
  : [PATCH v7 0/9] arm64: Add the support for new Exynos5433 SoC
[3] https://lkml.org/lkml/2016/8/16/64
  : [PATCH 3/7] cpufreq: dt: Add exynos5433 compatible to use generic cpufreq 
driver

Chanwoo Choi (6):
  clocksource: exynos_mct: Add the support for ARM64
  Documentation: bindings: Add Exynos5433 PMU compatible
  pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank
  arm64: dts: exynos: Add dts files for Samsung Exynos5433 64bit SoC
  arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board
  arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board

Joonyoung Shim (1):
  pinctrl: samsung: Add GPF support for Exynos5433

 .../devicetree/bindings/arm/samsung/pmu.txt|1 +
 .../bindings/arm/samsung/samsung-boards.txt|2 +
 .../bindings/pinctrl/samsung-pinctrl.txt   |   18 +
 arch/arm64/boot/dts/exynos/Makefile|5 +-
 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi |  792 
 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts  |  985 +++
 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts |   41 +
 .../dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi |   23 +
 .../dts/exynos/exynos5433-tmu-sensor-conf.dtsi |   22 +
 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi |  306 +
 arch/arm64/boot/dts/exynos/exynos5433.dtsi | 1327 
 drivers/clocksource/Kconfig|2 +-
 drivers/clocksource/exynos_mct.c   |4 +
 drivers/pinctrl/samsung/pinctrl-exynos.c   |   52 +-
 drivers/pinctrl/samsung/pinctrl-exynos.h   |   47 +-
 drivers/pinctrl/samsung/pinctrl-samsung.c  |   55 +-
 drivers/pinctrl/samsung/pinctrl-samsung.h  |7 +-
 17 files changed, 3646 insertions(+), 43 deletions(-)
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
 create mode 100644 
arch/arm64/boot/dts/exynos/exynos5433-tmu-g3d-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu-sensor-conf.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433-tmu.dtsi
 create mode 100644 arch/arm64/boot/dts/exynos/exynos5433.dtsi

-- 
1.9.1



[PATCH v2 3/7] pinctrl: samsung: Add the support the multiple IORESOURCE_MEM for one pin-bank

2016-08-24 Thread Chanwoo Choi
This patch supports the multiple IORESOURCE_MEM resources for one pin-bank.
In the pre-existing Exynos series, the registers of the gpio bank are included
in the one memory map. But, some gpio bank need to support the one more memory
map (IORESOURCE_MEM) because the registers of gpio bank are located in
the different memory map.

For example,
The both ALIVE and IMEM domain have the different memory base address.
The GFP[1-5] of exynos5433 are composed as following:
- ALIVE domain : WEINT_* registers
- IMEM domain  : CON/DAT/PUD/DRV/CONPDN/PUDPDN register

Cc: Linus Walleij 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Tomasz Figa 
Cc: Krzysztof Kozlowski 
Cc: Sylwester Nawrocki 
Cc: Kukjin Kim 
Cc: linux-g...@vger.kernel.org
Suggested-by: Tomasz Figa 
Signed-off-by: Chanwoo Choi 
---
 .../bindings/pinctrl/samsung-pinctrl.txt   | 17 +++
 drivers/pinctrl/samsung/pinctrl-exynos.c   | 46 +++---
 drivers/pinctrl/samsung/pinctrl-exynos.h   | 47 --
 drivers/pinctrl/samsung/pinctrl-samsung.c  | 55 ++
 drivers/pinctrl/samsung/pinctrl-samsung.h  |  7 ++-
 5 files changed, 131 insertions(+), 41 deletions(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 6db16b90873a..37bc692445d4 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -94,6 +94,11 @@ Required Properties:
   pin configuration should use the bindings listed in the 
"pinctrl-bindings.txt"
   file.
 
+Optional Properties:
+- reg: Second base address of the pin controller hardware module and length of
+  the address space it occupies if the specific register of the pin controller
+  are located in the different base address.
+
 External GPIO and Wakeup Interrupts:
 
 The controller supports two types of external interrupts over gpio. The first
@@ -305,6 +310,18 @@ Example 2: A pin-controller node with external wakeup 
interrupt controller node.
};
};
 
+   - A pin-controller node with multiple base address.
+
+   pinctrl_0: pinctrl@1058 {
+   compatible = "samsung,exynos5433-pinctrl";
+   reg = <0x1058 0x1a20>, <0x1109 0x100>;
+
+   wakeup-interrupt-controller {
+   compatible = "samsung,exynos7-wakeup-eint";
+   interrupts = <0 16 0>;
+   };
+   };
+
 Example 3: A uart client node that supports 'default' and 'flow-control' 
states.
 
uart@1380 {
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 051b5bf701a8..12fa9d3f1113 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -65,12 +65,13 @@ static void exynos_irq_mask(struct irq_data *irqd)
unsigned long reg_mask = our_chip->eint_mask + bank->eint_offset;
unsigned long mask;
unsigned long flags;
+   unsigned int eint_res_idx = bank->eint_res_idx;
 
spin_lock_irqsave(&bank->slock, flags);
 
-   mask = readl(d->virt_base + reg_mask);
+   mask = readl(d->virt_base[eint_res_idx] + reg_mask);
mask |= 1 << irqd->hwirq;
-   writel(mask, d->virt_base + reg_mask);
+   writel(mask, d->virt_base[eint_res_idx] + reg_mask);
 
spin_unlock_irqrestore(&bank->slock, flags);
 }
@@ -82,8 +83,9 @@ static void exynos_irq_ack(struct irq_data *irqd)
struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
struct samsung_pinctrl_drv_data *d = bank->drvdata;
unsigned long reg_pend = our_chip->eint_pend + bank->eint_offset;
+   unsigned int eint_res_idx = bank->eint_res_idx;
 
-   writel(1 << irqd->hwirq, d->virt_base + reg_pend);
+   writel(1 << irqd->hwirq, d->virt_base[eint_res_idx] + reg_pend);
 }
 
 static void exynos_irq_unmask(struct irq_data *irqd)
@@ -95,6 +97,7 @@ static void exynos_irq_unmask(struct irq_data *irqd)
unsigned long reg_mask = our_chip->eint_mask + bank->eint_offset;
unsigned long mask;
unsigned long flags;
+   unsigned int eint_res_idx = bank->eint_res_idx;
 
/*
 * Ack level interrupts right before unmask
@@ -109,9 +112,9 @@ static void exynos_irq_unmask(struct irq_data *irqd)
 
spin_lock_irqsave(&bank->slock, flags);
 
-   mask = readl(d->virt_base + reg_mask);
+   mask = readl(d->virt_base[eint_res_idx] + reg_mask);
mask &= ~(1 << irqd->hwirq);
-   writel(mask, d->virt_base + reg_mask);
+   writel(mask, d->virt_base[eint_res_idx] + reg_mask);
 
spin_unlock_irqrestore(&bank->slock, flags);
 }
@@ -125,6 +128,7 @@ static int exynos_irq_set_type(struct irq_data *irqd, 
unsigned int type)
unsigned int shift = EXYNOS_EINT_CON_LEN * irqd->hwirq;
unsigned int con, trig_type;
u

[PATCH v2 1/7] clocksource: exynos_mct: Add the support for ARM64

2016-08-24 Thread Chanwoo Choi
This patch adds the support for ARM 64bit. The delay_timer is only supported
on ARM 32bit.

Cc: Daniel Lezcano 
Cc: Thomas Gleixner 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Signed-off-by: Chanwoo Choi 
---
 drivers/clocksource/Kconfig  | 2 +-
 drivers/clocksource/exynos_mct.c | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 567788664723..ec443c318c77 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -351,7 +351,7 @@ config CLKSRC_METAG_GENERIC
 
 config CLKSRC_EXYNOS_MCT
bool "Exynos multi core timer driver" if COMPILE_TEST
-   depends on ARM
+   depends on ARM || ARM64
help
  Support for Multi Core Timer controller on Exynos SoCs.
 
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 41840d02c331..8f3488b80896 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -223,6 +223,7 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_read_count_32();
 }
 
+#if defined(CONFIG_ARM)
 static struct delay_timer exynos4_delay_timer;
 
 static cycles_t exynos4_read_current_timer(void)
@@ -231,14 +232,17 @@ static cycles_t exynos4_read_current_timer(void)
 "cycles_t needs to move to 32-bit for ARM64 usage");
return exynos4_read_count_32();
 }
+#endif
 
 static int __init exynos4_clocksource_init(void)
 {
exynos4_mct_frc_start();
 
+#if defined(CONFIG_ARM)
exynos4_delay_timer.read_current_timer = &exynos4_read_current_timer;
exynos4_delay_timer.freq = clk_rate;
register_current_timer_delay(&exynos4_delay_timer);
+#endif
 
if (clocksource_register_hz(&mct_frc, clk_rate))
panic("%s: can't register clocksource\n", mct_frc.name);
-- 
1.9.1



[PATCH] usbnet: ax88179_178a: Add support for writing the EEPROM

2016-08-24 Thread Alban Bedel
Implement the .set_eeprom callback to allow setting the MAC address
as well as a few other parameters. Note that the EEPROM must have a
correct PID/VID checksum set otherwise the SROM is used and reads
return the SROM content.

Signed-off-by: Alban Bedel 
---
 drivers/net/usb/ax88179_178a.c | 57 ++
 1 file changed, 57 insertions(+)

diff --git a/drivers/net/usb/ax88179_178a.c b/drivers/net/usb/ax88179_178a.c
index e6338c16081a..e6a986303dad 100644
--- a/drivers/net/usb/ax88179_178a.c
+++ b/drivers/net/usb/ax88179_178a.c
@@ -28,6 +28,7 @@
 
 #define AX88179_PHY_ID 0x03
 #define AX_EEPROM_LEN  0x100
+#define AX_EEPROM_BLOCK0x40u
 #define AX88179_EEPROM_MAGIC   0x17900b95
 #define AX_MCAST_FLTSIZE   8
 #define AX_MAX_MCAST   64
@@ -43,6 +44,7 @@
 #define AX_ACCESS_PHY  0x02
 #define AX_ACCESS_EEPROM   0x04
 #define AX_ACCESS_EFUS 0x05
+#define AX_RELOAD_EEPROM   0x06
 #define AX_PAUSE_WATERLVL_HIGH 0x54
 #define AX_PAUSE_WATERLVL_LOW  0x55
 
@@ -620,6 +622,60 @@ ax88179_get_eeprom(struct net_device *net, struct 
ethtool_eeprom *eeprom,
return 0;
 }
 
+static int
+ax88179_set_eeprom(struct net_device *net, struct ethtool_eeprom *eeprom,
+  u8 *data)
+{
+   struct usbnet *dev = netdev_priv(net);
+   unsigned int offset = eeprom->offset;
+   unsigned int len = eeprom->len;
+   int i, err = 0;
+   u8 *block;
+
+   /* The EEPROM data must be aligned on blocks of 64 bytes */
+   if ((offset % AX_EEPROM_BLOCK) || (len % AX_EEPROM_BLOCK)) {
+   offset = eeprom->offset / AX_EEPROM_BLOCK * AX_EEPROM_BLOCK;
+   len = eeprom->len + eeprom->offset - offset;
+   len = DIV_ROUND_UP(len, AX_EEPROM_BLOCK) * AX_EEPROM_BLOCK;
+
+   block = kmalloc(len, GFP_KERNEL);
+   if (!block)
+   return -ENOMEM;
+
+   /* Copy the current data, we could skip some but KISS */
+   for (i = 0; i < len; i += AX_EEPROM_BLOCK) {
+   err = __ax88179_read_cmd(dev, AX_ACCESS_EEPROM,
+(offset + i) >> 1,
+AX_EEPROM_BLOCK >> 1,
+AX_EEPROM_BLOCK,
+&block[i], 0);
+   if (err < 0) {
+   kfree(block);
+   return err;
+   }
+   }
+   memcpy(block + eeprom->offset - offset, data, eeprom->len);
+   } else {
+   block = data;
+   }
+
+   for (i = 0; err >= 0 && i < len; i += AX_EEPROM_BLOCK) {
+   err = ax88179_write_cmd(dev, AX_ACCESS_EEPROM,
+   (offset + i) >> 1,
+   AX_EEPROM_BLOCK >> 1,
+   AX_EEPROM_BLOCK, &block[i]);
+   }
+
+   if (block != data)
+   kfree(block);
+
+   /* Reload the EEPROM */
+   if (err >= 0)
+   err = ax88179_write_cmd(dev, AX_RELOAD_EEPROM, 0, 0, 0, NULL);
+
+   return err < 0 ? err : 0;
+}
+
 static int ax88179_get_settings(struct net_device *net, struct ethtool_cmd 
*cmd)
 {
struct usbnet *dev = netdev_priv(net);
@@ -826,6 +882,7 @@ static const struct ethtool_ops ax88179_ethtool_ops = {
.set_wol= ax88179_set_wol,
.get_eeprom_len = ax88179_get_eeprom_len,
.get_eeprom = ax88179_get_eeprom,
+   .set_eeprom = ax88179_set_eeprom,
.get_settings   = ax88179_get_settings,
.set_settings   = ax88179_set_settings,
.get_eee= ax88179_get_eee,
-- 
2.9.3



Re: [RFC PATCH 0/3] UART slave device bus

2016-08-24 Thread One Thousand Gnomes
> So you mean if I do "hciconfig hci0 down", then the uart-bus should
> "down" the tty and only on "hciconfig hci0 up" it should "up" the
> tty? I would expect a uart-bus slave-device takes control of the
> device ("up" it) on probe. It's hardwired anyway.

Today you can switch stacks at runtime, you can switch between the kernel
stack and debug tools at runtime. Breaking that is a regression.

> Also what should happen if old userspace use hciattach while
> uart-bus slave-device doesn't have control over it? Do you

You would either use the old hciattach in which case you wouldn't be able
to manage it via a new API while attached, or the new API in which case
you wouldn't be able to manage it via the old interface while it was
being used directly.

> Or do you suggest to register hci1 and one cannot use hci0? I guess
> this breaks even more devices, as the device number changes.

Device numbers are dynamic anyway. Plug a USB adapter in and if it beats
your onboard adapter to registration then the order changes.

> So yes, from your point of view there is a regression, just because
> it's working automatically. So let's just not convert existing boards
> with working hciattach based bluetooth devices. New devices can use

>From a distribution point of view that would be a nightmare.

> the uart-bus, as it's not a regression for them and Nokia N series
> can also do it, since they have no working bluetooth at all at the
> moment.

The Nokia N series is a weird corner case.

> > In many cases you'll also still need the tty interface to do
> > things like firmware upgrades.  
> 
> I would expect the uart-slave driver to know how to do firmware
> updates. Actually most bluetooth chips are initialized by uploading
> a firmware to them.

Usually no - you don't want a ton of kernel code for flashing adapters
when they have built in firmware (similar issue for 3G modems)

> And there are definitely uart drivers not caring about having a tty
> device. Nokia's vendor driver for their bluetooth protocol contains
> a custom omap-serial driver combined with the actual bluetooth
> driver. There is nothing related to the tty framework. I think the
> same would work for the other hardwired bluetooth chips perfectly
> fine.

That means having two different omap serial drivers to maintain which is
not ideal.

To me there are four different things

1. bluetooth devices "just work". That can be user space (eg it seems to
just work on my Fedora boxes and bluetooth enumeration is being done via
user space, or may be via kernel enumeration, or a mix. PPP is an
existing example of this - serial port PPP is an ldisc but ports that are
not UART like speak directly to the PPP layer as network adapters.

2. Sideband controls and power management, where we need to give the
tty_port a child device and power it up/down properly and have the
tty_port hooks to do so based upon the ldisc protocol state machine when
talking stuff like NMEA or HCI.

3. The special case UART power saving features/hacks like GPIO snooping,
again with the right hooks

4. Whether it's useful to be able to create a tty device in kernel and
attach that to stuff with no userspace involved.

All are independent.

Alan


Re: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

2016-08-24 Thread Leon Romanovsky
On Wed, Aug 24, 2016 at 04:44:50AM +0800, Salil Mehta wrote:
> This patch is meant to add support of ACPI to the Hisilicon RoCE
> driver.
>
> Changes done are primarily meant to detect the type and then either
> use DT specific or ACPI spcific functions. Where ever possible,
> this patch tries to make use of Unified Device Property Interface
> APIs to support both DT and ACPI through single interface.
>
> This patch depends upon HNS ethernet driver to Reset RoCE. This
> function within HNS ethernet driver has also been enhanced to
> support ACPI and is part of other accompanying patch with this
> patch-set.
>
> NOTE: The changes in this patch are done over below branch,
> https://github.com/dledford/linux/tree/hns-roce
>
> Signed-off-by: Salil Mehta 
> ---
> Change Log
>
> PATCH V1: Initial version to support ACPI in HNS RoCE driver.
> ---
>  drivers/infiniband/hw/hns/hns_roce_device.h |2 +-
>  drivers/infiniband/hw/hns/hns_roce_eq.c |2 +-
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++--
>  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |2 +-
>  drivers/infiniband/hw/hns/hns_roce_main.c   |  127 
> ++-
>  5 files changed, 136 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h 
> b/drivers/infiniband/hw/hns/hns_roce_device.h
> index 00f01be..ea73580 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_device.h
> +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
> @@ -531,7 +531,7 @@ struct hns_roce_dev {
>   struct ib_deviceib_dev;
>   struct platform_device  *pdev;
>   struct hns_roce_uar priv_uar;
> - const char  *irq_names;
> + const char  *irq_names[HNS_ROCE_MAX_IRQ_NUM];
>   spinlock_t  sm_lock;
>   spinlock_t  cq_db_lock;
>   spinlock_t  bt_cmd_lock;
> diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c 
> b/drivers/infiniband/hw/hns/hns_roce_eq.c
> index 5febbb4..98af7fe 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_eq.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
> @@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev *hr_dev)
>
>   for (j = 0; j < eq_num; j++) {
>   ret = request_irq(eq_table->eq[j].irq, hns_roce_msi_x_interrupt,
> -   0, hr_dev->irq_names, eq_table->eq + j);
> +   0, hr_dev->irq_names[j], eq_table->eq + j);
>   if (ret) {
>   dev_err(dev, "request irq error!\n");
>   goto err_request_irq_fail;
> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c 
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> index b52f3ba..399f5de 100644
> --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> @@ -31,6 +31,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include "hns_roce_common.h"
>  #include "hns_roce_device.h"
> @@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct hns_roce_dev 
> *hr_dev, int enable_flag)
>   * @enable: true -- drop reset, false -- reset
>   * return 0 - success , negative --fail
>   */
> -int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
> +int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
>  {
>   struct device_node *dsaf_node;
>   struct device *dev = &hr_dev->pdev->dev;
>   struct device_node *np = dev->of_node;
> + struct fwnode_handle *fwnode;
>   int ret;
>
> - dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> - if (!dsaf_node) {
> - dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
> - return -EINVAL;
> + /* check if this is DT/ACPI case */
> + if (dev_of_node(dev)) {
> + dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> + if (!dsaf_node) {
> + dev_err(dev, "could not find dsaf-handle\n");
> + return -EINVAL;
> + }
> + fwnode = &dsaf_node->fwnode;
> + } else if (is_acpi_device_node(dev->fwnode)) {
> + struct acpi_reference_args args;
> +
> + ret = acpi_node_get_property_reference(dev->fwnode,
> +"dsaf-handle", 0, &args);
> + if (ret) {
> + dev_err(dev, "could not find dsaf-handle\n");
> + return ret;
> + }
> + fwnode = acpi_fwnode_handle(args.adev);
> + } else {
> + dev_err(dev, "cannot read data from DT or ACPI\n");
> + return -ENXIO;
>   }
>
> - ret = hns_dsaf_roce_reset(&dsaf_node->fwnode, false);
> + ret = hns_dsaf_roce_reset(fwnode, false);
>   if (ret)
>   return ret;
>
> - if (enable) {
> + if (dereset) {
>   msleep(SLEEP_TIME_INTERVAL);
> - return hns_dsaf_roce_reset(&dsaf_node->fwnode, true);
> + ret = hns_dsaf_roce_

[PATCH v2] [media] v4l2-async: Always unregister the subdev on failure

2016-08-24 Thread Alban Bedel
In v4l2_async_test_notify() if the registered_async callback or the
complete notifier returns an error the subdev is not unregistered.
This leave paths where v4l2_async_register_subdev() can fail but
leave the subdev still registered.

Add the required calls to v4l2_device_unregister_subdev() to plug
these holes.

Signed-off-by: Alban Bedel 
---
Changelog:
v2: * Added the missing unbind() calls as suggested by Javier.
---
 drivers/media/v4l2-core/v4l2-async.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-async.c 
b/drivers/media/v4l2-core/v4l2-async.c
index ceb28d47c3f9..abe512d0b4cb 100644
--- a/drivers/media/v4l2-core/v4l2-async.c
+++ b/drivers/media/v4l2-core/v4l2-async.c
@@ -113,23 +113,28 @@ static int v4l2_async_test_notify(struct 
v4l2_async_notifier *notifier,
list_move(&sd->async_list, ¬ifier->done);
 
ret = v4l2_device_register_subdev(notifier->v4l2_dev, sd);
-   if (ret < 0) {
-   if (notifier->unbind)
-   notifier->unbind(notifier, sd, asd);
-   return ret;
-   }
+   if (ret < 0)
+   goto err_subdev_register;
 
ret = v4l2_subdev_call(sd, core, registered_async);
-   if (ret < 0 && ret != -ENOIOCTLCMD) {
-   if (notifier->unbind)
-   notifier->unbind(notifier, sd, asd);
-   return ret;
+   if (ret < 0 && ret != -ENOIOCTLCMD)
+   goto err_subdev_call;
+
+   if (list_empty(¬ifier->waiting) && notifier->complete) {
+   ret = notifier->complete(notifier);
+   if (ret < 0)
+   goto err_subdev_call;
}
 
-   if (list_empty(¬ifier->waiting) && notifier->complete)
-   return notifier->complete(notifier);
-
return 0;
+
+err_subdev_call:
+   v4l2_device_unregister_subdev(sd);
+err_subdev_register:
+   if (notifier->unbind)
+   notifier->unbind(notifier, sd, asd);
+
+   return ret;
 }
 
 static void v4l2_async_cleanup(struct v4l2_subdev *sd)
-- 
2.9.3



Re: CVE-2014-9900 fix is not upstream

2016-08-24 Thread Lennart Sorensen
On Tue, Aug 23, 2016 at 10:25:45PM +0100, Al Viro wrote:
> Sadly, sizeof is what we use when copying that sucker to userland.  So these
> padding bits in the end would've leaked, true enough, and the case is somewhat
> weaker.  And any normal architecture will have those, but then any such
> architecture will have no more trouble zeroing a 32bit value than 16bit one.

Hmm, good point.  Too bad I don't see a compiler option of "zero all
padding in structs".  Certainly generating the code should not really
be that different.

I see someone did request it 2 years ago:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479

-- 
Len Sorensen


Re: [PATCH v2 1/5] ethernet: add sun8i-emac driver

2016-08-24 Thread LABBE Corentin
> > +/* Set Management Data Clock, must be call after device reset */
> > +static void sun8i_emac_set_mdc(struct net_device *ndev)
> > +{
> > +   struct sun8i_emac_priv *priv = netdev_priv(ndev);
> > +   unsigned long rate;
> > +   u32 reg;
> > +
> > +   rate = clk_get_rate(priv->ahb_clk);
> > +   if (rate > 16000)
> > +   reg = 0x3 << 20; /* AHB / 128 */
> > +   else if (rate > 8000)
> > +   reg = 0x2 << 20; /* AHB / 64 */
> > +   else if (rate > 4000)
> > +   reg = 0x1 << 20; /* AHB / 32 */
> > +   else
> > +   reg = 0x0 << 20; /* AHB / 16 */
> > +   netif_dbg(priv, link, ndev, "MDC auto : %x\n", reg);
> > +   writel(reg, priv->base + SUN8I_EMAC_MDIO_CMD);
> 
> You could also expose that as a clock.
> 

For which purpose ?
No ethernet driver expose the MDC as clock and I dont see any interest:
- I dont think that tuning it give any gain
- Knowing it's value is of little interest

Regards



Re: [PATCH v2 5/8] hisi_sas: add v2 hw slot complete internal abort support

2016-08-24 Thread John Garry

On 24/08/2016 13:59, Hannes Reinecke wrote:

On 08/24/2016 01:05 PM, John Garry wrote:

Add code in slot_complete_v2_hw() to deal with the
slots which have completed due to internal abort.

The status codes have the following meaning:
- STAT_IO_ABORTED: the IO has been aborted due to
internal abort, whether by device or individual
abort command
- STAT_IO_COMPLETE: internal abort command has
completed successfully for device or individual
abort command
- STAT_IO_NO_DEVICE: internal abort command has
completed for device but cannot find any IO
- STAT_IO_NOT_VALID: internal abort command has
completed for single command but could not
find the command

Signed-off-by: John Garry 
---
 drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c 
b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
index fec1675..bf9b693 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
@@ -227,6 +227,13 @@
 #define CMPLT_HDR_RSPNS_XFRD_MSK   (0x1 << CMPLT_HDR_RSPNS_XFRD_OFF)
 #define CMPLT_HDR_ERX_OFF  12
 #define CMPLT_HDR_ERX_MSK  (0x1 << CMPLT_HDR_ERX_OFF)
+#define CMPLT_HDR_ABORT_STAT_OFF   13
+#define CMPLT_HDR_ABORT_STAT_MSK   (0x7 << CMPLT_HDR_ABORT_STAT_OFF)
+/* abort_stat */
+#define STAT_IO_NOT_VALID  0x1
+#define STAT_IO_NO_DEVICE  0x2
+#define STAT_IO_COMPLETE   0x3
+#define STAT_IO_ABORTED0x4
 /* dw1 */
 #define CMPLT_HDR_IPTT_OFF 0
 #define CMPLT_HDR_IPTT_MSK (0x << CMPLT_HDR_IPTT_OFF)
@@ -1569,6 +1576,30 @@ slot_complete_v2_hw(struct hisi_hba *hisi_hba, struct 
hisi_sas_slot *slot,
goto out;
}

+   /* Use SAS+TMF status codes */
+   switch ((complete_hdr->dw0 & CMPLT_HDR_ABORT_STAT_MSK)
+   >> CMPLT_HDR_ABORT_STAT_OFF) {
+   case STAT_IO_ABORTED:
+   /* this io has been aborted by abort command */
+   ts->stat = SAS_ABORTED_TASK;
+   goto out;
+   case STAT_IO_COMPLETE:
+   /* internal abort command complete */
+   ts->stat = TMF_RESP_FUNC_COMPLETE;
+   goto out;
+   case STAT_IO_NO_DEVICE:
+   ts->stat = TMF_RESP_FUNC_COMPLETE;
+   goto out;
+   case STAT_IO_NOT_VALID:
+   /* abort single io, controller don't find
+* the io need to abort
+*/
+   ts->stat = TMF_RESP_FUNC_FAILED;
+   goto out;

Hmm. This will cause the SCSI EH to kick in.
And then, according to the description abort has succeeded, it's just
that for some reason the associated command couldn't be found.
So couldn't this be due to a race condition, and the command has in fact
been aborted correctly (and the code is just too slow acknowledging it)?



Hi Hannes,

I'm not sure I fully get your question.

The internal abort would happen from the SCSI error handling. An example 
would be when the disk was not safely removed and some IO is still in 
flight. In this case the IO will timeout, SCSI EH starts, and we try to 
abort the command in LLDD, by TMF (which would fail) and internal abort.


For internal abort, if the abort command succeeds then 2 things happen:
- abort task completes with status STAT_IO_COMPLETE
- task which was aborted completes with status STAT_IO_ABORTED

If the command does not abort successfully then:
- abort task completes with status STAT_IO_NOT_VALID
- task which we wanted to be aborted does not complete and is probably 
still in the slave device


I hope that this makes it clear.

Thanks,
John


Cheers,

Hannes






Re: [PATCHv6 1/3] usb: USB Type-C connector class

2016-08-24 Thread Vincent Palatin
Sorry if I'm making redundant comments with previous discussions, I
might have missed a few threads.


On Mon, Aug 22, 2016 at 2:05 PM, Heikki Krogerus
 wrote:
> The purpose of USB Type-C connector class is to provide
> unified interface for the user space to get the status and
> basic information about USB Type-C connectors on a system,
> control over data role swapping, and when the port supports
> USB Power Delivery, also control over power role swapping
> and Alternate Modes.
>
> Signed-off-by: Heikki Krogerus 
> ---
>  Documentation/ABI/testing/sysfs-class-typec |  199 +
>  Documentation/usb/typec.txt |  103 +++
>  MAINTAINERS |9 +
>  drivers/usb/Kconfig |2 +
>  drivers/usb/Makefile|2 +
>  drivers/usb/typec/Kconfig   |7 +
>  drivers/usb/typec/Makefile  |1 +
>  drivers/usb/typec/typec.c   | 1090 
> +++
>  include/linux/usb/typec.h   |  260 +++
>  9 files changed, 1673 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-class-typec
>  create mode 100644 Documentation/usb/typec.txt
>  create mode 100644 drivers/usb/typec/Kconfig
>  create mode 100644 drivers/usb/typec/Makefile
>  create mode 100644 drivers/usb/typec/typec.c
>  create mode 100644 include/linux/usb/typec.h
>
> diff --git a/Documentation/ABI/testing/sysfs-class-typec 
> b/Documentation/ABI/testing/sysfs-class-typec
> new file mode 100644
> index 000..e6179d3
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-typec
> @@ -0,0 +1,199 @@
> +USB Type-C port devices (eg. /sys/class/typec/usbc0/)
> +
> +What:  /sys/class/typec//current_data_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current USB data role the port is operating in. This
> +   attribute can be used for requesting data role swapping on the
> +   port.

role swapping is sometimes a long operation. maybe we need to say
explicitly whether the 'write' is synchronous and returns when the
swap has succeeded / failed or asynchronous (and requires polling
current_data_role afterwards to know the result ?)


> +
> +   Valid values:
> +   - host
> +   - device

the USB workgroup has settled for DFP/UFP rather than host/device ?


> +
> +What:  /sys/class/typec//current_power_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The current power role of the port. This attribute can be used
> +   to request power role swap on the port when the port supports

ditto


> +   USB Power Delivery.
> +
> +   Valid values:
> +   - source
> +   - sink
> +
> +What:  /sys/class/typec//current_vconn_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current VCONN role of the port. This attribute can 
> be
> +   used to request VCONN role swap on the port when the port
> +   supports USB Power Delivery.
> +
> +   Valid values are:
> +   - source
> +   - sink


either we are currently sourcing vconn or not, but even if you are
not, you are probably not a vconn sink either (ie only vconn-powered
accessory are, your usual linux-powered laptop/phone is probably not)


> +
> +What:  /sys/class/typec//power_operation_mode
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   Shows the current power operational mode the port is in.
> +
> +   Valid values:
> +   - USB - Normal power levels defined in USB specifications
> +   - BC1.2 - Power levels defined in Battery Charging 
> Specification
> + v1.2
> +   - USB Type-C 1.5A - Higher 1.5A current defined in USB Type-C
> +   specification.
> +   - USB Type-C 3.0A - Higher 3A current defined in USB Type-C
> +   specification.
> +- USB Power Delivery - The voltages and currents defined in 
> USB
> +  Power Delivery specification
> +
> +What:  /sys/class/typec//preferred_role
> +Date:  June 2016
> +Contact:   Heikki Krogerus 
> +Description:
> +   The user space can notify the driver about the preferred role.
> +   It should be handled as enabling of Try.SRC or Try.SNK, as
> +   defined in USB Type-C specification, in the port drivers. By
> +   default there is no preferred role.
> +
> +   Valid values:
> +   - host
> +   - device
> +   - For example "none" to remove preference (anything else 
> except
>

Re: [PATCH] nvme: Fix nvme_get/set_features() with a NULL result pointer

2016-08-24 Thread Jens Axboe

On 08/24/2016 04:52 AM, Andy Lutomirski wrote:

nvme_set_features() callers seem to expect that passing NULL as the
result pointer is acceptable.  Teach nvme_set_features() not to try to
write to the NULL address.

For symmetry, make the same change to nvme_get_features(), despite the
fact that all current callers pass a valid result pointer.

I assume that this bug hasn't been reported in practice because
the callers that pass NULL are all in the SCSI translation layer
and no one uses the relevant operations.


Thanks, applied for 4.8.


--
Jens Axboe


Re: [PATCH] net: phy: micrel: remove suspend/resume

2016-08-24 Thread Christophe Leroy



Le 23/08/2016 à 21:03, Florian Fainelli a écrit :

+others,

On 08/23/2016 04:13 AM, Christophe Leroy wrote:

In ERRATA DS8700A dated 05 May 2016, Microship recommends to
not use software power down mode on KSZ8041 family.


s/Microship/Microchip/


They say they have no plan to fix this ERRATA in future releases.


The errata applies to specific revisions, is this revision present in
the lower 4 bits of the MII_PHYSID2 register such that it could be used
to key the disabling of the power down?


It doesn't seem clear to me how this could/should be handled.

According to the documentation, all variants have the same ID 0x0022151x 
with revision x. A3 has ID 0x00221512 and A4 has 0x00221513.
According to the doc, the KSZ8041RNLI should has same ID. But according 
to micrel driver, it has ID 0x00221537. And the buggy revision of that 
one is rev A. Is it what the 7 means ?


The ERRATA applies to KSZ8041NL revision A4 and to KSZ8041NL-AM revision 
A3. My understanding it that both variants have ID 0x0022151x, ie 
KSZ8041NL-AM revision A3 has ID 0x00221512 and KSZ8041NL revision A4 has 
ID 0x00221513. But KSZ8041NL revision A3 also has ID 0x00221512 and the 
ERRATA doesn't apply to it.


So what can be done really ? Only apply the fix to ID 0x00221513 (which 
is what I need as I have KSZ8041NL revision A4 on my boards) ? Or apply 
it for all KSZ8041 and KSZ8041RNLI to be on the safe side ?


Christophe






http://ww1.microchip.com/downloads/en/DeviceDoc/8700A.pdf

Signed-off-by: Christophe Leroy 
---
 drivers/net/phy/micrel.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 053e879..f456c55 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -837,8 +837,6 @@ static struct phy_driver ksphy_driver[] = {
.get_sset_count = kszphy_get_sset_count,
.get_strings= kszphy_get_strings,
.get_stats  = kszphy_get_stats,
-   .suspend= genphy_suspend,
-   .resume = genphy_resume,
 }, {
.phy_id = PHY_ID_KSZ8041RNLI,
.phy_id_mask= MICREL_PHY_ID_MASK,
@@ -856,8 +854,6 @@ static struct phy_driver ksphy_driver[] = {
.get_sset_count = kszphy_get_sset_count,
.get_strings= kszphy_get_strings,
.get_stats  = kszphy_get_stats,
-   .suspend= genphy_suspend,
-   .resume = genphy_resume,
 }, {
.phy_id = PHY_ID_KSZ8051,
.phy_id_mask= MICREL_PHY_ID_MASK,






Re: [PATCH 1/3] perf/x86/intel/bts: Fix confused ordering of PMU callbacks

2016-08-24 Thread Alexander Shishkin
Alexander Shishkin  writes:

> Alexander Shishkin  writes:
>
>> Signed-off-by: Alexander Shishkin 
>
> Ok, this one is broken, please disregard.

Vince, can you try the following (with the other two in this series)?

---

>From 68713194b3df8e565c4d319a80e9e7338fa1ec13 Mon Sep 17 00:00:00 2001
From: Alexander Shishkin 
Date: Tue, 23 Aug 2016 10:50:57 +0300
Subject: [PATCH] perf/x86/intel/bts: Fix confused ordering of PMU callbacks

The intel_bts driver is using a cpu-local 'started' variable to order
callbacks and PMIs and make sure that AUX transactions don't get messed
up. However, the ordering rules in regard to this variable is a complete
mess, which recently resulted in perf_fuzzer-triggered warnings and
panics.

The general ordering rule that is patch is enforcing is that this
cpu-local variable be set only when the cpu-local AUX transaction is
active; consequently, this variable is to be checked before the AUX
related bits can be touched.

Signed-off-by: Alexander Shishkin 
---
 arch/x86/events/intel/bts.c | 119 +++-
 1 file changed, 96 insertions(+), 23 deletions(-)

diff --git a/arch/x86/events/intel/bts.c b/arch/x86/events/intel/bts.c
index 0a6e393a2e..13ce76e895 100644
--- a/arch/x86/events/intel/bts.c
+++ b/arch/x86/events/intel/bts.c
@@ -31,7 +31,18 @@
 struct bts_ctx {
struct perf_output_handle   handle;
struct debug_store  ds_back;
-   int started;
+   local_t pmi_pending;
+   int state;
+};
+
+/* BTS context states: */
+enum {
+   /* no ongoing AUX transactions */
+   BTS_STATE_STOPPED = 0,
+   /* AUX transaction is on, BTS tracing is disabled */
+   BTS_STATE_INACTIVE,
+   /* AUX transaction is on, BTS tracing is running */
+   BTS_STATE_ACTIVE,
 };
 
 static DEFINE_PER_CPU(struct bts_ctx, bts_ctx);
@@ -191,6 +202,9 @@ static void bts_update(struct bts_ctx *bts)
if (ds->bts_index >= ds->bts_absolute_maximum)
local_inc(&buf->lost);
 
+   if (ds->bts_index >= ds->bts_interrupt_threshold)
+   local_inc(&bts->pmi_pending);
+
/*
 * old and head are always in the same physical buffer, so we
 * can subtract them to get the data size.
@@ -204,6 +218,16 @@ static void bts_update(struct bts_ctx *bts)
 static int
 bts_buffer_reset(struct bts_buffer *buf, struct perf_output_handle *handle);
 
+/*
+ * Ordering PMU callbacks wrt themselves and the PMI is done by means
+ * of bts::state, which:
+ *  - is set when bts::handle::event is valid, that is, between
+ *perf_aux_output_begin() and perf_aux_output_end();
+ *  - is zero otherwise;
+ *  - is ordered against bts::handle::event with a local barrier to
+ *enforce CPU ordering.
+ */
+
 static void __bts_event_start(struct perf_event *event)
 {
struct bts_ctx *bts = this_cpu_ptr(&bts_ctx);
@@ -221,10 +245,13 @@ static void __bts_event_start(struct perf_event *event)
 
/*
 * local barrier to make sure that ds configuration made it
-* before we enable BTS
+* before we enable BTS and bts::state goes ACTIVE
 */
wmb();
 
+   /* INACTIVE/STOPPED -> ACTIVE */
+   WRITE_ONCE(bts->state, BTS_STATE_ACTIVE);
+
intel_pmu_enable_bts(config);
 
 }
@@ -251,9 +278,6 @@ static void bts_event_start(struct perf_event *event, int 
flags)
 
__bts_event_start(event);
 
-   /* PMI handler: this counter is running and likely generating PMIs */
-   ACCESS_ONCE(bts->started) = 1;
-
return;
 
 fail_end_stop:
@@ -265,28 +289,36 @@ fail_stop:
 
 static void __bts_event_stop(struct perf_event *event)
 {
+   struct bts_ctx *bts = this_cpu_ptr(&bts_ctx);
+
+   /* ACTIVE -> INACTIVE */
+   WRITE_ONCE(bts->state, BTS_STATE_INACTIVE);
+
/*
 * No extra synchronization is mandated by the documentation to have
 * BTS data stores globally visible.
 */
intel_pmu_disable_bts();
-
-   if (event->hw.state & PERF_HES_STOPPED)
-   return;
-
-   ACCESS_ONCE(event->hw.state) |= PERF_HES_STOPPED;
 }
 
 static void bts_event_stop(struct perf_event *event, int flags)
 {
struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
struct bts_ctx *bts = this_cpu_ptr(&bts_ctx);
-   struct bts_buffer *buf = perf_get_aux(&bts->handle);
+   struct bts_buffer *buf;
+
+   if (READ_ONCE(bts->state) == BTS_STATE_ACTIVE)
+   __bts_event_stop(event);
+
+   /*
+* order buf (handle::event load) against bts::state store;
+* matches wmb() in intel_bts_interrupt()
+*/
+   mb();
 
-   /* PMI handler: don't restart this counter */
-   ACCESS_ONCE(bts->started) = 0;
+   buf = perf_get_aux(&bts->handle);
 
-   __bts_event_stop(event);
+   event->hw.state |= PERF

Re: [PATCH] drm/tegra: Fix window[0] base address corruption

2016-08-24 Thread Thierry Reding
On Sun, Aug 21, 2016 at 11:57:58AM +0300, Dmitry Osipenko wrote:
> Window uses shared stride for UV planes and tegra_dc_window struct
> defines array of 2 strides per window. That's not taken in account
> during setting up of the window addresses and strides, resulting in
> out-of-bounds write of the 3-rd (non-existent) V plane stride that
> overwrites Y plane base address.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/gpu/drm/tegra/dc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

Applied and added a comment to the code why it is safe to do this.

Thanks,
Thierry


signature.asc
Description: PGP signature


Re: [PATCH][RFC v3] PCI: Workaround to enable poweroff on Mac Pro 11

2016-08-24 Thread Lukas Wunner
On Fri, Aug 19, 2016 at 04:30:25PM +0800, Chen Yu wrote:
> People reported that they can not do a poweroff nor a
> suspend to ram on their Mac Pro 11. After some investigations
> it was found that, once the PCI bridge :00:1c.0 reassigns its
> mm windows to ([mem 0x7fa0-0x7fbf] and
> [mem 0x7fc0-0x7fdf 64bit pref]), the region of ACPI
> io resource 0x1804 becomes unaccessible immediately, where the
> ACPI Sleep register is located, as a result neither poweroff(S5)
> nor suspend to ram(S3) works.

To provide a bit more context:

The root port in question (:00:1c.0) is not listed in the DSDT.
On macOS, only devices present in the ACPI namespace are incorporated
into the I/O Kit registry. Consequently macOS pretends that this root
port doesn't exist. It's not listed in the "ioreg -l" output and thus
no driver is attached to this device.

So what we're dealing with is sloppiness on the part of Apple:
Some engineer probably forgot to disable this unused root port
and they didn't notice it during testing because their OS ignores
such devices.

We could in principle achieve the same behaviour by adding a PCI
device only if it has an ACPI companion, perhaps quirk this only
to Macs. I'm not sure if that's the right thing to do though.
What if they hide devices from macOS but we want to access them
on Linux?

What's really odd is that changing *memory* windows affects
accessibility of *I/O ports*.

One theory would be that I/O ports are somehow mapped into memory.
The GPIO pins of Intel chipsets are usually accessible through
I/O ports, but I've recently looked at the DSDT of the newest
MacBook9,1 (2016) and it looks like they're now accessed through
SystemMemory instead of SystemIO. Perhaps someone at Intel knows
about these intricacies of their chipsets.

If I/O ports are indeed mapped into memory, we need to find a way
to identify and reserve that region. So while this patch seems
like a workable and sufficiently small fix, it might mask a larger
underlying issue. It's certainly a problem though that these
machines currently cannot power off or suspend.

FWIW, we have a somewhat similar issue with the Apple gmux
(a microcontroller built into dual GPU MacBook Pros). That chip
is attached to the LPC bus and accessed through I/O ports.
It turns out that once VGA IO is locked to the discrete GPU
using vgaarb, gmux' I/O ports suddenly become inaccessible.
Apparently its I/O ports are routed to the secondary PCI bus
to which the discrete GPU is connected, and no longer to the
root bus on which the LPC bridge resides. However gmux' I/O ports
are in the 0x700-0x7ff range, whereas the VGA registers are in
the 0x3b0-0x3bb and 0x3c0-0x3df range. So that's another oddity
of Intel chipsets with regards to I/O accessibility.

Best regards,

Lukas

> 
> As suggested by Bjorn, further testing shows that, there is an
> unreported device may be (using) conflict with above aperture,
> which brings unpredictable result such as the failure of accessing
> the io port, which blocks the poweroff(S5). Besides if we reassign
> the memory aperture to the other place, the poweroff works again.
> 
> As we do not find any resource declared in _CRS which contain above
> memory aperture, and Mac OS does not use this pci bridge neither, we
> choose a simple workaround to clear the hotplug flag(suggested by
> Yinghai Lu), thus do not allocate any resource for this pci bridge,
> and thereby no conflict anymore.
> 
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=103211
> Cc: Bjorn Helgaas 
> Cc: Rafael J. Wysocki 
> Cc: Lukas Wunner 
> Signed-off-by: Chen Yu 
> ---
>  drivers/pci/quirks.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 37ff015..04bbdba 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -2776,6 +2776,26 @@ static void quirk_hotplug_bridge(struct pci_dev *dev)
>  DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_HINT, 0x0020, quirk_hotplug_bridge);
>  
>  /*
> + * Apple: Avoid programming the memory/io aperture of 00:1c.0
> + *
> + * BIOS does not declare any resource for 00:1c.0, but with
> + * hotplug flag set, thus the OS allocates:
> + * [mem 0x7fa0 - 0x7fbf]
> + * [mem 0x7fc0-0x7fdf 64bit pref]
> + * which is conflict with an unreported device, which
> + * causes unpredictable result such as accessing io port.
> + * So clear the hotplug flag to work around it.
> + */
> +static void quirk_apple_mbp_poweroff(struct pci_dev *dev)
> +{
> + if (dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,4") ||
> + dmi_match(DMI_PRODUCT_NAME, "MacBookPro11,5"))
> + dev->is_hotplug_bridge = 0;
> +}
> +
> +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
> quirk_apple_mbp_poweroff);
> +
> +/*
>   * This is a quirk for the Ricoh MMC controller found as a part of
>   * some mulifunction chips.
>  
> -- 
> 2.7.4
> 


Re: [PATCH v4] block: make sure big bio is splitted into at most 256 bvecs

2016-08-24 Thread Jens Axboe

On 08/23/2016 07:49 AM, Ming Lei wrote:

After arbitrary bio size is supported, the incoming bio may
be very big. We have to split the bio into small bios so that
each holds at most BIO_MAX_PAGES bvecs for safety reason, such
as bio_clone().

This patch fixes the following kernel crash:


[  172.660142] BUG: unable to handle kernel NULL pointer dereference at 
0028
[  172.660229] IP: [] bio_trim+0xf/0x2a
[  172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
[  172.660399] Oops:  [#1] SMP
[...]
[  172.664780] Call Trace:
[  172.664813]  [] ? raid1_make_request+0x2e8/0xad7 [raid1]
[  172.664846]  [] ? blk_queue_split+0x377/0x3d4
[  172.664880]  [] ? md_make_request+0xf6/0x1e9 [md_mod]
[  172.664912]  [] ? generic_make_request+0xb5/0x155
[  172.664947]  [] ? prio_io+0x85/0x95 [bcache]
[  172.664981]  [] ? register_cache_set+0x355/0x8d0 [bcache]
[  172.665016]  [] ? register_bcache+0x1006/0x1174 [bcache]


The issue can be reproduced by the following steps:
- create one raid1 over two virtio-blk
- build bcache device over the above raid1 and another cache device
and bucket size is set as 2Mbytes
- set cache mode as writeback
- run random write over ext4 on the bcache device


Applied for 4.8, thanks.

--
Jens Axboe



[v.3] clocksource:clps711x-timer:- Unmap a region obtained by remap.

2016-08-24 Thread Arvind Yadav
iounmap frees the mapping when timer id is not matching.

Signed-off-by: Arvind Yadav 
---
 drivers/clocksource/clps711x-timer.c | 41 +++-
 1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/clocksource/clps711x-timer.c 
b/drivers/clocksource/clps711x-timer.c
index 24db6d6..784c000 100644
--- a/drivers/clocksource/clps711x-timer.c
+++ b/drivers/clocksource/clps711x-timer.c
@@ -33,14 +33,7 @@ static u64 notrace clps711x_sched_clock_read(void)
 
 static int __init _clps711x_clksrc_init(struct clk *clock, void __iomem *base)
 {
-   unsigned long rate;
-
-   if (!base)
-   return -ENOMEM;
-   if (IS_ERR(clock))
-   return PTR_ERR(clock);
-
-   rate = clk_get_rate(clock);
+   unsigned long rate = clk_get_rate(clock);
 
tcd = base;
 
@@ -67,13 +60,6 @@ static int __init _clps711x_clkevt_init(struct clk *clock, 
void __iomem *base,
struct clock_event_device *clkevt;
unsigned long rate;
 
-   if (!irq)
-   return -EINVAL;
-   if (!base)
-   return -ENOMEM;
-   if (IS_ERR(clock))
-   return PTR_ERR(clock);
-
clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL);
if (!clkevt)
return -ENOMEM;
@@ -106,16 +92,33 @@ void __init clps711x_clksrc_init(void __iomem *tc1_base, 
void __iomem *tc2_base,
 #ifdef CONFIG_CLKSRC_OF
 static int __init clps711x_timer_init(struct device_node *np)
 {
-   unsigned int irq = irq_of_parse_and_map(np, 0);
-   struct clk *clock = of_clk_get(np, 0);
-   void __iomem *base = of_iomap(np, 0);
+   unsigned int irq;
+   struct clk *clock;
+   void __iomem *base;
+   int ret;
+
+   clock = of_clk_get(np, 0);
+   if (IS_ERR(clock))
+   return PTR_ERR(clock);
+
+   base = of_iomap(np, 0);
+   if (!base)
+   return -ENOMEM;
 
switch (of_alias_get_id(np, "timer")) {
case CLPS711X_CLKSRC_CLOCKSOURCE:
return _clps711x_clksrc_init(clock, base);
case CLPS711X_CLKSRC_CLOCKEVENT:
-   return _clps711x_clkevt_init(clock, base, irq);
+   irq = irq_of_parse_and_map(np, 0);
+   if (!irq)
+   return -EINVAL;
+
+   ret = _clps711x_clkevt_init(clock, base, irq);
+   if (ret)
+   iounmap(base);
+   return ret;
default:
+   iounmap(base);
return -EINVAL;
}
 }
-- 
2.7.4



Re: [v.1] clk:clk-rockchip:-of_iomap failed to remap then abort clock initialization.

2016-08-24 Thread arvind Yadav

yes, I am referring this code for clock control.

--Arvind


On Tuesday 23 August 2016 09:45 PM, Heiko Stübner wrote:

Hi Arvind,

Am Samstag, 13. August 2016, 20:56:18 schrieb Arvind Yadav:

-check return of 'of_iomap'.if It's falied to remap then abort.

-Unmap a region obtained by remap. iounmap frees the mapping when failed
to allocate the memory.

Signed-off-by: Arvind Yadav 
---
  drivers/clk/rockchip/clk-rockchip.c | 7 ++-

I've applied the patch, after rewording both patch subject and message [0].

That driver is deprecated for quite some time, see
Documenation/devicetree/bindings/clock/rockchip.txt - so I'm hoping this is
more of a random find and you're not actually using it?


Thanks
Heiko

[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=023a8280b8355a0aebe094299afec8d8b7b264cd





Re: [PATCH] perf tools: Fix error handling of lzma decompression

2016-08-24 Thread Arnaldo Carvalho de Melo
Em Sun, Aug 21, 2016 at 03:57:33PM +0800, Shawn Lin escreveu:
> lzma_decompress_to_file never actually close the file
> pointer, let's fix it.
> 
> Signed-off-by: Shawn Lin 

Thanks, I changed the logic a bit to shorten the patch, this is how it
ended up:


commit ffe67c2fabf128122b30fbf0ac498928e171b0b3
Author: Shawn Lin 
Date:   Sun Aug 21 15:57:33 2016 +0800

perf tools: Fix error handling of lzma decompression

lzma_decompress_to_file() never actually closes the file pointer, let's
fix it.

Signed-off-by: Shawn Lin 
Cc: Peter Zijlstra 
Link: 
http://lkml.kernel.org/r/1471766253-1964-1-git-send-email-shawn@rock-chips.com
[ Make err = -1, the common case, set it to 0 before the error label ]
Signed-off-by: Arnaldo Carvalho de Melo 

diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
index 95a1acb61245..9ddea5cecd94 100644
--- a/tools/perf/util/lzma.c
+++ b/tools/perf/util/lzma.c
@@ -29,6 +29,7 @@ int lzma_decompress_to_file(const char *input, int output_fd)
lzma_action action = LZMA_RUN;
lzma_stream strm   = LZMA_STREAM_INIT;
lzma_ret ret;
+   int err = -1;
 
u8 buf_in[BUFSIZE];
u8 buf_out[BUFSIZE];
@@ -45,7 +46,7 @@ int lzma_decompress_to_file(const char *input, int output_fd)
if (ret != LZMA_OK) {
pr_err("lzma: lzma_stream_decoder failed %s (%d)\n",
lzma_strerror(ret), ret);
-   return -1;
+   goto err_fclose;
}
 
strm.next_in   = NULL;
@@ -60,7 +61,7 @@ int lzma_decompress_to_file(const char *input, int output_fd)
 
if (ferror(infile)) {
pr_err("lzma: read error: %s\n", 
strerror(errno));
-   return -1;
+   goto err_fclose;
}
 
if (feof(infile))
@@ -74,7 +75,7 @@ int lzma_decompress_to_file(const char *input, int output_fd)
 
if (writen(output_fd, buf_out, write_size) != 
write_size) {
pr_err("lzma: write error: %s\n", 
strerror(errno));
-   return -1;
+   goto err_fclose;
}
 
strm.next_out  = buf_out;
@@ -83,13 +84,15 @@ int lzma_decompress_to_file(const char *input, int 
output_fd)
 
if (ret != LZMA_OK) {
if (ret == LZMA_STREAM_END)
-   return 0;
+   break;
 
pr_err("lzma: failed %s\n", lzma_strerror(ret));
-   return -1;
+   goto err_fclose;
}
}
 
+   err = 0;
+err_fclose:
fclose(infile);
-   return 0;
+   return err;
 }

> 
>  tools/perf/util/lzma.c | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
> index 95a1acb..a95d473 100644
> --- a/tools/perf/util/lzma.c
> +++ b/tools/perf/util/lzma.c
> @@ -29,6 +29,7 @@ int lzma_decompress_to_file(const char *input, int 
> output_fd)
>   lzma_action action = LZMA_RUN;
>   lzma_stream strm   = LZMA_STREAM_INIT;
>   lzma_ret ret;
> + int err = 0;
>  
>   u8 buf_in[BUFSIZE];
>   u8 buf_out[BUFSIZE];
> @@ -45,7 +46,8 @@ int lzma_decompress_to_file(const char *input, int 
> output_fd)
>   if (ret != LZMA_OK) {
>   pr_err("lzma: lzma_stream_decoder failed %s (%d)\n",
>   lzma_strerror(ret), ret);
> - return -1;
> + err = -1;
> + goto err_fclose;
>   }
>  
>   strm.next_in   = NULL;
> @@ -60,7 +62,8 @@ int lzma_decompress_to_file(const char *input, int 
> output_fd)
>  
>   if (ferror(infile)) {
>   pr_err("lzma: read error: %s\n", 
> strerror(errno));
> - return -1;
> + err = -1;
> + goto err_fclose;
>   }
>  
>   if (feof(infile))
> @@ -74,7 +77,8 @@ int lzma_decompress_to_file(const char *input, int 
> output_fd)
>  
>   if (writen(output_fd, buf_out, write_size) != 
> write_size) {
>   pr_err("lzma: write error: %s\n", 
> strerror(errno));
> - return -1;
> + err = -1;
> + goto err_fclose;
>   }
>  
>   strm.next_out  = buf_out;
> @@ -83,13 +87,14 @@ int lzma_decompress_to_file(const char *input, int 
> output_fd)
>  
>   if (ret != LZMA_OK) {
>   if (ret == LZMA_STREAM_END)
> - return 0;
> + goto err_fclose;
>  
>   pr_err("lzm

Re: [PATCH][RFC] printk: make pr_cont buffer per-cpu

2016-08-24 Thread Sergey Senozhatsky
On (08/24/16 10:19), Petr Mladek wrote:
> > On (08/23/16 13:47), Petr Mladek wrote:
> > [..]
> > > > if (!(lflags & LOG_NEWLINE)) {
> > > > +   if (!this_cpu_read(cont_printing)) {
> > > > +   if (system_state == SYSTEM_RUNNING) {
> > > > +   this_cpu_write(cont_printing, true);
> > > > +   preempt_disable();
> > > > +   }
> > > > +   }
> > > 
> > > I am afraid that this is not acceptable. It means that printk() will have
> > > an unexpected side effect. The missing "\n" at the end of a printed
> > > string would disable preemption. See below for more.
> > 
> > missing '\n' must WARN about "sched while atomic" eventually, so it
> > shouldn't go unnoticed or stay hidden.
> 
> Well, it will still force people to rebuilt a test kernel because they
> forget to use '\n" and the test kernel is unusable.

you are right. misusage of printk() will now force user to go and fix
it. the kernel most likely will be rebuilt anyway - there is a missing
\n after all. and rebuild here is pretty much incremental because basically
only one line is getting updated (missing `\n' in printk() message). so
it's like 15 seconds, perhaps.

> IMHO, the connection between '\n' and preemption is not
> intuitive and hard to spot. We should do our best to avoid it.

yes. what can be done is a simple hint -- we are in preempt disabled
path when we report `sched while atomic', so it's safe to check if
this_cpu(cont).len != 0 and if it is then additionally report:
"incomplete cont line".

in normal life no one _probably_ would see the change. well, I saw broken
backtraces on my laptop before, but didn't consider it to be important.
for the last two days the problem is not theoretical anymore on my side,
as now I'm looking at actual pr_cont()-related bug report [internal].
I'm truing to move the whole thing into 'don't use the cont lines' direction;
there is a mix of numerous pr_cont() calls & missing new-lines [internal code].
the kernel, unfortunately, IMHO, was too nice in the latter case, flushing
incomplete cont buffer with LOG_NEWLINE. so many of those `accidental' cont
lines went unnoticed.

this "don't use the cont lines" is actually a bit tricky and doesn't
look so solid. there is a need for cont lines, and the kernel has cont
printk... but it's sort of broken, so people have to kinda work-around
it. not the best example, but still (arch/arm64/kernel/traps.c)

static void __dump_instr(const char *lvl, struct pt_regs *regs)
{
unsigned long addr = instruction_pointer(regs);
char str[sizeof(" ") * 5 + 2 + 1], *p = str;
int i;

for (i = -4; i < 1; i++) {
unsigned int val, bad;

bad = __get_user(val, &((u32 *)addr)[i]);

if (!bad)
p += sprintf(p, i == 0 ? "(%08x) " : "%08x ", val);
else {
p += sprintf(p, "bad PC value");
break;
}
}
printk("%sCode: %s\n", lvl, str);
}

which is fine, but getting a bit boring once you have more than,
let's say, 20 function that want to do cont output.

[..]
> > well, I do understand what you mean and agree with it, but I'm
> > afraid pr_cont() kinda matters after all and people *probably*
> > expect it to be SMP safe (I'm not entirely sure whether all of
> > those pr_cont() calls were put there with the idea that the
> > output can be messed up and quite hard to read).
> 
> This was even worse before the cont lines buffer.
> 
> Sigh, I do not feel experienced enough to decide about this.
> I wonder if this is rather theoretical problem or if there
> are many real complains about it.
>
> I feel that we might be trapped by a perfectionism.

well. may be, not entirely, but may be :)

-ss


Re: [v.3] clocksource:clps711x-timer:- Unmap a region obtained by remap.

2016-08-24 Thread Daniel Lezcano
On 08/24/2016 04:10 PM, Arvind Yadav wrote:
> iounmap frees the mapping when timer id is not matching.
> 
> Signed-off-by: Arvind Yadav 

What is the difference with the V2 ?

> ---
>  drivers/clocksource/clps711x-timer.c | 41 
> +++-
>  1 file changed, 22 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/clocksource/clps711x-timer.c 
> b/drivers/clocksource/clps711x-timer.c
> index 24db6d6..784c000 100644
> --- a/drivers/clocksource/clps711x-timer.c
> +++ b/drivers/clocksource/clps711x-timer.c
> @@ -33,14 +33,7 @@ static u64 notrace clps711x_sched_clock_read(void)
>  
>  static int __init _clps711x_clksrc_init(struct clk *clock, void __iomem 
> *base)
>  {
> - unsigned long rate;
> -
> - if (!base)
> - return -ENOMEM;
> - if (IS_ERR(clock))
> - return PTR_ERR(clock);
> -
> - rate = clk_get_rate(clock);
> + unsigned long rate = clk_get_rate(clock);
>  
>   tcd = base;
>  
> @@ -67,13 +60,6 @@ static int __init _clps711x_clkevt_init(struct clk *clock, 
> void __iomem *base,
>   struct clock_event_device *clkevt;
>   unsigned long rate;
>  
> - if (!irq)
> - return -EINVAL;
> - if (!base)
> - return -ENOMEM;
> - if (IS_ERR(clock))
> - return PTR_ERR(clock);
> -
>   clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL);
>   if (!clkevt)
>   return -ENOMEM;
> @@ -106,16 +92,33 @@ void __init clps711x_clksrc_init(void __iomem *tc1_base, 
> void __iomem *tc2_base,
>  #ifdef CONFIG_CLKSRC_OF
>  static int __init clps711x_timer_init(struct device_node *np)
>  {
> - unsigned int irq = irq_of_parse_and_map(np, 0);
> - struct clk *clock = of_clk_get(np, 0);
> - void __iomem *base = of_iomap(np, 0);
> + unsigned int irq;
> + struct clk *clock;
> + void __iomem *base;
> + int ret;
> +
> + clock = of_clk_get(np, 0);
> + if (IS_ERR(clock))
> + return PTR_ERR(clock);
> +
> + base = of_iomap(np, 0);
> + if (!base)
> + return -ENOMEM;
>  
>   switch (of_alias_get_id(np, "timer")) {
>   case CLPS711X_CLKSRC_CLOCKSOURCE:
>   return _clps711x_clksrc_init(clock, base);
>   case CLPS711X_CLKSRC_CLOCKEVENT:
> - return _clps711x_clkevt_init(clock, base, irq);
> + irq = irq_of_parse_and_map(np, 0);
> + if (!irq)
> + return -EINVAL;
> +
> + ret = _clps711x_clkevt_init(clock, base, irq);
> + if (ret)
> + iounmap(base);
> + return ret;
>   default:
> + iounmap(base);
>   return -EINVAL;
>   }
>  }
> 


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



ARM,SoC: About the use DT-defined properties by 3rd-party drivers

2016-08-24 Thread Sebastian Frias
Hi,

Given a SoC and its SDK, 3rd party users of said SoC (customers of the SoC's
manufacturer) may need/want to write kernel modules.
Since the DT describes the HW, it would make sense to expose some HW properties
through the DT, and have 3rd party users rely on them to write their drivers in
a generic way.
However, it seems that one is not allowed to upstream DT bindings and
properties without a driver, is that right?

If true, that hampers DT usage by out-of-tree drivers (or in this case,
drivers that are not written yet) and limits the usage of DT properties as an
API.

We can understand that DT maintainers want to know what goes upstream,
make sure that the bindings are documented, that there are no conflicts with
other bindings or generic strings, etc.
However, it is hard to see why there is not a "relaxed" upstreaming path
for SoC-specific properties (i.e.: that do not affect DT API nor other
SoCs).

As an example, we would like to add some properties to /soc/ like:

   soc {
   compatible = "simple-bus";
   ...
   sigma-register-layout-version = <2>;
   sigma-has-XYZ-capability;

and so on.

If this is really not possible, it forces the SoC manufacturer to expose
those properties in a different way, thus wasting a (seemingly) perfectly
fine way of doing so: the DT and its documentation.

Thoughts?

By the way, what about properties generated on-the-fly by the bootloader?

Thanks in advance.
Best regards,

Sebastian


Re: [RFC PATCH 0/3] UART slave device bus

2016-08-24 Thread Marcel Holtmann
Hi Alan,

>> So you mean if I do "hciconfig hci0 down", then the uart-bus should
>> "down" the tty and only on "hciconfig hci0 up" it should "up" the
>> tty? I would expect a uart-bus slave-device takes control of the
>> device ("up" it) on probe. It's hardwired anyway.
> 
> Today you can switch stacks at runtime, you can switch between the kernel
> stack and debug tools at runtime. Breaking that is a regression.

actually that is not true. We have HCI User Channel since a long time that 
gives you raw access to the devices. And also kernel interfaces to do all 
vendor / debug tasks.

Regards

Marcel



kernel BUG at net/unix/garbage.c:149!"

2016-08-24 Thread Nikolay Borisov
Hello, 

I hit the following BUG: 

[1851513.239831] [ cut here ]
[1851513.240079] kernel BUG at net/unix/garbage.c:149!
[1851513.240313] invalid opcode:  [#1] SMP 
[1851513.248320] CPU: 37 PID: 11683 Comm: nginx Tainted: G   O
4.4.14-clouder3 #26
[1851513.248719] Hardware name: Supermicro X10DRi/X10DRi, BIOS 1.1 04/14/2015
[1851513.248966] task: 883b0f6f ti: 880189cf task.ti: 
880189cf
[1851513.249361] RIP: 0010:[]  [] 
unix_notinflight+0x8d/0x90
[1851513.249846] RSP: 0018:880189cf3cf8  EFLAGS: 00010246
[1851513.250082] RAX: 883b05491968 RBX: 883b05491680 RCX: 
8807f9967330
[1851513.250476] RDX: 0001 RSI: 882e6d8bae00 RDI: 
82073f10
[1851513.250886] RBP: 880189cf3d08 R08: 880cbc70e200 R09: 
00018021
[1851513.251280] R10: 883fff3b9dc0 R11: ea0032f1c380 R12: 
883fbaf5
[1851513.251674] R13: 815f6354 R14: 881a7c77b140 R15: 
881a7c7792c0
[1851513.252083] FS:  7f4f19573720() GS:883fff3a() 
knlGS:
[1851513.252481] CS:  0010 DS:  ES:  CR0: 80050033
[1851513.252717] CR2: 013062d8 CR3: 001712f32000 CR4: 
001406e0
[1851513.253116] Stack:
[1851513.253345]   880189cf3d40 880189cf3d28 
815f4383
[1851513.254022]  8839ee11a800 8839ee11a800 880189cf3d60 
815f53b8
[1851513.254685]   883406788de0  

[1851513.255360] Call Trace:
[1851513.255594]  [] unix_detach_fds.isra.19+0x43/0x50
[1851513.255851]  [] unix_destruct_scm+0x48/0x80
[1851513.256090]  [] skb_release_head_state+0x4f/0xb0
[1851513.256328]  [] skb_release_all+0x12/0x30
[1851513.256564]  [] kfree_skb+0x32/0xa0
[1851513.256810]  [] unix_release_sock+0x1e4/0x2c0
[1851513.257046]  [] unix_release+0x20/0x30
[1851513.257284]  [] sock_release+0x1f/0x80
[1851513.257521]  [] sock_close+0x12/0x20
[1851513.257769]  [] __fput+0xea/0x1f0
[1851513.258005]  [] fput+0xe/0x10
[1851513.258244]  [] task_work_run+0x7f/0xb0
[1851513.258488]  [] exit_to_usermode_loop+0xc0/0xd0
[1851513.258728]  [] syscall_return_slowpath+0x80/0xf0
[1851513.258983]  [] int_ret_from_sys_call+0x25/0x9f
[1851513.259222] Code: 7e 5b 41 5c 5d c3 48 8b 8b e8 02 00 00 48 8b 93 f0 02 00 
00 48 89 51 08 48 89 0a 48 89 83 e8 02 00 00 48 89 83 f0 02 00 00 eb b8 <0f> 0b 
90 0f 1f 44 00 00 55 48 c7 c7 10 3f 07 82 48 89 e5 41 54 
[1851513.268473] RIP  [] unix_notinflight+0x8d/0x90
[1851513.268793]  RSP 

That's essentially BUG_ON(list_empty(&u->link));

I see that all the code involving the ->link member hasn't really been 
touched since it was introduced in 2007. So this must be a latent bug. 
This is the first time I've observed it. The state 
of the struct unix_sock can be found here http://sprunge.us/WCMW . Evidently, 
there are no inflight sockets. 

Regards, 
Nikolay 

 


Re: [PATCH v2 1/3] drm/panel: simple-panel: add the delay timing for Sharp LQ123P1JX31

2016-08-24 Thread Thierry Reding
On Fri, Jul 22, 2016 at 09:42:30AM +0800, Yakir Yang wrote:
> According to page 16 of Sharp LQ123P1JX31 datasheet, we need to add the
> missing delay timing. Panel prepare time should be t1 (0.5ms~10ms) plus
> t3 (0ms~100ms), and panel enable time should equal to t7 (0ms~50ms), and
> panel unprepare time should be t11 (1ms~50ms) plus t12 (500ms~).
> 
> Signed-off-by: Yakir Yang 
> Reviewed-by: Sean Paul 
> ---
> Changes in v2:
> - Add the reviewed tag from Sean.
> 
>  drivers/gpu/drm/panel/panel-simple.c | 5 +
>  1 file changed, 5 insertions(+)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature


RE: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the Hisilicon RoCE driver

2016-08-24 Thread Salil Mehta
> -Original Message-
> From: Leon Romanovsky [mailto:l...@kernel.org]
> Sent: Wednesday, August 24, 2016 2:59 PM
> To: Salil Mehta
> Cc: dledf...@redhat.com; da...@davemloft.net; Huwei (Xavier); oulijun;
> Zhuangyuzeng (Yisen); mehta.salil@gmail.com; linux-
> r...@vger.kernel.org; net...@vger.kernel.org; linux-
> ker...@vger.kernel.org; Linuxarm
> Subject: Re: [PATCH for-next 2/2] IB/hns: Add support of ACPI to the
> Hisilicon RoCE driver
> 
> On Wed, Aug 24, 2016 at 04:44:50AM +0800, Salil Mehta wrote:
> > This patch is meant to add support of ACPI to the Hisilicon RoCE
> > driver.
> >
> > Changes done are primarily meant to detect the type and then either
> > use DT specific or ACPI spcific functions. Where ever possible,
> > this patch tries to make use of Unified Device Property Interface
> > APIs to support both DT and ACPI through single interface.
> >
> > This patch depends upon HNS ethernet driver to Reset RoCE. This
> > function within HNS ethernet driver has also been enhanced to
> > support ACPI and is part of other accompanying patch with this
> > patch-set.
> >
> > NOTE: The changes in this patch are done over below branch,
> > https://github.com/dledford/linux/tree/hns-roce
> >
> > Signed-off-by: Salil Mehta 
> > ---
> > Change Log
> >
> > PATCH V1: Initial version to support ACPI in HNS RoCE driver.
> > ---
> >  drivers/infiniband/hw/hns/hns_roce_device.h |2 +-
> >  drivers/infiniband/hw/hns/hns_roce_eq.c |2 +-
> >  drivers/infiniband/hw/hns/hns_roce_hw_v1.c  |   37 ++--
> >  drivers/infiniband/hw/hns/hns_roce_hw_v1.h  |2 +-
> >  drivers/infiniband/hw/hns/hns_roce_main.c   |  127
> ++-
> >  5 files changed, 136 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_device.h
> b/drivers/infiniband/hw/hns/hns_roce_device.h
> > index 00f01be..ea73580 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_device.h
> > +++ b/drivers/infiniband/hw/hns/hns_roce_device.h
> > @@ -531,7 +531,7 @@ struct hns_roce_dev {
> > struct ib_deviceib_dev;
> > struct platform_device  *pdev;
> > struct hns_roce_uar priv_uar;
> > -   const char  *irq_names;
> > +   const char  *irq_names[HNS_ROCE_MAX_IRQ_NUM];
> > spinlock_t  sm_lock;
> > spinlock_t  cq_db_lock;
> > spinlock_t  bt_cmd_lock;
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_eq.c
> b/drivers/infiniband/hw/hns/hns_roce_eq.c
> > index 5febbb4..98af7fe 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_eq.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_eq.c
> > @@ -713,7 +713,7 @@ int hns_roce_init_eq_table(struct hns_roce_dev
> *hr_dev)
> >
> > for (j = 0; j < eq_num; j++) {
> > ret = request_irq(eq_table->eq[j].irq,
> hns_roce_msi_x_interrupt,
> > - 0, hr_dev->irq_names, eq_table->eq + j);
> > + 0, hr_dev->irq_names[j], eq_table->eq + j);
> > if (ret) {
> > dev_err(dev, "request irq error!\n");
> > goto err_request_irq_fail;
> > diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> > index b52f3ba..399f5de 100644
> > --- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> > +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
> > @@ -31,6 +31,7 @@
> >   */
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include "hns_roce_common.h"
> >  #include "hns_roce_device.h"
> > @@ -794,29 +795,47 @@ static void hns_roce_port_enable(struct
> hns_roce_dev *hr_dev, int enable_flag)
> >   * @enable: true -- drop reset, false -- reset
> >   * return 0 - success , negative --fail
> >   */
> > -int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool enable)
> > +int hns_roce_v1_reset(struct hns_roce_dev *hr_dev, bool dereset)
> >  {
> > struct device_node *dsaf_node;
> > struct device *dev = &hr_dev->pdev->dev;
> > struct device_node *np = dev->of_node;
> > +   struct fwnode_handle *fwnode;
> > int ret;
> >
> > -   dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> > -   if (!dsaf_node) {
> > -   dev_err(dev, "Unable to get dsaf node by dsaf-handle!\n");
> > -   return -EINVAL;
> > +   /* check if this is DT/ACPI case */
> > +   if (dev_of_node(dev)) {
> > +   dsaf_node = of_parse_phandle(np, "dsaf-handle", 0);
> > +   if (!dsaf_node) {
> > +   dev_err(dev, "could not find dsaf-handle\n");
> > +   return -EINVAL;
> > +   }
> > +   fwnode = &dsaf_node->fwnode;
> > +   } else if (is_acpi_device_node(dev->fwnode)) {
> > +   struct acpi_reference_args args;
> > +
> > +   ret = acpi_node_get_property_reference(dev->fwnode,
> > +  "dsaf-handle", 0, &args);
> > +   if (ret) {
> > +   dev_err(dev, "could not find dsaf-handle\n");
> > +   

Re: [PATCH v2 5/8] hisi_sas: add v2 hw slot complete internal abort support

2016-08-24 Thread Hannes Reinecke
On 08/24/2016 04:07 PM, John Garry wrote:
> On 24/08/2016 13:59, Hannes Reinecke wrote:
>> On 08/24/2016 01:05 PM, John Garry wrote:
>>> Add code in slot_complete_v2_hw() to deal with the
>>> slots which have completed due to internal abort.
>>>
>>> The status codes have the following meaning:
>>> - STAT_IO_ABORTED: the IO has been aborted due to
>>> internal abort, whether by device or individual
>>> abort command
>>> - STAT_IO_COMPLETE: internal abort command has
>>> completed successfully for device or individual
>>> abort command
>>> - STAT_IO_NO_DEVICE: internal abort command has
>>> completed for device but cannot find any IO
>>> - STAT_IO_NOT_VALID: internal abort command has
>>> completed for single command but could not
>>> find the command
>>>
>>> Signed-off-by: John Garry 
>>> ---
>>>  drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 31
>>> +++
>>>  1 file changed, 31 insertions(+)
>>>
>>> diff --git a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
>>> b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
>>> index fec1675..bf9b693 100644
>>> --- a/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
>>> +++ b/drivers/scsi/hisi_sas/hisi_sas_v2_hw.c
>>> @@ -227,6 +227,13 @@
>>>  #define CMPLT_HDR_RSPNS_XFRD_MSK(0x1 << CMPLT_HDR_RSPNS_XFRD_OFF)
>>>  #define CMPLT_HDR_ERX_OFF12
>>>  #define CMPLT_HDR_ERX_MSK(0x1 << CMPLT_HDR_ERX_OFF)
>>> +#define CMPLT_HDR_ABORT_STAT_OFF13
>>> +#define CMPLT_HDR_ABORT_STAT_MSK(0x7 << CMPLT_HDR_ABORT_STAT_OFF)
>>> +/* abort_stat */
>>> +#define STAT_IO_NOT_VALID0x1
>>> +#define STAT_IO_NO_DEVICE0x2
>>> +#define STAT_IO_COMPLETE0x3
>>> +#define STAT_IO_ABORTED0x4
>>>  /* dw1 */
>>>  #define CMPLT_HDR_IPTT_OFF0
>>>  #define CMPLT_HDR_IPTT_MSK(0x << CMPLT_HDR_IPTT_OFF)
>>> @@ -1569,6 +1576,30 @@ slot_complete_v2_hw(struct hisi_hba *hisi_hba,
>>> struct hisi_sas_slot *slot,
>>>  goto out;
>>>  }
>>>
>>> +/* Use SAS+TMF status codes */
>>> +switch ((complete_hdr->dw0 & CMPLT_HDR_ABORT_STAT_MSK)
>>> +>> CMPLT_HDR_ABORT_STAT_OFF) {
>>> +case STAT_IO_ABORTED:
>>> +/* this io has been aborted by abort command */
>>> +ts->stat = SAS_ABORTED_TASK;
>>> +goto out;
>>> +case STAT_IO_COMPLETE:
>>> +/* internal abort command complete */
>>> +ts->stat = TMF_RESP_FUNC_COMPLETE;
>>> +goto out;
>>> +case STAT_IO_NO_DEVICE:
>>> +ts->stat = TMF_RESP_FUNC_COMPLETE;
>>> +goto out;
>>> +case STAT_IO_NOT_VALID:
>>> +/* abort single io, controller don't find
>>> + * the io need to abort
>>> + */
>>> +ts->stat = TMF_RESP_FUNC_FAILED;
>>> +goto out;
>> Hmm. This will cause the SCSI EH to kick in.
>> And then, according to the description abort has succeeded, it's just
>> that for some reason the associated command couldn't be found.
>> So couldn't this be due to a race condition, and the command has in fact
>> been aborted correctly (and the code is just too slow acknowledging it)?
>>
> 
> Hi Hannes,
> 
> I'm not sure I fully get your question.
> 
> The internal abort would happen from the SCSI error handling. An example
> would be when the disk was not safely removed and some IO is still in
> flight. In this case the IO will timeout, SCSI EH starts, and we try to
> abort the command in LLDD, by TMF (which would fail) and internal abort.
> 
> For internal abort, if the abort command succeeds then 2 things happen:
> - abort task completes with status STAT_IO_COMPLETE
> - task which was aborted completes with status STAT_IO_ABORTED
> 
> If the command does not abort successfully then:
> - abort task completes with status STAT_IO_NOT_VALID
> - task which we wanted to be aborted does not complete and is probably
> still in the slave device
> 
> I hope that this makes it clear.
> 
Right, that answers it.

Reviewed-by: Hannes Reinecke 

Cheers,

Hannes
-- 
Dr. Hannes ReineckeTeamlead Storage & Networking
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)


Re: [v.3] clocksource:clps711x-timer:- Unmap a region obtained by remap.

2016-08-24 Thread arvind Yadav

This clocksource(_clps711x_clksrc_init) initialization is not depend on irq.

We should check irq only for clockevent(_clps711x_clkevt_init) 
initialization.


In V2, I was checking irq for both the initialization.

--Arvind Y


On Wednesday 24 August 2016 07:51 PM, Daniel Lezcano wrote:

On 08/24/2016 04:10 PM, Arvind Yadav wrote:

iounmap frees the mapping when timer id is not matching.

Signed-off-by: Arvind Yadav 

What is the difference with the V2 ?


---
  drivers/clocksource/clps711x-timer.c | 41 +++-
  1 file changed, 22 insertions(+), 19 deletions(-)

diff --git a/drivers/clocksource/clps711x-timer.c 
b/drivers/clocksource/clps711x-timer.c
index 24db6d6..784c000 100644
--- a/drivers/clocksource/clps711x-timer.c
+++ b/drivers/clocksource/clps711x-timer.c
@@ -33,14 +33,7 @@ static u64 notrace clps711x_sched_clock_read(void)
  
  static int __init _clps711x_clksrc_init(struct clk *clock, void __iomem *base)

  {
-   unsigned long rate;
-
-   if (!base)
-   return -ENOMEM;
-   if (IS_ERR(clock))
-   return PTR_ERR(clock);
-
-   rate = clk_get_rate(clock);
+   unsigned long rate = clk_get_rate(clock);
  
  	tcd = base;
  
@@ -67,13 +60,6 @@ static int __init _clps711x_clkevt_init(struct clk *clock, void __iomem *base,

struct clock_event_device *clkevt;
unsigned long rate;
  
-	if (!irq)

-   return -EINVAL;
-   if (!base)
-   return -ENOMEM;
-   if (IS_ERR(clock))
-   return PTR_ERR(clock);
-
clkevt = kzalloc(sizeof(*clkevt), GFP_KERNEL);
if (!clkevt)
return -ENOMEM;
@@ -106,16 +92,33 @@ void __init clps711x_clksrc_init(void __iomem *tc1_base, 
void __iomem *tc2_base,
  #ifdef CONFIG_CLKSRC_OF
  static int __init clps711x_timer_init(struct device_node *np)
  {
-   unsigned int irq = irq_of_parse_and_map(np, 0);
-   struct clk *clock = of_clk_get(np, 0);
-   void __iomem *base = of_iomap(np, 0);
+   unsigned int irq;
+   struct clk *clock;
+   void __iomem *base;
+   int ret;
+
+   clock = of_clk_get(np, 0);
+   if (IS_ERR(clock))
+   return PTR_ERR(clock);
+
+   base = of_iomap(np, 0);
+   if (!base)
+   return -ENOMEM;
  
  	switch (of_alias_get_id(np, "timer")) {

case CLPS711X_CLKSRC_CLOCKSOURCE:
return _clps711x_clksrc_init(clock, base);
case CLPS711X_CLKSRC_CLOCKEVENT:
-   return _clps711x_clkevt_init(clock, base, irq);
+   irq = irq_of_parse_and_map(np, 0);
+   if (!irq)
+   return -EINVAL;
+
+   ret = _clps711x_clkevt_init(clock, base, irq);
+   if (ret)
+   iounmap(base);
+   return ret;
default:
+   iounmap(base);
return -EINVAL;
}
  }







[PATCH] misc: retire the old BMP085 driver

2016-08-24 Thread Linus Walleij
Patches merged to the IIO BMP085 driver makes it fully compliant
with all features found in this old misc driver. Retire this old
driver in favor of the new one in the proper subsystem.

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Jonathan Cameron 
Cc: Marek Belisko 
Cc: H. Nikolaus Schaller 
Cc: linux-...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
Greg I guess you can merge this unless somebody starts screaming.
---
 drivers/iio/pressure/Kconfig |   2 -
 drivers/misc/Kconfig |  28 ---
 drivers/misc/Makefile|   3 -
 drivers/misc/bmp085-i2c.c|  83 ---
 drivers/misc/bmp085-spi.c|  79 ---
 drivers/misc/bmp085.c| 506 ---
 drivers/misc/bmp085.h|  33 ---
 7 files changed, 734 deletions(-)
 delete mode 100644 drivers/misc/bmp085-i2c.c
 delete mode 100644 drivers/misc/bmp085-spi.c
 delete mode 100644 drivers/misc/bmp085.c
 delete mode 100644 drivers/misc/bmp085.h

diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
index d130cdc78f43..7fa65ab664fb 100644
--- a/drivers/iio/pressure/Kconfig
+++ b/drivers/iio/pressure/Kconfig
@@ -8,8 +8,6 @@ menu "Pressure sensors"
 config BMP280
tristate "Bosch Sensortec BMP180/BMP280 pressure sensor I2C driver"
depends on (I2C || SPI_MASTER)
-   depends on !(BMP085_I2C=y || BMP085_I2C=m)
-   depends on !(BMP085_SPI=y || BMP085_SPI=m)
select REGMAP
select BMP280_I2C if (I2C)
select BMP280_SPI if (SPI_MASTER)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a216b4667742..09f6f84a6a7f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -439,34 +439,6 @@ config ARM_CHARLCD
  line and the Linux version on the second line, but that's
  still useful.
 
-config BMP085
-   tristate
-   depends on SYSFS
-
-config BMP085_I2C
-   tristate "BMP085 digital pressure sensor on I2C"
-   select BMP085
-   select REGMAP_I2C
-   depends on I2C && SYSFS
-   help
- Say Y here if you want to support Bosch Sensortec's digital pressure
- sensor hooked to an I2C bus.
-
- To compile this driver as a module, choose M here: the
- module will be called bmp085-i2c.
-
-config BMP085_SPI
-   tristate "BMP085 digital pressure sensor on SPI"
-   select BMP085
-   select REGMAP_SPI
-   depends on SPI_MASTER && SYSFS
-   help
- Say Y here if you want to support Bosch Sensortec's digital pressure
- sensor hooked to an SPI bus.
-
- To compile this driver as a module, choose M here: the
- module will be called bmp085-spi.
-
 config PCH_PHUB
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
select GENERIC_NET_UTILS
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4387ccb79e64..dc619b5a6b30 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -9,9 +9,6 @@ obj-$(CONFIG_AD525X_DPOT_SPI)   += ad525x_dpot-spi.o
 obj-$(CONFIG_INTEL_MID_PTI)+= pti.o
 obj-$(CONFIG_ATMEL_SSC)+= atmel-ssc.o
 obj-$(CONFIG_ATMEL_TCLIB)  += atmel_tclib.o
-obj-$(CONFIG_BMP085)   += bmp085.o
-obj-$(CONFIG_BMP085_I2C)   += bmp085-i2c.o
-obj-$(CONFIG_BMP085_SPI)   += bmp085-spi.o
 obj-$(CONFIG_DUMMY_IRQ)+= dummy-irq.o
 obj-$(CONFIG_ICS932S401)   += ics932s401.o
 obj-$(CONFIG_LKDTM)+= lkdtm.o
diff --git a/drivers/misc/bmp085-i2c.c b/drivers/misc/bmp085-i2c.c
deleted file mode 100644
index f35c218aaa1a..
--- a/drivers/misc/bmp085-i2c.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
- * Copyright (c) 2012  Bosch Sensortec GmbH
- * Copyright (c) 2012  Unixphere AB
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include 
-#include 
-#include 
-#include "bmp085.h"
-
-#define BMP085_I2C_ADDRESS 0x77
-
-static const unsigned short normal_i2c[] = { BMP085_I2C_ADDRESS,
-   I2C_CLIENT_END };
-
-static int bmp085_i2c_detect(struct i2c_client *client,
-struct i2c_board_info *info)
-{
-   if (client->addr != BMP085_I2C_ADDRESS)
-   return -ENODEV;
-
-   return bmp085_detect(&client->dev);
-}
-
-static int bmp085_i2c_probe(struct i2c_client *client,
-

Re: [PATCH] usbnet: ax88179_178a: Add support for writing the EEPROM

2016-08-24 Thread Oliver Neukum
On Wed, 2016-08-24 at 15:52 +0200, Alban Bedel wrote:
> Implement the .set_eeprom callback to allow setting the MAC address
> as well as a few other parameters. Note that the EEPROM must have a
> correct PID/VID checksum set otherwise the SROM is used and reads
> return the SROM content.
> 
> Signed-off-by: Alban Bedel 
> ---
>  drivers/net/usb/ax88179_178a.c | 57
> ++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/drivers/net/usb/ax88179_178a.c
> b/drivers/net/usb/ax88179_178a.c
> index e6338c16081a..e6a986303dad 100644
> --- a/drivers/net/usb/ax88179_178a.c
> +++ b/drivers/net/usb/ax88179_178a.c
> @@ -28,6 +28,7 @@
>  
>  #define AX88179_PHY_ID 0x03
>  #define AX_EEPROM_LEN  0x100
> +#define AX_EEPROM_BLOCK0x40u
>  #define AX88179_EEPROM_MAGIC   0x17900b95
>  #define AX_MCAST_FLTSIZE   8
>  #define AX_MAX_MCAST   64
> @@ -43,6 +44,7 @@
>  #define AX_ACCESS_PHY  0x02
>  #define AX_ACCESS_EEPROM   0x04
>  #define AX_ACCESS_EFUS 0x05
> +#define AX_RELOAD_EEPROM   0x06
>  #define AX_PAUSE_WATERLVL_HIGH 0x54
>  #define AX_PAUSE_WATERLVL_LOW  0x55
>  
> @@ -620,6 +622,60 @@ ax88179_get_eeprom(struct net_device *net, struct
> ethtool_eeprom *eeprom,
> return 0;
>  }
>  
> +static int
> +ax88179_set_eeprom(struct net_device *net, struct ethtool_eeprom
> *eeprom,
> +  u8 *data)
> +{
> +   struct usbnet *dev = netdev_priv(net);
> +   unsigned int offset = eeprom->offset;
> +   unsigned int len = eeprom->len;
> +   int i, err = 0;
> +   u8 *block;
> +
> +   /* The EEPROM data must be aligned on blocks of 64 bytes */
> +   if ((offset % AX_EEPROM_BLOCK) || (len % AX_EEPROM_BLOCK)) {
> +   offset = eeprom->offset / AX_EEPROM_BLOCK *
> AX_EEPROM_BLOCK;
> +   len = eeprom->len + eeprom->offset - offset;
> +   len = DIV_ROUND_UP(len, AX_EEPROM_BLOCK) *
> AX_EEPROM_BLOCK;
> +
> +   block = kmalloc(len, GFP_KERNEL);
> +   if (!block)
> +   return -ENOMEM;
> +
> +   /* Copy the current data, we could skip some but KISS
> */
> +   for (i = 0; i < len; i += AX_EEPROM_BLOCK) {
> +   err = __ax88179_read_cmd(dev,
> AX_ACCESS_EEPROM,
> +(offset + i) >> 1,
> +AX_EEPROM_BLOCK >> 1,
> +AX_EEPROM_BLOCK,
> +&block[i], 0);
> +   if (err < 0) {
> +   kfree(block);
> +   return err;
> +   }
> +   }
> +   memcpy(block + eeprom->offset - offset, data,
> eeprom->len);
> +   } else {
> +   block = data;
> +   }
> +
> +   for (i = 0; err >= 0 && i < len; i += AX_EEPROM_BLOCK) {
> +   err = ax88179_write_cmd(dev, AX_ACCESS_EEPROM,
> +   (offset + i) >> 1,
> +   AX_EEPROM_BLOCK >> 1,
> +   AX_EEPROM_BLOCK, &block[i]);
> +   }
> +
> +   if (block != data)
> +   kfree(block);

And if block == dta, what frees the memory?

Regards
Oliver




[PATCH v2] misc: retire the old BMP085 driver

2016-08-24 Thread Linus Walleij
Patches merged to the IIO BMP085 driver makes it fully compliant
with all features found in this old misc driver. Retire this old
driver in favor of the new one in the proper subsystem.

Cc: Arnd Bergmann 
Cc: Greg Kroah-Hartman 
Cc: Jonathan Cameron 
Cc: Marek Belisko 
Cc: H. Nikolaus Schaller 
Cc: linux-...@vger.kernel.org
Signed-off-by: Linus Walleij 
---
ChangeLog v1->v2:
- Also delete the dangling sysfs ABI file.

Greg I guess you can merge this unless somebody starts screaming.
---
 Documentation/ABI/testing/sysfs-i2c-bmp085 |  31 --
 drivers/iio/pressure/Kconfig   |   2 -
 drivers/misc/Kconfig   |  28 --
 drivers/misc/Makefile  |   3 -
 drivers/misc/bmp085-i2c.c  |  83 -
 drivers/misc/bmp085-spi.c  |  79 -
 drivers/misc/bmp085.c  | 506 -
 drivers/misc/bmp085.h  |  33 --
 8 files changed, 765 deletions(-)
 delete mode 100644 Documentation/ABI/testing/sysfs-i2c-bmp085
 delete mode 100644 drivers/misc/bmp085-i2c.c
 delete mode 100644 drivers/misc/bmp085-spi.c
 delete mode 100644 drivers/misc/bmp085.c
 delete mode 100644 drivers/misc/bmp085.h

diff --git a/Documentation/ABI/testing/sysfs-i2c-bmp085 
b/Documentation/ABI/testing/sysfs-i2c-bmp085
deleted file mode 100644
index 585962ad0465..
--- a/Documentation/ABI/testing/sysfs-i2c-bmp085
+++ /dev/null
@@ -1,31 +0,0 @@
-What:  /sys/bus/i2c/devices/-/pressure0_input
-Date:  June 2010
-Contact:   Christoph Mair 
-Description:   Start a pressure measurement and read the result. Values
-   represent the ambient air pressure in pascal (0.01 millibar).
-
-   Reading: returns the current air pressure.
-
-
-What:  /sys/bus/i2c/devices/-/temp0_input
-Date:  June 2010
-Contact:   Christoph Mair 
-Description:   Measure the ambient temperature. The returned value represents
-   the ambient temperature in units of 0.1 degree celsius.
-
-   Reading: returns the current temperature.
-
-
-What:  /sys/bus/i2c/devices/-/oversampling
-Date:  June 2010
-Contact:   Christoph Mair 
-Description:   Tell the bmp085 to use more samples to calculate a pressure
-   value. When writing to this file the chip will use 2^x samples
-   to calculate the next pressure value with x being the value
-   written. Using this feature will decrease RMS noise and
-   increase the measurement time.
-
-   Reading: returns the current oversampling setting.
-
-   Writing: sets a new oversampling setting.
-   Accepted values: 0..3.
diff --git a/drivers/iio/pressure/Kconfig b/drivers/iio/pressure/Kconfig
index d130cdc78f43..7fa65ab664fb 100644
--- a/drivers/iio/pressure/Kconfig
+++ b/drivers/iio/pressure/Kconfig
@@ -8,8 +8,6 @@ menu "Pressure sensors"
 config BMP280
tristate "Bosch Sensortec BMP180/BMP280 pressure sensor I2C driver"
depends on (I2C || SPI_MASTER)
-   depends on !(BMP085_I2C=y || BMP085_I2C=m)
-   depends on !(BMP085_SPI=y || BMP085_SPI=m)
select REGMAP
select BMP280_I2C if (I2C)
select BMP280_SPI if (SPI_MASTER)
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a216b4667742..09f6f84a6a7f 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -439,34 +439,6 @@ config ARM_CHARLCD
  line and the Linux version on the second line, but that's
  still useful.
 
-config BMP085
-   tristate
-   depends on SYSFS
-
-config BMP085_I2C
-   tristate "BMP085 digital pressure sensor on I2C"
-   select BMP085
-   select REGMAP_I2C
-   depends on I2C && SYSFS
-   help
- Say Y here if you want to support Bosch Sensortec's digital pressure
- sensor hooked to an I2C bus.
-
- To compile this driver as a module, choose M here: the
- module will be called bmp085-i2c.
-
-config BMP085_SPI
-   tristate "BMP085 digital pressure sensor on SPI"
-   select BMP085
-   select REGMAP_SPI
-   depends on SPI_MASTER && SYSFS
-   help
- Say Y here if you want to support Bosch Sensortec's digital pressure
- sensor hooked to an SPI bus.
-
- To compile this driver as a module, choose M here: the
- module will be called bmp085-spi.
-
 config PCH_PHUB
tristate "Intel EG20T PCH/LAPIS Semicon IOH(ML7213/ML7223/ML7831) PHUB"
select GENERIC_NET_UTILS
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 4387ccb79e64..dc619b5a6b30 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -9,9 +9,6 @@ obj-$(CONFIG_AD525X_DPOT_SPI)   += ad525x_dpot-spi.o
 obj-$(CONFIG_INTEL_MID_PTI)+= pti.o
 obj-$(CONFIG_ATMEL_SSC)+= atmel-ssc.o
 obj-$(CONFIG_ATMEL_TCLIB)  += atmel_tclib.o
-obj-$(CONFIG_BMP085)   += bmp085.o
-obj-$(

Re: [PATCH] memremap: Fix NULL pointer BUG in get_zone_device_page()

2016-08-24 Thread Kani, Toshimitsu
On Tue, 2016-08-23 at 21:48 -0700, Dan Williams wrote:
> On Tue, Aug 23, 2016 at 9:28 PM, Kani, Toshimitsu  > 
> > BTW, why does devm_memremap_pages() put a whole range to
> > pgmap_radix as device memory, but only initialize page->pgmap for
> > its data range?  Is there particular reason for this inconsistency?
>
> The radix tree is indexed by section number, but we don't always
> initialize a full section.  The cases when we don't use a full
> section is when it overlaps device metadata, or if a platform
> multiplexes the device memory range with another resource within the
> same section.

I see, but I still feel odd about making get_dev_pagemap() to work for
metadata, but get_page() -> get_zone_device_page() to crash like this.
 follow_devmap_pmd() assumes get_page() to work when get_dev_pagemap()
returns a valid pgmap...

Thanks,
-Toshi

linux kernel 3.19.X does not load when compiled with binutils 2.6, works fine when compiled with binutils 2.22

2016-08-24 Thread luigi.genoni

Hi all,

recentrly I was in need to compile and run linux kernel 3.19.8 on some 
servers, with different bios and cpus.


so i noticed that If i compile this kernel with binutils 2.6 (and 2.7) it 
does not load the image, both lilo, grub/grub2 show the message:


loading kernel

loading ramdisk and nothing happens.

i tried the debug option, at boot, but it simply does not load the kernel.


if i compile this kernel with:

binutils 2.22

everything works fine,

I tried this on a xeon with startdard bios, a xeon with efi, an amd 
Athlon-mp with bios and an AMD A8 with EFI.


I tried gcc 4.3 and gcc 4.8, with both the kernel loads if compiled with 
binutils 2.22, and doesn't load with binutils 2.6.



What really bugs me is that on all the 4 servers i user i could compile 
and run without problems linux 4.7 compiled with binutils 2.6 and 2.7 with 
gcc 4.8 5.9 and 6.1
i cannot afford to downgrate binutils (and glibc to 2.15) every time i 
need to compiled and e 3.19.X kernel.


excuse my bad english

please include my address in the reply, since I am not subscribed to this 
list.


regards

Luigi Genoni



Re: [RFC/PATCH 1/2] cpuidle: Allow idle-states to be disabled at start

2016-08-24 Thread Daniel Lezcano
On 08/19/2016 12:26 AM, Gautham R. Shenoy wrote:
> From: "Gautham R. Shenoy" 
> 
> Currently all the idle states registered by a cpu-idle driver are
> enabled by default. This patch adds a mechanism which allows the
> driver to hint if an idle-state should start in a disabled state. The
> cpu-idle core will use this hint to appropriately initialize the
> usage->disable knob of the CPU device idle state.

Why do you need to do that ?

> The state can be enabled at run time by echo'ing a zero to the sysfs
> "disable" control file.

... for each cpu.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



<    1   2   3   4   5   6   7   8   9   >