[PATCH v2 3/4] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

2017-07-31 Thread Minchan Kim
Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
problem and Mel fixed it[1] and found same problem on MADV_FREE[2].

Quote from Mel Gorman

"The race in question is CPU 0 running madv_free and updating some PTEs
while CPU 1 is also running madv_free and looking at the same PTEs.
CPU 1 may have writable TLB entries for a page but fail the pte_dirty
check (because CPU 0 has updated it already) and potentially fail to flush.
Hence, when madv_free on CPU 1 returns, there are still potentially writable
TLB entries and the underlying PTE is still present so that a subsequent write
does not necessarily propagate the dirty bit to the underlying PTE any more.
Reclaim at some unknown time at the future may then see that the PTE is still
clean and discard the page even though a write has happened in the meantime.
I think this is possible but I could have missed some protection in madv_free
that prevents it happening."

This patch aims for solving both problems all at once and is ready for
other problem with KSM, MADV_FREE and soft-dirty story[3].

TLB batch API(tlb_[gather|finish]_mmu] uses [inc|dec]_tlb_flush_pending
and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can catch
there are parallel threads going on. In that case, forcefully, flush TLB
to prevent for user to access memory via stale TLB entry although it fail
to gather page table entry.

I confiremd this patch works with [4] test program Nadav gave so this patch
supersedes "mm: Always flush VMA ranges affected by zap_page_range v2"
in current mmotm.

NOTE:
This patch modifies arch-specific TLB gathering interface(x86, ia64,
s390, sh, um). It seems most of architecture are straightforward but s390
need to be careful because tlb_flush_mmu works only if mm->context.flush_mm
is set to non-zero which happens only a pte entry really is cleared by
ptep_get_and_clear and friends. However, this problem never changes the
pte entries but need to flush to prevent memory access from stale tlb.

Any thoughts?

[1] http://lkml.kernel.org/r/20170725101230.5v7gvnjmcnkzz...@techsingularity.net
[2] http://lkml.kernel.org/r/20170725100722.2dxnmgypmwnrf...@suse.de
[3] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com
[4] https://patchwork.kernel.org/patch/9861621/

Cc: Ingo Molnar 
Cc: Russell King 
Cc: Tony Luck 
Cc: Martin Schwidefsky 
Cc: "David S. Miller" 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Jeff Dike 
Cc: linux-a...@vger.kernel.org
Cc: Nadav Amit 
Reported-by: Mel Gorman 
Signed-off-by: Minchan Kim 
---
 arch/arm/include/asm/tlb.h  |  7 ++-
 arch/ia64/include/asm/tlb.h |  4 +++-
 arch/s390/include/asm/tlb.h |  7 ++-
 arch/sh/include/asm/tlb.h   |  4 ++--
 arch/um/include/asm/tlb.h   |  7 ++-
 include/asm-generic/tlb.h   |  2 +-
 include/linux/mm_types.h|  8 
 mm/memory.c | 32 +---
 8 files changed, 49 insertions(+), 22 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 7f5b2a2d3861..d5562f9ce600 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -168,8 +168,13 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm,
 
 static inline void
 arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end, bool force)
 {
+   if (force) {
+   tlb->range_start = start;
+   tlb->range_end = end;
+   }
+
tlb_flush_mmu(tlb);
 
/* keep the page table cache within bounds */
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index 93cadc04ac62..cbe5ac3699bf 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -187,8 +187,10 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm,
  */
 static inline void
 arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end, bool force)
 {
+   if (force)
+   tlb->need_flush = 1;
/*
 * Note: tlb->nr may be 0 at this point, so we can't rely on 
tlb->start_addr and
 * tlb->end_addr.
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index fa4b461694b7..3a14b864b2e3 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -77,8 +77,13 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 
 static inline void
 arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end, bool force)
 {
+   

[PATCH v2 3/4] mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem

2017-07-31 Thread Minchan Kim
Nadav reported parallel MADV_DONTNEED on same range has a stale TLB
problem and Mel fixed it[1] and found same problem on MADV_FREE[2].

Quote from Mel Gorman

"The race in question is CPU 0 running madv_free and updating some PTEs
while CPU 1 is also running madv_free and looking at the same PTEs.
CPU 1 may have writable TLB entries for a page but fail the pte_dirty
check (because CPU 0 has updated it already) and potentially fail to flush.
Hence, when madv_free on CPU 1 returns, there are still potentially writable
TLB entries and the underlying PTE is still present so that a subsequent write
does not necessarily propagate the dirty bit to the underlying PTE any more.
Reclaim at some unknown time at the future may then see that the PTE is still
clean and discard the page even though a write has happened in the meantime.
I think this is possible but I could have missed some protection in madv_free
that prevents it happening."

This patch aims for solving both problems all at once and is ready for
other problem with KSM, MADV_FREE and soft-dirty story[3].

TLB batch API(tlb_[gather|finish]_mmu] uses [inc|dec]_tlb_flush_pending
and mmu_tlb_flush_pending so that when tlb_finish_mmu is called, we can catch
there are parallel threads going on. In that case, forcefully, flush TLB
to prevent for user to access memory via stale TLB entry although it fail
to gather page table entry.

I confiremd this patch works with [4] test program Nadav gave so this patch
supersedes "mm: Always flush VMA ranges affected by zap_page_range v2"
in current mmotm.

NOTE:
This patch modifies arch-specific TLB gathering interface(x86, ia64,
s390, sh, um). It seems most of architecture are straightforward but s390
need to be careful because tlb_flush_mmu works only if mm->context.flush_mm
is set to non-zero which happens only a pte entry really is cleared by
ptep_get_and_clear and friends. However, this problem never changes the
pte entries but need to flush to prevent memory access from stale tlb.

Any thoughts?

[1] http://lkml.kernel.org/r/20170725101230.5v7gvnjmcnkzz...@techsingularity.net
[2] http://lkml.kernel.org/r/20170725100722.2dxnmgypmwnrf...@suse.de
[3] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com
[4] https://patchwork.kernel.org/patch/9861621/

Cc: Ingo Molnar 
Cc: Russell King 
Cc: Tony Luck 
Cc: Martin Schwidefsky 
Cc: "David S. Miller" 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Jeff Dike 
Cc: linux-a...@vger.kernel.org
Cc: Nadav Amit 
Reported-by: Mel Gorman 
Signed-off-by: Minchan Kim 
---
 arch/arm/include/asm/tlb.h  |  7 ++-
 arch/ia64/include/asm/tlb.h |  4 +++-
 arch/s390/include/asm/tlb.h |  7 ++-
 arch/sh/include/asm/tlb.h   |  4 ++--
 arch/um/include/asm/tlb.h   |  7 ++-
 include/asm-generic/tlb.h   |  2 +-
 include/linux/mm_types.h|  8 
 mm/memory.c | 32 +---
 8 files changed, 49 insertions(+), 22 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 7f5b2a2d3861..d5562f9ce600 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -168,8 +168,13 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm,
 
 static inline void
 arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end, bool force)
 {
+   if (force) {
+   tlb->range_start = start;
+   tlb->range_end = end;
+   }
+
tlb_flush_mmu(tlb);
 
/* keep the page table cache within bounds */
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index 93cadc04ac62..cbe5ac3699bf 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -187,8 +187,10 @@ arch_tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm,
  */
 static inline void
 arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end, bool force)
 {
+   if (force)
+   tlb->need_flush = 1;
/*
 * Note: tlb->nr may be 0 at this point, so we can't rely on 
tlb->start_addr and
 * tlb->end_addr.
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index fa4b461694b7..3a14b864b2e3 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -77,8 +77,13 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 
 static inline void
 arch_tlb_finish_mmu(struct mmu_gather *tlb,
-   unsigned long start, unsigned long end)
+   unsigned long start, unsigned long end, bool force)
 {
+   if (force) {
+   tlb->start = start;
+   tlb->end = end;
+   }
+
tlb_flush_mmu(tlb);
 }
 
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 89786560dbd4..51a8bc967e75 100644
--- 

[PATCH v2 1/4] mm: refactoring TLB gathering API

2017-07-31 Thread Minchan Kim
This patch is ready for solving race problems caused by TLB batch.
For that, we will increase/decrease TLB flush pending count of
mm_struct whenever tlb_[gather|finish]_mmu is called.

Before making it simple, this patch separates architecture specific
part and rename it to arch_tlb_[gather|finish]_mmu and generic part
just calls it.

It shouldn't change any behavior.

Cc: Ingo Molnar 
Cc: Russell King 
Cc: Tony Luck 
Cc: Martin Schwidefsky 
Cc: "David S. Miller" 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Jeff Dike 
Cc: linux-a...@vger.kernel.org
Cc: Nadav Amit 
Cc: Mel Gorman 
Signed-off-by: Minchan Kim 
---
 arch/arm/include/asm/tlb.h  |  6 --
 arch/ia64/include/asm/tlb.h |  6 --
 arch/s390/include/asm/tlb.h | 12 ++--
 arch/sh/include/asm/tlb.h   |  6 --
 arch/um/include/asm/tlb.h   |  8 +---
 include/asm-generic/tlb.h   |  7 ---
 include/linux/mm_types.h|  6 ++
 mm/memory.c | 36 +---
 8 files changed, 62 insertions(+), 25 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 3f2eb76243e3..7f5b2a2d3861 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -148,7 +148,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 }
 
 static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long 
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->fullmm = !(start | (end+1));
@@ -166,7 +167,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct 
*mm, unsigned long start
 }
 
 static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long start, unsigned long end)
 {
tlb_flush_mmu(tlb);
 
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index fced197b9626..93cadc04ac62 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -168,7 +168,8 @@ static inline void __tlb_alloc_page(struct mmu_gather *tlb)
 
 
 static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long 
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->max = ARRAY_SIZE(tlb->local);
@@ -185,7 +186,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct 
*mm, unsigned long start
  * collected.
  */
 static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long start, unsigned long end)
 {
/*
 * Note: tlb->nr may be 0 at this point, so we can't rely on 
tlb->start_addr and
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 950af48e88be..fa4b461694b7 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -47,10 +47,9 @@ struct mmu_table_batch {
 extern void tlb_table_flush(struct mmu_gather *tlb);
 extern void tlb_remove_table(struct mmu_gather *tlb, void *table);
 
-static inline void tlb_gather_mmu(struct mmu_gather *tlb,
- struct mm_struct *mm,
- unsigned long start,
- unsigned long end)
+static inline void
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->start = start;
@@ -76,8 +75,9 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
tlb_flush_mmu_free(tlb);
 }
 
-static inline void tlb_finish_mmu(struct mmu_gather *tlb,
- unsigned long start, unsigned long end)
+static inline void
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long start, unsigned long end)
 {
tlb_flush_mmu(tlb);
 }
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 46e0d635e36f..89786560dbd4 100644
--- a/arch/sh/include/asm/tlb.h
+++ b/arch/sh/include/asm/tlb.h
@@ -36,7 +36,8 @@ static inline void init_tlb_gather(struct mmu_gather *tlb)
 }
 
 static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long 
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->start = start;
@@ -47,7 +48,8 @@ 

[PATCH v2 1/4] mm: refactoring TLB gathering API

2017-07-31 Thread Minchan Kim
This patch is ready for solving race problems caused by TLB batch.
For that, we will increase/decrease TLB flush pending count of
mm_struct whenever tlb_[gather|finish]_mmu is called.

Before making it simple, this patch separates architecture specific
part and rename it to arch_tlb_[gather|finish]_mmu and generic part
just calls it.

It shouldn't change any behavior.

Cc: Ingo Molnar 
Cc: Russell King 
Cc: Tony Luck 
Cc: Martin Schwidefsky 
Cc: "David S. Miller" 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Jeff Dike 
Cc: linux-a...@vger.kernel.org
Cc: Nadav Amit 
Cc: Mel Gorman 
Signed-off-by: Minchan Kim 
---
 arch/arm/include/asm/tlb.h  |  6 --
 arch/ia64/include/asm/tlb.h |  6 --
 arch/s390/include/asm/tlb.h | 12 ++--
 arch/sh/include/asm/tlb.h   |  6 --
 arch/um/include/asm/tlb.h   |  8 +---
 include/asm-generic/tlb.h   |  7 ---
 include/linux/mm_types.h|  6 ++
 mm/memory.c | 36 +---
 8 files changed, 62 insertions(+), 25 deletions(-)

diff --git a/arch/arm/include/asm/tlb.h b/arch/arm/include/asm/tlb.h
index 3f2eb76243e3..7f5b2a2d3861 100644
--- a/arch/arm/include/asm/tlb.h
+++ b/arch/arm/include/asm/tlb.h
@@ -148,7 +148,8 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
 }
 
 static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long 
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->fullmm = !(start | (end+1));
@@ -166,7 +167,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct 
*mm, unsigned long start
 }
 
 static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long start, unsigned long end)
 {
tlb_flush_mmu(tlb);
 
diff --git a/arch/ia64/include/asm/tlb.h b/arch/ia64/include/asm/tlb.h
index fced197b9626..93cadc04ac62 100644
--- a/arch/ia64/include/asm/tlb.h
+++ b/arch/ia64/include/asm/tlb.h
@@ -168,7 +168,8 @@ static inline void __tlb_alloc_page(struct mmu_gather *tlb)
 
 
 static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long 
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->max = ARRAY_SIZE(tlb->local);
@@ -185,7 +186,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct 
*mm, unsigned long start
  * collected.
  */
 static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long start, unsigned long end)
 {
/*
 * Note: tlb->nr may be 0 at this point, so we can't rely on 
tlb->start_addr and
diff --git a/arch/s390/include/asm/tlb.h b/arch/s390/include/asm/tlb.h
index 950af48e88be..fa4b461694b7 100644
--- a/arch/s390/include/asm/tlb.h
+++ b/arch/s390/include/asm/tlb.h
@@ -47,10 +47,9 @@ struct mmu_table_batch {
 extern void tlb_table_flush(struct mmu_gather *tlb);
 extern void tlb_remove_table(struct mmu_gather *tlb, void *table);
 
-static inline void tlb_gather_mmu(struct mmu_gather *tlb,
- struct mm_struct *mm,
- unsigned long start,
- unsigned long end)
+static inline void
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->start = start;
@@ -76,8 +75,9 @@ static inline void tlb_flush_mmu(struct mmu_gather *tlb)
tlb_flush_mmu_free(tlb);
 }
 
-static inline void tlb_finish_mmu(struct mmu_gather *tlb,
- unsigned long start, unsigned long end)
+static inline void
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long start, unsigned long end)
 {
tlb_flush_mmu(tlb);
 }
diff --git a/arch/sh/include/asm/tlb.h b/arch/sh/include/asm/tlb.h
index 46e0d635e36f..89786560dbd4 100644
--- a/arch/sh/include/asm/tlb.h
+++ b/arch/sh/include/asm/tlb.h
@@ -36,7 +36,8 @@ static inline void init_tlb_gather(struct mmu_gather *tlb)
 }
 
 static inline void
-tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, unsigned long 
start, unsigned long end)
+arch_tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm,
+   unsigned long start, unsigned long end)
 {
tlb->mm = mm;
tlb->start = start;
@@ -47,7 +48,8 @@ tlb_gather_mmu(struct mmu_gather *tlb, struct mm_struct *mm, 
unsigned long start
 }
 
 static inline void
-tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
+arch_tlb_finish_mmu(struct mmu_gather *tlb,
+   unsigned long 

[PATCH v2 2/4] mm: make tlb_flush_pending global

2017-07-31 Thread Minchan Kim
Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING|
COMPACTION] but upcoming patches to solve subtle TLB flush bacting
problem will use it regardless of compaction/numa so this patch
doesn't remove the dependency.

Cc: Nadav Amit 
Cc: Mel Gorman 
Signed-off-by: Minchan Kim 
---
 include/linux/mm_types.h | 21 -
 mm/debug.c   |  2 --
 2 files changed, 23 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index c605f2a3a68e..892a7b0196fd 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -487,14 +487,12 @@ struct mm_struct {
/* numa_scan_seq prevents two threads setting pte_numa */
int numa_scan_seq;
 #endif
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
/*
 * An operation with batched TLB flushing is going on. Anything that
 * can move process memory needs to flush the TLB when moving a
 * PROT_NONE or PROT_NUMA mapped page.
 */
atomic_t tlb_flush_pending;
-#endif
 #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
/* See flush_tlb_batched_pending() */
bool tlb_flush_batched;
@@ -528,7 +526,6 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm,
 extern void tlb_finish_mmu(struct mmu_gather *tlb,
unsigned long start, unsigned long end);
 
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
 /*
  * Memory barriers to keep this state in sync are graciously provided by
  * the page table locks, outside of which no page table modifications happen.
@@ -569,24 +566,6 @@ static inline void dec_tlb_flush_pending(struct mm_struct 
*mm)
smp_mb__before_atomic();
atomic_dec(>tlb_flush_pending);
 }
-#else
-static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
-{
-   return false;
-}
-
-static inline void init_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-
-static inline void inc_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-
-static inline void dec_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-#endif
 
 struct vm_fault;
 
diff --git a/mm/debug.c b/mm/debug.c
index d70103bb4731..18a9b15b1e37 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -158,9 +158,7 @@ void dump_mm(const struct mm_struct *mm)
 #ifdef CONFIG_NUMA_BALANCING
mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
 #endif
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
atomic_read(>tlb_flush_pending),
-#endif
mm->def_flags, >def_flags
);
 }
-- 
2.7.4



[PATCH v2 2/4] mm: make tlb_flush_pending global

2017-07-31 Thread Minchan Kim
Currently, tlb_flush_pending is used only for CONFIG_[NUMA_BALANCING|
COMPACTION] but upcoming patches to solve subtle TLB flush bacting
problem will use it regardless of compaction/numa so this patch
doesn't remove the dependency.

Cc: Nadav Amit 
Cc: Mel Gorman 
Signed-off-by: Minchan Kim 
---
 include/linux/mm_types.h | 21 -
 mm/debug.c   |  2 --
 2 files changed, 23 deletions(-)

diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index c605f2a3a68e..892a7b0196fd 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -487,14 +487,12 @@ struct mm_struct {
/* numa_scan_seq prevents two threads setting pte_numa */
int numa_scan_seq;
 #endif
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
/*
 * An operation with batched TLB flushing is going on. Anything that
 * can move process memory needs to flush the TLB when moving a
 * PROT_NONE or PROT_NUMA mapped page.
 */
atomic_t tlb_flush_pending;
-#endif
 #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
/* See flush_tlb_batched_pending() */
bool tlb_flush_batched;
@@ -528,7 +526,6 @@ extern void tlb_gather_mmu(struct mmu_gather *tlb, struct 
mm_struct *mm,
 extern void tlb_finish_mmu(struct mmu_gather *tlb,
unsigned long start, unsigned long end);
 
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
 /*
  * Memory barriers to keep this state in sync are graciously provided by
  * the page table locks, outside of which no page table modifications happen.
@@ -569,24 +566,6 @@ static inline void dec_tlb_flush_pending(struct mm_struct 
*mm)
smp_mb__before_atomic();
atomic_dec(>tlb_flush_pending);
 }
-#else
-static inline bool mm_tlb_flush_pending(struct mm_struct *mm)
-{
-   return false;
-}
-
-static inline void init_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-
-static inline void inc_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-
-static inline void dec_tlb_flush_pending(struct mm_struct *mm)
-{
-}
-#endif
 
 struct vm_fault;
 
diff --git a/mm/debug.c b/mm/debug.c
index d70103bb4731..18a9b15b1e37 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -158,9 +158,7 @@ void dump_mm(const struct mm_struct *mm)
 #ifdef CONFIG_NUMA_BALANCING
mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
 #endif
-#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
atomic_read(>tlb_flush_pending),
-#endif
mm->def_flags, >def_flags
);
 }
-- 
2.7.4



[PATCH v2 0/4] fix several TLB batch races

2017-07-31 Thread Minchan Kim
Nadav and Mel founded several subtle races caused by TLB batching.
This patchset aims for solving thoses problems using embedding
[inc|dec]_tlb_flush_pending to TLB batching API.
With that, places to know TLB flush pending catch it up by
using mm_tlb_flush_pending.

Each patch includes detailed description.

This patchset is based on v4.13-rc2-mmots-2017-07-28-16-10 +
"[PATCH v5 0/3] mm: fixes of tlb_flush_pending races" from Nadav

* from v1
  * TLB batching API separation core part from arch specific one - Mel
  * introduce mm_tlb_flush_nested - Mel

Minchan Kim (4):
  mm: refactoring TLB gathering API
  mm: make tlb_flush_pending global
  mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem
  mm: fix KSM data corruption

 arch/arm/include/asm/tlb.h  | 11 ++--
 arch/ia64/include/asm/tlb.h |  8 --
 arch/s390/include/asm/tlb.h | 17 -
 arch/sh/include/asm/tlb.h   |  8 +++---
 arch/um/include/asm/tlb.h   | 13 +++---
 fs/proc/task_mmu.c  |  4 ++-
 include/asm-generic/tlb.h   |  7 ++---
 include/linux/mm_types.h| 35 ++---
 mm/debug.c  |  2 --
 mm/ksm.c|  3 ++-
 mm/memory.c | 62 +++--
 11 files changed, 107 insertions(+), 63 deletions(-)

-- 
2.7.4



[PATCH v2 4/4] mm: fix KSM data corruption

2017-07-31 Thread Minchan Kim
Nadav reported KSM can corrupt the user data by the TLB batching race[1].
That means data user written can be lost.

Quote from Nadav Amit
"
For this race we need 4 CPUs:

CPU0: Caches a writable and dirty PTE entry, and uses the stale value for
write later.

CPU1: Runs madvise_free on the range that includes the PTE. It would clear
the dirty-bit. It batches TLB flushes.

CPU2: Writes 4 to /proc/PID/clear_refs , clearing the PTEs soft-dirty. We
care about the fact that it clears the PTE write-bit, and of course, batches
TLB flushes.

CPU3: Runs KSM. Our purpose is to pass the following test in
write_protect_page():

if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) ||
(pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)))

Since it will avoid TLB flush. And we want to do it while the PTE is stale.
Later, and before replacing the page, we would be able to change the page.

Note that all the operations the CPU1-3 perform canhappen in parallel since
they only acquire mmap_sem for read.

We start with two identical pages. Everything below regards the same
page/PTE.

CPU0CPU1CPU2CPU3

Write the same
value on page

[cache PTE as
 dirty in TLB]

MADV_FREE
pte_mkclean()

4 > clear_refs
pte_wrprotect()

write_protect_page()
[ success, no flush ]

pages_indentical()
[ ok ]

Write to page
different value

[Ok, using stale
 PTE]

replace_page()

Later, CPU1, CPU2 and CPU3 would flush the TLB, but that is too late. CPU0
already wrote on the page, but KSM ignored this write, and it got lost.
"

In above scenario, MADV_FREE is fixed by changing TLB batching API
including [set|clear]_tlb_flush_pending. Remained thing is soft-dirty part.

This patch changes soft-dirty uses TLB batching API instead of flush_tlb_mm
and KSM checks pending TLB flush by using mm_tlb_flush_pending so that
it will flush TLB to avoid data lost if there are other parallel threads
pending TLB flush.

[1] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com

Note:
I failed to reproduce this problem through Nadav's test program which
need to tune timing in my system speed so didn't confirm it work.
Nadav, Could you test this patch on your test machine?

Thanks!

Cc: Nadav Amit 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Andrea Arcangeli 
Signed-off-by: Minchan Kim 
---
 fs/proc/task_mmu.c | 4 +++-
 mm/ksm.c   | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9782dedeead7..58ef3a6abbc0 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1018,6 +1018,7 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
enum clear_refs_types type;
int itype;
int rv;
+   struct mmu_gather tlb;
 
memset(buffer, 0, sizeof(buffer));
if (count > sizeof(buffer) - 1)
@@ -1062,6 +1063,7 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
}
 
down_read(>mmap_sem);
+   tlb_gather_mmu(, mm, 0, -1);
if (type == CLEAR_REFS_SOFT_DIRTY) {
for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (!(vma->vm_flags & VM_SOFTDIRTY))
@@ -1083,7 +1085,7 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
walk_page_range(0, mm->highest_vm_end, _refs_walk);
if (type == CLEAR_REFS_SOFT_DIRTY)
mmu_notifier_invalidate_range_end(mm, 0, -1);
-   flush_tlb_mm(mm);
+   tlb_finish_mmu(, 0, -1);
up_read(>mmap_sem);
 out_mm:
mmput(mm);
diff --git a/mm/ksm.c b/mm/ksm.c
index 0c927e36a639..15dd7415f7b3 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1038,7 +1038,8 @@ static int write_protect_page(struct vm_area_struct *vma, 
struct page *page,
goto out_unlock;
 
if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) ||
-   (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) {
+   (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)) ||
+   mm_tlb_flush_pending(mm)) {
pte_t entry;
 
swapped = PageSwapCache(page);
-- 
2.7.4



[PATCH v2 0/4] fix several TLB batch races

2017-07-31 Thread Minchan Kim
Nadav and Mel founded several subtle races caused by TLB batching.
This patchset aims for solving thoses problems using embedding
[inc|dec]_tlb_flush_pending to TLB batching API.
With that, places to know TLB flush pending catch it up by
using mm_tlb_flush_pending.

Each patch includes detailed description.

This patchset is based on v4.13-rc2-mmots-2017-07-28-16-10 +
"[PATCH v5 0/3] mm: fixes of tlb_flush_pending races" from Nadav

* from v1
  * TLB batching API separation core part from arch specific one - Mel
  * introduce mm_tlb_flush_nested - Mel

Minchan Kim (4):
  mm: refactoring TLB gathering API
  mm: make tlb_flush_pending global
  mm: fix MADV_[FREE|DONTNEED] TLB flush miss problem
  mm: fix KSM data corruption

 arch/arm/include/asm/tlb.h  | 11 ++--
 arch/ia64/include/asm/tlb.h |  8 --
 arch/s390/include/asm/tlb.h | 17 -
 arch/sh/include/asm/tlb.h   |  8 +++---
 arch/um/include/asm/tlb.h   | 13 +++---
 fs/proc/task_mmu.c  |  4 ++-
 include/asm-generic/tlb.h   |  7 ++---
 include/linux/mm_types.h| 35 ++---
 mm/debug.c  |  2 --
 mm/ksm.c|  3 ++-
 mm/memory.c | 62 +++--
 11 files changed, 107 insertions(+), 63 deletions(-)

-- 
2.7.4



[PATCH v2 4/4] mm: fix KSM data corruption

2017-07-31 Thread Minchan Kim
Nadav reported KSM can corrupt the user data by the TLB batching race[1].
That means data user written can be lost.

Quote from Nadav Amit
"
For this race we need 4 CPUs:

CPU0: Caches a writable and dirty PTE entry, and uses the stale value for
write later.

CPU1: Runs madvise_free on the range that includes the PTE. It would clear
the dirty-bit. It batches TLB flushes.

CPU2: Writes 4 to /proc/PID/clear_refs , clearing the PTEs soft-dirty. We
care about the fact that it clears the PTE write-bit, and of course, batches
TLB flushes.

CPU3: Runs KSM. Our purpose is to pass the following test in
write_protect_page():

if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) ||
(pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)))

Since it will avoid TLB flush. And we want to do it while the PTE is stale.
Later, and before replacing the page, we would be able to change the page.

Note that all the operations the CPU1-3 perform canhappen in parallel since
they only acquire mmap_sem for read.

We start with two identical pages. Everything below regards the same
page/PTE.

CPU0CPU1CPU2CPU3

Write the same
value on page

[cache PTE as
 dirty in TLB]

MADV_FREE
pte_mkclean()

4 > clear_refs
pte_wrprotect()

write_protect_page()
[ success, no flush ]

pages_indentical()
[ ok ]

Write to page
different value

[Ok, using stale
 PTE]

replace_page()

Later, CPU1, CPU2 and CPU3 would flush the TLB, but that is too late. CPU0
already wrote on the page, but KSM ignored this write, and it got lost.
"

In above scenario, MADV_FREE is fixed by changing TLB batching API
including [set|clear]_tlb_flush_pending. Remained thing is soft-dirty part.

This patch changes soft-dirty uses TLB batching API instead of flush_tlb_mm
and KSM checks pending TLB flush by using mm_tlb_flush_pending so that
it will flush TLB to avoid data lost if there are other parallel threads
pending TLB flush.

[1] http://lkml.kernel.org/r/bd3a0ebe-ecf4-41d4-87fa-c755ea9ab...@gmail.com

Note:
I failed to reproduce this problem through Nadav's test program which
need to tune timing in my system speed so didn't confirm it work.
Nadav, Could you test this patch on your test machine?

Thanks!

Cc: Nadav Amit 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Andrea Arcangeli 
Signed-off-by: Minchan Kim 
---
 fs/proc/task_mmu.c | 4 +++-
 mm/ksm.c   | 3 ++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 9782dedeead7..58ef3a6abbc0 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1018,6 +1018,7 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
enum clear_refs_types type;
int itype;
int rv;
+   struct mmu_gather tlb;
 
memset(buffer, 0, sizeof(buffer));
if (count > sizeof(buffer) - 1)
@@ -1062,6 +1063,7 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
}
 
down_read(>mmap_sem);
+   tlb_gather_mmu(, mm, 0, -1);
if (type == CLEAR_REFS_SOFT_DIRTY) {
for (vma = mm->mmap; vma; vma = vma->vm_next) {
if (!(vma->vm_flags & VM_SOFTDIRTY))
@@ -1083,7 +1085,7 @@ static ssize_t clear_refs_write(struct file *file, const 
char __user *buf,
walk_page_range(0, mm->highest_vm_end, _refs_walk);
if (type == CLEAR_REFS_SOFT_DIRTY)
mmu_notifier_invalidate_range_end(mm, 0, -1);
-   flush_tlb_mm(mm);
+   tlb_finish_mmu(, 0, -1);
up_read(>mmap_sem);
 out_mm:
mmput(mm);
diff --git a/mm/ksm.c b/mm/ksm.c
index 0c927e36a639..15dd7415f7b3 100644
--- a/mm/ksm.c
+++ b/mm/ksm.c
@@ -1038,7 +1038,8 @@ static int write_protect_page(struct vm_area_struct *vma, 
struct page *page,
goto out_unlock;
 
if (pte_write(*pvmw.pte) || pte_dirty(*pvmw.pte) ||
-   (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte))) {
+   (pte_protnone(*pvmw.pte) && pte_savedwrite(*pvmw.pte)) ||
+   mm_tlb_flush_pending(mm)) {
pte_t entry;
 
swapped = PageSwapCache(page);
-- 
2.7.4



Re: [RFC]Add new mdev interface for QoS

2017-07-31 Thread Gao, Ping A

On 2017/7/28 0:00, Gao, Ping A wrote:
> On 2017/7/27 0:43, Alex Williamson wrote:
>> [cc +libvir-list]
>>
>> On Wed, 26 Jul 2017 21:16:59 +0800
>> "Gao, Ping A"  wrote:
>>
>>> The vfio-mdev provide the capability to let different guest share the
>>> same physical device through mediate sharing, as result it bring a
>>> requirement about how to control the device sharing, we need a QoS
>>> related interface for mdev to management virtual device resource.
>>>
>>> E.g. In practical use, vGPUs assigned to different quests almost has
>>> different performance requirements, some guests may need higher priority
>>> for real time usage, some other may need more portion of the GPU
>>> resource to get higher 3D performance, corresponding we can define some
>>> interfaces like weight/cap for overall budget control, priority for
>>> single submission control.
>>>
>>> So I suggest to add some common attributes which are vendor agnostic in
>>> mdev core sysfs for QoS purpose.
>> I think what you're asking for is just some standardization of a QoS
>> attribute_group which a vendor can optionally include within the
>> existing mdev_parent_ops.mdev_attr_groups.  The mdev core will
>> transparently enable this, but it really only provides the standard,
>> all of the support code is left for the vendor.  I'm fine with that,
>> but of course the trouble with and sort of standardization is arriving
>> at an agreed upon standard.  Are there QoS knobs that are generic
>> across any mdev device type?  Are there others that are more specific
>> to vGPU?  Are there existing examples of this that we can steal their
>> specification?
> Yes, you are right, standardization QoS knobs are exactly what I wanted.
> Only when it become a part of the mdev framework and libvirt, then QoS
> such critical feature can be leveraged by cloud usage. HW vendor only
> need to focus on the implementation of the corresponding QoS algorithm
> in their back-end driver.
>
> Vfio-mdev framework provide the capability to share the device that lack
> of HW virtualization support to guests, no matter the device type,
> mediated sharing actually is a time sharing multiplex method, from this
> point of view, QoS can be take as a generic way about how to control the
> time assignment for virtual mdev device that occupy HW. As result we can
> define QoS knob generic across any device type by this way. Even if HW
> has build in with some kind of QoS support, I think it's not a problem
> for back-end driver to convert mdev standard QoS definition to their
> specification to reach the same performance expectation. Seems there are
> no examples for us to follow, we need define it from scratch.
>
> I proposal universal QoS control interfaces like below:
>
> Cap: The cap limits the maximum percentage of time a mdev device can own
> physical device. e.g. cap=60, means mdev device cannot take over 60% of
> total physical resource.
>
> Weight: The weight define proportional control of the mdev device
> resource between guests, it’s orthogonal with Cap, to target load
> balancing. E.g. if guest 1 should take double mdev device resource
> compare with guest 2, need set weight ratio to 2:1.
>
> Priority: The guest who has higher priority will get execution first,
> target to some real time usage and speeding interactive response.
>
> Above QoS interfaces cover both overall budget control and single
> submission control. I will sent out detail design later once get aligned.

Hi Alex,
Any comments about the interface mentioned above?

>> Also, mdev devices are not necessarily the exclusive users of the
>> hardware, we can have a native user such as a local X client.  They're
>> not an mdev user, so we can't support them via the mdev_attr_group.
>> Does there need to be a per mdev parent QoS attribute_group standard
>> for somehow defining the QoS of all the child mdev devices, or perhaps
>> representing the remaining host QoS attributes?
> That's really an open, if we don't take host workload into consideration
> for cloud usage, it's not a problem any more, however such assumption is
> not reasonable. Any way if we take mdev devices as clients of host
> driver, and host driver provide the capability to divide out a portion
> HW resource to mdev devices, then it's only need to take care about the
> resource that host assigned for mdev devices. Follow this way QoS for
> mdev focus on the relationship between mdev devices no need to take care
> the host workload.
>
> -Ping
>
>> Ultimately libvirt and upper level management tools would be the
>> consumer of these control knobs, so let's immediately get libvirt
>> involved in the discussion.  Thanks,
>>
>> Alex



Re: [RFC]Add new mdev interface for QoS

2017-07-31 Thread Gao, Ping A

On 2017/7/28 0:00, Gao, Ping A wrote:
> On 2017/7/27 0:43, Alex Williamson wrote:
>> [cc +libvir-list]
>>
>> On Wed, 26 Jul 2017 21:16:59 +0800
>> "Gao, Ping A"  wrote:
>>
>>> The vfio-mdev provide the capability to let different guest share the
>>> same physical device through mediate sharing, as result it bring a
>>> requirement about how to control the device sharing, we need a QoS
>>> related interface for mdev to management virtual device resource.
>>>
>>> E.g. In practical use, vGPUs assigned to different quests almost has
>>> different performance requirements, some guests may need higher priority
>>> for real time usage, some other may need more portion of the GPU
>>> resource to get higher 3D performance, corresponding we can define some
>>> interfaces like weight/cap for overall budget control, priority for
>>> single submission control.
>>>
>>> So I suggest to add some common attributes which are vendor agnostic in
>>> mdev core sysfs for QoS purpose.
>> I think what you're asking for is just some standardization of a QoS
>> attribute_group which a vendor can optionally include within the
>> existing mdev_parent_ops.mdev_attr_groups.  The mdev core will
>> transparently enable this, but it really only provides the standard,
>> all of the support code is left for the vendor.  I'm fine with that,
>> but of course the trouble with and sort of standardization is arriving
>> at an agreed upon standard.  Are there QoS knobs that are generic
>> across any mdev device type?  Are there others that are more specific
>> to vGPU?  Are there existing examples of this that we can steal their
>> specification?
> Yes, you are right, standardization QoS knobs are exactly what I wanted.
> Only when it become a part of the mdev framework and libvirt, then QoS
> such critical feature can be leveraged by cloud usage. HW vendor only
> need to focus on the implementation of the corresponding QoS algorithm
> in their back-end driver.
>
> Vfio-mdev framework provide the capability to share the device that lack
> of HW virtualization support to guests, no matter the device type,
> mediated sharing actually is a time sharing multiplex method, from this
> point of view, QoS can be take as a generic way about how to control the
> time assignment for virtual mdev device that occupy HW. As result we can
> define QoS knob generic across any device type by this way. Even if HW
> has build in with some kind of QoS support, I think it's not a problem
> for back-end driver to convert mdev standard QoS definition to their
> specification to reach the same performance expectation. Seems there are
> no examples for us to follow, we need define it from scratch.
>
> I proposal universal QoS control interfaces like below:
>
> Cap: The cap limits the maximum percentage of time a mdev device can own
> physical device. e.g. cap=60, means mdev device cannot take over 60% of
> total physical resource.
>
> Weight: The weight define proportional control of the mdev device
> resource between guests, it’s orthogonal with Cap, to target load
> balancing. E.g. if guest 1 should take double mdev device resource
> compare with guest 2, need set weight ratio to 2:1.
>
> Priority: The guest who has higher priority will get execution first,
> target to some real time usage and speeding interactive response.
>
> Above QoS interfaces cover both overall budget control and single
> submission control. I will sent out detail design later once get aligned.

Hi Alex,
Any comments about the interface mentioned above?

>> Also, mdev devices are not necessarily the exclusive users of the
>> hardware, we can have a native user such as a local X client.  They're
>> not an mdev user, so we can't support them via the mdev_attr_group.
>> Does there need to be a per mdev parent QoS attribute_group standard
>> for somehow defining the QoS of all the child mdev devices, or perhaps
>> representing the remaining host QoS attributes?
> That's really an open, if we don't take host workload into consideration
> for cloud usage, it's not a problem any more, however such assumption is
> not reasonable. Any way if we take mdev devices as clients of host
> driver, and host driver provide the capability to divide out a portion
> HW resource to mdev devices, then it's only need to take care about the
> resource that host assigned for mdev devices. Follow this way QoS for
> mdev focus on the relationship between mdev devices no need to take care
> the host workload.
>
> -Ping
>
>> Ultimately libvirt and upper level management tools would be the
>> consumer of these control knobs, so let's immediately get libvirt
>> involved in the discussion.  Thanks,
>>
>> Alex



linux-next: manual merge of the akpm tree with the wberr tree

2017-07-31 Thread Stephen Rothwell
Hi Andrew,

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

  include/linux/fs.h

between commit:

  9dcc0577f2a4 ("mm: remove optimizations based on i_size in mapping writeback 
waits")

from the wberr tree and patch:

  "mm: remove optimizations based on i_size in mapping writeback waits"

from the akpm tree.

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

-- 
Cheers,
Stephen Rothwell


linux-next: manual merge of the akpm tree with the wberr tree

2017-07-31 Thread Stephen Rothwell
Hi Andrew,

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

  include/linux/fs.h

between commit:

  9dcc0577f2a4 ("mm: remove optimizations based on i_size in mapping writeback 
waits")

from the wberr tree and patch:

  "mm: remove optimizations based on i_size in mapping writeback waits"

from the akpm tree.

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

-- 
Cheers,
Stephen Rothwell


Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

2017-07-31 Thread Feng Kan
On Mon, Jul 31, 2017 at 2:55 PM, Alex Williamson
 wrote:
> On Mon, 31 Jul 2017 10:56:53 -0700
> Feng Kan  wrote:
>
>> On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson
>>  wrote:
>> > On Fri, 28 Jul 2017 11:50:43 -0700
>> > Feng Kan  wrote:
>> >
>> >> The APM X-Gene PCIe root port does not support ACS at this point.
>> >> However, the hw provides isolation and source validation through
>> >> the SMMU. The stream ID generated by the PCIe ports contain both
>> >> the BDF as well as the port ID in its 3 most significant bits.
>> >> Turn on ACS but disable all the peer to peer features.
>> >>
>> >> Signed-off-by: Feng Kan 
>> >> ---
>> >>   V3 Change: Add comment regarding unique port id in stream ID
>> >>   V2 Change: Move XGene ACS quirk to unique XGene function
>> >>
>> >>  drivers/pci/quirks.c | 15 +++
>> >>  1 file changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> >> index 085fb78..0f8f1cd 100644
>> >> --- a/drivers/pci/quirks.c
>> >> +++ b/drivers/pci/quirks.c
>> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   return acs_flags ? 0 : 1;
>> >>  }
>> >>
>> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> >> +{
>> >> + /*
>> >> +  * XGene root matching this quirk do not allow peer-to-peer
>> >> +  * transactions with others, allowing masking out these bits as if 
>> >> they
>> >> +  * were unimplemented in the ACS capability.
>> >> +  */
>> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> >> +
>> >> + return acs_flags ? 0 : 1;
>> >> +}
>> >> +
>> >>  /*
>> >>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>> >>   * transactions and validate bus numbers in requests, but do not provide 
>> >> an
>> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>> >>   /* Cavium ThunderX */
>> >>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> >> + /* APM XGene */
>> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>> >>   { 0 }
>> >>  };
>> >>
>> >
>> > Hi Feng,
>> >
>> > Sorry, I have one more question as I happened to spend some time
>> > looking at PCI_ACS_DT this week.  DT specifies that peer-to-peer should
>> > occur normally between egress ports for transactions which are
>> > pre-translated by an ATS unit on the endpoint.  Therefore if a root
>> > port doesn't allow peer-to-peer, it seems like it should not claim to
>> > support PCI_ACS_DT.  I know your quirk is just a copy of the Cavium
>> > one, but we should also go back and verify this question with them, or
>> > perhaps I'm misinterpreting this capability.  AIUI this is also a
>> > performance capability, not an isolation capability, so it shouldn't
>> > affect the ability to consider a device isolated, it only gets
>> > confusing if we expect a performance benefit from this but don't
>> > actually see one.  Does your root port have this ability to
>> > selectively allow peer-to-peer of pre-translated transactions?  Thanks,
>> We do not support peer to peer between root ports (each root port is a
>> root complex in itself).
>> Therefore, this bit set/unset has no effect.
>>
>> As one of our guys pointed out in PCIe 3.1a, it may help address your
>> concern above.
>>
>> """
>> Root Port indication of ACS Direct Translated P2P support does not imply any
>> particular level of peer-to-peer support by the Root Complex, or that
>> peer-to-peer traffic is supported at all.
>> """
>
> That's interesting, but is that referring to the ACS capability or the
> control?


I could imagine how advertising the capability would not
> imply any particular level of p2p, but enabling the control (which is
> what we're claiming via this quirk) the spec states:
>
>   When ACS Direct Translated P2P is enabled in a Downstream Port,
>   peer-to-peer Memory Requests whose Address Type (AT) field indicates
>   a Translated address must be routed normally (“directly”) to the peer
>   Egress Port, regardless of ACS P2P Request Redirect and ACS P2P
>   Egress Control settings. All other peer-to-peer Requests must still
>   be subject to ACS P2P Request Redirect and ACS P2P Egress Control
>   settings.
>
> Note the *must* phrasing.  Furthermore, 7.16.3:
>
>   ACS Direct Translated P2P Enable (T) – When Set, overrides the ACS
>   P2P Request Redirect and ACS P2P Egress Control mechanisms with
>   peer-to-peer Memory Requests whose Address Translation (AT) field
>   indicates a Translated address (see Section 6.12.3).
>
>   This bit is ignored if ACS Translation Blocking Enable (B) is 1b.
>
>   Default value of this bit is 0b. 

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

2017-07-31 Thread Linus Torvalds
On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk
 wrote:
> Another NFSv4 KASAN splat, this time from rc3.
>
> BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]

Ugh. It's really hard to tell what access that it - KASAN doesn't
actually give enough information. There's lots of 8-byte accesses
there in that function.

Any chance of getting the output from

   ./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0

or something? That would be extremely useful in general for
stacktraces, but it's doubly useful for KASAN because most *other*
stacktraces tend to have a very limited number of things that can warn
(ie there's one or two WARN_ON() calls in a function), but KASAN can
have tens or hundreds..

   Linus


> Read of size 8 at addr 8804508af528 by task kworker/2:1/34
>
> CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1
> Workqueue: rpciod rpc_async_schedule [sunrpc]
> Call Trace:
>  dump_stack+0x68/0xa1
>  print_address_description+0xd9/0x270
>  kasan_report+0x257/0x370
>  ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
>  check_memory_region+0x13a/0x1a0
>  __asan_loadN+0xf/0x20
>  nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
>  ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4]
>  rpc_exit_task+0x69/0x110 [sunrpc]
>  ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
>  ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
>  __rpc_execute+0x1a0/0x840 [sunrpc]
>  ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc]
>  ? __lock_is_held+0x9a/0x100
>  ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30
>  rpc_async_schedule+0x12/0x20 [sunrpc]
>  process_one_work+0x4d5/0xa70
>  ? flush_delayed_work+0x70/0x70
>  ? lock_acquire+0xfc/0x220
>  worker_thread+0x88/0x630
>  ? pci_mmcfg_check_reserved+0xc0/0xc0
>  kthread+0x1a6/0x1f0
>  ? process_one_work+0xa70/0xa70
>  ? kthread_create_on_node+0xc0/0xc0
>  ret_from_fork+0x27/0x40
>
> Allocated by task 1:
>  save_stack_trace+0x1b/0x20
>  save_stack+0x46/0xd0
>  kasan_kmalloc+0xad/0xe0
>  kasan_slab_alloc+0x12/0x20
>  kmem_cache_alloc+0xe0/0x2f0
>  getname_flags+0x43/0x220
>  getname+0x12/0x20
>  do_sys_open+0x14c/0x2b0
>  SyS_open+0x1e/0x20
>  do_syscall_64+0xea/0x260
>  return_from_SYSCALL_64+0x0/0x7a
>
> Freed by task 1:
>  save_stack_trace+0x1b/0x20
>  save_stack+0x46/0xd0
>  kasan_slab_free+0x72/0xc0
>  kmem_cache_free+0xa8/0x300
>  putname+0x80/0x90
>  do_sys_open+0x22f/0x2b0
>  SyS_open+0x1e/0x20
>  do_syscall_64+0xea/0x260
>  return_from_SYSCALL_64+0x0/0x7a
>
> The buggy address belongs to the object at 8804508aeac0\x0a which belongs 
> to the cache names_cache of size 4096
> The buggy address is located 2664 bytes inside of\x0a 4096-byte region 
> [8804508aeac0, 8804508afac0)
> The buggy address belongs to the page:
> page:ea0011422a00 count:1 mapcount:0 mapping:  (null) index:0x0
> [CONT START]  compound_mapcount: 0
> flags: 0x80008100(slab|head)
> raw: 80008100   000100070007
> raw: ea00113d6020 ea001136e220 8804664f8040 
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>   ^
>  8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
>


Re: [PATCH V3] pci: quirk: Apply APM ACS quirk to XGene devices

2017-07-31 Thread Feng Kan
On Mon, Jul 31, 2017 at 2:55 PM, Alex Williamson
 wrote:
> On Mon, 31 Jul 2017 10:56:53 -0700
> Feng Kan  wrote:
>
>> On Fri, Jul 28, 2017 at 4:00 PM, Alex Williamson
>>  wrote:
>> > On Fri, 28 Jul 2017 11:50:43 -0700
>> > Feng Kan  wrote:
>> >
>> >> The APM X-Gene PCIe root port does not support ACS at this point.
>> >> However, the hw provides isolation and source validation through
>> >> the SMMU. The stream ID generated by the PCIe ports contain both
>> >> the BDF as well as the port ID in its 3 most significant bits.
>> >> Turn on ACS but disable all the peer to peer features.
>> >>
>> >> Signed-off-by: Feng Kan 
>> >> ---
>> >>   V3 Change: Add comment regarding unique port id in stream ID
>> >>   V2 Change: Move XGene ACS quirk to unique XGene function
>> >>
>> >>  drivers/pci/quirks.c | 15 +++
>> >>  1 file changed, 15 insertions(+)
>> >>
>> >> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> >> index 085fb78..0f8f1cd 100644
>> >> --- a/drivers/pci/quirks.c
>> >> +++ b/drivers/pci/quirks.c
>> >> @@ -4120,6 +4120,19 @@ static int pci_quirk_cavium_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   return acs_flags ? 0 : 1;
>> >>  }
>> >>
>> >> +static int pci_quirk_xgene_acs(struct pci_dev *dev, u16 acs_flags)
>> >> +{
>> >> + /*
>> >> +  * XGene root matching this quirk do not allow peer-to-peer
>> >> +  * transactions with others, allowing masking out these bits as if 
>> >> they
>> >> +  * were unimplemented in the ACS capability.
>> >> +  */
>> >> + acs_flags &= ~(PCI_ACS_SV | PCI_ACS_TB | PCI_ACS_RR |
>> >> +PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> >> +
>> >> + return acs_flags ? 0 : 1;
>> >> +}
>> >> +
>> >>  /*
>> >>   * Many Intel PCH root ports do provide ACS-like features to disable peer
>> >>   * transactions and validate bus numbers in requests, but do not provide 
>> >> an
>> >> @@ -4368,6 +4381,8 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev 
>> >> *dev, u16 acs_flags)
>> >>   { 0x10df, 0x720, pci_quirk_mf_endpoint_acs }, /* Emulex Skyhawk-R */
>> >>   /* Cavium ThunderX */
>> >>   { PCI_VENDOR_ID_CAVIUM, PCI_ANY_ID, pci_quirk_cavium_acs },
>> >> + /* APM XGene */
>> >> + { PCI_VENDOR_ID_AMCC, 0xE004, pci_quirk_xgene_acs },
>> >>   { 0 }
>> >>  };
>> >>
>> >
>> > Hi Feng,
>> >
>> > Sorry, I have one more question as I happened to spend some time
>> > looking at PCI_ACS_DT this week.  DT specifies that peer-to-peer should
>> > occur normally between egress ports for transactions which are
>> > pre-translated by an ATS unit on the endpoint.  Therefore if a root
>> > port doesn't allow peer-to-peer, it seems like it should not claim to
>> > support PCI_ACS_DT.  I know your quirk is just a copy of the Cavium
>> > one, but we should also go back and verify this question with them, or
>> > perhaps I'm misinterpreting this capability.  AIUI this is also a
>> > performance capability, not an isolation capability, so it shouldn't
>> > affect the ability to consider a device isolated, it only gets
>> > confusing if we expect a performance benefit from this but don't
>> > actually see one.  Does your root port have this ability to
>> > selectively allow peer-to-peer of pre-translated transactions?  Thanks,
>> We do not support peer to peer between root ports (each root port is a
>> root complex in itself).
>> Therefore, this bit set/unset has no effect.
>>
>> As one of our guys pointed out in PCIe 3.1a, it may help address your
>> concern above.
>>
>> """
>> Root Port indication of ACS Direct Translated P2P support does not imply any
>> particular level of peer-to-peer support by the Root Complex, or that
>> peer-to-peer traffic is supported at all.
>> """
>
> That's interesting, but is that referring to the ACS capability or the
> control?


I could imagine how advertising the capability would not
> imply any particular level of p2p, but enabling the control (which is
> what we're claiming via this quirk) the spec states:
>
>   When ACS Direct Translated P2P is enabled in a Downstream Port,
>   peer-to-peer Memory Requests whose Address Type (AT) field indicates
>   a Translated address must be routed normally (“directly”) to the peer
>   Egress Port, regardless of ACS P2P Request Redirect and ACS P2P
>   Egress Control settings. All other peer-to-peer Requests must still
>   be subject to ACS P2P Request Redirect and ACS P2P Egress Control
>   settings.
>
> Note the *must* phrasing.  Furthermore, 7.16.3:
>
>   ACS Direct Translated P2P Enable (T) – When Set, overrides the ACS
>   P2P Request Redirect and ACS P2P Egress Control mechanisms with
>   peer-to-peer Memory Requests whose Address Translation (AT) field
>   indicates a Translated address (see Section 6.12.3).
>
>   This bit is ignored if ACS Translation Blocking Enable (B) is 1b.
>
>   Default value of this bit is 0b. Must be hardwired to 0b if the ACS
>   Direct Translated P2P functionality is not implemented.
>
> 

Re: [GIT PULL] Please pull NFS client changes for Linux 4.13

2017-07-31 Thread Linus Torvalds
On Mon, Jul 31, 2017 at 8:43 AM, da...@codemonkey.org.uk
 wrote:
> Another NFSv4 KASAN splat, this time from rc3.
>
> BUG: KASAN: use-after-free in nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]

Ugh. It's really hard to tell what access that it - KASAN doesn't
actually give enough information. There's lots of 8-byte accesses
there in that function.

Any chance of getting the output from

   ./scripts/faddr2line vmlinux nfs4_exchange_id_done+0x3d7/0x8e0

or something? That would be extremely useful in general for
stacktraces, but it's doubly useful for KASAN because most *other*
stacktraces tend to have a very limited number of things that can warn
(ie there's one or two WARN_ON() calls in a function), but KASAN can
have tens or hundreds..

   Linus


> Read of size 8 at addr 8804508af528 by task kworker/2:1/34
>
> CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 4.13.0-rc3-think+ #1
> Workqueue: rpciod rpc_async_schedule [sunrpc]
> Call Trace:
>  dump_stack+0x68/0xa1
>  print_address_description+0xd9/0x270
>  kasan_report+0x257/0x370
>  ? nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
>  check_memory_region+0x13a/0x1a0
>  __asan_loadN+0xf/0x20
>  nfs4_exchange_id_done+0x3d7/0x8e0 [nfsv4]
>  ? nfs4_exchange_id_release+0xb0/0xb0 [nfsv4]
>  rpc_exit_task+0x69/0x110 [sunrpc]
>  ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
>  ? rpc_destroy_wait_queue+0x20/0x20 [sunrpc]
>  __rpc_execute+0x1a0/0x840 [sunrpc]
>  ? rpc_wake_up_queued_task+0x50/0x50 [sunrpc]
>  ? __lock_is_held+0x9a/0x100
>  ? debug_lockdep_rcu_enabled.part.16+0x1a/0x30
>  rpc_async_schedule+0x12/0x20 [sunrpc]
>  process_one_work+0x4d5/0xa70
>  ? flush_delayed_work+0x70/0x70
>  ? lock_acquire+0xfc/0x220
>  worker_thread+0x88/0x630
>  ? pci_mmcfg_check_reserved+0xc0/0xc0
>  kthread+0x1a6/0x1f0
>  ? process_one_work+0xa70/0xa70
>  ? kthread_create_on_node+0xc0/0xc0
>  ret_from_fork+0x27/0x40
>
> Allocated by task 1:
>  save_stack_trace+0x1b/0x20
>  save_stack+0x46/0xd0
>  kasan_kmalloc+0xad/0xe0
>  kasan_slab_alloc+0x12/0x20
>  kmem_cache_alloc+0xe0/0x2f0
>  getname_flags+0x43/0x220
>  getname+0x12/0x20
>  do_sys_open+0x14c/0x2b0
>  SyS_open+0x1e/0x20
>  do_syscall_64+0xea/0x260
>  return_from_SYSCALL_64+0x0/0x7a
>
> Freed by task 1:
>  save_stack_trace+0x1b/0x20
>  save_stack+0x46/0xd0
>  kasan_slab_free+0x72/0xc0
>  kmem_cache_free+0xa8/0x300
>  putname+0x80/0x90
>  do_sys_open+0x22f/0x2b0
>  SyS_open+0x1e/0x20
>  do_syscall_64+0xea/0x260
>  return_from_SYSCALL_64+0x0/0x7a
>
> The buggy address belongs to the object at 8804508aeac0\x0a which belongs 
> to the cache names_cache of size 4096
> The buggy address is located 2664 bytes inside of\x0a 4096-byte region 
> [8804508aeac0, 8804508afac0)
> The buggy address belongs to the page:
> page:ea0011422a00 count:1 mapcount:0 mapping:  (null) index:0x0
> [CONT START]  compound_mapcount: 0
> flags: 0x80008100(slab|head)
> raw: 80008100   000100070007
> raw: ea00113d6020 ea001136e220 8804664f8040 
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
>  8804508af400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8804508af480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>8804508af500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>   ^
>  8804508af580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>  8804508af600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==
>


Re: [PATCH v7 08/15] RISC-V: Atomic and Locking Code

2017-07-31 Thread Boqun Feng
On Mon, Jul 31, 2017 at 06:00:02PM -0700, Palmer Dabbelt wrote:
> This contains all the code that directly interfaces with the RISC-V
> memory model.  While this code corforms to the current RISC-V ISA
> specifications (user 2.2 and priv 1.10), the memory model is somewhat
> underspecified in those documents.  There is a working group that hopes
> to produce a formal memory model by the end of the year, but my
> understanding is that the basic definitions we're relying on here won't
> change significantly.
> 
> Signed-off-by: Palmer Dabbelt 
> ---
>  arch/riscv/include/asm/atomic.h | 328 
> 
>  arch/riscv/include/asm/barrier.h|  68 +++
>  arch/riscv/include/asm/bitops.h | 218 +
>  arch/riscv/include/asm/cacheflush.h |  39 
>  arch/riscv/include/asm/cmpxchg.h| 134 +
>  arch/riscv/include/asm/io.h | 303 +
>  arch/riscv/include/asm/spinlock.h   | 165 
>  arch/riscv/include/asm/spinlock_types.h |  33 
>  arch/riscv/include/asm/tlb.h|  24 +++
>  arch/riscv/include/asm/tlbflush.h   |  64 +++
>  10 files changed, 1376 insertions(+)
>  create mode 100644 arch/riscv/include/asm/atomic.h
>  create mode 100644 arch/riscv/include/asm/barrier.h
>  create mode 100644 arch/riscv/include/asm/bitops.h
>  create mode 100644 arch/riscv/include/asm/cacheflush.h
>  create mode 100644 arch/riscv/include/asm/cmpxchg.h
>  create mode 100644 arch/riscv/include/asm/io.h
>  create mode 100644 arch/riscv/include/asm/spinlock.h
>  create mode 100644 arch/riscv/include/asm/spinlock_types.h
>  create mode 100644 arch/riscv/include/asm/tlb.h
>  create mode 100644 arch/riscv/include/asm/tlbflush.h
> 
> diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
> new file mode 100644
> index ..ee3ab06e492b
> --- /dev/null
> +++ b/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,328 @@
> +/*
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2017 SiFive
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#ifndef _ASM_RISCV_ATOMIC_H
> +#define _ASM_RISCV_ATOMIC_H
> +
> +#ifdef CONFIG_GENERIC_ATOMIC64
> +# include 
> +#else
> +# if (__riscv_xlen < 64)
> +#  error "64-bit atomics require XLEN to be at least 64"
> +# endif
> +#endif
> +
> +#include 
> +#include 
> +
> +#define ATOMIC_INIT(i)   { (i) }
> +static __always_inline int atomic_read(const atomic_t *v)
> +{
> + return READ_ONCE(v->counter);
> +}
> +static __always_inline void atomic_set(atomic_t *v, int i)
> +{
> + WRITE_ONCE(v->counter, i);
> +}
> +
> +#ifndef CONFIG_GENERIC_ATOMIC64
> +#define ATOMIC64_INIT(i) { (i) }
> +static __always_inline int atomic64_read(const atomic64_t *v)
 ^

should be "long long"?

> +{
> + return READ_ONCE(v->counter);
> +}
> +static __always_inline void atomic64_set(atomic64_t *v, int i)
  ^
Ditto.

Have you ever run the selftest with CONFIG_ATOMIC64_SELFTEST=y?

Regards,
Boqun

> +{
> + WRITE_ONCE(v->counter, i);
> +}
> +#endif
> +
[...]


signature.asc
Description: PGP signature


Re: [PATCH v7 08/15] RISC-V: Atomic and Locking Code

2017-07-31 Thread Boqun Feng
On Mon, Jul 31, 2017 at 06:00:02PM -0700, Palmer Dabbelt wrote:
> This contains all the code that directly interfaces with the RISC-V
> memory model.  While this code corforms to the current RISC-V ISA
> specifications (user 2.2 and priv 1.10), the memory model is somewhat
> underspecified in those documents.  There is a working group that hopes
> to produce a formal memory model by the end of the year, but my
> understanding is that the basic definitions we're relying on here won't
> change significantly.
> 
> Signed-off-by: Palmer Dabbelt 
> ---
>  arch/riscv/include/asm/atomic.h | 328 
> 
>  arch/riscv/include/asm/barrier.h|  68 +++
>  arch/riscv/include/asm/bitops.h | 218 +
>  arch/riscv/include/asm/cacheflush.h |  39 
>  arch/riscv/include/asm/cmpxchg.h| 134 +
>  arch/riscv/include/asm/io.h | 303 +
>  arch/riscv/include/asm/spinlock.h   | 165 
>  arch/riscv/include/asm/spinlock_types.h |  33 
>  arch/riscv/include/asm/tlb.h|  24 +++
>  arch/riscv/include/asm/tlbflush.h   |  64 +++
>  10 files changed, 1376 insertions(+)
>  create mode 100644 arch/riscv/include/asm/atomic.h
>  create mode 100644 arch/riscv/include/asm/barrier.h
>  create mode 100644 arch/riscv/include/asm/bitops.h
>  create mode 100644 arch/riscv/include/asm/cacheflush.h
>  create mode 100644 arch/riscv/include/asm/cmpxchg.h
>  create mode 100644 arch/riscv/include/asm/io.h
>  create mode 100644 arch/riscv/include/asm/spinlock.h
>  create mode 100644 arch/riscv/include/asm/spinlock_types.h
>  create mode 100644 arch/riscv/include/asm/tlb.h
>  create mode 100644 arch/riscv/include/asm/tlbflush.h
> 
> diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
> new file mode 100644
> index ..ee3ab06e492b
> --- /dev/null
> +++ b/arch/riscv/include/asm/atomic.h
> @@ -0,0 +1,328 @@
> +/*
> + * Copyright (C) 2007 Red Hat, Inc. All Rights Reserved.
> + * Copyright (C) 2012 Regents of the University of California
> + * Copyright (C) 2017 SiFive
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public Licence
> + * as published by the Free Software Foundation; either version
> + * 2 of the Licence, or (at your option) any later version.
> + */
> +
> +#ifndef _ASM_RISCV_ATOMIC_H
> +#define _ASM_RISCV_ATOMIC_H
> +
> +#ifdef CONFIG_GENERIC_ATOMIC64
> +# include 
> +#else
> +# if (__riscv_xlen < 64)
> +#  error "64-bit atomics require XLEN to be at least 64"
> +# endif
> +#endif
> +
> +#include 
> +#include 
> +
> +#define ATOMIC_INIT(i)   { (i) }
> +static __always_inline int atomic_read(const atomic_t *v)
> +{
> + return READ_ONCE(v->counter);
> +}
> +static __always_inline void atomic_set(atomic_t *v, int i)
> +{
> + WRITE_ONCE(v->counter, i);
> +}
> +
> +#ifndef CONFIG_GENERIC_ATOMIC64
> +#define ATOMIC64_INIT(i) { (i) }
> +static __always_inline int atomic64_read(const atomic64_t *v)
 ^

should be "long long"?

> +{
> + return READ_ONCE(v->counter);
> +}
> +static __always_inline void atomic64_set(atomic64_t *v, int i)
  ^
Ditto.

Have you ever run the selftest with CONFIG_ATOMIC64_SELFTEST=y?

Regards,
Boqun

> +{
> + WRITE_ONCE(v->counter, i);
> +}
> +#endif
> +
[...]


signature.asc
Description: PGP signature


Re: [PATCH v2] Bluetooth: btusb: add ID for LiteOn 04ca:3016

2017-07-31 Thread Johan Hedberg
Hi Brian,

On Mon, Jul 31, 2017, Brian Norris wrote:
> Contains a QCA6174A-5 chipset, with USB BT. Let's support loading
> firmware on it.
> 
> From usb-devices:
> T:  Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
> D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=04ca ProdID=3016 Rev=00.01
> C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 
> Signed-off-by: Brian Norris 
> ---
> v2:
>  * include usb-devices info in commit message
> 
>  drivers/bluetooth/btusb.c | 1 +
>  1 file changed, 1 insertion(+)

Applied to bluetooth-next. Thanks.

Johan


Re: [PATCH v2] Bluetooth: btusb: add ID for LiteOn 04ca:3016

2017-07-31 Thread Johan Hedberg
Hi Brian,

On Mon, Jul 31, 2017, Brian Norris wrote:
> Contains a QCA6174A-5 chipset, with USB BT. Let's support loading
> firmware on it.
> 
> From usb-devices:
> T:  Bus=02 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
> D:  Ver= 2.01 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=04ca ProdID=3016 Rev=00.01
> C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> 
> Signed-off-by: Brian Norris 
> ---
> v2:
>  * include usb-devices info in commit message
> 
>  drivers/bluetooth/btusb.c | 1 +
>  1 file changed, 1 insertion(+)

Applied to bluetooth-next. Thanks.

Johan


linux-next: build failure after merge of the akpm-current tree

2017-07-31 Thread Stephen Rothwell
Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kernel/rtas.c: In function 'rtas_online_cpus_mask':
arch/powerpc/kernel/rtas.c:917:37: error: 'GFP_KENREL' undeclared (first use in 
this function)
   if (!alloc_cpumask_var(_mask, GFP_KENREL))
 ^

Caused by commit

  404170cf1c4c ("mm: treewide: remove GFP_TEMPORARY allocation flag")

I added the following patch:

From: Stephen Rothwell 
Date: Tue, 1 Aug 2017 15:25:33 +1000
Subject: [PATCH] mm: treewide: remove GFP_TEMPORARY allocation flag fix

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/kernel/rtas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 90d27dcd0da8..1643e9e53655 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -914,7 +914,7 @@ int rtas_online_cpus_mask(cpumask_var_t cpus)
if (ret) {
cpumask_var_t tmp_mask;
 
-   if (!alloc_cpumask_var(_mask, GFP_KENREL))
+   if (!alloc_cpumask_var(_mask, GFP_KERNEL))
return ret;
 
/* Use tmp_mask to preserve cpus mask from first failure */
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell


linux-next: build failure after merge of the akpm-current tree

2017-07-31 Thread Stephen Rothwell
Hi Andrew,

After merging the akpm-current tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:

arch/powerpc/kernel/rtas.c: In function 'rtas_online_cpus_mask':
arch/powerpc/kernel/rtas.c:917:37: error: 'GFP_KENREL' undeclared (first use in 
this function)
   if (!alloc_cpumask_var(_mask, GFP_KENREL))
 ^

Caused by commit

  404170cf1c4c ("mm: treewide: remove GFP_TEMPORARY allocation flag")

I added the following patch:

From: Stephen Rothwell 
Date: Tue, 1 Aug 2017 15:25:33 +1000
Subject: [PATCH] mm: treewide: remove GFP_TEMPORARY allocation flag fix

Signed-off-by: Stephen Rothwell 
---
 arch/powerpc/kernel/rtas.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/rtas.c b/arch/powerpc/kernel/rtas.c
index 90d27dcd0da8..1643e9e53655 100644
--- a/arch/powerpc/kernel/rtas.c
+++ b/arch/powerpc/kernel/rtas.c
@@ -914,7 +914,7 @@ int rtas_online_cpus_mask(cpumask_var_t cpus)
if (ret) {
cpumask_var_t tmp_mask;
 
-   if (!alloc_cpumask_var(_mask, GFP_KENREL))
+   if (!alloc_cpumask_var(_mask, GFP_KERNEL))
return ret;
 
/* Use tmp_mask to preserve cpus mask from first failure */
-- 
2.13.2

-- 
Cheers,
Stephen Rothwell


RE: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]

2017-07-31 Thread Usyskin, Alexander
Hi

We using pci_dev_run_wake that changed in mentioned patch to decide
if to replace usual PM callbacks with domain ones.
IIRC, the mei device is not remote wakeable on that platform,
so we should set domain callbacks.
There was a patch in PM framework that squashes runtime suspend with
usual suspend for some devices.
May it be that now pci_dev_run_wake returns true form mei and we are
not setting domain callbacks?
In that case we going through PCI device level PM path and may trigger that 
squash.
That will explain lack of mei logs on suspend.

Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))"
at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks by force
to see if this is indeed the case?

--
Alexander (Sasha) Usyskin

ISDC TEE CoE – HECI et alii
Intel Corporation

-Original Message-
From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. 
Wysocki
Sent: Tuesday, August 01, 2017 03:05
To: Rafael J. Wysocki 
Cc: Dominik Brodowski ; Winkler, Tomas 
; Wysocki, Rafael J ; Mika 
Westerberg ; Bjorn Helgaas 
; Usyskin, Alexander ; 
linux-kernel@vger.kernel.org; Linux PM ; ACPI Devel 
Maling List 
Subject: Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from 
struct dev_pm_info [Was: MEI-related WARN_ON() triggered during 
resume-from-sleep on v4.13-rc2+]

On Tue, Aug 1, 2017 at 1:55 AM, Rafael J. Wysocki  wrote:
> Hi,
>
> On Tue, Aug 1, 2017 at 12:16 AM, Dominik Brodowski 
>  wrote:
>> Rafael, Mika, Bjorn and Tomas,
>>
>> can't explain exactly what causes breakage between MEI and PM first 
>> seen on
>> v4.13-rc2 (ther was a typo in the orignal message), but I was able to 
>> bisect it down to commit
>>
>> [de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8] PM / core: Drop run_wake 
>> flag from struct dev_pm_info
>>
>
> [cut]
>
>>>
>>> > [  192.940537] Restarting tasks ...
>>> > [  192.940610] PGI is not set
>>> > [  192.940619] [ cut here ] [  192.940623] 
>>> > WARNING: CPU: 0
>>> > PID: 1661 at 
>>> > /home/brodo/local/kernel/git/linux/drivers/misc/mei/hw-
>>> > me.c:653 mei_me_pg_exit_sync+0x351/0x360 [  192.940624] Modules 
>>> > linked
>>> > in:
>>> > [  192.940627] CPU: 0 PID: 1661 Comm: kworker/0:3 Not tainted 
>>> > 4.13.0-rc2+
>>> > #2 [  192.940628] Hardware name: Dell Inc. XPS 13 9343/0TM99H, 
>>> > BIOS A11
>>> > 12/08/2016 [  192.940630] Workqueue: pm pm_runtime_work  [ 
>>> > 192.940642] Call Trace:
>>> > [  192.940646]  ? pci_pme_active+0x1de/0x1f0 [  192.940649]  ?
>>> > pci_restore_standard_config+0x50/0x50
>>> > [  192.940651]  ? kfree+0x172/0x190 [  192.940653]  ? 
>>> > kfree+0x172/0x190 [  192.940655]  ? 
>>> > pci_restore_standard_config+0x50/0x50
>>> > [  192.940663]  mei_me_pm_runtime_resume+0x3f/0xc0
>>> > [  192.940665]  pci_pm_runtime_resume+0x7a/0xa0 [  192.940667]
>>> > __rpm_callback+0xb9/0x1e0 [  192.940668]  ?
>>> > preempt_count_add+0x6d/0xc0 [  192.940670]  rpm_callback+0x24/0x90 
>>> > [ 192.940672]  ? pci_restore_standard_config+0x50/0x50
>>> > [  192.940674]  rpm_resume+0x4e8/0x800 [  192.940676]  
>>> > pm_runtime_work+0x55/0xb0 [  192.940678]
>>> > process_one_work+0x184/0x3e0 [  192.940680]  
>>> > worker_thread+0x4d/0x3a0 [ 192.940681]  ? 
>>> > preempt_count_sub+0x9b/0x100 [  192.940683]
>>> > kthread+0x122/0x140 [  192.940684]  ? process_one_work+0x3e0/0x3e0 
>>> > kthread+[
>>> > 192.940685]  ? __kthread_create_on_node+0x1a0/0x1a0
>>> > [  192.940688]  ret_from_fork+0x27/0x40 [  192.940690] Code: 96 3a 
>>> > 9e ff 48 8b 7d 98 e8 cd 21 58 00 83 bb bc 01 00 00
>>> > 04 0f 85 40 fe ff ff e9 41 fe ff ff 48 c7 c7 5f 04 99 96 e8 93 6b 
>>> > 9f ff <0f> ff e9 5d fd ff ff e8 33 fe 99 ff 0f 1f 00 0f 1f 44 00 
>>> > 00 55 [  192.940719] ---[ end trace
>>> > a86955597774ead8 ]--- [  192.942540] done.
>>> >
>>> > This doesn't / didn't happen on v4.12.
>>
>>
>> By using the dynamic_debug infrastructure, I was able to obtain a few 
>> more data points:
>>
>> Running 0847684cfc5f, when suspending the system to ram and resuming 
>> again, I see the following messages:
>
> You have removed some relevant parts of the log, but I think I see 
> what's going on.
>
>> [  614.936773] sd 3:0:0:0: [sda] Stopping disk
>> [  614.956004] mei_me :00:16.0: rpm: me: runtime resume
>
> This is a runtime resume during system suspend.
>
>> [  614.956165] ACPI : EC: event blocked
>> [  614.980164] mei_me :00:16.0: interrupt source 0x0002
>> [  614.980191] mei_me :00:16.0: function called after ISR to 
>> handle the interrupt processing.
>> ...
>> [  615.266896] Suspended for 1.190 seconds
>> ...
>> [  615.455775] sd 3:0:0:0: [sda] Starting 

RE: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from struct dev_pm_info [Was: MEI-related WARN_ON() triggered during resume-from-sleep on v4.13-rc2+]

2017-07-31 Thread Usyskin, Alexander
Hi

We using pci_dev_run_wake that changed in mentioned patch to decide
if to replace usual PM callbacks with domain ones.
IIRC, the mei device is not remote wakeable on that platform,
so we should set domain callbacks.
There was a patch in PM framework that squashes runtime suspend with
usual suspend for some devices.
May it be that now pci_dev_run_wake returns true form mei and we are
not setting domain callbacks?
In that case we going through PCI device level PM path and may trigger that 
squash.
That will explain lack of mei logs on suspend.

Dominik, can you try comment out "if (!pci_dev_run_wake(pdev))"
at drivers/misc/mei/pci-me.c (around line 223) to set domain callbacks by force
to see if this is indeed the case?

--
Alexander (Sasha) Usyskin

ISDC TEE CoE – HECI et alii
Intel Corporation

-Original Message-
From: rjwyso...@gmail.com [mailto:rjwyso...@gmail.com] On Behalf Of Rafael J. 
Wysocki
Sent: Tuesday, August 01, 2017 03:05
To: Rafael J. Wysocki 
Cc: Dominik Brodowski ; Winkler, Tomas 
; Wysocki, Rafael J ; Mika 
Westerberg ; Bjorn Helgaas 
; Usyskin, Alexander ; 
linux-kernel@vger.kernel.org; Linux PM ; ACPI Devel 
Maling List 
Subject: Re: Issue with commit de3ef1eb1cd - PM / core: Drop run_wake flag from 
struct dev_pm_info [Was: MEI-related WARN_ON() triggered during 
resume-from-sleep on v4.13-rc2+]

On Tue, Aug 1, 2017 at 1:55 AM, Rafael J. Wysocki  wrote:
> Hi,
>
> On Tue, Aug 1, 2017 at 12:16 AM, Dominik Brodowski 
>  wrote:
>> Rafael, Mika, Bjorn and Tomas,
>>
>> can't explain exactly what causes breakage between MEI and PM first 
>> seen on
>> v4.13-rc2 (ther was a typo in the orignal message), but I was able to 
>> bisect it down to commit
>>
>> [de3ef1eb1cd0cc3a75f7a3661e10ed827f370ab8] PM / core: Drop run_wake 
>> flag from struct dev_pm_info
>>
>
> [cut]
>
>>>
>>> > [  192.940537] Restarting tasks ...
>>> > [  192.940610] PGI is not set
>>> > [  192.940619] [ cut here ] [  192.940623] 
>>> > WARNING: CPU: 0
>>> > PID: 1661 at 
>>> > /home/brodo/local/kernel/git/linux/drivers/misc/mei/hw-
>>> > me.c:653 mei_me_pg_exit_sync+0x351/0x360 [  192.940624] Modules 
>>> > linked
>>> > in:
>>> > [  192.940627] CPU: 0 PID: 1661 Comm: kworker/0:3 Not tainted 
>>> > 4.13.0-rc2+
>>> > #2 [  192.940628] Hardware name: Dell Inc. XPS 13 9343/0TM99H, 
>>> > BIOS A11
>>> > 12/08/2016 [  192.940630] Workqueue: pm pm_runtime_work  [ 
>>> > 192.940642] Call Trace:
>>> > [  192.940646]  ? pci_pme_active+0x1de/0x1f0 [  192.940649]  ?
>>> > pci_restore_standard_config+0x50/0x50
>>> > [  192.940651]  ? kfree+0x172/0x190 [  192.940653]  ? 
>>> > kfree+0x172/0x190 [  192.940655]  ? 
>>> > pci_restore_standard_config+0x50/0x50
>>> > [  192.940663]  mei_me_pm_runtime_resume+0x3f/0xc0
>>> > [  192.940665]  pci_pm_runtime_resume+0x7a/0xa0 [  192.940667]
>>> > __rpm_callback+0xb9/0x1e0 [  192.940668]  ?
>>> > preempt_count_add+0x6d/0xc0 [  192.940670]  rpm_callback+0x24/0x90 
>>> > [ 192.940672]  ? pci_restore_standard_config+0x50/0x50
>>> > [  192.940674]  rpm_resume+0x4e8/0x800 [  192.940676]  
>>> > pm_runtime_work+0x55/0xb0 [  192.940678]
>>> > process_one_work+0x184/0x3e0 [  192.940680]  
>>> > worker_thread+0x4d/0x3a0 [ 192.940681]  ? 
>>> > preempt_count_sub+0x9b/0x100 [  192.940683]
>>> > kthread+0x122/0x140 [  192.940684]  ? process_one_work+0x3e0/0x3e0 
>>> > kthread+[
>>> > 192.940685]  ? __kthread_create_on_node+0x1a0/0x1a0
>>> > [  192.940688]  ret_from_fork+0x27/0x40 [  192.940690] Code: 96 3a 
>>> > 9e ff 48 8b 7d 98 e8 cd 21 58 00 83 bb bc 01 00 00
>>> > 04 0f 85 40 fe ff ff e9 41 fe ff ff 48 c7 c7 5f 04 99 96 e8 93 6b 
>>> > 9f ff <0f> ff e9 5d fd ff ff e8 33 fe 99 ff 0f 1f 00 0f 1f 44 00 
>>> > 00 55 [  192.940719] ---[ end trace
>>> > a86955597774ead8 ]--- [  192.942540] done.
>>> >
>>> > This doesn't / didn't happen on v4.12.
>>
>>
>> By using the dynamic_debug infrastructure, I was able to obtain a few 
>> more data points:
>>
>> Running 0847684cfc5f, when suspending the system to ram and resuming 
>> again, I see the following messages:
>
> You have removed some relevant parts of the log, but I think I see 
> what's going on.
>
>> [  614.936773] sd 3:0:0:0: [sda] Stopping disk
>> [  614.956004] mei_me :00:16.0: rpm: me: runtime resume
>
> This is a runtime resume during system suspend.
>
>> [  614.956165] ACPI : EC: event blocked
>> [  614.980164] mei_me :00:16.0: interrupt source 0x0002
>> [  614.980191] mei_me :00:16.0: function called after ISR to 
>> handle the interrupt processing.
>> ...
>> [  615.266896] Suspended for 1.190 seconds
>> ...
>> [  615.455775] sd 3:0:0:0: [sda] Starting disk
>> [  615.455855] mei_me :00:16.0: interrupt source 0x0002
>> [  615.455870] mei_me :00:16.0: function called after ISR to 
>> handle the interrupt processing.
>> [  615.455877] mei_me :00:16.0: we need to start the dev.
>>
>> and 

linux-next: build warning after merge of the akpm-current tree

2017-07-31 Thread Stephen Rothwell
Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

fs/proc/task_mmu.c: In function 'show_map_vma':
fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable]
  struct proc_maps_private *priv = m->private;
^

Introduced by commit

  14ccc3193225 ("fs, proc: remove priv argument from is_stack")

-- 
Cheers,
Stephen Rothwell


linux-next: build warning after merge of the akpm-current tree

2017-07-31 Thread Stephen Rothwell
Hi Andrew,

After merging the akpm-current tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

fs/proc/task_mmu.c: In function 'show_map_vma':
fs/proc/task_mmu.c:285:28: warning: unused variable 'priv' [-Wunused-variable]
  struct proc_maps_private *priv = m->private;
^

Introduced by commit

  14ccc3193225 ("fs, proc: remove priv argument from is_stack")

-- 
Cheers,
Stephen Rothwell


Re: "BUG: unable to handle kernel NULL pointer dereference" in swapping shmem

2017-07-31 Thread Naoya Horiguchi
Hello Huang,

On Tue, Aug 01, 2017 at 11:30:41AM +0800, Huang, Ying wrote:
> Hi, Horiguchi san,
> 
> Naoya Horiguchi  writes:
> 
> > Hi,
> >
> > I found the following bug when testing mmotm-2017-07-31-16-56.
> > The triggering testcase just swaps in/out shmem pages.
> > It seems to me related to thp swapping improvement patchset,
> > so let me report this to the relevant people.
> >
> > Thanks,
> > Naoya Horiguchi
> > ---
...
> 
> Thanks for reporting!  Do you test it on a HDD?  I can reproduce this on
> a HDD, the fix patch is as follow, could you try it?

Yes, my test ran on a HDD.
And I confirmed that the suggested patch fixes the panic.
Thank you for your quick work.

- Naoya Horiguchi

> 
> Best Regards,
> Huang, Ying
> 
> ->8-
> From 2487f0230fef59c1ef89792e2af7bcabc02470cf Mon Sep 17 00:00:00 2001
> From: Huang Ying 
> Date: Tue, 1 Aug 2017 11:20:23 +0800
> Subject: [PATCH] mm, THP, swap: Fix swap_page_trans_huge_swapped on HDD
> 
> To fix the following kernel bug,
> 
> [  112.690842] ===> testcase 'mm/shmem_swap' start
> [ 112.788440] Adding 40956k swap on
> /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile.
> Priority:-2 extents:1 across:40956k FS
> [  112.815903] bash (17346): drop_caches: 3
> [  112.975713] BUG: unable to handle kernel NULL pointer dereference at 
> 0007
> [  112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0
> [  112.990202] PGD 805e62067
> [  112.990202] P4D 805e62067
> [  112.993219] PUD 80447b067
> [  112.996236] PMD 0
> [  112.999253]
> [  113.003155] Oops:  [#1] SMP
> [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache
> xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun
> bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter
> intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm
> iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich
> ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac
> lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables
> sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata
> megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log
> dm_mod
> [  113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted 
> 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1
> [  113.089323] Hardware name: NEC Express5800/T110g-E 
> [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014
> [  113.099516] task: a06705de9740 task.stack: ac0947c0c000
> [  113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0
> [  113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246
> [  113.118269] RAX:  RBX:  RCX: 
> 0040
> [  113.126233] RDX: 0001 RSI: 05d6 RDI: 
> a06705674cfc
> [  113.134196] RBP: ac0947c0fb60 R08:  R09: 
> 88ca2180
> [  113.142161] R10: 0230 R11: a066e7a9b451 R12: 
> a06705674c00
> [  113.150123] R13: 05d6 R14: 0400 R15: 
> ac0944001000
> [  113.158088] FS:  7f855b243740() GS:a0672fc0() 
> knlGS:
> [  113.167118] CS:  0010 DS:  ES:  CR0: 80050033
> [  113.173529] CR2: 0007 CR3: 000808de2002 CR4: 
> 001606f0
> [  113.181493] Call Trace:
> [  113.184222]  free_swap_and_cache+0x73/0x1d0
> [  113.19]  shmem_free_swap+0x5e/0x70
> [  113.193072]  shmem_undo_range+0x4bd/0x8b0
> [  113.197547]  shmem_truncate_range+0x14/0x40
> [  113.202211]  shmem_evict_inode+0xba/0x190
> [  113.206686]  evict+0xd3/0x1a0
> [  113.210004]  iput+0x17d/0x1d0
> [  113.213316]  dentry_unlink_inode+0xb9/0xf0
> [  113.217887]  __dentry_kill+0xc7/0x170
> [  113.221994]  dput+0x19c/0x1d0
> [  113.225311]  __fput+0x188/0x210
> [  113.228813]  fput+0xe/0x10
> [  113.232221]  task_work_run+0x86/0xa0
> [  113.236209]  exit_to_usermode_loop+0x6d/0x99
> [  113.240981]  syscall_return_slowpath+0xad/0xd0
> [  113.245961]  entry_SYSCALL_64_fastpath+0xa3/0xa5
> [  113.251127] RIP: 0033:0x7f855a940b17
> [  113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: 
> 001f
> [  113.263562] RAX:  RBX:  RCX: 
> 7f855a940b17
> [  113.271524] RDX:  RSI:  RDI: 
> 00028001
> [  113.279488] RBP: 7fff955b5060 R08:  R09: 
> 
> [  113.287450] R10: 7fff955b4dd0 R11: 0206 R12: 
> 00401da0
> [  113.295414] R13: 7fff955b5350 R14:  R15: 
> 
> [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85
> c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85
> db 74 59  43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01 

Re: "BUG: unable to handle kernel NULL pointer dereference" in swapping shmem

2017-07-31 Thread Naoya Horiguchi
Hello Huang,

On Tue, Aug 01, 2017 at 11:30:41AM +0800, Huang, Ying wrote:
> Hi, Horiguchi san,
> 
> Naoya Horiguchi  writes:
> 
> > Hi,
> >
> > I found the following bug when testing mmotm-2017-07-31-16-56.
> > The triggering testcase just swaps in/out shmem pages.
> > It seems to me related to thp swapping improvement patchset,
> > so let me report this to the relevant people.
> >
> > Thanks,
> > Naoya Horiguchi
> > ---
...
> 
> Thanks for reporting!  Do you test it on a HDD?  I can reproduce this on
> a HDD, the fix patch is as follow, could you try it?

Yes, my test ran on a HDD.
And I confirmed that the suggested patch fixes the panic.
Thank you for your quick work.

- Naoya Horiguchi

> 
> Best Regards,
> Huang, Ying
> 
> ->8-
> From 2487f0230fef59c1ef89792e2af7bcabc02470cf Mon Sep 17 00:00:00 2001
> From: Huang Ying 
> Date: Tue, 1 Aug 2017 11:20:23 +0800
> Subject: [PATCH] mm, THP, swap: Fix swap_page_trans_huge_swapped on HDD
> 
> To fix the following kernel bug,
> 
> [  112.690842] ===> testcase 'mm/shmem_swap' start
> [ 112.788440] Adding 40956k swap on
> /mnt/tests/examples/regression/kernel/mm_regression/mm_regression/work/swapfile.
> Priority:-2 extents:1 across:40956k FS
> [  112.815903] bash (17346): drop_caches: 3
> [  112.975713] BUG: unable to handle kernel NULL pointer dereference at 
> 0007
> [  112.984464] IP: swap_page_trans_huge_swapped+0x49/0xd0
> [  112.990202] PGD 805e62067
> [  112.990202] P4D 805e62067
> [  112.993219] PUD 80447b067
> [  112.996236] PMD 0
> [  112.999253]
> [  113.003155] Oops:  [#1] SMP
> [ 113.006658] Modules linked in: nfsv4 dns_resolver nfs fscache
> xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4
> iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4
> xt_conntrack nf_conntrack libcrc32c ipt_REJECT nf_reject_ipv4 tun
> bridge stp llc ebtable_filter ebtables ip6_tables iptable_filter
> intel_rapl x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm
> iTCO_wdt nfsd iTCO_vendor_support mei_me auth_rpcgss mei lpc_ich
> ipmi_si ipmi_devintf irqbypass nfs_acl shpchp sg mfd_core ie31200_edac
> lockd ipmi_msghandler pcspkr video acpi_pad grace sunrpc ip_tables
> sr_mod sd_mod cdrom tg3 ata_generic pata_acpi ata_piix ptp libata
> megaraid_sas crc32c_intel pps_core dm_mirror dm_region_hash dm_log
> dm_mod
> [  113.077676] CPU: 0 PID: 17431 Comm: test_alloc_gene Not tainted 
> 4.13.0-rc3-mm1-v4.13-rc3-mmotm-2017-07-31-16-56+ #1
> [  113.089323] Hardware name: NEC Express5800/T110g-E 
> [N8100-2187Y]/GA-6LASV1, BIOS 4.6.1204 10/17/2014
> [  113.099516] task: a06705de9740 task.stack: ac0947c0c000
> [  113.106124] RIP: 0010:swap_page_trans_huge_swapped+0x49/0xd0
> [  113.112438] RSP: 0018:ac0947c0fb38 EFLAGS: 00010246
> [  113.118269] RAX:  RBX:  RCX: 
> 0040
> [  113.126233] RDX: 0001 RSI: 05d6 RDI: 
> a06705674cfc
> [  113.134196] RBP: ac0947c0fb60 R08:  R09: 
> 88ca2180
> [  113.142161] R10: 0230 R11: a066e7a9b451 R12: 
> a06705674c00
> [  113.150123] R13: 05d6 R14: 0400 R15: 
> ac0944001000
> [  113.158088] FS:  7f855b243740() GS:a0672fc0() 
> knlGS:
> [  113.167118] CS:  0010 DS:  ES:  CR0: 80050033
> [  113.173529] CR2: 0007 CR3: 000808de2002 CR4: 
> 001606f0
> [  113.181493] Call Trace:
> [  113.184222]  free_swap_and_cache+0x73/0x1d0
> [  113.19]  shmem_free_swap+0x5e/0x70
> [  113.193072]  shmem_undo_range+0x4bd/0x8b0
> [  113.197547]  shmem_truncate_range+0x14/0x40
> [  113.202211]  shmem_evict_inode+0xba/0x190
> [  113.206686]  evict+0xd3/0x1a0
> [  113.210004]  iput+0x17d/0x1d0
> [  113.213316]  dentry_unlink_inode+0xb9/0xf0
> [  113.217887]  __dentry_kill+0xc7/0x170
> [  113.221994]  dput+0x19c/0x1d0
> [  113.225311]  __fput+0x188/0x210
> [  113.228813]  fput+0xe/0x10
> [  113.232221]  task_work_run+0x86/0xa0
> [  113.236209]  exit_to_usermode_loop+0x6d/0x99
> [  113.240981]  syscall_return_slowpath+0xad/0xd0
> [  113.245961]  entry_SYSCALL_64_fastpath+0xa3/0xa5
> [  113.251127] RIP: 0033:0x7f855a940b17
> [  113.255113] RSP: 002b:7fff955b5048 EFLAGS: 0206 ORIG_RAX: 
> 001f
> [  113.263562] RAX:  RBX:  RCX: 
> 7f855a940b17
> [  113.271524] RDX:  RSI:  RDI: 
> 00028001
> [  113.279488] RBP: 7fff955b5060 R08:  R09: 
> 
> [  113.287450] R10: 7fff955b4dd0 R11: 0206 R12: 
> 00401da0
> [  113.295414] R13: 7fff955b5350 R14:  R15: 
> 
> [ 113.303378] Code: f5 41 54 49 89 fc 53 48 8b 47 70 4c 8b 7f 68 48 85
> c0 74 70 4c 89 f3 48 c1 eb 06 48 01 c3 48 89 df e8 fc 10 54 00 48 85
> db 74 59  43 07 04 75 31 48 b8 ff ff ff ff ff ff ff 01 49 21 c5 43
> 80
> [  113.324450] RIP: 

[GIT] Networking

2017-07-31 Thread David Miller

1) Handle notifier registry failures properly in tun/tap driver, from
   Tonghao Zhang.

2) Fix bpf verifier handling of subtraction bounds and add a testcase
   for this, from Edward Cree.

3) Increase reset timeout in ftgmac100 driver, from Ben Herrenschmidt.

4) Fix use after free in prd_retire_rx_blk_timer_exired() in AF_PACKET,
   from Cong Wang.

5) Fix SElinux regression due to recent UDP optimizations, from Paolo
   Abeni.

6) We accidently increment IPSTATS_MIB_FRAGFAILS in the ipv6 code paths,
   fix from Stefano Brivio.

7) Fix some mem leaks in dccp, from Xin Long.

8) Adjust MDIO_BUS kconfig deps to avoid build errors, from Arnd
   Bergmann.

9) Mac address length check and buffer size fixes from Cong Wang.

10) Don't leak sockets in ipv6 udp early demux, from Paolo Abeni.

11) Fix return value when copy_from_user() fails in
bpf_prog_get_info_by_fd(), from Daniel Borkmann.

12) Handle PHY_HALTED properly in phy library state machine, from
Florian Fainelli.

13) Fix OOPS in fib_sync_down_dev(), from Ido Schimmel.

14) Fix truesize calculation in virtio_net which led to performance
regressions, from Michael S. Tsirkin.

Please pull, thanks a lot!

The following changes since commit 96080f697786e0a30006fcbcc5b53f350fcb3e9f:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-20 
16:33:39 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to cc75f8514db6a3aec517760fccaf954e5b46478c:

  samples/bpf: fix bpf tunnel cleanup (2017-07-31 22:02:47 -0700)


Alex Vesker (1):
  net/mlx5e: IPoIB, Modify add/remove underlay QPN flows

Arend Van Spriel (2):
  brcmfmac: fix regression in brcmf_sdio_txpkt_hdalign()
  brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice

Arnd Bergmann (3):
  net: phy: rework Kconfig settings for MDIO_BUS
  phy: bcm-ns-usb3: fix MDIO_BUS dependency
  tcp: avoid bogus gcc-7 array-bounds warning

Aviv Heller (1):
  net/mlx5: Consider tx_enabled in all modes on remap

Benjamin Herrenschmidt (2):
  ftgmac100: Increase reset timeout
  ftgmac100: Make the MDIO bus a child of the ethernet device

Colin Ian King (1):
  net: tc35815: fix spelling mistake: "Intterrupt" -> "Interrupt"

Dan Carpenter (1):
  iwlwifi: missing error code in iwl_trans_pcie_alloc()

Daniel Borkmann (2):
  bpf: don't indicate success when copy_from_user fails
  bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len

Daniel Stone (1):
  brcmfmac: Don't grow SKB by negative size

David S. Miller (4):
  Merge branch 'bpf-fix-verifier-min-max-handling-in-BPF_SUB'
  Merge tag 'wireless-drivers-for-davem-2017-07-21' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge tag 'mlx5-fixes-2017-07-27-V2' of 
git://git.kernel.org/.../saeed/linux
  Merge tag 'wireless-drivers-for-davem-2017-07-28' of 
git://git.kernel.org/.../kvalo/wireless-drivers

Edward Cree (2):
  selftests/bpf: subtraction bounds test
  bpf/verifier: fix min/max handling in BPF_SUB

Emmanuel Grumbach (3):
  iwlwifi: dvm: prevent an out of bounds access
  iwlwifi: mvm: fix a NULL pointer dereference of error in recovery
  iwlwifi: fix tracing when tx only is enabled

Eran Ben Elisha (1):
  net/mlx5: Clean SRIOV eswitch resources upon VF creation failure

Eugenia Emantayev (7):
  net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure size
  net/mlx5e: Add field select to MTPPS register
  net/mlx5e: Fix broken disable 1PPS flow
  net/mlx5e: Change 1PPS out scheme
  net/mlx5e: Add missing support for PTP_CLK_REQ_PPS request
  net/mlx5e: Fix wrong delay calculation for overflow check scheduling
  net/mlx5e: Schedule overflow check work to mlx5e workqueue

Florian Fainelli (4):
  net: dsa: Initialize ds->cpu_port_mask earlier
  net: phy: Correctly process PHY_HALTED in phy_stop_machine()
  MAINTAINERS: Add more files to the PHY LIBRARY section
  Revert "net: bcmgenet: Remove init parameter from bcmgenet_mii_config"

Gao Feng (1):
  ppp: Fix a scheduling-while-atomic bug in del_chan

Ido Schimmel (2):
  mlxsw: spectrum_router: Don't offload routes next in list
  ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev()

Ilan Tayari (1):
  net/mlx5e: Fix outer_header_zero() check size

Jakub Kicinski (1):
  bpf: don't zero out the info struct in bpf_obj_get_info_by_fd()

Jason Wang (1):
  Revert "vhost: cache used event for better performance"

Joel Stanley (1):
  ftgmac100: return error in ftgmac100_alloc_rx_buf

Johannes Berg (1):
  iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART

Kalle Valo (1):
  Merge tag 'iwlwifi-for-kalle-2017-07-21' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Larry Finger (1):
  Revert "rtlwifi: btcoex: rtl8723be: fix ant_sel not 

[GIT] Networking

2017-07-31 Thread David Miller

1) Handle notifier registry failures properly in tun/tap driver, from
   Tonghao Zhang.

2) Fix bpf verifier handling of subtraction bounds and add a testcase
   for this, from Edward Cree.

3) Increase reset timeout in ftgmac100 driver, from Ben Herrenschmidt.

4) Fix use after free in prd_retire_rx_blk_timer_exired() in AF_PACKET,
   from Cong Wang.

5) Fix SElinux regression due to recent UDP optimizations, from Paolo
   Abeni.

6) We accidently increment IPSTATS_MIB_FRAGFAILS in the ipv6 code paths,
   fix from Stefano Brivio.

7) Fix some mem leaks in dccp, from Xin Long.

8) Adjust MDIO_BUS kconfig deps to avoid build errors, from Arnd
   Bergmann.

9) Mac address length check and buffer size fixes from Cong Wang.

10) Don't leak sockets in ipv6 udp early demux, from Paolo Abeni.

11) Fix return value when copy_from_user() fails in
bpf_prog_get_info_by_fd(), from Daniel Borkmann.

12) Handle PHY_HALTED properly in phy library state machine, from
Florian Fainelli.

13) Fix OOPS in fib_sync_down_dev(), from Ido Schimmel.

14) Fix truesize calculation in virtio_net which led to performance
regressions, from Michael S. Tsirkin.

Please pull, thanks a lot!

The following changes since commit 96080f697786e0a30006fcbcc5b53f350fcb3e9f:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-07-20 
16:33:39 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git 

for you to fetch changes up to cc75f8514db6a3aec517760fccaf954e5b46478c:

  samples/bpf: fix bpf tunnel cleanup (2017-07-31 22:02:47 -0700)


Alex Vesker (1):
  net/mlx5e: IPoIB, Modify add/remove underlay QPN flows

Arend Van Spriel (2):
  brcmfmac: fix regression in brcmf_sdio_txpkt_hdalign()
  brcmfmac: fix memleak due to calling brcmf_sdiod_sgtable_alloc() twice

Arnd Bergmann (3):
  net: phy: rework Kconfig settings for MDIO_BUS
  phy: bcm-ns-usb3: fix MDIO_BUS dependency
  tcp: avoid bogus gcc-7 array-bounds warning

Aviv Heller (1):
  net/mlx5: Consider tx_enabled in all modes on remap

Benjamin Herrenschmidt (2):
  ftgmac100: Increase reset timeout
  ftgmac100: Make the MDIO bus a child of the ethernet device

Colin Ian King (1):
  net: tc35815: fix spelling mistake: "Intterrupt" -> "Interrupt"

Dan Carpenter (1):
  iwlwifi: missing error code in iwl_trans_pcie_alloc()

Daniel Borkmann (2):
  bpf: don't indicate success when copy_from_user fails
  bpf: fix bpf_prog_get_info_by_fd to dump correct xlated_prog_len

Daniel Stone (1):
  brcmfmac: Don't grow SKB by negative size

David S. Miller (4):
  Merge branch 'bpf-fix-verifier-min-max-handling-in-BPF_SUB'
  Merge tag 'wireless-drivers-for-davem-2017-07-21' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge tag 'mlx5-fixes-2017-07-27-V2' of 
git://git.kernel.org/.../saeed/linux
  Merge tag 'wireless-drivers-for-davem-2017-07-28' of 
git://git.kernel.org/.../kvalo/wireless-drivers

Edward Cree (2):
  selftests/bpf: subtraction bounds test
  bpf/verifier: fix min/max handling in BPF_SUB

Emmanuel Grumbach (3):
  iwlwifi: dvm: prevent an out of bounds access
  iwlwifi: mvm: fix a NULL pointer dereference of error in recovery
  iwlwifi: fix tracing when tx only is enabled

Eran Ben Elisha (1):
  net/mlx5: Clean SRIOV eswitch resources upon VF creation failure

Eugenia Emantayev (7):
  net/mlx5: Fix mlx5_ifc_mtpps_reg_bits structure size
  net/mlx5e: Add field select to MTPPS register
  net/mlx5e: Fix broken disable 1PPS flow
  net/mlx5e: Change 1PPS out scheme
  net/mlx5e: Add missing support for PTP_CLK_REQ_PPS request
  net/mlx5e: Fix wrong delay calculation for overflow check scheduling
  net/mlx5e: Schedule overflow check work to mlx5e workqueue

Florian Fainelli (4):
  net: dsa: Initialize ds->cpu_port_mask earlier
  net: phy: Correctly process PHY_HALTED in phy_stop_machine()
  MAINTAINERS: Add more files to the PHY LIBRARY section
  Revert "net: bcmgenet: Remove init parameter from bcmgenet_mii_config"

Gao Feng (1):
  ppp: Fix a scheduling-while-atomic bug in del_chan

Ido Schimmel (2):
  mlxsw: spectrum_router: Don't offload routes next in list
  ipv4: fib: Fix NULL pointer deref during fib_sync_down_dev()

Ilan Tayari (1):
  net/mlx5e: Fix outer_header_zero() check size

Jakub Kicinski (1):
  bpf: don't zero out the info struct in bpf_obj_get_info_by_fd()

Jason Wang (1):
  Revert "vhost: cache used event for better performance"

Joel Stanley (1):
  ftgmac100: return error in ftgmac100_alloc_rx_buf

Johannes Berg (1):
  iwlwifi: mvm: defer setting IWL_MVM_STATUS_IN_HW_RESTART

Kalle Valo (1):
  Merge tag 'iwlwifi-for-kalle-2017-07-21' of 
git://git.kernel.org/.../iwlwifi/iwlwifi-fixes

Larry Finger (1):
  Revert "rtlwifi: btcoex: rtl8723be: fix ant_sel not 

Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec

2017-07-31 Thread Linus Torvalds
On Mon, Jul 31, 2017 at 10:11 PM, Linus Torvalds
 wrote:
>
> And I just checked this on a separate branch, just because I wanted to
> see what the overall diff was. There's a conflict [..]

Side note: the overall patch looks fine to me. I like how it removes
complexity and code. I didn't test it (other than test *building* the
merge), so take that for what it's worth, but at least the patches
look sensible both on an individual level and as an end result.

   Linus


Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec

2017-07-31 Thread Linus Torvalds
On Mon, Jul 31, 2017 at 10:11 PM, Linus Torvalds
 wrote:
>
> And I just checked this on a separate branch, just because I wanted to
> see what the overall diff was. There's a conflict [..]

Side note: the overall patch looks fine to me. I like how it removes
complexity and code. I didn't test it (other than test *building* the
merge), so take that for what it's worth, but at least the patches
look sensible both on an individual level and as an end result.

   Linus


Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec

2017-07-31 Thread Linus Torvalds
On Mon, Jul 31, 2017 at 8:03 PM, Kees Cook  wrote:
>
> Yeah, I'm open to whatever. It's not clear where it should go, but if
> you want to take it and Linus doesn't want it "early", that works for
> me. Linus, Andrew, thoughts?

I'd actually like this to go in separately from all the other security stuff.

And I just checked this on a separate branch, just because I wanted to
see what the overall diff was. There's a conflict with apparmor
already - the resolution looks fairly straightforward, but considering
the area this touches, it would probably be good that Kees keeps this
branch and verifies things like that.

Linus


[PATCH] staging/pi433: Solved some coding style issues in pi433_if.c

2017-07-31 Thread Rishabh Hardas
From: Rishabh Hardas 

Solved a few coding style issues, used BIT macro to set MINORBITS.

Signed-off-by: Rishabh Hardas 
---
 drivers/staging/pi433/pi433_if.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index d9328ce..f10ffc3 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -47,18 +47,18 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_COMPAT
-#include 
+#include 
 #endif

 #include "pi433_if.h"
 #include "rf69.h"

-
-#define N_PI433_MINORS (1U << MINORBITS) /*32*//* ... 
up to 256 */
-#define MAX_MSG_SIZE   900 /* min: FIFO_SIZE! */
-#define MSG_FIFO_SIZE  65536   /* 65536 = 2^16  */
-#define NUM_DIO2
+#define N_PI433_MINORS BIT(MINORBITS) /*32*/ /* ... up to 256 */
+#define MAX_MSG_SIZE   900 /* min: FIFO_SIZE! */
+#define MSG_FIFO_SIZE  65536   /* 65536 = 2^16  */
+#define NUM_DIO2

 static dev_t pi433_dev;
 static DEFINE_IDR(pi433_idr);
@@ -66,10 +66,14 @@

 static struct class *pi433_class; /* mainly for udev to create /dev/pi433 */

-/* tx config is instance specific
-   so with each open a new tx config struct is needed */
-/* rx config is device specific
-   so we have just one rx config, ebedded in device struct */
+/*
+ * tx config is instance specific
+ * so with each open a new tx config struct is needed
+ */
+/*
+ * rx config is device specific
+ * so we have just one rx config, ebedded in device struct
+ */
 struct pi433_device {
/* device handling related values */
dev_t   devt;
--
1.9.1


Re: [PATCH v4 00/15] exec: Use sane stack rlimit under secureexec

2017-07-31 Thread Linus Torvalds
On Mon, Jul 31, 2017 at 8:03 PM, Kees Cook  wrote:
>
> Yeah, I'm open to whatever. It's not clear where it should go, but if
> you want to take it and Linus doesn't want it "early", that works for
> me. Linus, Andrew, thoughts?

I'd actually like this to go in separately from all the other security stuff.

And I just checked this on a separate branch, just because I wanted to
see what the overall diff was. There's a conflict with apparmor
already - the resolution looks fairly straightforward, but considering
the area this touches, it would probably be good that Kees keeps this
branch and verifies things like that.

Linus


[PATCH] staging/pi433: Solved some coding style issues in pi433_if.c

2017-07-31 Thread Rishabh Hardas
From: Rishabh Hardas 

Solved a few coding style issues, used BIT macro to set MINORBITS.

Signed-off-by: Rishabh Hardas 
---
 drivers/staging/pi433/pi433_if.c | 24 ++--
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/pi433/pi433_if.c b/drivers/staging/pi433/pi433_if.c
index d9328ce..f10ffc3 100644
--- a/drivers/staging/pi433/pi433_if.c
+++ b/drivers/staging/pi433/pi433_if.c
@@ -47,18 +47,18 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef CONFIG_COMPAT
-#include 
+#include 
 #endif

 #include "pi433_if.h"
 #include "rf69.h"

-
-#define N_PI433_MINORS (1U << MINORBITS) /*32*//* ... 
up to 256 */
-#define MAX_MSG_SIZE   900 /* min: FIFO_SIZE! */
-#define MSG_FIFO_SIZE  65536   /* 65536 = 2^16  */
-#define NUM_DIO2
+#define N_PI433_MINORS BIT(MINORBITS) /*32*/ /* ... up to 256 */
+#define MAX_MSG_SIZE   900 /* min: FIFO_SIZE! */
+#define MSG_FIFO_SIZE  65536   /* 65536 = 2^16  */
+#define NUM_DIO2

 static dev_t pi433_dev;
 static DEFINE_IDR(pi433_idr);
@@ -66,10 +66,14 @@

 static struct class *pi433_class; /* mainly for udev to create /dev/pi433 */

-/* tx config is instance specific
-   so with each open a new tx config struct is needed */
-/* rx config is device specific
-   so we have just one rx config, ebedded in device struct */
+/*
+ * tx config is instance specific
+ * so with each open a new tx config struct is needed
+ */
+/*
+ * rx config is device specific
+ * so we have just one rx config, ebedded in device struct
+ */
 struct pi433_device {
/* device handling related values */
dev_t   devt;
--
1.9.1


Re: [PATCH v2] Coccinelle: Script to remove unnecessary static on local variables

2017-07-31 Thread Julia Lawall
Acked-by: Julia Lawall 

On Mon, 31 Jul 2017, Gustavo A. R. Silva wrote:

> Coccinelle script to remove unnecessary static on local variables when
> the variables are not used before update.
>
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  Update header and Copyright note.
>
>  scripts/coccinelle/misc/static_unnecessary.cocci | 96 
> 
>  1 file changed, 96 insertions(+)
>  create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci
>
> diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci 
> b/scripts/coccinelle/misc/static_unnecessary.cocci
> new file mode 100644
> index 000..2b10586
> --- /dev/null
> +++ b/scripts/coccinelle/misc/static_unnecessary.cocci
> @@ -0,0 +1,96 @@
> +/// Drop static on local variable when the variable is not used before 
> update.
> +//#
> +//# Removing unnecessary static on local variables reduces the code
> +//# size and increases maintainability.
> +//#
> +//# On the other hand, even though it is rare, be aware that if a
> +//# large object is initialized all at once, it might not be wise
> +//# to remove the static because that would increase the risk of a
> +//# stack overflow.
> +///
> +// Confidence: Moderate
> +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
> +// URL: http://coccinelle.lip6.fr/
> +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2.
> +// Work supported by a grant from
> +// The Linux Foundation's Core Infrastructure Initiative.
> +// URL: https://www.coreinfrastructure.org/
> +// Options: --no-includes --include-headers
> +// Keywords: static
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +// 
> +@bad exists@
> +position p;
> +identifier x;
> +expression e;
> +type T;
> +@@
> +
> +T x@p;
> +... when != x = e
> +x = <+...x...+>
> +
> +@worse exists@
> +position p;
> +identifier x;
> +type T;
> +@@
> +
> +T x@p;
> +...
> + 
> +
> +@modify depends on patch && !context && !org && !report@
> +identifier x;
> +expression e;
> +type T;
> +position p != {bad.p,worse.p};
> +@@
> +
> +-static
> + T x@p;
> + ... when != x
> + when strict
> +?x = e;
> +// 
> +
> +
> +// 
> 
> +
> +@modify_context depends on !patch && (context || org || report) forall@
> +type T;
> +identifier x;
> +expression e;
> +position p != {bad.p,worse.p};
> +position j0;
> +@@
> +
> +* static
> + T x@j0@p;
> + ... when != x
> + when strict
> +?x = e;
> +
> +// 
> 
> +
> +@script:python modify_org depends on org@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.org.print_todo(j0[0], msg)
> +
> +// 
> 
> +
> +@script:python modify_report depends on report@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.report.print_report(j0[0], msg)
> +
> --
> 2.5.0
>
>


Re: [PATCH v2] Coccinelle: Script to remove unnecessary static on local variables

2017-07-31 Thread Julia Lawall
Acked-by: Julia Lawall 

On Mon, 31 Jul 2017, Gustavo A. R. Silva wrote:

> Coccinelle script to remove unnecessary static on local variables when
> the variables are not used before update.
>
> Signed-off-by: Gustavo A. R. Silva 
> ---
> Changes in v2:
>  Update header and Copyright note.
>
>  scripts/coccinelle/misc/static_unnecessary.cocci | 96 
> 
>  1 file changed, 96 insertions(+)
>  create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci
>
> diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci 
> b/scripts/coccinelle/misc/static_unnecessary.cocci
> new file mode 100644
> index 000..2b10586
> --- /dev/null
> +++ b/scripts/coccinelle/misc/static_unnecessary.cocci
> @@ -0,0 +1,96 @@
> +/// Drop static on local variable when the variable is not used before 
> update.
> +//#
> +//# Removing unnecessary static on local variables reduces the code
> +//# size and increases maintainability.
> +//#
> +//# On the other hand, even though it is rare, be aware that if a
> +//# large object is initialized all at once, it might not be wise
> +//# to remove the static because that would increase the risk of a
> +//# stack overflow.
> +///
> +// Confidence: Moderate
> +// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
> +// URL: http://coccinelle.lip6.fr/
> +// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2.
> +// Work supported by a grant from
> +// The Linux Foundation's Core Infrastructure Initiative.
> +// URL: https://www.coreinfrastructure.org/
> +// Options: --no-includes --include-headers
> +// Keywords: static
> +
> +virtual patch
> +virtual context
> +virtual org
> +virtual report
> +
> +// 
> +@bad exists@
> +position p;
> +identifier x;
> +expression e;
> +type T;
> +@@
> +
> +T x@p;
> +... when != x = e
> +x = <+...x...+>
> +
> +@worse exists@
> +position p;
> +identifier x;
> +type T;
> +@@
> +
> +T x@p;
> +...
> + 
> +
> +@modify depends on patch && !context && !org && !report@
> +identifier x;
> +expression e;
> +type T;
> +position p != {bad.p,worse.p};
> +@@
> +
> +-static
> + T x@p;
> + ... when != x
> + when strict
> +?x = e;
> +// 
> +
> +
> +// 
> 
> +
> +@modify_context depends on !patch && (context || org || report) forall@
> +type T;
> +identifier x;
> +expression e;
> +position p != {bad.p,worse.p};
> +position j0;
> +@@
> +
> +* static
> + T x@j0@p;
> + ... when != x
> + when strict
> +?x = e;
> +
> +// 
> 
> +
> +@script:python modify_org depends on org@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.org.print_todo(j0[0], msg)
> +
> +// 
> 
> +
> +@script:python modify_report depends on report@
> +j0 << modify_context.j0;
> +@@
> +
> +msg = "Unnecessary static on local variable."
> +coccilib.report.print_report(j0[0], msg)
> +
> --
> 2.5.0
>
>


[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event

2017-07-31 Thread Keith Packard
Here's an updated series for the proposed new IOCTLs. Major changes
since last time:

 * Leave driver API with 32-bit vblank counts
 * Use ktime_t instead of struct timespec.
 * Check for MODESETTING before using modesetting APIs
 * Ensure vblank is running in new get_sequence ioctl

There are other minor changes noted in each patch.

Thanks to helpful review from:

Daniel Vetter 
Michel Dänzer 
Ville Syrjälä 

-keith



[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-07-31 Thread Keith Packard
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.

v2:

 * Check for DRIVER_MODESET in new crtc-based vblank ioctls

Failing to check this will oops the driver.

 * Ensure vblank interupt is running in crtc_get_sequence ioctl

The sequence and timing values are not correct while the
interrupt is off, so make sure it's running before asking for
them.

 * Short-circuit get_sequence if the counter is enabled and accurate

Steal the idea from the code in wait_vblank to avoid the
expense of drm_vblank_get/put

 * Return active state of crtc in crtc_get_sequence ioctl

Might be useful for applications that aren't in charge of
modesetting?

 * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls

Daniel Vetter prefers these over the old drm_vblank_put/get
APIs.

 * Return s64 ns instead of u64 in new sequence event

Suggested-by:  Daniel Vetter 
Suggested-by: Ville Syrjälä 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_internal.h |   6 ++
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_vblank.c   | 173 +
 include/drm/drm_vblank.h   |   1 +
 include/uapi/drm/drm.h |  32 
 5 files changed, 214 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5cecc974d2f9..b68a193b7907 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void 
*data,
 int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
+
+int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
 /* drm_auth.c */
 int drm_getmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e568176da9..63016cf3e224 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7e7119a5ada3..69b8c92cdd3a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -812,6 +812,11 @@ static void send_vblank_event(struct drm_device *dev,
e->event.vbl.tv_sec = tv.tv_sec;
e->event.vbl.tv_usec = tv.tv_usec;
break;
+   case DRM_EVENT_CRTC_SEQUENCE:
+   if (seq)
+   e->event.seq.sequence = seq;
+   e->event.seq.time_ns = ktime_to_ns(now);
+   break;
}
trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
@@ -1682,3 +1687,171 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
 }
 EXPORT_SYMBOL(drm_crtc_handle_vblank);
+
+/*
+ * Get crtc VBLANK count.
+ *
+ * \param dev DRM device
+ * \param data user arguement, pointing to a drm_crtc_get_sequence structure.
+ * \param file_priv drm file private for the user's open file descriptor
+ */
+
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_crtc *crtc;
+   struct drm_vblank_crtc *vblank;
+   int pipe;
+   struct drm_crtc_get_sequence *get_seq = data;
+   ktime_t now;
+   bool vblank_enabled;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   crtc = drm_crtc_find(dev, get_seq->crtc_id);
+   if (!crtc)
+   return -ENOENT;
+
+   pipe = drm_crtc_index(crtc);
+
+   vblank = >vblank[pipe];
+   vblank_enabled = dev->vblank_disable_immediate && 
READ_ONCE(vblank->enabled);
+
+   if (!vblank_enabled) {
+   ret = drm_crtc_vblank_get(crtc);
+   if (ret) {
+   DRM_DEBUG("crtc %d failed to 

[PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2]

2017-07-31 Thread Keith Packard
This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and switch to using ktime_t for timestamps to
increase resolution from microseconds to nanoseconds.

The driver interfaces have been left using 32 bits of vblank count;
all of the code necessary to widen that value for the user API was
already included to handle devices returning fewer than 32-bits.

This will provide the necessary datatypes for the Vulkan API.

v2:

 * Re-write wait_vblank ioctl to ABSOLUTE sequence

When an application uses the WAIT_VBLANK ioctl with RELATIVE
or NEXTONMISS bits set, the target vblank interval is updated
within the kernel. We need to write that target back to the
ioctl buffer and update the flags bits so that if the wait is
interrupted by a signal, when it is re-started, it will target
precisely the same vblank count as before.

 * Leave driver API with 32-bit vblank count

Suggested-by:  Michel Dänzer 
Suggested-by: Daniel Vetter 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_vblank.c | 186 +--
 include/drm/drmP.h   |   2 +-
 include/drm/drm_drv.h|   2 +-
 include/drm/drm_vblank.h |  16 ++--
 4 files changed, 120 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 463e4d81fb0d..346601ad698d 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -43,7 +43,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, bool in_vblank_irq);
+ ktime_t *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -64,7 +64,7 @@ MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic 
timestamps");
 
 static void store_vblank(struct drm_device *dev, unsigned int pipe,
 u32 vblank_count_inc,
-struct timeval *t_vblank, u32 last)
+ktime_t t_vblank, u32 last)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
@@ -73,7 +73,7 @@ static void store_vblank(struct drm_device *dev, unsigned int 
pipe,
vblank->last = last;
 
write_seqlock(>seqlock);
-   vblank->time = *t_vblank;
+   vblank->time = t_vblank;
vblank->count += vblank_count_inc;
write_sequnlock(>seqlock);
 }
@@ -116,7 +116,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 {
u32 cur_vblank;
bool rc;
-   struct timeval t_vblank;
+   ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
 
spin_lock(>vblank_time_lock);
@@ -136,13 +136,13 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 * interrupt and assign 0 for now, to mark the vblanktimestamp as 
invalid.
 */
if (!rc)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
/*
 * +1 to make sure user will never see the same
 * vblank counter value before and after a modeset
 */
-   store_vblank(dev, pipe, 1, _vblank, cur_vblank);
+   store_vblank(dev, pipe, 1, t_vblank, cur_vblank);
 
spin_unlock(>vblank_time_lock);
 }
@@ -165,7 +165,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
struct drm_vblank_crtc *vblank = >vblank[pipe];
u32 cur_vblank, diff;
bool rc;
-   struct timeval t_vblank;
+   ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
int framedur_ns = vblank->framedur_ns;
 
@@ -190,11 +190,9 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
/* trust the hw counter when it's around */
diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
} else if (rc && framedur_ns) {
-   const struct timeval *t_old;
-   u64 diff_ns;
+   ktime_t diff_ns;
 
-   t_old = >time;
-   diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);
+   diff_ns = t_vblank - vblank->time;
 
/*
 * Figure out how many vblanks we've missed based
@@ -228,7 +226,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
}
 
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
- " current=%u, diff=%u, hw=%u hw_last=%u\n",
+ " current=%llu, diff=%u, hw=%u hw_last=%u\n",
  pipe, vblank->count, diff, cur_vblank, vblank->last);
 
if (diff == 0) {
@@ -243,9 +241,9 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
 * for now, to mark the vblanktimestamp as invalid.
 

[PATCH 0/3] drm: Add CRTC-id based ioctls for vblank query/event

2017-07-31 Thread Keith Packard
Here's an updated series for the proposed new IOCTLs. Major changes
since last time:

 * Leave driver API with 32-bit vblank counts
 * Use ktime_t instead of struct timespec.
 * Check for MODESETTING before using modesetting APIs
 * Ensure vblank is running in new get_sequence ioctl

There are other minor changes noted in each patch.

Thanks to helpful review from:

Daniel Vetter 
Michel Dänzer 
Ville Syrjälä 

-keith



[PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls [v2]

2017-07-31 Thread Keith Packard
These provide crtc-id based functions instead of pipe-number, while
also offering higher resolution time (ns) and wider frame count (64)
as required by the Vulkan API.

v2:

 * Check for DRIVER_MODESET in new crtc-based vblank ioctls

Failing to check this will oops the driver.

 * Ensure vblank interupt is running in crtc_get_sequence ioctl

The sequence and timing values are not correct while the
interrupt is off, so make sure it's running before asking for
them.

 * Short-circuit get_sequence if the counter is enabled and accurate

Steal the idea from the code in wait_vblank to avoid the
expense of drm_vblank_get/put

 * Return active state of crtc in crtc_get_sequence ioctl

Might be useful for applications that aren't in charge of
modesetting?

 * Use drm_crtc_vblank_get/put in new crtc-based vblank sequence ioctls

Daniel Vetter prefers these over the old drm_vblank_put/get
APIs.

 * Return s64 ns instead of u64 in new sequence event

Suggested-by:  Daniel Vetter 
Suggested-by: Ville Syrjälä 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_internal.h |   6 ++
 drivers/gpu/drm/drm_ioctl.c|   2 +
 drivers/gpu/drm/drm_vblank.c   | 173 +
 include/drm/drm_vblank.h   |   1 +
 include/uapi/drm/drm.h |  32 
 5 files changed, 214 insertions(+)

diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 5cecc974d2f9..b68a193b7907 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -65,6 +65,12 @@ int drm_legacy_irq_control(struct drm_device *dev, void 
*data,
 int drm_legacy_modeset_ctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv);
 
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *filp);
+
+int drm_crtc_queue_sequence_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *filp);
+
 /* drm_auth.c */
 int drm_getmagic(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index f1e568176da9..63016cf3e224 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -657,6 +657,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
DRM_IOCTL_DEF(DRM_IOCTL_SYNCOBJ_FD_TO_HANDLE, 
drm_syncobj_fd_to_handle_ioctl,
  DRM_UNLOCKED|DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_GET_SEQUENCE, drm_crtc_get_sequence_ioctl, 
DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_CRTC_QUEUE_SEQUENCE, 
drm_crtc_queue_sequence_ioctl, DRM_UNLOCKED),
 };
 
 #define DRM_CORE_IOCTL_COUNT   ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 7e7119a5ada3..69b8c92cdd3a 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -812,6 +812,11 @@ static void send_vblank_event(struct drm_device *dev,
e->event.vbl.tv_sec = tv.tv_sec;
e->event.vbl.tv_usec = tv.tv_usec;
break;
+   case DRM_EVENT_CRTC_SEQUENCE:
+   if (seq)
+   e->event.seq.sequence = seq;
+   e->event.seq.time_ns = ktime_to_ns(now);
+   break;
}
trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
@@ -1682,3 +1687,171 @@ bool drm_crtc_handle_vblank(struct drm_crtc *crtc)
return drm_handle_vblank(crtc->dev, drm_crtc_index(crtc));
 }
 EXPORT_SYMBOL(drm_crtc_handle_vblank);
+
+/*
+ * Get crtc VBLANK count.
+ *
+ * \param dev DRM device
+ * \param data user arguement, pointing to a drm_crtc_get_sequence structure.
+ * \param file_priv drm file private for the user's open file descriptor
+ */
+
+int drm_crtc_get_sequence_ioctl(struct drm_device *dev, void *data,
+   struct drm_file *file_priv)
+{
+   struct drm_crtc *crtc;
+   struct drm_vblank_crtc *vblank;
+   int pipe;
+   struct drm_crtc_get_sequence *get_seq = data;
+   ktime_t now;
+   bool vblank_enabled;
+   int ret;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   if (!dev->irq_enabled)
+   return -EINVAL;
+
+   crtc = drm_crtc_find(dev, get_seq->crtc_id);
+   if (!crtc)
+   return -ENOENT;
+
+   pipe = drm_crtc_index(crtc);
+
+   vblank = >vblank[pipe];
+   vblank_enabled = dev->vblank_disable_immediate && 
READ_ONCE(vblank->enabled);
+
+   if (!vblank_enabled) {
+   ret = drm_crtc_vblank_get(crtc);
+   if (ret) {
+   DRM_DEBUG("crtc %d failed to acquire vblank counter, 
%d\n", pipe, ret);
+   

[PATCH 1/3] drm: Widen vblank UAPI to 64 bits. Change vblank time to ktime_t [v2]

2017-07-31 Thread Keith Packard
This modifies the datatypes used by the vblank code to provide both 64
bits of vblank count and switch to using ktime_t for timestamps to
increase resolution from microseconds to nanoseconds.

The driver interfaces have been left using 32 bits of vblank count;
all of the code necessary to widen that value for the user API was
already included to handle devices returning fewer than 32-bits.

This will provide the necessary datatypes for the Vulkan API.

v2:

 * Re-write wait_vblank ioctl to ABSOLUTE sequence

When an application uses the WAIT_VBLANK ioctl with RELATIVE
or NEXTONMISS bits set, the target vblank interval is updated
within the kernel. We need to write that target back to the
ioctl buffer and update the flags bits so that if the wait is
interrupted by a signal, when it is re-started, it will target
precisely the same vblank count as before.

 * Leave driver API with 32-bit vblank count

Suggested-by:  Michel Dänzer 
Suggested-by: Daniel Vetter 
Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_vblank.c | 186 +--
 include/drm/drmP.h   |   2 +-
 include/drm/drm_drv.h|   2 +-
 include/drm/drm_vblank.h |  16 ++--
 4 files changed, 120 insertions(+), 86 deletions(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 463e4d81fb0d..346601ad698d 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -43,7 +43,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, bool in_vblank_irq);
+ ktime_t *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -64,7 +64,7 @@ MODULE_PARM_DESC(timestamp_monotonic, "Use monotonic 
timestamps");
 
 static void store_vblank(struct drm_device *dev, unsigned int pipe,
 u32 vblank_count_inc,
-struct timeval *t_vblank, u32 last)
+ktime_t t_vblank, u32 last)
 {
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
@@ -73,7 +73,7 @@ static void store_vblank(struct drm_device *dev, unsigned int 
pipe,
vblank->last = last;
 
write_seqlock(>seqlock);
-   vblank->time = *t_vblank;
+   vblank->time = t_vblank;
vblank->count += vblank_count_inc;
write_sequnlock(>seqlock);
 }
@@ -116,7 +116,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 {
u32 cur_vblank;
bool rc;
-   struct timeval t_vblank;
+   ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
 
spin_lock(>vblank_time_lock);
@@ -136,13 +136,13 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 * interrupt and assign 0 for now, to mark the vblanktimestamp as 
invalid.
 */
if (!rc)
-   t_vblank = (struct timeval) {0, 0};
+   t_vblank = 0;
 
/*
 * +1 to make sure user will never see the same
 * vblank counter value before and after a modeset
 */
-   store_vblank(dev, pipe, 1, _vblank, cur_vblank);
+   store_vblank(dev, pipe, 1, t_vblank, cur_vblank);
 
spin_unlock(>vblank_time_lock);
 }
@@ -165,7 +165,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
struct drm_vblank_crtc *vblank = >vblank[pipe];
u32 cur_vblank, diff;
bool rc;
-   struct timeval t_vblank;
+   ktime_t t_vblank;
int count = DRM_TIMESTAMP_MAXRETRIES;
int framedur_ns = vblank->framedur_ns;
 
@@ -190,11 +190,9 @@ static void drm_update_vblank_count(struct drm_device 
*dev, unsigned int pipe,
/* trust the hw counter when it's around */
diff = (cur_vblank - vblank->last) & dev->max_vblank_count;
} else if (rc && framedur_ns) {
-   const struct timeval *t_old;
-   u64 diff_ns;
+   ktime_t diff_ns;
 
-   t_old = >time;
-   diff_ns = timeval_to_ns(_vblank) - timeval_to_ns(t_old);
+   diff_ns = t_vblank - vblank->time;
 
/*
 * Figure out how many vblanks we've missed based
@@ -228,7 +226,7 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
}
 
DRM_DEBUG_VBL("updating vblank count on crtc %u:"
- " current=%u, diff=%u, hw=%u hw_last=%u\n",
+ " current=%llu, diff=%u, hw=%u hw_last=%u\n",
  pipe, vblank->count, diff, cur_vblank, vblank->last);
 
if (diff == 0) {
@@ -243,9 +241,9 @@ static void drm_update_vblank_count(struct drm_device *dev, 
unsigned int pipe,
 * for now, to mark the vblanktimestamp as invalid.
 */
if (!rc && in_vblank_irq)
-   

[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2]

2017-07-31 Thread Keith Packard
Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.

Assignments to the crtc_id field are now done when the event is
allocated, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.

v2:
 * Remove 'dev' argument from create_vblank_event

It wasn't being used anyways, and if we need it in the future,
we can always get it from crtc->dev.

 * Check for MODESETTING before looking for crtc in queue_vblank_event

UMS drivers will oops if we try to get a crtc, so make sure
we're modesetting before we try to find a crtc_id to fill into
the event.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_atomic.c |  7 ---
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_vblank.c | 30 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  4 ++--
 include/drm/drm_vblank.h |  8 +++-
 6 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0f336d23f9c..272b83ea9369 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
  */
 
 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, uint64_t user_data)
+   struct drm_crtc *crtc, uint64_t user_data)
 {
struct drm_pending_vblank_event *e = NULL;
 
@@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
 
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = user_data;
+   e->event.vbl.crtc_id = crtc->base.id;
+   e->event.vbl.user_data = user_data;
 
return e;
 }
@@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
struct drm_pending_vblank_event *e;
 
-   e = create_vblank_event(dev, arg->user_data);
+   e = create_vblank_event(crtc, arg->user_data);
if (!e)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c4350602..fe9f31285bc2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = page_flip->user_data;
+   e->event.vbl.user_data = page_flip->user_data;
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);
if (ret) {
kfree(e);
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 346601ad698d..7e7119a5ada3 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -804,14 +804,16 @@ static void send_vblank_event(struct drm_device *dev,
 {
struct timeval tv;
 
-   tv = ktime_to_timeval(now);
-   e->event.sequence = seq;
-   e->event.tv_sec = tv.tv_sec;
-   e->event.tv_usec = tv.tv_usec;
-
-   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe,
-e->event.sequence);
-
+   switch (e->event.base.type) {
+   case DRM_EVENT_VBLANK:
+   case DRM_EVENT_FLIP_COMPLETE:
+   tv = ktime_to_timeval(now);
+   e->event.vbl.sequence = seq;
+   e->event.vbl.tv_sec = tv.tv_sec;
+   e->event.vbl.tv_usec = tv.tv_usec;
+   break;
+   }
+   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
 }
 
@@ -863,7 +865,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
 
e->pipe = pipe;
e->sequence = drm_vblank_count(dev, pipe);
-   e->event.crtc_id = crtc->base.id;
list_add_tail(>base.link, >vblank_event_list);
 }
 EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
@@ -894,7 +895,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
now = get_drm_timestamp();
}
e->pipe = pipe;
-   e->event.crtc_id = crtc->base.id;
send_vblank_event(dev, e, seq, now);
 }
 EXPORT_SYMBOL(drm_crtc_send_vblank_event);
@@ -1354,8 +1354,14 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, unsigned int pipe,
 
e->pipe = pipe;
e->event.base.type = DRM_EVENT_VBLANK;
-   e->event.base.length = sizeof(e->event);
-   

[PATCH 2/3] drm: Reorganize drm_pending_event to support future event types [v2]

2017-07-31 Thread Keith Packard
Place drm_event_vblank in a new union that includes that and a bare
drm_event structure. This will allow new members of that union to be
added in the future without changing code related to the existing vbl
event type.

Assignments to the crtc_id field are now done when the event is
allocated, rather than when delievered. This way, delivery doesn't
need to have the crtc ID available.

v2:
 * Remove 'dev' argument from create_vblank_event

It wasn't being used anyways, and if we need it in the future,
we can always get it from crtc->dev.

 * Check for MODESETTING before looking for crtc in queue_vblank_event

UMS drivers will oops if we try to get a crtc, so make sure
we're modesetting before we try to find a crtc_id to fill into
the event.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/drm_atomic.c |  7 ---
 drivers/gpu/drm/drm_plane.c  |  2 +-
 drivers/gpu/drm/drm_vblank.c | 30 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  4 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c |  4 ++--
 include/drm/drm_vblank.h |  8 +++-
 6 files changed, 34 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index c0f336d23f9c..272b83ea9369 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1839,7 +1839,7 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
  */
 
 static struct drm_pending_vblank_event *create_vblank_event(
-   struct drm_device *dev, uint64_t user_data)
+   struct drm_crtc *crtc, uint64_t user_data)
 {
struct drm_pending_vblank_event *e = NULL;
 
@@ -1849,7 +1849,8 @@ static struct drm_pending_vblank_event 
*create_vblank_event(
 
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = user_data;
+   e->event.vbl.crtc_id = crtc->base.id;
+   e->event.vbl.user_data = user_data;
 
return e;
 }
@@ -2052,7 +2053,7 @@ static int prepare_crtc_signaling(struct drm_device *dev,
if (arg->flags & DRM_MODE_PAGE_FLIP_EVENT || fence_ptr) {
struct drm_pending_vblank_event *e;
 
-   e = create_vblank_event(dev, arg->user_data);
+   e = create_vblank_event(crtc, arg->user_data);
if (!e)
return -ENOMEM;
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 5dc8c4350602..fe9f31285bc2 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -918,7 +918,7 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
}
e->event.base.type = DRM_EVENT_FLIP_COMPLETE;
e->event.base.length = sizeof(e->event);
-   e->event.user_data = page_flip->user_data;
+   e->event.vbl.user_data = page_flip->user_data;
ret = drm_event_reserve_init(dev, file_priv, >base, 
>event.base);
if (ret) {
kfree(e);
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 346601ad698d..7e7119a5ada3 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -804,14 +804,16 @@ static void send_vblank_event(struct drm_device *dev,
 {
struct timeval tv;
 
-   tv = ktime_to_timeval(now);
-   e->event.sequence = seq;
-   e->event.tv_sec = tv.tv_sec;
-   e->event.tv_usec = tv.tv_usec;
-
-   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe,
-e->event.sequence);
-
+   switch (e->event.base.type) {
+   case DRM_EVENT_VBLANK:
+   case DRM_EVENT_FLIP_COMPLETE:
+   tv = ktime_to_timeval(now);
+   e->event.vbl.sequence = seq;
+   e->event.vbl.tv_sec = tv.tv_sec;
+   e->event.vbl.tv_usec = tv.tv_usec;
+   break;
+   }
+   trace_drm_vblank_event_delivered(e->base.file_priv, e->pipe, seq);
drm_send_event_locked(dev, >base);
 }
 
@@ -863,7 +865,6 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
 
e->pipe = pipe;
e->sequence = drm_vblank_count(dev, pipe);
-   e->event.crtc_id = crtc->base.id;
list_add_tail(>base.link, >vblank_event_list);
 }
 EXPORT_SYMBOL(drm_crtc_arm_vblank_event);
@@ -894,7 +895,6 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
now = get_drm_timestamp();
}
e->pipe = pipe;
-   e->event.crtc_id = crtc->base.id;
send_vblank_event(dev, e, seq, now);
 }
 EXPORT_SYMBOL(drm_crtc_send_vblank_event);
@@ -1354,8 +1354,14 @@ static int drm_queue_vblank_event(struct drm_device 
*dev, unsigned int pipe,
 
e->pipe = pipe;
e->event.base.type = DRM_EVENT_VBLANK;
-   e->event.base.length = sizeof(e->event);
-   e->event.user_data = 

Re: [alsa-devel] [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger

2017-07-31 Thread Keyon Jie


On 2017年08月01日 11:30, Vinod Koul wrote:

On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:

From: "U. Artie Eoff" 

Reset the hw_ptr before queuing the restore_stream_context
work to eradicate a nasty white audio noise on resume.


Liam, Jie? This on legacy BYT driver..



Tested-by: Cheng-Yi Chiang 
Signed-off-by: U. Artie Eoff 
Signed-off-by: Cheng-Yi Chiang 
---
  sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c 
b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
index 4765ad474544..e0db7070cd42 100644
--- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
+++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
@@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream 
*substream, int cmd)
sst_byt_stream_start(byt, pcm_data->stream, 0);
break;
case SNDRV_PCM_TRIGGER_RESUME:
-   if (pdata->restore_stream == true)
+   if (pdata->restore_stream == true) {
+   pcm_data->hw_ptr = 0;


Won't this break the hw_ptr and make the resuming won't play from the 
pausing point of the last suspending?


Thanks,
~Keyon


schedule_work(_data->work);
+   }
else
sst_byt_stream_resume(byt, pcm_data->stream);
break;
--
2.12.2





Re: [alsa-devel] [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger

2017-07-31 Thread Keyon Jie


On 2017年08月01日 11:30, Vinod Koul wrote:

On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:

From: "U. Artie Eoff" 

Reset the hw_ptr before queuing the restore_stream_context
work to eradicate a nasty white audio noise on resume.


Liam, Jie? This on legacy BYT driver..



Tested-by: Cheng-Yi Chiang 
Signed-off-by: U. Artie Eoff 
Signed-off-by: Cheng-Yi Chiang 
---
  sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c 
b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
index 4765ad474544..e0db7070cd42 100644
--- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
+++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
@@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct snd_pcm_substream 
*substream, int cmd)
sst_byt_stream_start(byt, pcm_data->stream, 0);
break;
case SNDRV_PCM_TRIGGER_RESUME:
-   if (pdata->restore_stream == true)
+   if (pdata->restore_stream == true) {
+   pcm_data->hw_ptr = 0;


Won't this break the hw_ptr and make the resuming won't play from the 
pausing point of the last suspending?


Thanks,
~Keyon


schedule_work(_data->work);
+   }
else
sst_byt_stream_resume(byt, pcm_data->stream);
break;
--
2.12.2





[PATCH 3/7] mtd: spi-nor: cadence-quadspi: Add runtime PM support

2017-07-31 Thread Vignesh R
Add pm_runtime* calls to cadence-quadspi driver. This is required to
switch on QSPI power domain on TI 66AK2G SoC during probe.

Signed-off-by: Vignesh R 
---
 drivers/mtd/spi-nor/cadence-quadspi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 297c86a2d4a7..1e432916e00b 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1219,6 +1220,13 @@ static int cqspi_probe(struct platform_device *pdev)
return -ENXIO;
}
 
+   pm_runtime_enable(>dev);
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   return ret;
+   }
+
ret = clk_prepare_enable(cqspi->clk);
if (ret) {
dev_err(dev, "Cannot enable QSPI clock.\n");
@@ -1269,6 +1277,9 @@ static int cqspi_remove(struct platform_device *pdev)
 
clk_disable_unprepare(cqspi->clk);
 
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
return 0;
 }
 
-- 
2.13.3



[PATCH 3/7] mtd: spi-nor: cadence-quadspi: Add runtime PM support

2017-07-31 Thread Vignesh R
Add pm_runtime* calls to cadence-quadspi driver. This is required to
switch on QSPI power domain on TI 66AK2G SoC during probe.

Signed-off-by: Vignesh R 
---
 drivers/mtd/spi-nor/cadence-quadspi.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 297c86a2d4a7..1e432916e00b 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1219,6 +1220,13 @@ static int cqspi_probe(struct platform_device *pdev)
return -ENXIO;
}
 
+   pm_runtime_enable(>dev);
+   ret = pm_runtime_get_sync(>dev);
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
+   return ret;
+   }
+
ret = clk_prepare_enable(cqspi->clk);
if (ret) {
dev_err(dev, "Cannot enable QSPI clock.\n");
@@ -1269,6 +1277,9 @@ static int cqspi_remove(struct platform_device *pdev)
 
clk_disable_unprepare(cqspi->clk);
 
+   pm_runtime_put_sync(>dev);
+   pm_runtime_disable(>dev);
+
return 0;
 }
 
-- 
2.13.3



[PATCH 4/7] ARM: dts: keystone-k2g: Add QSPI DT entry

2017-07-31 Thread Vignesh R
Add DT node for Cadence QSPI IP present in 66AK2G SoC.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index bf4d1fa30840..95327aabfaa4 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -168,5 +168,20 @@
#reset-cells = <2>;
};
};
+
+   qspi: qspi@294 {
+   compatible = "ti,k2g-qspi", "cdns,qspi-nor";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0294 0x1000>,
+ <0x2400 0x400>;
+   interrupts = ;
+   cdns,fifo-depth = <256>;
+   cdns,fifo-width = <4>;
+   cdns,trigger-address = <0x2400>;
+   clocks = <_clks 0x43 0x0>;
+   power-domains = <_pds 0x43>;
+   status = "disabled";
+   };
};
 };
-- 
2.13.3



[PATCH 4/7] ARM: dts: keystone-k2g: Add QSPI DT entry

2017-07-31 Thread Vignesh R
Add DT node for Cadence QSPI IP present in 66AK2G SoC.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index bf4d1fa30840..95327aabfaa4 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -168,5 +168,20 @@
#reset-cells = <2>;
};
};
+
+   qspi: qspi@294 {
+   compatible = "ti,k2g-qspi", "cdns,qspi-nor";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0x0294 0x1000>,
+ <0x2400 0x400>;
+   interrupts = ;
+   cdns,fifo-depth = <256>;
+   cdns,fifo-width = <4>;
+   cdns,trigger-address = <0x2400>;
+   clocks = <_clks 0x43 0x0>;
+   power-domains = <_pds 0x43>;
+   status = "disabled";
+   };
};
 };
-- 
2.13.3



[PATCH 1/7] mtd: spi-nor: cadence-quadspi: add a delay in write sequence

2017-07-31 Thread Vignesh R
As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
Controller programming sequence, a delay equal to couple QSPI master
clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
writing data to the flash. Add a new compatible to handle the couple of
cycles of delay required in the indirect write sequence, since this
delay is specific to TI 66AK2G SoC.

[1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt |  1 +
 drivers/mtd/spi-nor/cadence-quadspi.c | 13 +
 2 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index f248056da24c..fdd511a83511 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible : Should be "cdns,qspi-nor".
+  Should be "ti,k2g-qspi" for TI 66AK2G platform.
 - reg : Contains two entries, each of which is a tuple consisting of a
physical address and length. The first entry is the address and
length of the controller register set. The second entry is the
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 53c7d8e0327a..94571590371d 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -76,6 +76,7 @@ struct cqspi_st {
u32 fifo_depth;
u32 fifo_width;
u32 trigger_address;
+   u32 wr_delay;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
 };
 
@@ -608,6 +609,14 @@ static int cqspi_indirect_write_execute(struct spi_nor 
*nor,
reinit_completion(>transfer_complete);
writel(CQSPI_REG_INDIRECTWR_START_MASK,
   reg_base + CQSPI_REG_INDIRECTWR);
+   /*
+* As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access
+* Controller programming sequence, couple of cycles of
+* QSPI_REF_CLK delay is required for the above bit to
+* be internally synchronized by the QSPI module. Provide 5
+* cycles of delay.
+*/
+   ndelay(cqspi->wr_delay);
 
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
@@ -1213,6 +1222,9 @@ static int cqspi_probe(struct platform_device *pdev)
}
 
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
+   if (of_device_is_compatible(dev->of_node, "ti,k2g-qspi"))
+   cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
+  cqspi->master_ref_clk_hz);
 
ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
   pdev->name, cqspi);
@@ -1285,6 +1297,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
 
 static const struct of_device_id cqspi_dt_ids[] = {
{.compatible = "cdns,qspi-nor",},
+   {.compatible = "ti,k2g-qspi",},
{ /* end of table */ }
 };
 
-- 
2.13.3



[PATCH 1/7] mtd: spi-nor: cadence-quadspi: add a delay in write sequence

2017-07-31 Thread Vignesh R
As per 66AK2G02 TRM[1] SPRUHY8F section 11.15.5.3 Indirect Access
Controller programming sequence, a delay equal to couple QSPI master
clock(~5ns) is required after setting CQSPI_REG_INDIRECTWR_START bit and
writing data to the flash. Add a new compatible to handle the couple of
cycles of delay required in the indirect write sequence, since this
delay is specific to TI 66AK2G SoC.

[1]http://www.ti.com/lit/ug/spruhy8f/spruhy8f.pdf

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt |  1 +
 drivers/mtd/spi-nor/cadence-quadspi.c | 13 +
 2 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index f248056da24c..fdd511a83511 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -2,6 +2,7 @@
 
 Required properties:
 - compatible : Should be "cdns,qspi-nor".
+  Should be "ti,k2g-qspi" for TI 66AK2G platform.
 - reg : Contains two entries, each of which is a tuple consisting of a
physical address and length. The first entry is the address and
length of the controller register set. The second entry is the
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 53c7d8e0327a..94571590371d 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -76,6 +76,7 @@ struct cqspi_st {
u32 fifo_depth;
u32 fifo_width;
u32 trigger_address;
+   u32 wr_delay;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
 };
 
@@ -608,6 +609,14 @@ static int cqspi_indirect_write_execute(struct spi_nor 
*nor,
reinit_completion(>transfer_complete);
writel(CQSPI_REG_INDIRECTWR_START_MASK,
   reg_base + CQSPI_REG_INDIRECTWR);
+   /*
+* As per 66AK2G02 TRM SPRUHY8F section 11.15.5.3 Indirect Access
+* Controller programming sequence, couple of cycles of
+* QSPI_REF_CLK delay is required for the above bit to
+* be internally synchronized by the QSPI module. Provide 5
+* cycles of delay.
+*/
+   ndelay(cqspi->wr_delay);
 
while (remaining > 0) {
write_bytes = remaining > page_size ? page_size : remaining;
@@ -1213,6 +1222,9 @@ static int cqspi_probe(struct platform_device *pdev)
}
 
cqspi->master_ref_clk_hz = clk_get_rate(cqspi->clk);
+   if (of_device_is_compatible(dev->of_node, "ti,k2g-qspi"))
+   cqspi->wr_delay = 5 * DIV_ROUND_UP(NSEC_PER_SEC,
+  cqspi->master_ref_clk_hz);
 
ret = devm_request_irq(dev, irq, cqspi_irq_handler, 0,
   pdev->name, cqspi);
@@ -1285,6 +1297,7 @@ static const struct dev_pm_ops cqspi__dev_pm_ops = {
 
 static const struct of_device_id cqspi_dt_ids[] = {
{.compatible = "cdns,qspi-nor",},
+   {.compatible = "ti,k2g-qspi",},
{ /* end of table */ }
 };
 
-- 
2.13.3



[PATCH 5/7] ARM: dts: keystone-k2g-evm: Add QSPI node

2017-07-31 Thread Vignesh R
66AK2G EVM has a s25fl512s flash connected to QSPI CS0. Add pinmux for
QSPI and DT entries for the same.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts 
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 61883cb969d2..55d632977e8f 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -34,6 +34,18 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart0_txd.uart0_txd */
>;
};
+
+   qspi_pins: pinmux_qspi_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_clk.qspi_clk */
+   K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_rclk.qspi_rclk */
+   K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d0.qspi_d0 */
+   K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d1.qspi_d1 */
+   K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d2.qspi_d2 */
+   K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d3.qspi_d3 */
+   K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+   >;
+   };
 };
 
  {
@@ -41,3 +53,60 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   cdns,rclk-en;
+   status = "okay";
+
+   flash0: m25p80@0 {
+   compatible = "s25fl512s", "jedec,spi-nor";
+   reg = <0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <9600>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   cdns,read-delay = <5>;
+   cdns,tshsl-ns = <500>;
+   cdns,tsd2d-ns = <500>;
+   cdns,tchsh-ns = <119>;
+   cdns,tslch-ns = <119>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "QSPI.u-boot";
+   reg = <0x 0x0010>;
+   };
+   partition@10 {
+   label = "QSPI.u-boot-env";
+   reg = <0x0010 0x0004>;
+   };
+   partition@14 {
+   label = "QSPI.skern";
+   reg = <0x0014 0x004>;
+   };
+   partition@18 {
+   label = "QSPI.sci-firmware";
+   reg = <0x0018 0x004>;
+   };
+   partition@1c {
+   label = "QSPI.kernel";
+   reg = <0x001c 0x080>;
+   };
+   partition@9c {
+   label = "QSPI.u-boot-spl-os";
+   reg = <0x009c 0x004>;
+   };
+   partition@a0 {
+   label = "QSPI.file-system";
+   reg = <0x00a0 0x360>;
+   };
+   };
+   };
+};
-- 
2.13.3



Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes

2017-07-31 Thread kgunda

On 2017-07-28 12:40, Kiran Gunda wrote:

v2:

* [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type 
function

  Added Stephen's Reviewed-by tag.

* [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for 
mapping_table

  Added Fixes tag and Stephen's Reviewed-by tag.

* [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and 
other cleanup

  Added Stephen's Reviewed-by tag.

* [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with 
__raw_writel

  Added Fixes tag.

* [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function
  Fixed alignement issue and added Stephen's reviewed-by tag.

Now all the patches in this series are reviewed and acked by Stephen
boyd and are ready
for merge.

v1:

* This patch series add the support for pmic arbiter hardware v5 along 
with

  the few bug fixes and code cleanup.

* This new series is the combined series of
  [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and
  [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, 
which are

  being reviewed by Stephen Boyd.

* This series depends on the below patch uploaded by Stephen Boyd
  https://patchwork.kernel.org/patch/9810723/.

David Collins (1):
  spmi: pmic-arb: add support for HW version 5

Fenglin Wu (1):
  spmi: pmic-arb: Remove checking opc value not less than 0

Kiran Gunda (10):
  spmi: pmic-arb: remove the read/write access checks
  spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup
  spmi: pmic-arb: clean up pmic_arb_find_apid function
  spmi: pmic-arb: optimize qpnpint_irq_set_type function
  spmi: pmic-arb: fix memory allocation for mapping_table
  spmi: pmic-arb: replace the writel_relaxed with __raw_writel
  spmi: pmic-arb: return the value instead of passing by pointer
  spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup
capability
  spmi: pmic-arb: return __iomem pointer instead of offset
  spmi: pmic-arb: fix a possible null pointer dereference

 drivers/spmi/spmi-pmic-arb.c | 825 
+--

 1 file changed, 481 insertions(+), 344 deletions(-)

Hi Greg,
Could you please pull this patch series in to your tree? All these 
patches

are reviewed and acked by Stephen boyd.


[PATCH 2/7] mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit

2017-07-31 Thread Vignesh R
Cadence QSPI IP has a adapted loopback circuit which can be enabled by
setting BYPASS field to 0 in READCAPTURE register. It enables use of
QSPI return clock to latch the data rather than the internal QSPI
reference clock. For high speed operations, adapted loopback circuit
using QSPI return clock helps to increase data valid window.

Add DT parameter cdns,rclk-en to help enable adapted loopback circuit
for boards which do have QSPI return clock provided.
This patch also modifies cqspi_readdata_capture() function's bypass
parameter to bool to match how its used in the function.

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 3 +++
 drivers/mtd/spi-nor/cadence-quadspi.c | 8 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index fdd511a83511..6cc7d58ce7f6 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -15,6 +15,9 @@ Required properties:
 
 Optional properties:
 - cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
+- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
+  the read data rather than the QSPI clock. Make sure that QSPI return
+  clock is populated on the board before using this property.
 
 Optional subnodes:
 Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 94571590371d..297c86a2d4a7 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -75,6 +75,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+   boolrclk_en;
u32 trigger_address;
u32 wr_delay;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
@@ -784,7 +785,7 @@ static void cqspi_config_baudrate_div(struct cqspi_st 
*cqspi)
 }
 
 static void cqspi_readdata_capture(struct cqspi_st *cqspi,
-  const unsigned int bypass,
+  const bool bypass,
   const unsigned int delay)
 {
void __iomem *reg_base = cqspi->iobase;
@@ -848,7 +849,8 @@ static void cqspi_configure(struct spi_nor *nor)
cqspi->sclk = sclk;
cqspi_config_baudrate_div(cqspi);
cqspi_delay(nor);
-   cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay);
+   cqspi_readdata_capture(cqspi, !cqspi->rclk_en,
+  f_pdata->read_delay);
}
 
if (switch_cs || switch_ck)
@@ -1045,6 +1047,8 @@ static int cqspi_of_get_pdata(struct platform_device 
*pdev)
return -ENXIO;
}
 
+   cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
+
return 0;
 }
 
-- 
2.13.3



[PATCH 0/7] K2G: Add QSPI support

2017-07-31 Thread Vignesh R
This series adds support for Cadence QSPI for 66AK2G SoC. The first
three patches enhance the cadence-quadspi driver to support loopback
clock and pm_runtime and tweaks for 66AK2G SoC. Remaining patches add
DT nodes and enable the driver in defconfig.

Tested on 66AK2G GP and ICE boards.

Vignesh R (7):
  mtd: spi-nor: cadence-quadspi: add a delay in write sequence
  mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock
circuit
  mtd: spi-nor: cadence-quadspi: Add runtime PM support
  ARM: dts: keystone-k2g: Add QSPI DT entry
  ARM: dts: keystone-k2g-evm: Add QSPI node
  ARM: dts: keystone-k2g-ice: Add QSPI node
  ARM: configs: keystone: Enable Cadence QSPI driver

 .../devicetree/bindings/mtd/cadence-quadspi.txt|  4 ++
 arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++
 arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++
 arch/arm/boot/dts/keystone-k2g.dtsi| 15 +
 arch/arm/configs/keystone_defconfig|  1 +
 drivers/mtd/spi-nor/cadence-quadspi.c  | 32 +-
 6 files changed, 188 insertions(+), 2 deletions(-)

-- 
2.13.3



[PATCH 5/7] ARM: dts: keystone-k2g-evm: Add QSPI node

2017-07-31 Thread Vignesh R
66AK2G EVM has a s25fl512s flash connected to QSPI CS0. Add pinmux for
QSPI and DT entries for the same.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts 
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 61883cb969d2..55d632977e8f 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -34,6 +34,18 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart0_txd.uart0_txd */
>;
};
+
+   qspi_pins: pinmux_qspi_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_clk.qspi_clk */
+   K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_rclk.qspi_rclk */
+   K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d0.qspi_d0 */
+   K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d1.qspi_d1 */
+   K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d2.qspi_d2 */
+   K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d3.qspi_d3 */
+   K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+   >;
+   };
 };
 
  {
@@ -41,3 +53,60 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   cdns,rclk-en;
+   status = "okay";
+
+   flash0: m25p80@0 {
+   compatible = "s25fl512s", "jedec,spi-nor";
+   reg = <0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <9600>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   cdns,read-delay = <5>;
+   cdns,tshsl-ns = <500>;
+   cdns,tsd2d-ns = <500>;
+   cdns,tchsh-ns = <119>;
+   cdns,tslch-ns = <119>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "QSPI.u-boot";
+   reg = <0x 0x0010>;
+   };
+   partition@10 {
+   label = "QSPI.u-boot-env";
+   reg = <0x0010 0x0004>;
+   };
+   partition@14 {
+   label = "QSPI.skern";
+   reg = <0x0014 0x004>;
+   };
+   partition@18 {
+   label = "QSPI.sci-firmware";
+   reg = <0x0018 0x004>;
+   };
+   partition@1c {
+   label = "QSPI.kernel";
+   reg = <0x001c 0x080>;
+   };
+   partition@9c {
+   label = "QSPI.u-boot-spl-os";
+   reg = <0x009c 0x004>;
+   };
+   partition@a0 {
+   label = "QSPI.file-system";
+   reg = <0x00a0 0x360>;
+   };
+   };
+   };
+};
-- 
2.13.3



Re: [PATCH V2 00/12]: spmi: pmic-arb: Support for HW v5 and other fixes

2017-07-31 Thread kgunda

On 2017-07-28 12:40, Kiran Gunda wrote:

v2:

* [PATCH V2 04/12] spmi: pmic-arb: optimize qpnpint_irq_set_type 
function

  Added Stephen's Reviewed-by tag.

* [PATCH V2 05/12] spmi: pmic-arb: fix memory allocation for 
mapping_table

  Added Fixes tag and Stephen's Reviewed-by tag.

* [PATCH V2 02/12] spmi: pmic-arb: rename pa_xx to pmic_arb_xx and 
other cleanup

  Added Stephen's Reviewed-by tag.

* [PATCH V2 06/12] spmi: pmic-arb: replace the writel_relaxed with 
__raw_writel

  Added Fixes tag.

* [PATCH V2 03/12] spmi: pmic-arb: clean up pmic_arb_find_apid function
  Fixed alignement issue and added Stephen's reviewed-by tag.

Now all the patches in this series are reviewed and acked by Stephen
boyd and are ready
for merge.

v1:

* This patch series add the support for pmic arbiter hardware v5 along 
with

  the few bug fixes and code cleanup.

* This new series is the combined series of
  [PATCH V3 0/5]: spmi: pmic-arb: Fixup patches and
  [PATCH V4 0/4]: spmi: pmic-arb: support for V5 HW and bug fixes, 
which are

  being reviewed by Stephen Boyd.

* This series depends on the below patch uploaded by Stephen Boyd
  https://patchwork.kernel.org/patch/9810723/.

David Collins (1):
  spmi: pmic-arb: add support for HW version 5

Fenglin Wu (1):
  spmi: pmic-arb: Remove checking opc value not less than 0

Kiran Gunda (10):
  spmi: pmic-arb: remove the read/write access checks
  spmi: pmic-arb: rename pa_xx to pmic_arb_xx and other cleanup
  spmi: pmic-arb: clean up pmic_arb_find_apid function
  spmi: pmic-arb: optimize qpnpint_irq_set_type function
  spmi: pmic-arb: fix memory allocation for mapping_table
  spmi: pmic-arb: replace the writel_relaxed with __raw_writel
  spmi: pmic-arb: return the value instead of passing by pointer
  spmi: pmic-arb: use irq_chip callback to set spmi irq wakeup
capability
  spmi: pmic-arb: return __iomem pointer instead of offset
  spmi: pmic-arb: fix a possible null pointer dereference

 drivers/spmi/spmi-pmic-arb.c | 825 
+--

 1 file changed, 481 insertions(+), 344 deletions(-)

Hi Greg,
Could you please pull this patch series in to your tree? All these 
patches

are reviewed and acked by Stephen boyd.


[PATCH 2/7] mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock circuit

2017-07-31 Thread Vignesh R
Cadence QSPI IP has a adapted loopback circuit which can be enabled by
setting BYPASS field to 0 in READCAPTURE register. It enables use of
QSPI return clock to latch the data rather than the internal QSPI
reference clock. For high speed operations, adapted loopback circuit
using QSPI return clock helps to increase data valid window.

Add DT parameter cdns,rclk-en to help enable adapted loopback circuit
for boards which do have QSPI return clock provided.
This patch also modifies cqspi_readdata_capture() function's bypass
parameter to bool to match how its used in the function.

Signed-off-by: Vignesh R 
---
 Documentation/devicetree/bindings/mtd/cadence-quadspi.txt | 3 +++
 drivers/mtd/spi-nor/cadence-quadspi.c | 8 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
index fdd511a83511..6cc7d58ce7f6 100644
--- a/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/cadence-quadspi.txt
@@ -15,6 +15,9 @@ Required properties:
 
 Optional properties:
 - cdns,is-decoded-cs : Flag to indicate whether decoder is used or not.
+- cdns,rclk-en : Flag to indicate that QSPI return clock is used to latch
+  the read data rather than the QSPI clock. Make sure that QSPI return
+  clock is populated on the board before using this property.
 
 Optional subnodes:
 Subnodes of the Cadence Quad SPI controller are spi slave nodes with additional
diff --git a/drivers/mtd/spi-nor/cadence-quadspi.c 
b/drivers/mtd/spi-nor/cadence-quadspi.c
index 94571590371d..297c86a2d4a7 100644
--- a/drivers/mtd/spi-nor/cadence-quadspi.c
+++ b/drivers/mtd/spi-nor/cadence-quadspi.c
@@ -75,6 +75,7 @@ struct cqspi_st {
boolis_decoded_cs;
u32 fifo_depth;
u32 fifo_width;
+   boolrclk_en;
u32 trigger_address;
u32 wr_delay;
struct cqspi_flash_pdata f_pdata[CQSPI_MAX_CHIPSELECT];
@@ -784,7 +785,7 @@ static void cqspi_config_baudrate_div(struct cqspi_st 
*cqspi)
 }
 
 static void cqspi_readdata_capture(struct cqspi_st *cqspi,
-  const unsigned int bypass,
+  const bool bypass,
   const unsigned int delay)
 {
void __iomem *reg_base = cqspi->iobase;
@@ -848,7 +849,8 @@ static void cqspi_configure(struct spi_nor *nor)
cqspi->sclk = sclk;
cqspi_config_baudrate_div(cqspi);
cqspi_delay(nor);
-   cqspi_readdata_capture(cqspi, 1, f_pdata->read_delay);
+   cqspi_readdata_capture(cqspi, !cqspi->rclk_en,
+  f_pdata->read_delay);
}
 
if (switch_cs || switch_ck)
@@ -1045,6 +1047,8 @@ static int cqspi_of_get_pdata(struct platform_device 
*pdev)
return -ENXIO;
}
 
+   cqspi->rclk_en = of_property_read_bool(np, "cdns,rclk-en");
+
return 0;
 }
 
-- 
2.13.3



[PATCH 0/7] K2G: Add QSPI support

2017-07-31 Thread Vignesh R
This series adds support for Cadence QSPI for 66AK2G SoC. The first
three patches enhance the cadence-quadspi driver to support loopback
clock and pm_runtime and tweaks for 66AK2G SoC. Remaining patches add
DT nodes and enable the driver in defconfig.

Tested on 66AK2G GP and ICE boards.

Vignesh R (7):
  mtd: spi-nor: cadence-quadspi: add a delay in write sequence
  mtd: spi-nor: cadence-quadspi: Add support to enable loopback clock
circuit
  mtd: spi-nor: cadence-quadspi: Add runtime PM support
  ARM: dts: keystone-k2g: Add QSPI DT entry
  ARM: dts: keystone-k2g-evm: Add QSPI node
  ARM: dts: keystone-k2g-ice: Add QSPI node
  ARM: configs: keystone: Enable Cadence QSPI driver

 .../devicetree/bindings/mtd/cadence-quadspi.txt|  4 ++
 arch/arm/boot/dts/keystone-k2g-evm.dts | 69 ++
 arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++
 arch/arm/boot/dts/keystone-k2g.dtsi| 15 +
 arch/arm/configs/keystone_defconfig|  1 +
 drivers/mtd/spi-nor/cadence-quadspi.c  | 32 +-
 6 files changed, 188 insertions(+), 2 deletions(-)

-- 
2.13.3



[PATCH 6/7] ARM: dts: keystone-k2g-ice: Add QSPI node

2017-07-31 Thread Vignesh R
66AK2G ICE board has a s25fl256s1 flash connected to QSPI CS0. Add
pinmux and DT entries for the same.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts 
b/arch/arm/boot/dts/keystone-k2g-ice.dts
index d820d37b5148..075c3a605c8b 100644
--- a/arch/arm/boot/dts/keystone-k2g-ice.dts
+++ b/arch/arm/boot/dts/keystone-k2g-ice.dts
@@ -26,6 +26,18 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart0_txd.uart0_txd */
>;
};
+
+   qspi_pins: pinmux_qspi_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_clk.qspi_clk */
+   K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_rclk.qspi_rclk */
+   K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d0.qspi_d0 */
+   K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d1.qspi_d1 */
+   K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d2.qspi_d2 */
+   K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d3.qspi_d3 */
+   K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+   >;
+   };
 };
 
  {
@@ -33,3 +45,60 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   cdns,rclk-en;
+   status = "okay";
+
+   flash0: m25p80@0 {
+   compatible = "s25fl256s1", "jedec,spi-nor";
+   reg = <0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <9600>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   cdns,read-delay = <5>;
+   cdns,tshsl-ns = <500>;
+   cdns,tsd2d-ns = <500>;
+   cdns,tchsh-ns = <119>;
+   cdns,tslch-ns = <119>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "QSPI.u-boot";
+   reg = <0x 0x0010>;
+   };
+   partition@10 {
+   label = "QSPI.u-boot-env";
+   reg = <0x0010 0x0004>;
+   };
+   partition@14 {
+   label = "QSPI.skern";
+   reg = <0x0014 0x004>;
+   };
+   partition@18 {
+   label = "QSPI.sci-firmware";
+   reg = <0x0018 0x004>;
+   };
+   partition@1c {
+   label = "QSPI.kernel";
+   reg = <0x001c 0x080>;
+   };
+   partition@9c {
+   label = "QSPI.u-boot-spl-os";
+   reg = <0x009c 0x004>;
+   };
+   partition@a0 {
+   label = "QSPI.file-system";
+   reg = <0x00a0 0x160>;
+   };
+   };
+   };
+};
-- 
2.13.3



[PATCH 7/7] ARM: configs: keystone: Enable Cadence QSPI driver

2017-07-31 Thread Vignesh R
66AK2G SoC has a Cadence QSPI IP. Therefore, enable cadence-quadspi
driver as part of keystone_defconfig. Since, QSPI flash can be used to
for root filesystem, built it into the kernel instead of module.

Signed-off-by: Vignesh R 
---
 arch/arm/configs/keystone_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index d47ea43d097e..4c8abf3c1ab1 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -124,6 +124,7 @@ CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_CADENCE_QUADSPI=y
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_SRAM=y
-- 
2.13.3



[PATCH 6/7] ARM: dts: keystone-k2g-ice: Add QSPI node

2017-07-31 Thread Vignesh R
66AK2G ICE board has a s25fl256s1 flash connected to QSPI CS0. Add
pinmux and DT entries for the same.

Signed-off-by: Vignesh R 
---
 arch/arm/boot/dts/keystone-k2g-ice.dts | 69 ++
 1 file changed, 69 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-ice.dts 
b/arch/arm/boot/dts/keystone-k2g-ice.dts
index d820d37b5148..075c3a605c8b 100644
--- a/arch/arm/boot/dts/keystone-k2g-ice.dts
+++ b/arch/arm/boot/dts/keystone-k2g-ice.dts
@@ -26,6 +26,18 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart0_txd.uart0_txd */
>;
};
+
+   qspi_pins: pinmux_qspi_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x1204) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_clk.qspi_clk */
+   K2G_CORE_IOPAD(0x1208) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_rclk.qspi_rclk */
+   K2G_CORE_IOPAD(0x120c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d0.qspi_d0 */
+   K2G_CORE_IOPAD(0x1210) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d1.qspi_d1 */
+   K2G_CORE_IOPAD(0x1214) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d2.qspi_d2 */
+   K2G_CORE_IOPAD(0x1218) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_d3.qspi_d3 */
+   K2G_CORE_IOPAD(0x121c) (BUFFER_CLASS_B | PULL_DISABLE | 
MUX_MODE0) /* qspi_csn0.qspi_csn0 */
+   >;
+   };
 };
 
  {
@@ -33,3 +45,60 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   cdns,rclk-en;
+   status = "okay";
+
+   flash0: m25p80@0 {
+   compatible = "s25fl256s1", "jedec,spi-nor";
+   reg = <0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <9600>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   cdns,read-delay = <5>;
+   cdns,tshsl-ns = <500>;
+   cdns,tsd2d-ns = <500>;
+   cdns,tchsh-ns = <119>;
+   cdns,tslch-ns = <119>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "QSPI.u-boot";
+   reg = <0x 0x0010>;
+   };
+   partition@10 {
+   label = "QSPI.u-boot-env";
+   reg = <0x0010 0x0004>;
+   };
+   partition@14 {
+   label = "QSPI.skern";
+   reg = <0x0014 0x004>;
+   };
+   partition@18 {
+   label = "QSPI.sci-firmware";
+   reg = <0x0018 0x004>;
+   };
+   partition@1c {
+   label = "QSPI.kernel";
+   reg = <0x001c 0x080>;
+   };
+   partition@9c {
+   label = "QSPI.u-boot-spl-os";
+   reg = <0x009c 0x004>;
+   };
+   partition@a0 {
+   label = "QSPI.file-system";
+   reg = <0x00a0 0x160>;
+   };
+   };
+   };
+};
-- 
2.13.3



[PATCH 7/7] ARM: configs: keystone: Enable Cadence QSPI driver

2017-07-31 Thread Vignesh R
66AK2G SoC has a Cadence QSPI IP. Therefore, enable cadence-quadspi
driver as part of keystone_defconfig. Since, QSPI flash can be used to
for root filesystem, built it into the kernel instead of module.

Signed-off-by: Vignesh R 
---
 arch/arm/configs/keystone_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index d47ea43d097e..4c8abf3c1ab1 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -124,6 +124,7 @@ CONFIG_MTD_M25P80=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_DAVINCI=y
 CONFIG_MTD_SPI_NOR=y
+CONFIG_SPI_CADENCE_QUADSPI=y
 CONFIG_MTD_UBI=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_SRAM=y
-- 
2.13.3



[PATCH 2/6] dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller

2017-07-31 Thread Lokesh Vutla
Update the ti,omap-hsmmc.txt to include information about
66AK2G specific mmc controller. Also cleanup the entries
under optional properties to look a bit nicer.

Signed-off-by: Lokesh Vutla 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  | 52 +++---
 1 file changed, 37 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0e026c151c1c..016741402e37 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -1,33 +1,55 @@
-* TI Highspeed MMC host controller for OMAP
+* TI Highspeed MMC host controller for OMAP and 66AK2G family.
 
-The Highspeed MMC Host Controller on TI OMAP family
+The Highspeed MMC Host Controller on TI OMAP and 66AK2G family
 provides an interface for MMC, SD, and SDIO types of memory cards.
 
 This file documents differences between the core properties described
 by mmc.txt and the properties used by the omap_hsmmc driver.
 
 Required properties:
+
 - compatible:
  Should be "ti,omap2-hsmmc", for OMAP2 controllers
  Should be "ti,omap3-hsmmc", for OMAP3 controllers
  Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
  Should be "ti,omap4-hsmmc", for OMAP4 controllers
  Should be "ti,am33xx-hsmmc", for AM335x controllers
-- ti,hwmods: Must be "mmc", n is controller instance starting 1
+ Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers.
+
+SoC specific required properties:
+-
+The following are mandatory properties for OMAPs, AM33xx and AM43xx SoCs only:
+- ti,hwmods: Must be "mmc", n is controller instance starting 1.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+   and an args specifier containing the MMC device id
+   value. This property is as per the binding,
+   Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+- clocks:  Must contain an entry for each entry in clock-names. Should
+   be defined as per the he appropriate clock bindings consumer
+   usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+- clock-names: Shall be "fck" for the functional clock,
+   and "mmchsdb_fck" for the debounce clock.
+
 
 Optional properties:
-ti,dual-volt: boolean, supports dual voltage cards
--supply: phandle to the regulator device tree node
-"supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc
-ti,non-removable: non-removable slot (like eMMC)
-ti,needs-special-reset: Requires a special softreset sequence
-ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
-dmas: List of DMA specifiers with the controller specific format
-as described in the generic DMA client binding. A tx and rx
-specifier is required.
-dma-names: List of DMA request names. These strings correspond
-1:1 with the DMA specifiers listed in dmas. The string naming is
-to be "rx" and "tx" for RX and TX DMA requests, respectively.
+
+- ti,dual-volt:boolean, supports dual voltage cards
+- -supply:phandle to the regulator device tree node
+ "supply-name" examples are "vmmc",
+ "vmmc_aux"(deprecated)/"vqmmc" etc
+- ti,non-removable:non-removable slot (like eMMC)
+- ti,needs-special-reset:  Requires a special softreset sequence
+- ti,needs-special-hs-handling:HSMMC IP needs special setting
+ for handling High Speed
+- dmas:List of DMA specifiers with the controller 
specific
+   format as described in the generic DMA client
+   binding. A tx and rx specifier is required.
+- dma-names:   List of DMA request names. These strings correspond
+   1:1 with the DMA specifiers listed in dmas.
+   The string naming is to be "rx" and "tx" for
+   RX and TX DMA requests, respectively.
 
 Examples:
 
-- 
2.13.0



[PATCH 2/6] dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller

2017-07-31 Thread Lokesh Vutla
Update the ti,omap-hsmmc.txt to include information about
66AK2G specific mmc controller. Also cleanup the entries
under optional properties to look a bit nicer.

Signed-off-by: Lokesh Vutla 
---
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  | 52 +++---
 1 file changed, 37 insertions(+), 15 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 0e026c151c1c..016741402e37 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -1,33 +1,55 @@
-* TI Highspeed MMC host controller for OMAP
+* TI Highspeed MMC host controller for OMAP and 66AK2G family.
 
-The Highspeed MMC Host Controller on TI OMAP family
+The Highspeed MMC Host Controller on TI OMAP and 66AK2G family
 provides an interface for MMC, SD, and SDIO types of memory cards.
 
 This file documents differences between the core properties described
 by mmc.txt and the properties used by the omap_hsmmc driver.
 
 Required properties:
+
 - compatible:
  Should be "ti,omap2-hsmmc", for OMAP2 controllers
  Should be "ti,omap3-hsmmc", for OMAP3 controllers
  Should be "ti,omap3-pre-es3-hsmmc" for OMAP3 controllers pre ES3.0
  Should be "ti,omap4-hsmmc", for OMAP4 controllers
  Should be "ti,am33xx-hsmmc", for AM335x controllers
-- ti,hwmods: Must be "mmc", n is controller instance starting 1
+ Should be "ti,k2g-hsmmc", "ti,omap4-hsmmc" for 66AK2G controllers.
+
+SoC specific required properties:
+-
+The following are mandatory properties for OMAPs, AM33xx and AM43xx SoCs only:
+- ti,hwmods: Must be "mmc", n is controller instance starting 1.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+   and an args specifier containing the MMC device id
+   value. This property is as per the binding,
+   Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+- clocks:  Must contain an entry for each entry in clock-names. Should
+   be defined as per the he appropriate clock bindings consumer
+   usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt
+- clock-names: Shall be "fck" for the functional clock,
+   and "mmchsdb_fck" for the debounce clock.
+
 
 Optional properties:
-ti,dual-volt: boolean, supports dual voltage cards
--supply: phandle to the regulator device tree node
-"supply-name" examples are "vmmc", "vmmc_aux"(deprecated)/"vqmmc" etc
-ti,non-removable: non-removable slot (like eMMC)
-ti,needs-special-reset: Requires a special softreset sequence
-ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High 
Speed
-dmas: List of DMA specifiers with the controller specific format
-as described in the generic DMA client binding. A tx and rx
-specifier is required.
-dma-names: List of DMA request names. These strings correspond
-1:1 with the DMA specifiers listed in dmas. The string naming is
-to be "rx" and "tx" for RX and TX DMA requests, respectively.
+
+- ti,dual-volt:boolean, supports dual voltage cards
+- -supply:phandle to the regulator device tree node
+ "supply-name" examples are "vmmc",
+ "vmmc_aux"(deprecated)/"vqmmc" etc
+- ti,non-removable:non-removable slot (like eMMC)
+- ti,needs-special-reset:  Requires a special softreset sequence
+- ti,needs-special-hs-handling:HSMMC IP needs special setting
+ for handling High Speed
+- dmas:List of DMA specifiers with the controller 
specific
+   format as described in the generic DMA client
+   binding. A tx and rx specifier is required.
+- dma-names:   List of DMA request names. These strings correspond
+   1:1 with the DMA specifiers listed in dmas.
+   The string naming is to be "rx" and "tx" for
+   RX and TX DMA requests, respectively.
 
 Examples:
 
-- 
2.13.0



[PATCH 6/6] ARM: configs: keystone: Enable MMC and regulators

2017-07-31 Thread Lokesh Vutla
Enable the TI OMAP HSMMC and fixed regulator support
for keystone platforms.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/configs/keystone_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index d47ea43d097e..3397e91a5db1 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -156,6 +156,8 @@ CONFIG_POWER_RESET_KEYSTONE=y
 # CONFIG_HWMON is not set
 CONFIG_WATCHDOG=y
 CONFIG_DAVINCI_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
@@ -164,6 +166,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=y
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_KEYSTONE_USB_PHY=y
+CONFIG_MMC=y
+CONFIG_MMC_OMAP_HS=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
-- 
2.13.0



[PATCH 6/6] ARM: configs: keystone: Enable MMC and regulators

2017-07-31 Thread Lokesh Vutla
Enable the TI OMAP HSMMC and fixed regulator support
for keystone platforms.

Signed-off-by: Lokesh Vutla 
---
 arch/arm/configs/keystone_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/configs/keystone_defconfig 
b/arch/arm/configs/keystone_defconfig
index d47ea43d097e..3397e91a5db1 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -156,6 +156,8 @@ CONFIG_POWER_RESET_KEYSTONE=y
 # CONFIG_HWMON is not set
 CONFIG_WATCHDOG=y
 CONFIG_DAVINCI_WATCHDOG=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
@@ -164,6 +166,8 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_DWC3=y
 CONFIG_NOP_USB_XCEIV=y
 CONFIG_KEYSTONE_USB_PHY=y
+CONFIG_MMC=y
+CONFIG_MMC_OMAP_HS=y
 CONFIG_NEW_LEDS=y
 CONFIG_LEDS_CLASS=y
 CONFIG_LEDS_GPIO=y
-- 
2.13.0



[PATCH 0/6] ARM: dts: keystone-k2g: Add support for eDMA and MMC

2017-07-31 Thread Lokesh Vutla
This series adds DT nodes and documentation for eDMA and MMC IPs on
Keystone 66AK2G SoC. Also enable the required configs in keystone_defconfig.

This series depends on Keerthy's gpio node patches on 66AK2G:
https://patchwork.kernel.org/patch/9864311/

Tested:
k2g-evm with rootfs on mmc: http://pastebin.ubuntu.com/25217978/

Lokesh Vutla (5):
  dt-bindings: ti,edma: Add 66AK2G specific information
  dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller
  ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes
  ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1
  ARM: configs: keystone: Enable MMC and regulators

Peter Ujfalusi (1):
  ARM: dts: keystone-k2g: Add eDMA nodes

 Documentation/devicetree/bindings/dma/ti-edma.txt  | 95 +++--
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  | 52 
 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 
 arch/arm/boot/dts/keystone-k2g.dtsi| 98 ++
 arch/arm/configs/keystone_defconfig|  4 +
 5 files changed, 282 insertions(+), 20 deletions(-)

-- 
2.13.0



[PATCH 5/6] ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1

2017-07-31 Thread Lokesh Vutla
Enable MMC0 which is used for micro SD and MMC1 which is used for the on
board EMMC.

Signed-off-by: Lokesh Vutla 
[fcoo...@ti.com: add mmc1, bufferclass and pullup/pulldown settings]
Signed-off-by: Franklin S Cooper Jr 
[nsek...@ti.com: add card detect GPIO support]
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 ++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts 
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 61883cb969d2..f47f95d8bf1c 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -25,6 +25,13 @@
reg = <0x0008 0x 0x 0x8000>;
};
 
+   vcc3v3_dcin_reg: fixedregulator-vcc3v3-dcin {
+   compatible = "regulator-fixed";
+   regulator-name = "mmc0_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
 };
 
 _pinctrl {
@@ -34,6 +41,33 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart0_txd.uart0_txd */
>;
};
+
+   mmc0_pins: pinmux_mmc0_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x1300) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat3.mmc0_dat3 */
+   K2G_CORE_IOPAD(0x1304) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat2.mmc0_dat2 */
+   K2G_CORE_IOPAD(0x1308) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat1.mmc0_dat1 */
+   K2G_CORE_IOPAD(0x130c) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat0.mmc0_dat0 */
+   K2G_CORE_IOPAD(0x1310) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_clk.mmc0_clk */
+   K2G_CORE_IOPAD(0x1314) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_cmd.mmc0_cmd */
+   K2G_CORE_IOPAD(0x12ec) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE3)/* mmc0_sdcd.gpio1_12 */
+   >;
+   };
+
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x10ec) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat7.mmc1_dat7 */
+   K2G_CORE_IOPAD(0x10f0) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat6.mmc1_dat6 */
+   K2G_CORE_IOPAD(0x10f4) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat5.mmc1_dat5 */
+   K2G_CORE_IOPAD(0x10f8) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat4.mmc1_dat4 */
+   K2G_CORE_IOPAD(0x10fc) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat3.mmc1_dat3 */
+   K2G_CORE_IOPAD(0x1100) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat2.mmc1_dat2 */
+   K2G_CORE_IOPAD(0x1104) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat1.mmc1_dat1 */
+   K2G_CORE_IOPAD(0x1108) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat0.mmc1_dat0 */
+   K2G_CORE_IOPAD(0x110c) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_clk.mmc1_clk */
+   K2G_CORE_IOPAD(0x1110) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_cmd.mmc1_cmd */
+   >;
+   };
 };
 
  {
@@ -41,3 +75,22 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcin_reg>;
+   cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcin_reg>; /* VCC3V3_EMMC is connected to 
VCC3V3_DCIN */
+   status = "okay";
+};
-- 
2.13.0



[PATCH 0/6] ARM: dts: keystone-k2g: Add support for eDMA and MMC

2017-07-31 Thread Lokesh Vutla
This series adds DT nodes and documentation for eDMA and MMC IPs on
Keystone 66AK2G SoC. Also enable the required configs in keystone_defconfig.

This series depends on Keerthy's gpio node patches on 66AK2G:
https://patchwork.kernel.org/patch/9864311/

Tested:
k2g-evm with rootfs on mmc: http://pastebin.ubuntu.com/25217978/

Lokesh Vutla (5):
  dt-bindings: ti,edma: Add 66AK2G specific information
  dt-bindings: ti,omap-hsmmc: Add 66AK2G mmc controller
  ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes
  ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1
  ARM: configs: keystone: Enable MMC and regulators

Peter Ujfalusi (1):
  ARM: dts: keystone-k2g: Add eDMA nodes

 Documentation/devicetree/bindings/dma/ti-edma.txt  | 95 +++--
 .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  | 52 
 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 
 arch/arm/boot/dts/keystone-k2g.dtsi| 98 ++
 arch/arm/configs/keystone_defconfig|  4 +
 5 files changed, 282 insertions(+), 20 deletions(-)

-- 
2.13.0



[PATCH 5/6] ARM: dts: keystone-k2g-evm: Enable MMC0 and MMC1

2017-07-31 Thread Lokesh Vutla
Enable MMC0 which is used for micro SD and MMC1 which is used for the on
board EMMC.

Signed-off-by: Lokesh Vutla 
[fcoo...@ti.com: add mmc1, bufferclass and pullup/pulldown settings]
Signed-off-by: Franklin S Cooper Jr 
[nsek...@ti.com: add card detect GPIO support]
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/keystone-k2g-evm.dts | 53 ++
 1 file changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g-evm.dts 
b/arch/arm/boot/dts/keystone-k2g-evm.dts
index 61883cb969d2..f47f95d8bf1c 100644
--- a/arch/arm/boot/dts/keystone-k2g-evm.dts
+++ b/arch/arm/boot/dts/keystone-k2g-evm.dts
@@ -25,6 +25,13 @@
reg = <0x0008 0x 0x 0x8000>;
};
 
+   vcc3v3_dcin_reg: fixedregulator-vcc3v3-dcin {
+   compatible = "regulator-fixed";
+   regulator-name = "mmc0_fixed";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   };
 };
 
 _pinctrl {
@@ -34,6 +41,33 @@
K2G_CORE_IOPAD(0x11d0) (BUFFER_CLASS_B | PIN_PULLDOWN | 
MUX_MODE0)  /* uart0_txd.uart0_txd */
>;
};
+
+   mmc0_pins: pinmux_mmc0_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x1300) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat3.mmc0_dat3 */
+   K2G_CORE_IOPAD(0x1304) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat2.mmc0_dat2 */
+   K2G_CORE_IOPAD(0x1308) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat1.mmc0_dat1 */
+   K2G_CORE_IOPAD(0x130c) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_dat0.mmc0_dat0 */
+   K2G_CORE_IOPAD(0x1310) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_clk.mmc0_clk */
+   K2G_CORE_IOPAD(0x1314) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE2)/* mmc0_cmd.mmc0_cmd */
+   K2G_CORE_IOPAD(0x12ec) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE3)/* mmc0_sdcd.gpio1_12 */
+   >;
+   };
+
+   mmc1_pins: pinmux_mmc1_pins {
+   pinctrl-single,pins = <
+   K2G_CORE_IOPAD(0x10ec) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat7.mmc1_dat7 */
+   K2G_CORE_IOPAD(0x10f0) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat6.mmc1_dat6 */
+   K2G_CORE_IOPAD(0x10f4) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat5.mmc1_dat5 */
+   K2G_CORE_IOPAD(0x10f8) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat4.mmc1_dat4 */
+   K2G_CORE_IOPAD(0x10fc) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat3.mmc1_dat3 */
+   K2G_CORE_IOPAD(0x1100) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat2.mmc1_dat2 */
+   K2G_CORE_IOPAD(0x1104) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat1.mmc1_dat1 */
+   K2G_CORE_IOPAD(0x1108) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_dat0.mmc1_dat0 */
+   K2G_CORE_IOPAD(0x110c) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_clk.mmc1_clk */
+   K2G_CORE_IOPAD(0x1110) (BUFFER_CLASS_B | PIN_PULLUP | 
MUX_MODE0)/* mmc1_cmd.mmc1_cmd */
+   >;
+   };
 };
 
  {
@@ -41,3 +75,22 @@
pinctrl-0 = <_pins>;
status = "okay";
 };
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcin_reg>;
+   cd-gpios = < 12 GPIO_ACTIVE_LOW>;
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins>;
+   vmmc-supply = <_dcin_reg>; /* VCC3V3_EMMC is connected to 
VCC3V3_DCIN */
+   status = "okay";
+};
-- 
2.13.0



[PATCH 4/6] ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes

2017-07-31 Thread Lokesh Vutla
Add device tree nodes for MMC0 and MMC1 pesent
on 66AK2G device.

Signed-off-by: Lokesh Vutla 
[nsek...@ti.com: fix clock-names for mmc1 node]
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index 3f1fd3df76d5..9ecea2c27d76 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -276,5 +276,37 @@
reg =   <0x027b8000 0x400>;
power-domains = <_pds 0x4f>;
};
+
+   mmc0: mmc@2300 {
+   compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+   reg = <0x2300 0x400>;
+   interrupts = ;
+   dmas = < 24 0>, < 25 0>;
+   dma-names = "tx", "rx";
+   bus-width = <4>;
+   ti,needs-special-reset;
+   no-1-8-v;
+   max-frequency = <9600>;
+   power-domains = <_pds 0xb>;
+   clocks = <_clks 0xb 1>, <_clks 0xb 2>;
+   clock-names = "fck", "mmchsdb_fck";
+   status = "disabled";
+   };
+
+   mmc1: mmc@2310 {
+   compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+   reg = <0x2310 0x400>;
+   interrupts = ;
+   dmas = < 26 0>, < 27 0>;
+   dma-names = "tx", "rx";
+   bus-width = <8>;
+   ti,needs-special-reset;
+   ti,non-removable;
+   max-frequency = <9600>;
+   power-domains = <_pds 0xc>;
+   clocks = <_clks 0xc 1>, <_clks 0xc 2>;
+   clock-names = "fck", "mmchsdb_fck";
+   status = "disabled";
+   };
};
 };
-- 
2.13.0



[PATCH 4/6] ARM: dts: keystone-k2g: add MMC0 and MMC1 nodes

2017-07-31 Thread Lokesh Vutla
Add device tree nodes for MMC0 and MMC1 pesent
on 66AK2G device.

Signed-off-by: Lokesh Vutla 
[nsek...@ti.com: fix clock-names for mmc1 node]
Signed-off-by: Sekhar Nori 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 32 
 1 file changed, 32 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index 3f1fd3df76d5..9ecea2c27d76 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -276,5 +276,37 @@
reg =   <0x027b8000 0x400>;
power-domains = <_pds 0x4f>;
};
+
+   mmc0: mmc@2300 {
+   compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+   reg = <0x2300 0x400>;
+   interrupts = ;
+   dmas = < 24 0>, < 25 0>;
+   dma-names = "tx", "rx";
+   bus-width = <4>;
+   ti,needs-special-reset;
+   no-1-8-v;
+   max-frequency = <9600>;
+   power-domains = <_pds 0xb>;
+   clocks = <_clks 0xb 1>, <_clks 0xb 2>;
+   clock-names = "fck", "mmchsdb_fck";
+   status = "disabled";
+   };
+
+   mmc1: mmc@2310 {
+   compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+   reg = <0x2310 0x400>;
+   interrupts = ;
+   dmas = < 26 0>, < 27 0>;
+   dma-names = "tx", "rx";
+   bus-width = <8>;
+   ti,needs-special-reset;
+   ti,non-removable;
+   max-frequency = <9600>;
+   power-domains = <_pds 0xc>;
+   clocks = <_clks 0xc 1>, <_clks 0xc 2>;
+   clock-names = "fck", "mmchsdb_fck";
+   status = "disabled";
+   };
};
 };
-- 
2.13.0



[PATCH 3/6] ARM: dts: keystone-k2g: Add eDMA nodes

2017-07-31 Thread Lokesh Vutla
From: Peter Ujfalusi 

Add nodes for eDMA0 and eDMA1.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Dave Gerlach 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 66 +
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index f9ff29972295..3f1fd3df76d5 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -210,5 +210,71 @@
clocks = <_clks 0x001c 0x0>;
clock-names = "gpio";
};
+
+   edma0: edma@0270 {
+   compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+   reg =   <0x0270 0x8000>;
+   reg-names = "edma3_cc";
+   interrupts = ,
+   ,
+   ;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+
+   ti,edma-memcpy-channels = <32 33 34 35>;
+
+   power-domains = <_pds 0x3f>;
+   };
+
+   edma0_tptc0: tptc@0276 {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x0276 0x400>;
+   power-domains = <_pds 0x3f>;
+   };
+
+   edma0_tptc1: tptc@02768000 {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x02768000 0x400>;
+   power-domains = <_pds 0x3f>;
+   };
+
+   edma1: edma@02728000 {
+   compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+   reg =   <0x02728000 0x8000>;
+   reg-names = "edma3_cc";
+   interrupts = ,
+   ,
+   ;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+
+   /*
+* memcpy is disabled, can be enabled with:
+* ti,edma-memcpy-channels = <12 13 14 15>;
+* for example.
+*/
+
+   power-domains = <_pds 0x4f>;
+   };
+
+   edma1_tptc0: tptc@027b {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b 0x400>;
+   power-domains = <_pds 0x4f>;
+   };
+
+   edma1_tptc1: tptc@027b8000 {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b8000 0x400>;
+   power-domains = <_pds 0x4f>;
+   };
};
 };
-- 
2.13.0



[PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

2017-07-31 Thread Lokesh Vutla
Update ti,edma binding documentation to reflect 66AK2G specific
properties.

Signed-off-by: Lokesh Vutla 
---
 Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +--
 1 file changed, 90 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 18090e7226b4..05fe2931d025 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -9,7 +9,12 @@ execute the actual DMA tansfer.
 eDMA3 Channel Controller
 
 Required properties:
-- compatible:  "ti,edma3-tpcc" for the channel controller(s)
+
+- compatible:  Should be:
+   - "ti,edma3-tpcc" for the channel controller(s) on OMAP,
+ AM33xx and AM43xx SoCs.
+   - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the
+ channel controller(s) on 66AK2G.
 - #dma-cells:  Should be set to <2>. The first number is the DMA request
number and the second is the TC the channel is serviced on.
 - reg: Memory map of eDMA CC
@@ -19,8 +24,19 @@ Required properties:
 - ti,tptcs:List of TPTCs associated with the eDMA in the following form:
<_phandle TC_priority_number>. The highest priority is 0.
 
+SoC-specific Required properties:
+
+The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only:
+- ti,hwmods:   Name of the hwmods associated to the eDMA CC.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+   and an args specifier containing the device id
+   value. This property is as per the binding,
+   Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+
 Optional properties:
-- ti,hwmods:   Name of the hwmods associated to the eDMA CC
+---
 - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, 
iow
these channels will be SW triggered channels. See example.
 - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
@@ -31,17 +47,34 @@ Optional properties:
 eDMA3 Transfer Controller
 
 Required properties:
-- compatible:  "ti,edma3-tptc" for the transfer controller(s)
+
+- compatible:  Should be:
+   - "ti,edma3-tptc" for the transfer controller(s) on OMAP,
+ AM33xx and AM43xx SoCs.
+   - "ti,k2g-edma3-tptc", "ti,edma3-tptc" for the
+ transfer controller(s) on 66AK2G.
 - reg: Memory map of eDMA TC
 - interrupts:  Interrupt number for TCerrint.
 
+SoC-specific Required properties:
+
+The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only:
+- ti,hwmods:   Name of the hwmods associated to the eDMA TC.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+   and an args specifier containing the device id
+   value. This property is as per the binding,
+   Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+
 Optional properties:
-- ti,hwmods:   Name of the hwmods associated to the given eDMA TC
+---
 - interrupt-names: "edma3_tcerrint"
 
 --
-Example:
+Examples:
 
+1.
 edma: edma@4900 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
@@ -109,6 +142,58 @@ mcasp0: mcasp@48038000 {
dma-names = "tx", "rx";
 };
 
+2.
+edma1: edma@02728000 {
+   compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+   reg =   <0x02728000 0x8000>;
+   reg-names = "edma3_cc";
+   interrupts = ,
+   ,
+   ;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+
+   /*
+* memcpy is disabled, can be enabled with:
+* ti,edma-memcpy-channels = <12 13 14 15>;
+* for example.
+*/
+
+   power-domains = <_pds 0x4f>;
+};
+
+edma1_tptc0: tptc@027b {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b 0x400>;
+   power-domains = <_pds 0x4f>;
+};
+
+edma1_tptc1: tptc@027b8000 {
+   compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b8000 0x400>;
+   power-domains = <_pds 0x4f>;
+};
+
+mmc0: mmc@2300 {
+   compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+   reg = <0x2300 0x400>;
+   interrupts = ;
+   dmas = < 24 0>, < 25 0>;
+   dma-names = "tx", "rx";
+   bus-width = <4>;
+   ti,needs-special-reset;
+   no-1-8-v;
+   max-frequency = 

[PATCH 3/6] ARM: dts: keystone-k2g: Add eDMA nodes

2017-07-31 Thread Lokesh Vutla
From: Peter Ujfalusi 

Add nodes for eDMA0 and eDMA1.

Signed-off-by: Peter Ujfalusi 
Signed-off-by: Dave Gerlach 
Signed-off-by: Lokesh Vutla 
---
 arch/arm/boot/dts/keystone-k2g.dtsi | 66 +
 1 file changed, 66 insertions(+)

diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi 
b/arch/arm/boot/dts/keystone-k2g.dtsi
index f9ff29972295..3f1fd3df76d5 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -210,5 +210,71 @@
clocks = <_clks 0x001c 0x0>;
clock-names = "gpio";
};
+
+   edma0: edma@0270 {
+   compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+   reg =   <0x0270 0x8000>;
+   reg-names = "edma3_cc";
+   interrupts = ,
+   ,
+   ;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+
+   ti,edma-memcpy-channels = <32 33 34 35>;
+
+   power-domains = <_pds 0x3f>;
+   };
+
+   edma0_tptc0: tptc@0276 {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x0276 0x400>;
+   power-domains = <_pds 0x3f>;
+   };
+
+   edma0_tptc1: tptc@02768000 {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x02768000 0x400>;
+   power-domains = <_pds 0x3f>;
+   };
+
+   edma1: edma@02728000 {
+   compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+   reg =   <0x02728000 0x8000>;
+   reg-names = "edma3_cc";
+   interrupts = ,
+   ,
+   ;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+
+   /*
+* memcpy is disabled, can be enabled with:
+* ti,edma-memcpy-channels = <12 13 14 15>;
+* for example.
+*/
+
+   power-domains = <_pds 0x4f>;
+   };
+
+   edma1_tptc0: tptc@027b {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b 0x400>;
+   power-domains = <_pds 0x4f>;
+   };
+
+   edma1_tptc1: tptc@027b8000 {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b8000 0x400>;
+   power-domains = <_pds 0x4f>;
+   };
};
 };
-- 
2.13.0



[PATCH 1/6] dt-bindings: ti,edma: Add 66AK2G specific information

2017-07-31 Thread Lokesh Vutla
Update ti,edma binding documentation to reflect 66AK2G specific
properties.

Signed-off-by: Lokesh Vutla 
---
 Documentation/devicetree/bindings/dma/ti-edma.txt | 95 +--
 1 file changed, 90 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt 
b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 18090e7226b4..05fe2931d025 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -9,7 +9,12 @@ execute the actual DMA tansfer.
 eDMA3 Channel Controller
 
 Required properties:
-- compatible:  "ti,edma3-tpcc" for the channel controller(s)
+
+- compatible:  Should be:
+   - "ti,edma3-tpcc" for the channel controller(s) on OMAP,
+ AM33xx and AM43xx SoCs.
+   - "ti,k2g-edma3-tpcc", "ti,edma3-tpcc" for the
+ channel controller(s) on 66AK2G.
 - #dma-cells:  Should be set to <2>. The first number is the DMA request
number and the second is the TC the channel is serviced on.
 - reg: Memory map of eDMA CC
@@ -19,8 +24,19 @@ Required properties:
 - ti,tptcs:List of TPTCs associated with the eDMA in the following form:
<_phandle TC_priority_number>. The highest priority is 0.
 
+SoC-specific Required properties:
+
+The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only:
+- ti,hwmods:   Name of the hwmods associated to the eDMA CC.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+   and an args specifier containing the device id
+   value. This property is as per the binding,
+   Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+
 Optional properties:
-- ti,hwmods:   Name of the hwmods associated to the eDMA CC
+---
 - ti,edma-memcpy-channels: List of channels allocated to be used for memcpy, 
iow
these channels will be SW triggered channels. See example.
 - ti,edma-reserved-slot-ranges: PaRAM slot ranges which should not be used by
@@ -31,17 +47,34 @@ Optional properties:
 eDMA3 Transfer Controller
 
 Required properties:
-- compatible:  "ti,edma3-tptc" for the transfer controller(s)
+
+- compatible:  Should be:
+   - "ti,edma3-tptc" for the transfer controller(s) on OMAP,
+ AM33xx and AM43xx SoCs.
+   - "ti,k2g-edma3-tptc", "ti,edma3-tptc" for the
+ transfer controller(s) on 66AK2G.
 - reg: Memory map of eDMA TC
 - interrupts:  Interrupt number for TCerrint.
 
+SoC-specific Required properties:
+
+The following are mandatory properties for OMAP, AM33xx and AM43xx SoCs only:
+- ti,hwmods:   Name of the hwmods associated to the eDMA TC.
+
+The following are mandatory properties for 66AK2G SoCs only:
+- power-domains:Should contain a phandle to a PM domain provider node
+   and an args specifier containing the device id
+   value. This property is as per the binding,
+   Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
+
 Optional properties:
-- ti,hwmods:   Name of the hwmods associated to the given eDMA TC
+---
 - interrupt-names: "edma3_tcerrint"
 
 --
-Example:
+Examples:
 
+1.
 edma: edma@4900 {
compatible = "ti,edma3-tpcc";
ti,hwmods = "tpcc";
@@ -109,6 +142,58 @@ mcasp0: mcasp@48038000 {
dma-names = "tx", "rx";
 };
 
+2.
+edma1: edma@02728000 {
+   compatible = "ti,k2g-edma3-tpcc", "ti,edma3-tpcc";
+   reg =   <0x02728000 0x8000>;
+   reg-names = "edma3_cc";
+   interrupts = ,
+   ,
+   ;
+   interrupt-names = "edma3_ccint", "emda3_mperr",
+ "edma3_ccerrint";
+   dma-requests = <64>;
+   #dma-cells = <2>;
+
+   ti,tptcs = <_tptc0 7>, <_tptc1 0>;
+
+   /*
+* memcpy is disabled, can be enabled with:
+* ti,edma-memcpy-channels = <12 13 14 15>;
+* for example.
+*/
+
+   power-domains = <_pds 0x4f>;
+};
+
+edma1_tptc0: tptc@027b {
+   compatible = "ti,k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b 0x400>;
+   power-domains = <_pds 0x4f>;
+};
+
+edma1_tptc1: tptc@027b8000 {
+   compatible = "ti, k2g-edma3-tptc", "ti,edma3-tptc";
+   reg =   <0x027b8000 0x400>;
+   power-domains = <_pds 0x4f>;
+};
+
+mmc0: mmc@2300 {
+   compatible = "ti,k2g-hsmmc", "ti,omap4-hsmmc";
+   reg = <0x2300 0x400>;
+   interrupts = ;
+   dmas = < 24 0>, < 25 0>;
+   dma-names = "tx", "rx";
+   bus-width = <4>;
+   ti,needs-special-reset;
+   no-1-8-v;
+   max-frequency = <9600>;
+   

[PATCH v2] Coccinelle: Script to remove unnecessary static on local variables

2017-07-31 Thread Gustavo A. R. Silva
Coccinelle script to remove unnecessary static on local variables when
the variables are not used before update.

Signed-off-by: Gustavo A. R. Silva 
---
Changes in v2:
 Update header and Copyright note.

 scripts/coccinelle/misc/static_unnecessary.cocci | 96 
 1 file changed, 96 insertions(+)
 create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci

diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci 
b/scripts/coccinelle/misc/static_unnecessary.cocci
new file mode 100644
index 000..2b10586
--- /dev/null
+++ b/scripts/coccinelle/misc/static_unnecessary.cocci
@@ -0,0 +1,96 @@
+/// Drop static on local variable when the variable is not used before update.
+//#
+//# Removing unnecessary static on local variables reduces the code
+//# size and increases maintainability.
+//#
+//# On the other hand, even though it is rare, be aware that if a
+//# large object is initialized all at once, it might not be wise
+//# to remove the static because that would increase the risk of a
+//# stack overflow.
+///
+// Confidence: Moderate
+// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2.
+// Work supported by a grant from
+// The Linux Foundation's Core Infrastructure Initiative.
+// URL: https://www.coreinfrastructure.org/
+// Options: --no-includes --include-headers
+// Keywords: static
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+// 
+@bad exists@
+position p;
+identifier x;
+expression e;
+type T;
+@@
+
+T x@p;
+... when != x = e
+x = <+...x...+>
+
+@worse exists@
+position p;
+identifier x;
+type T;
+@@
+
+T x@p;
+...
+ 
+
+@modify depends on patch && !context && !org && !report@
+identifier x;
+expression e;
+type T;
+position p != {bad.p,worse.p};
+@@
+
+-static
+ T x@p;
+ ... when != x
+ when strict
+?x = e;
+// 
+
+
+// 
+
+@modify_context depends on !patch && (context || org || report) forall@
+type T;
+identifier x;
+expression e;
+position p != {bad.p,worse.p};
+position j0;
+@@
+
+* static
+ T x@j0@p;
+ ... when != x
+ when strict
+?x = e;
+
+// 
+
+@script:python modify_org depends on org@
+j0 << modify_context.j0;
+@@
+
+msg = "Unnecessary static on local variable."
+coccilib.org.print_todo(j0[0], msg)
+
+// 
+
+@script:python modify_report depends on report@
+j0 << modify_context.j0;
+@@
+
+msg = "Unnecessary static on local variable."
+coccilib.report.print_report(j0[0], msg)
+
-- 
2.5.0



[PATCH v2] Coccinelle: Script to remove unnecessary static on local variables

2017-07-31 Thread Gustavo A. R. Silva
Coccinelle script to remove unnecessary static on local variables when
the variables are not used before update.

Signed-off-by: Gustavo A. R. Silva 
---
Changes in v2:
 Update header and Copyright note.

 scripts/coccinelle/misc/static_unnecessary.cocci | 96 
 1 file changed, 96 insertions(+)
 create mode 100644 scripts/coccinelle/misc/static_unnecessary.cocci

diff --git a/scripts/coccinelle/misc/static_unnecessary.cocci 
b/scripts/coccinelle/misc/static_unnecessary.cocci
new file mode 100644
index 000..2b10586
--- /dev/null
+++ b/scripts/coccinelle/misc/static_unnecessary.cocci
@@ -0,0 +1,96 @@
+/// Drop static on local variable when the variable is not used before update.
+//#
+//# Removing unnecessary static on local variables reduces the code
+//# size and increases maintainability.
+//#
+//# On the other hand, even though it is rare, be aware that if a
+//# large object is initialized all at once, it might not be wise
+//# to remove the static because that would increase the risk of a
+//# stack overflow.
+///
+// Confidence: Moderate
+// Copyright: (C) 2017 Julia Lawall, Inria. GPLv2.
+// URL: http://coccinelle.lip6.fr/
+// Copyright: (C) 2017 Gustavo A. R. Silva. GPLv2.
+// Work supported by a grant from
+// The Linux Foundation's Core Infrastructure Initiative.
+// URL: https://www.coreinfrastructure.org/
+// Options: --no-includes --include-headers
+// Keywords: static
+
+virtual patch
+virtual context
+virtual org
+virtual report
+
+// 
+@bad exists@
+position p;
+identifier x;
+expression e;
+type T;
+@@
+
+T x@p;
+... when != x = e
+x = <+...x...+>
+
+@worse exists@
+position p;
+identifier x;
+type T;
+@@
+
+T x@p;
+...
+ 
+
+@modify depends on patch && !context && !org && !report@
+identifier x;
+expression e;
+type T;
+position p != {bad.p,worse.p};
+@@
+
+-static
+ T x@p;
+ ... when != x
+ when strict
+?x = e;
+// 
+
+
+// 
+
+@modify_context depends on !patch && (context || org || report) forall@
+type T;
+identifier x;
+expression e;
+position p != {bad.p,worse.p};
+position j0;
+@@
+
+* static
+ T x@j0@p;
+ ... when != x
+ when strict
+?x = e;
+
+// 
+
+@script:python modify_org depends on org@
+j0 << modify_context.j0;
+@@
+
+msg = "Unnecessary static on local variable."
+coccilib.org.print_todo(j0[0], msg)
+
+// 
+
+@script:python modify_report depends on report@
+j0 << modify_context.j0;
+@@
+
+msg = "Unnecessary static on local variable."
+coccilib.report.print_report(j0[0], msg)
+
-- 
2.5.0



Re: [PATCH] staging: ks7010: fix styling WARNINGs

2017-07-31 Thread kbuild test robot
Hi Ashish,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc3 next-20170731]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   drivers/staging//ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb':
   drivers/staging//ks7010/ks7010_sdio.c:77:12: error: invalid storage class 
for function 'ks7010_sdio_readb'
   drivers/staging//ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
   drivers/staging//ks7010/ks7010_sdio.c:89:12: error: invalid storage class 
for function 'ks7010_sdio_read'
   drivers/staging//ks7010/ks7010_sdio.c:98:12: error: invalid storage class 
for function 'ks7010_sdio_writeb'
   drivers/staging//ks7010/ks7010_sdio.c:110:12: error: invalid storage class 
for function 'ks7010_sdio_write'
   drivers/staging//ks7010/ks7010_sdio.c:118:13: error: invalid storage class 
for function 'ks_wlan_hw_sleep_doze_request'
   drivers/staging//ks7010/ks7010_sdio.c:144:13: error: invalid storage class 
for function 'ks_wlan_hw_sleep_wakeup_request'
   drivers/staging//ks7010/ks7010_sdio.c:191:13: error: invalid storage class 
for function '_ks_wlan_hw_power_save'
   drivers/staging//ks7010/ks7010_sdio.c:252:12: error: invalid storage class 
for function 'enqueue_txdev'
   drivers/staging//ks7010/ks7010_sdio.c:290:12: error: invalid storage class 
for function 'write_to_device'
   drivers/staging//ks7010/ks7010_sdio.c:320:13: error: invalid storage class 
for function 'tx_device_task'
   drivers/staging//ks7010/ks7010_sdio.c:379:13: error: invalid storage class 
for function 'rx_event_task'
   drivers/staging//ks7010/ks7010_sdio.c:396:13: error: invalid storage class 
for function 'ks_wlan_hw_rx'
   drivers/staging//ks7010/ks7010_sdio.c:452:13: error: invalid storage class 
for function 'ks7010_rw_function'
   drivers/staging//ks7010/ks7010_sdio.c:522:13: error: invalid storage class 
for function 'ks_sdio_interrupt'
   drivers/staging//ks7010/ks7010_sdio.c:593:12: error: invalid storage class 
for function 'trx_device_init'
   drivers/staging//ks7010/ks7010_sdio.c:609:13: error: invalid storage class 
for function 'trx_device_exit'
   drivers/staging//ks7010/ks7010_sdio.c:625:12: error: invalid storage class 
for function 'ks7010_sdio_update_index'
   drivers/staging//ks7010/ks7010_sdio.c:652:12: error: invalid storage class 
for function 'ks7010_sdio_data_compare'
   drivers/staging//ks7010/ks7010_sdio.c:680:12: error: invalid storage class 
for function 'ks7010_upload_firmware'
   drivers/staging//ks7010/ks7010_sdio.c:775:13: error: invalid storage class 
for function 'ks7010_card_init'
   drivers/staging//ks7010/ks7010_sdio.c:828:13: error: invalid storage class 
for function 'ks7010_init_defaults'
   drivers/staging//ks7010/ks7010_sdio.c:855:12: error: invalid storage class 
for function 'ks7010_sdio_probe'
   drivers/staging//ks7010/ks7010_sdio.c:1005:12: error: invalid storage class 
for function 'send_stop_request'
   drivers/staging//ks7010/ks7010_sdio.c:1032:13: error: invalid storage class 
for function 'ks7010_sdio_remove'
   drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: initializer element is 
not constant
   drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: (near initialization 
for 'ks7010_sdio_driver.probe')
   drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: initializer element is 
not constant
   drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: (near initialization 
for 'ks7010_sdio_driver.remove')
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
for function 'ks7010_sdio_driver_init'
>> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
>> for function '__inittest'
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute 
ignored [-Wattributes]
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
for function 'ks7010_sdio_driver_exit'
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
>> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
>> for function '__exittest'
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute 
ignored [-Wattributes]
   drivers/staging//ks7010/ks7010_sdio.c:1105:1: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
   drivers/stag

Re: [PATCH] staging: ks7010: fix styling WARNINGs

2017-07-31 Thread kbuild test robot
Hi Ashish,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc3 next-20170731]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331
config: tile-allmodconfig (attached as .config)
compiler: tilegx-linux-gcc (GCC) 4.6.2
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=tile 

All errors (new ones prefixed by >>):

   drivers/staging//ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb':
   drivers/staging//ks7010/ks7010_sdio.c:77:12: error: invalid storage class 
for function 'ks7010_sdio_readb'
   drivers/staging//ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
   drivers/staging//ks7010/ks7010_sdio.c:89:12: error: invalid storage class 
for function 'ks7010_sdio_read'
   drivers/staging//ks7010/ks7010_sdio.c:98:12: error: invalid storage class 
for function 'ks7010_sdio_writeb'
   drivers/staging//ks7010/ks7010_sdio.c:110:12: error: invalid storage class 
for function 'ks7010_sdio_write'
   drivers/staging//ks7010/ks7010_sdio.c:118:13: error: invalid storage class 
for function 'ks_wlan_hw_sleep_doze_request'
   drivers/staging//ks7010/ks7010_sdio.c:144:13: error: invalid storage class 
for function 'ks_wlan_hw_sleep_wakeup_request'
   drivers/staging//ks7010/ks7010_sdio.c:191:13: error: invalid storage class 
for function '_ks_wlan_hw_power_save'
   drivers/staging//ks7010/ks7010_sdio.c:252:12: error: invalid storage class 
for function 'enqueue_txdev'
   drivers/staging//ks7010/ks7010_sdio.c:290:12: error: invalid storage class 
for function 'write_to_device'
   drivers/staging//ks7010/ks7010_sdio.c:320:13: error: invalid storage class 
for function 'tx_device_task'
   drivers/staging//ks7010/ks7010_sdio.c:379:13: error: invalid storage class 
for function 'rx_event_task'
   drivers/staging//ks7010/ks7010_sdio.c:396:13: error: invalid storage class 
for function 'ks_wlan_hw_rx'
   drivers/staging//ks7010/ks7010_sdio.c:452:13: error: invalid storage class 
for function 'ks7010_rw_function'
   drivers/staging//ks7010/ks7010_sdio.c:522:13: error: invalid storage class 
for function 'ks_sdio_interrupt'
   drivers/staging//ks7010/ks7010_sdio.c:593:12: error: invalid storage class 
for function 'trx_device_init'
   drivers/staging//ks7010/ks7010_sdio.c:609:13: error: invalid storage class 
for function 'trx_device_exit'
   drivers/staging//ks7010/ks7010_sdio.c:625:12: error: invalid storage class 
for function 'ks7010_sdio_update_index'
   drivers/staging//ks7010/ks7010_sdio.c:652:12: error: invalid storage class 
for function 'ks7010_sdio_data_compare'
   drivers/staging//ks7010/ks7010_sdio.c:680:12: error: invalid storage class 
for function 'ks7010_upload_firmware'
   drivers/staging//ks7010/ks7010_sdio.c:775:13: error: invalid storage class 
for function 'ks7010_card_init'
   drivers/staging//ks7010/ks7010_sdio.c:828:13: error: invalid storage class 
for function 'ks7010_init_defaults'
   drivers/staging//ks7010/ks7010_sdio.c:855:12: error: invalid storage class 
for function 'ks7010_sdio_probe'
   drivers/staging//ks7010/ks7010_sdio.c:1005:12: error: invalid storage class 
for function 'send_stop_request'
   drivers/staging//ks7010/ks7010_sdio.c:1032:13: error: invalid storage class 
for function 'ks7010_sdio_remove'
   drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: initializer element is 
not constant
   drivers/staging//ks7010/ks7010_sdio.c:1100:2: error: (near initialization 
for 'ks7010_sdio_driver.probe')
   drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: initializer element is 
not constant
   drivers/staging//ks7010/ks7010_sdio.c:1101:2: error: (near initialization 
for 'ks7010_sdio_driver.remove')
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
for function 'ks7010_sdio_driver_init'
>> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
>> for function '__inittest'
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute 
ignored [-Wattributes]
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
for function 'ks7010_sdio_driver_exit'
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
>> drivers/staging//ks7010/ks7010_sdio.c:1104:1: error: invalid storage class 
>> for function '__exittest'
   drivers/staging//ks7010/ks7010_sdio.c:1104:1: warning: 'alias' attribute 
ignored [-Wattributes]
   drivers/staging//ks7010/ks7010_sdio.c:1105:1: warning: ISO C90 forbids mixed 
declarations and code [-Wdeclaration-after-statement]
   drivers/stag

RE: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger

2017-07-31 Thread Eoff, Ullysses A
This patch was originally submitted in the context of the ChromiumOS kernel 
3.10 for BYT 
(https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/AsoBhfHzQg8).


> -Original Message-
> From: Koul, Vinod
> Sent: Monday, July 31, 2017 8:30 PM
> To: Cheng-Yi Chiang ; Jie, Yang 
> Cc: linux-kernel@vger.kernel.org; Liam Girdwood ; Mark 
> Brown ; Jaroslav Kysela
> ; Takashi Iwai ; Eoff, Ullysses A 
> ; alsa-de...@alsa-project.org
> Subject: Re: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
> 
> On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:
> > From: "U. Artie Eoff" 
> >
> > Reset the hw_ptr before queuing the restore_stream_context
> > work to eradicate a nasty white audio noise on resume.
> 
> Liam, Jie? This on legacy BYT driver..
> 
> >
> > Tested-by: Cheng-Yi Chiang 
> > Signed-off-by: U. Artie Eoff 
> > Signed-off-by: Cheng-Yi Chiang 
> > ---
> >  sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c 
> > b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > index 4765ad474544..e0db7070cd42 100644
> > --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct 
> > snd_pcm_substream *substream, int cmd)
> > sst_byt_stream_start(byt, pcm_data->stream, 0);
> > break;
> > case SNDRV_PCM_TRIGGER_RESUME:
> > -   if (pdata->restore_stream == true)
> > +   if (pdata->restore_stream == true) {
> > +   pcm_data->hw_ptr = 0;
> > schedule_work(_data->work);
> > +   }
> > else
> > sst_byt_stream_resume(byt, pcm_data->stream);
> > break;
> > --
> > 2.12.2
> >
> 
> --
> ~Vinod


RE: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger

2017-07-31 Thread Eoff, Ullysses A
This patch was originally submitted in the context of the ChromiumOS kernel 
3.10 for BYT 
(https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-reviews/AsoBhfHzQg8).


> -Original Message-
> From: Koul, Vinod
> Sent: Monday, July 31, 2017 8:30 PM
> To: Cheng-Yi Chiang ; Jie, Yang 
> Cc: linux-kernel@vger.kernel.org; Liam Girdwood ; Mark 
> Brown ; Jaroslav Kysela
> ; Takashi Iwai ; Eoff, Ullysses A 
> ; alsa-de...@alsa-project.org
> Subject: Re: [PATCH v2] ASoC: Intel: Reset hw_ptr on resume trigger
> 
> On Mon, Jul 31, 2017 at 06:47:34PM +0800, Cheng-Yi Chiang wrote:
> > From: "U. Artie Eoff" 
> >
> > Reset the hw_ptr before queuing the restore_stream_context
> > work to eradicate a nasty white audio noise on resume.
> 
> Liam, Jie? This on legacy BYT driver..
> 
> >
> > Tested-by: Cheng-Yi Chiang 
> > Signed-off-by: U. Artie Eoff 
> > Signed-off-by: Cheng-Yi Chiang 
> > ---
> >  sound/soc/intel/baytrail/sst-baytrail-pcm.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/sound/soc/intel/baytrail/sst-baytrail-pcm.c 
> > b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > index 4765ad474544..e0db7070cd42 100644
> > --- a/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > +++ b/sound/soc/intel/baytrail/sst-baytrail-pcm.c
> > @@ -187,8 +187,10 @@ static int sst_byt_pcm_trigger(struct 
> > snd_pcm_substream *substream, int cmd)
> > sst_byt_stream_start(byt, pcm_data->stream, 0);
> > break;
> > case SNDRV_PCM_TRIGGER_RESUME:
> > -   if (pdata->restore_stream == true)
> > +   if (pdata->restore_stream == true) {
> > +   pcm_data->hw_ptr = 0;
> > schedule_work(_data->work);
> > +   }
> > else
> > sst_byt_stream_resume(byt, pcm_data->stream);
> > break;
> > --
> > 2.12.2
> >
> 
> --
> ~Vinod


Re: [PATCH] staging: ks7010: fix styling WARNINGs

2017-07-31 Thread kbuild test robot
Hi Ashish,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc3 next-20170731]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331
config: i386-randconfig-x008-201731 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/staging/ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb':
>> drivers/staging/ks7010/ks7010_sdio.c:77:12: error: invalid storage class for 
>> function 'ks7010_sdio_readb'
static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int 
address,
   ^
>> drivers/staging/ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed 
>> declarations and code [-Wdeclaration-after-statement]
static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int 
address,
^~
>> drivers/staging/ks7010/ks7010_sdio.c:89:12: error: invalid storage class for 
>> function 'ks7010_sdio_read'
static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int 
address,
   ^~~~
>> drivers/staging/ks7010/ks7010_sdio.c:98:12: error: invalid storage class for 
>> function 'ks7010_sdio_writeb'
static int ks7010_sdio_writeb(struct ks_wlan_private *priv,
   ^~
>> drivers/staging/ks7010/ks7010_sdio.c:110:12: error: invalid storage class 
>> for function 'ks7010_sdio_write'
static int ks7010_sdio_write(struct ks_wlan_private *priv, unsigned int 
address,
   ^
>> drivers/staging/ks7010/ks7010_sdio.c:118:13: error: invalid storage class 
>> for function 'ks_wlan_hw_sleep_doze_request'
static void ks_wlan_hw_sleep_doze_request(struct ks_wlan_private *priv)
^
>> drivers/staging/ks7010/ks7010_sdio.c:144:13: error: invalid storage class 
>> for function 'ks_wlan_hw_sleep_wakeup_request'
static void ks_wlan_hw_sleep_wakeup_request(struct ks_wlan_private *priv)
^~~
>> drivers/staging/ks7010/ks7010_sdio.c:191:13: error: invalid storage class 
>> for function '_ks_wlan_hw_power_save'
static void _ks_wlan_hw_power_save(struct ks_wlan_private *priv)
^~
>> drivers/staging/ks7010/ks7010_sdio.c:252:12: error: invalid storage class 
>> for function 'enqueue_txdev'
static int enqueue_txdev(struct ks_wlan_private *priv, unsigned char *p,
   ^
>> drivers/staging/ks7010/ks7010_sdio.c:290:12: error: invalid storage class 
>> for function 'write_to_device'
static int write_to_device(struct ks_wlan_private *priv, unsigned char 
*buffer,
   ^~~
>> drivers/staging/ks7010/ks7010_sdio.c:320:13: error: invalid storage class 
>> for function 'tx_device_task'
static void tx_device_task(struct ks_wlan_private *priv)
^~
>> drivers/staging/ks7010/ks7010_sdio.c:379:13: error: invalid storage class 
>> for function 'rx_event_task'
static void rx_event_task(unsigned long dev)
^
>> drivers/staging/ks7010/ks7010_sdio.c:396:13: error: invalid storage class 
>> for function 'ks_wlan_hw_rx'
static void ks_wlan_hw_rx(struct ks_wlan_private *priv, uint16_t size)
^
>> drivers/staging/ks7010/ks7010_sdio.c:452:13: error: invalid storage class 
>> for function 'ks7010_rw_function'
static void ks7010_rw_function(struct work_struct *work)
^~
>> drivers/staging/ks7010/ks7010_sdio.c:522:13: error: invalid storage class 
>> for function 'ks_sdio_interrupt'
static void ks_sdio_interrupt(struct sdio_func *func)
^
>> drivers/staging/ks7010/ks7010_sdio.c:593:12: error: invalid storage class 
>> for function 'trx_device_init'
static int trx_device_init(struct ks_wlan_private *priv)
   ^~~
>> drivers/staging/ks7010/ks7010_sdio.c:609:13: error: invalid storage class 
>> for function 'trx_device_exit'
static void trx_device_exit(struct ks_wlan_private *priv)
^~~
>> drivers/staging/ks7010/ks7010_sdio.c:625:12: error: invalid storage class 
>> for function 'ks7010_sdio_update_index'
static int ks7010_sdio_update_index(struct ks_wlan_private *priv, u32 index)
   ^~~~
>> drivers/staging/ks7010/ks7010_sdio.c:652:12: error: invalid storage class 
>> for function 'ks7010_sdio_data_compare'
sta

Re: [PATCH] staging: ks7010: fix styling WARNINGs

2017-07-31 Thread kbuild test robot
Hi Ashish,

[auto build test ERROR on staging/staging-testing]
[also build test ERROR on v4.13-rc3 next-20170731]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Ashish-Kalra/staging-ks7010-fix-styling-WARNINGs/20170801-121331
config: i386-randconfig-x008-201731 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/staging/ks7010/ks7010_sdio.c: In function 'ks7010_sdio_readb':
>> drivers/staging/ks7010/ks7010_sdio.c:77:12: error: invalid storage class for 
>> function 'ks7010_sdio_readb'
static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int 
address,
   ^
>> drivers/staging/ks7010/ks7010_sdio.c:77:1: warning: ISO C90 forbids mixed 
>> declarations and code [-Wdeclaration-after-statement]
static int ks7010_sdio_readb(struct ks_wlan_private *priv, unsigned int 
address,
^~
>> drivers/staging/ks7010/ks7010_sdio.c:89:12: error: invalid storage class for 
>> function 'ks7010_sdio_read'
static int ks7010_sdio_read(struct ks_wlan_private *priv, unsigned int 
address,
   ^~~~
>> drivers/staging/ks7010/ks7010_sdio.c:98:12: error: invalid storage class for 
>> function 'ks7010_sdio_writeb'
static int ks7010_sdio_writeb(struct ks_wlan_private *priv,
   ^~
>> drivers/staging/ks7010/ks7010_sdio.c:110:12: error: invalid storage class 
>> for function 'ks7010_sdio_write'
static int ks7010_sdio_write(struct ks_wlan_private *priv, unsigned int 
address,
   ^
>> drivers/staging/ks7010/ks7010_sdio.c:118:13: error: invalid storage class 
>> for function 'ks_wlan_hw_sleep_doze_request'
static void ks_wlan_hw_sleep_doze_request(struct ks_wlan_private *priv)
^
>> drivers/staging/ks7010/ks7010_sdio.c:144:13: error: invalid storage class 
>> for function 'ks_wlan_hw_sleep_wakeup_request'
static void ks_wlan_hw_sleep_wakeup_request(struct ks_wlan_private *priv)
^~~
>> drivers/staging/ks7010/ks7010_sdio.c:191:13: error: invalid storage class 
>> for function '_ks_wlan_hw_power_save'
static void _ks_wlan_hw_power_save(struct ks_wlan_private *priv)
^~
>> drivers/staging/ks7010/ks7010_sdio.c:252:12: error: invalid storage class 
>> for function 'enqueue_txdev'
static int enqueue_txdev(struct ks_wlan_private *priv, unsigned char *p,
   ^
>> drivers/staging/ks7010/ks7010_sdio.c:290:12: error: invalid storage class 
>> for function 'write_to_device'
static int write_to_device(struct ks_wlan_private *priv, unsigned char 
*buffer,
   ^~~
>> drivers/staging/ks7010/ks7010_sdio.c:320:13: error: invalid storage class 
>> for function 'tx_device_task'
static void tx_device_task(struct ks_wlan_private *priv)
^~
>> drivers/staging/ks7010/ks7010_sdio.c:379:13: error: invalid storage class 
>> for function 'rx_event_task'
static void rx_event_task(unsigned long dev)
^
>> drivers/staging/ks7010/ks7010_sdio.c:396:13: error: invalid storage class 
>> for function 'ks_wlan_hw_rx'
static void ks_wlan_hw_rx(struct ks_wlan_private *priv, uint16_t size)
^
>> drivers/staging/ks7010/ks7010_sdio.c:452:13: error: invalid storage class 
>> for function 'ks7010_rw_function'
static void ks7010_rw_function(struct work_struct *work)
^~
>> drivers/staging/ks7010/ks7010_sdio.c:522:13: error: invalid storage class 
>> for function 'ks_sdio_interrupt'
static void ks_sdio_interrupt(struct sdio_func *func)
^
>> drivers/staging/ks7010/ks7010_sdio.c:593:12: error: invalid storage class 
>> for function 'trx_device_init'
static int trx_device_init(struct ks_wlan_private *priv)
   ^~~
>> drivers/staging/ks7010/ks7010_sdio.c:609:13: error: invalid storage class 
>> for function 'trx_device_exit'
static void trx_device_exit(struct ks_wlan_private *priv)
^~~
>> drivers/staging/ks7010/ks7010_sdio.c:625:12: error: invalid storage class 
>> for function 'ks7010_sdio_update_index'
static int ks7010_sdio_update_index(struct ks_wlan_private *priv, u32 index)
   ^~~~
>> drivers/staging/ks7010/ks7010_sdio.c:652:12: error: invalid storage class 
>> for function 'ks7010_sdio_data_compare'
sta

[PATCH] futex: allow for compiling out PI support

2017-07-31 Thread Nicolas Pitre
This makes it possible to preserve basic futex support and compile out
the PI support when RT mutexes are not available.

Signed-off-by: Nicolas Pitre 
---
 include/linux/futex.h   |  7 ++-
 init/Kconfig|  7 ++-
 kernel/futex.c  | 22 ++
 kernel/locking/rtmutex_common.h | 29 +
 4 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/include/linux/futex.h b/include/linux/futex.h
index 7c5b694864..f36bfd26f9 100644
--- a/include/linux/futex.h
+++ b/include/linux/futex.h
@@ -54,7 +54,6 @@ union futex_key {
 
 #ifdef CONFIG_FUTEX
 extern void exit_robust_list(struct task_struct *curr);
-extern void exit_pi_state_list(struct task_struct *curr);
 #ifdef CONFIG_HAVE_FUTEX_CMPXCHG
 #define futex_cmpxchg_enabled 1
 #else
@@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled;
 static inline void exit_robust_list(struct task_struct *curr)
 {
 }
+#endif
+
+#ifdef CONFIG_FUTEX_PI
+extern void exit_pi_state_list(struct task_struct *curr);
+#else
 static inline void exit_pi_state_list(struct task_struct *curr)
 {
 }
 #endif
+
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 8514b25db2..5f0ef850e8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1275,12 +1275,17 @@ config BASE_FULL
 config FUTEX
bool "Enable futex support" if EXPERT
default y
-   select RT_MUTEXES
+   imply RT_MUTEXES
help
  Disabling this option will cause the kernel to be built without
  support for "fast userspace mutexes".  The resulting kernel may not
  run glibc-based applications correctly.
 
+config FUTEX_PI
+   bool
+   depends on FUTEX && RT_MUTEXES
+   default y
+
 config HAVE_FUTEX_CMPXCHG
bool
depends on FUTEX
diff --git a/kernel/futex.c b/kernel/futex.c
index 16dbe4c938..ad0af4df1b 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -875,6 +875,8 @@ static struct task_struct *futex_find_get_task(pid_t pid)
return p;
 }
 
+#ifdef CONFIG_FUTEX_PI
+
 /*
  * This task is holding PI mutexes at exit time => bad.
  * Kernel cleans up PI-state, but userspace is likely hosed.
@@ -932,6 +934,8 @@ void exit_pi_state_list(struct task_struct *curr)
raw_spin_unlock_irq(>pi_lock);
 }
 
+#endif
+
 /*
  * We need to check the following states:
  *
@@ -1799,6 +1803,15 @@ static int futex_requeue(u32 __user *uaddr1, unsigned 
int flags,
struct futex_q *this, *next;
DEFINE_WAKE_Q(wake_q);
 
+   /*
+* When PI not supported: return -ENOSYS if requeue_pi is true,
+* consequently the compiler knows requeue_pi is always false past
+* this point which will optimize away all the conditional code
+* further down.
+*/
+   if (!IS_ENABLED(CONFIG_FUTEX_PI) && requeue_pi)
+   return -ENOSYS;
+
if (requeue_pi) {
/*
 * Requeue PI only works on two distinct uaddrs. This
@@ -2594,6 +2607,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int 
flags,
struct futex_q q = futex_q_init;
int res, ret;
 
+   if (!IS_ENABLED(CONFIG_FUTEX_PI))
+   return -ENOSYS;
+
if (refill_pi_state_cache())
return -ENOMEM;
 
@@ -2773,6 +2789,9 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned 
int flags)
struct futex_q *top_waiter;
int ret;
 
+   if (!IS_ENABLED(CONFIG_FUTEX_PI))
+   return -ENOSYS;
+
 retry:
if (get_user(uval, uaddr))
return -EFAULT;
@@ -2983,6 +3002,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
struct futex_q q = futex_q_init;
int res, ret;
 
+   if (!IS_ENABLED(CONFIG_FUTEX_PI))
+   return -ENOSYS;
+
if (uaddr == uaddr2)
return -EINVAL;
 
diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h
index 72ad45a9a7..8d039b928d 100644
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -40,6 +40,9 @@ struct rt_mutex_waiter {
 /*
  * Various helpers to access the waiters-tree:
  */
+
+#ifdef CONFIG_RT_MUTEXES
+
 static inline int rt_mutex_has_waiters(struct rt_mutex *lock)
 {
return !RB_EMPTY_ROOT(>waiters);
@@ -69,6 +72,32 @@ task_top_pi_waiter(struct task_struct *p)
pi_tree_entry);
 }
 
+#else
+
+static inline int rt_mutex_has_waiters(struct rt_mutex *lock)
+{
+   return false;
+}
+
+static inline struct rt_mutex_waiter *
+rt_mutex_top_waiter(struct rt_mutex *lock)
+{
+   return NULL;
+}
+
+static inline int task_has_pi_waiters(struct task_struct *p)
+{
+   return false;
+}
+
+static inline struct rt_mutex_waiter *
+task_top_pi_waiter(struct task_struct *p)
+{
+   return NULL;
+}
+
+#endif
+
 /*
  * lock->owner state tracking:
  */


[PATCH] futex: allow for compiling out PI support

2017-07-31 Thread Nicolas Pitre
This makes it possible to preserve basic futex support and compile out
the PI support when RT mutexes are not available.

Signed-off-by: Nicolas Pitre 
---
 include/linux/futex.h   |  7 ++-
 init/Kconfig|  7 ++-
 kernel/futex.c  | 22 ++
 kernel/locking/rtmutex_common.h | 29 +
 4 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/include/linux/futex.h b/include/linux/futex.h
index 7c5b694864..f36bfd26f9 100644
--- a/include/linux/futex.h
+++ b/include/linux/futex.h
@@ -54,7 +54,6 @@ union futex_key {
 
 #ifdef CONFIG_FUTEX
 extern void exit_robust_list(struct task_struct *curr);
-extern void exit_pi_state_list(struct task_struct *curr);
 #ifdef CONFIG_HAVE_FUTEX_CMPXCHG
 #define futex_cmpxchg_enabled 1
 #else
@@ -64,8 +63,14 @@ extern int futex_cmpxchg_enabled;
 static inline void exit_robust_list(struct task_struct *curr)
 {
 }
+#endif
+
+#ifdef CONFIG_FUTEX_PI
+extern void exit_pi_state_list(struct task_struct *curr);
+#else
 static inline void exit_pi_state_list(struct task_struct *curr)
 {
 }
 #endif
+
 #endif
diff --git a/init/Kconfig b/init/Kconfig
index 8514b25db2..5f0ef850e8 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1275,12 +1275,17 @@ config BASE_FULL
 config FUTEX
bool "Enable futex support" if EXPERT
default y
-   select RT_MUTEXES
+   imply RT_MUTEXES
help
  Disabling this option will cause the kernel to be built without
  support for "fast userspace mutexes".  The resulting kernel may not
  run glibc-based applications correctly.
 
+config FUTEX_PI
+   bool
+   depends on FUTEX && RT_MUTEXES
+   default y
+
 config HAVE_FUTEX_CMPXCHG
bool
depends on FUTEX
diff --git a/kernel/futex.c b/kernel/futex.c
index 16dbe4c938..ad0af4df1b 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -875,6 +875,8 @@ static struct task_struct *futex_find_get_task(pid_t pid)
return p;
 }
 
+#ifdef CONFIG_FUTEX_PI
+
 /*
  * This task is holding PI mutexes at exit time => bad.
  * Kernel cleans up PI-state, but userspace is likely hosed.
@@ -932,6 +934,8 @@ void exit_pi_state_list(struct task_struct *curr)
raw_spin_unlock_irq(>pi_lock);
 }
 
+#endif
+
 /*
  * We need to check the following states:
  *
@@ -1799,6 +1803,15 @@ static int futex_requeue(u32 __user *uaddr1, unsigned 
int flags,
struct futex_q *this, *next;
DEFINE_WAKE_Q(wake_q);
 
+   /*
+* When PI not supported: return -ENOSYS if requeue_pi is true,
+* consequently the compiler knows requeue_pi is always false past
+* this point which will optimize away all the conditional code
+* further down.
+*/
+   if (!IS_ENABLED(CONFIG_FUTEX_PI) && requeue_pi)
+   return -ENOSYS;
+
if (requeue_pi) {
/*
 * Requeue PI only works on two distinct uaddrs. This
@@ -2594,6 +2607,9 @@ static int futex_lock_pi(u32 __user *uaddr, unsigned int 
flags,
struct futex_q q = futex_q_init;
int res, ret;
 
+   if (!IS_ENABLED(CONFIG_FUTEX_PI))
+   return -ENOSYS;
+
if (refill_pi_state_cache())
return -ENOMEM;
 
@@ -2773,6 +2789,9 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned 
int flags)
struct futex_q *top_waiter;
int ret;
 
+   if (!IS_ENABLED(CONFIG_FUTEX_PI))
+   return -ENOSYS;
+
 retry:
if (get_user(uval, uaddr))
return -EFAULT;
@@ -2983,6 +3002,9 @@ static int futex_wait_requeue_pi(u32 __user *uaddr, 
unsigned int flags,
struct futex_q q = futex_q_init;
int res, ret;
 
+   if (!IS_ENABLED(CONFIG_FUTEX_PI))
+   return -ENOSYS;
+
if (uaddr == uaddr2)
return -EINVAL;
 
diff --git a/kernel/locking/rtmutex_common.h b/kernel/locking/rtmutex_common.h
index 72ad45a9a7..8d039b928d 100644
--- a/kernel/locking/rtmutex_common.h
+++ b/kernel/locking/rtmutex_common.h
@@ -40,6 +40,9 @@ struct rt_mutex_waiter {
 /*
  * Various helpers to access the waiters-tree:
  */
+
+#ifdef CONFIG_RT_MUTEXES
+
 static inline int rt_mutex_has_waiters(struct rt_mutex *lock)
 {
return !RB_EMPTY_ROOT(>waiters);
@@ -69,6 +72,32 @@ task_top_pi_waiter(struct task_struct *p)
pi_tree_entry);
 }
 
+#else
+
+static inline int rt_mutex_has_waiters(struct rt_mutex *lock)
+{
+   return false;
+}
+
+static inline struct rt_mutex_waiter *
+rt_mutex_top_waiter(struct rt_mutex *lock)
+{
+   return NULL;
+}
+
+static inline int task_has_pi_waiters(struct task_struct *p)
+{
+   return false;
+}
+
+static inline struct rt_mutex_waiter *
+task_top_pi_waiter(struct task_struct *p)
+{
+   return NULL;
+}
+
+#endif
+
 /*
  * lock->owner state tracking:
  */


[PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus

2017-07-31 Thread Danilo Krummrich
This driver provides PS/2 serio bus support by implementing bit banging
with the GPIO API. The GPIO pins, data and clock, can be configured with
a node in the device tree or by static platform data.

Writing to a device is supported as well, though it is not recommended as
the timings to be halt given by libps2 are very tough and difficult to
reach with bit banging. Therefore it can be configured (also in DT and
pdata) whether the serio write function should be available for clients.

This driver is for development purposes and not for productive use.
However, this driver can be useful e.g. when no USB port is available or
using old peripherals is desired as PS/2 controller chips getting rare.

This driver was tested on a RPI1 and on Hikey960 and it worked well
together with the atkbd driver.

Signed-off-by: Danilo Krummrich 
---
v2: Removed one verbose print statement, changed another one to dev_dbg.
v3: - fixed compiler warning on blackfin
- depends on GPIOLIB
- clarify documentation
---
 .../devicetree/bindings/serio/ps2-gpio.txt |  20 +
 Documentation/gpio/drivers-on-gpio.txt |   5 +
 drivers/input/serio/Kconfig|  11 +
 drivers/input/serio/Makefile   |   1 +
 drivers/input/serio/ps2-gpio.c | 439 +
 include/linux/ps2-gpio.h   |  27 ++
 6 files changed, 503 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serio/ps2-gpio.txt
 create mode 100644 drivers/input/serio/ps2-gpio.c
 create mode 100644 include/linux/ps2-gpio.h

diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.txt 
b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
new file mode 100644
index 000..828a5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for ps2 gpio driver
+
+Required properties:
+   - compatible = "ps2-gpio";
+   - gpios: data and clock gpio
+
+Optional properties:
+   - ps2-gpio,write-enable: Indicates whether write function is provided
+   to serio device. Most probably providing the write fn will not work,
+   because of the tough timing libps2 requires.
+
+Example nodes:
+
+ps2@0 {
+   compatible = "ps2-gpio";
+   gpios = < 24 0 /* data */
+ 23 0 /* clock */
+   >;
+   i2c-gpio,write-enable = <0>;
+};
diff --git a/Documentation/gpio/drivers-on-gpio.txt 
b/Documentation/gpio/drivers-on-gpio.txt
index 3065132..97c8716 100644
--- a/Documentation/gpio/drivers-on-gpio.txt
+++ b/Documentation/gpio/drivers-on-gpio.txt
@@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI:
   NAND flash MTD subsystem and provides chip access and partition parsing like
   any other NAND driving hardware.
 
+- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive an PS/2 (IBM) serio
+  bus, data and clock line, by bit banging two GPIO lines. It will appear as
+  any other serio bus to the system and makes it possible to connect drivers
+  for e.g. keyboards and other PS/2 protocol based devices.
+
 Apart from this there are special GPIO drivers in subsystems like MMC/SD to
 read card detect and write protect GPIO lines, and in the TTY serial subsystem
 to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index c3d05b4..292d6e2 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -292,6 +292,17 @@ config SERIO_SUN4I_PS2
  To compile this driver as a module, choose M here: the
  module will be called sun4i-ps2.
 
+config SERIO_GPIO_PS2
+   tristate "GPIO PS/2 bit banging driver"
+   depends on GPIOLIB
+   help
+ Say Y here if you want PS/2 bit banging support via GPIO.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gpio-ps2.
+
+ If you are unsure, say N.
+
 config USERIO
tristate "User space serio port driver support"
help
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 2374ef9..767bd9b 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_SERIO_APBPS2)+= apbps2.o
 obj-$(CONFIG_SERIO_OLPC_APSP)  += olpc_apsp.o
 obj-$(CONFIG_HYPERV_KEYBOARD)  += hyperv-keyboard.o
 obj-$(CONFIG_SERIO_SUN4I_PS2)  += sun4i-ps2.o
+obj-$(CONFIG_SERIO_GPIO_PS2)   += ps2-gpio.o
 obj-$(CONFIG_USERIO)   += userio.o
diff --git a/drivers/input/serio/ps2-gpio.c b/drivers/input/serio/ps2-gpio.c
new file mode 100644
index 000..fc5368b
--- /dev/null
+++ b/drivers/input/serio/ps2-gpio.c
@@ -0,0 +1,439 @@
+/*
+ * GPIO based serio bus driver for bit banging the PS/2 protocol
+ *
+ * Author: Danilo Krummrich 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * 

[PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus

2017-07-31 Thread Danilo Krummrich
This driver provides PS/2 serio bus support by implementing bit banging
with the GPIO API. The GPIO pins, data and clock, can be configured with
a node in the device tree or by static platform data.

Writing to a device is supported as well, though it is not recommended as
the timings to be halt given by libps2 are very tough and difficult to
reach with bit banging. Therefore it can be configured (also in DT and
pdata) whether the serio write function should be available for clients.

This driver is for development purposes and not for productive use.
However, this driver can be useful e.g. when no USB port is available or
using old peripherals is desired as PS/2 controller chips getting rare.

This driver was tested on a RPI1 and on Hikey960 and it worked well
together with the atkbd driver.

Signed-off-by: Danilo Krummrich 
---
v2: Removed one verbose print statement, changed another one to dev_dbg.
v3: - fixed compiler warning on blackfin
- depends on GPIOLIB
- clarify documentation
---
 .../devicetree/bindings/serio/ps2-gpio.txt |  20 +
 Documentation/gpio/drivers-on-gpio.txt |   5 +
 drivers/input/serio/Kconfig|  11 +
 drivers/input/serio/Makefile   |   1 +
 drivers/input/serio/ps2-gpio.c | 439 +
 include/linux/ps2-gpio.h   |  27 ++
 6 files changed, 503 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/serio/ps2-gpio.txt
 create mode 100644 drivers/input/serio/ps2-gpio.c
 create mode 100644 include/linux/ps2-gpio.h

diff --git a/Documentation/devicetree/bindings/serio/ps2-gpio.txt 
b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
new file mode 100644
index 000..828a5b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/ps2-gpio.txt
@@ -0,0 +1,20 @@
+Device-Tree bindings for ps2 gpio driver
+
+Required properties:
+   - compatible = "ps2-gpio";
+   - gpios: data and clock gpio
+
+Optional properties:
+   - ps2-gpio,write-enable: Indicates whether write function is provided
+   to serio device. Most probably providing the write fn will not work,
+   because of the tough timing libps2 requires.
+
+Example nodes:
+
+ps2@0 {
+   compatible = "ps2-gpio";
+   gpios = < 24 0 /* data */
+ 23 0 /* clock */
+   >;
+   i2c-gpio,write-enable = <0>;
+};
diff --git a/Documentation/gpio/drivers-on-gpio.txt 
b/Documentation/gpio/drivers-on-gpio.txt
index 3065132..97c8716 100644
--- a/Documentation/gpio/drivers-on-gpio.txt
+++ b/Documentation/gpio/drivers-on-gpio.txt
@@ -84,6 +84,11 @@ hardware descriptions such as device tree or ACPI:
   NAND flash MTD subsystem and provides chip access and partition parsing like
   any other NAND driving hardware.
 
+- ps2-gpio: drivers/input/serio/ps2-gpio.c is used to drive an PS/2 (IBM) serio
+  bus, data and clock line, by bit banging two GPIO lines. It will appear as
+  any other serio bus to the system and makes it possible to connect drivers
+  for e.g. keyboards and other PS/2 protocol based devices.
+
 Apart from this there are special GPIO drivers in subsystems like MMC/SD to
 read card detect and write protect GPIO lines, and in the TTY serial subsystem
 to emulate MCTRL (modem control) signals CTS/RTS by using two GPIO lines. The
diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
index c3d05b4..292d6e2 100644
--- a/drivers/input/serio/Kconfig
+++ b/drivers/input/serio/Kconfig
@@ -292,6 +292,17 @@ config SERIO_SUN4I_PS2
  To compile this driver as a module, choose M here: the
  module will be called sun4i-ps2.
 
+config SERIO_GPIO_PS2
+   tristate "GPIO PS/2 bit banging driver"
+   depends on GPIOLIB
+   help
+ Say Y here if you want PS/2 bit banging support via GPIO.
+
+ To compile this driver as a module, choose M here: the
+ module will be called gpio-ps2.
+
+ If you are unsure, say N.
+
 config USERIO
tristate "User space serio port driver support"
help
diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
index 2374ef9..767bd9b 100644
--- a/drivers/input/serio/Makefile
+++ b/drivers/input/serio/Makefile
@@ -30,4 +30,5 @@ obj-$(CONFIG_SERIO_APBPS2)+= apbps2.o
 obj-$(CONFIG_SERIO_OLPC_APSP)  += olpc_apsp.o
 obj-$(CONFIG_HYPERV_KEYBOARD)  += hyperv-keyboard.o
 obj-$(CONFIG_SERIO_SUN4I_PS2)  += sun4i-ps2.o
+obj-$(CONFIG_SERIO_GPIO_PS2)   += ps2-gpio.o
 obj-$(CONFIG_USERIO)   += userio.o
diff --git a/drivers/input/serio/ps2-gpio.c b/drivers/input/serio/ps2-gpio.c
new file mode 100644
index 000..fc5368b
--- /dev/null
+++ b/drivers/input/serio/ps2-gpio.c
@@ -0,0 +1,439 @@
+/*
+ * GPIO based serio bus driver for bit banging the PS/2 protocol
+ *
+ * Author: Danilo Krummrich 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 

Re: linux-next: manual merge of the rcu tree with the tip tree

2017-07-31 Thread Mathieu Desnoyers
- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paul...@linux.vnet.ibm.com 
wrote:

> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
>> paul...@linux.vnet.ibm.com
>> wrote:
>> 
>> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
>> >> Hi Paul,
>> >> 
>> >> Today's linux-next merge of the rcu tree got a conflict in:
>> >> 
>> >>   arch/x86/mm/tlb.c
>> >> 
>> >> between commit:
>> >> 
>> >>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
>> >> 
>> >> from the tip tree and commit:
>> >> 
>> >>   d7713e8f8b23 ("membarrier: Expedited private command")
>> >> 
>> >> from the rcu tree.
>> >> 
>> >> I fixed it up (the former removed the comment and the load_cr3(), so I
>> >> just dropped the commend change in the latter) and can carry the fix as
>> >> necessary. This is now fixed as far as linux-next is concerned, but any
>> >> non trivial conflicts should be mentioned to your upstream maintainer
>> >> when your tree is submitted for merging.  You may also want to consider
>> >> cooperating with the maintainer of the conflicting tree to minimise any
>> >> particularly complex conflicts.
>> > 
>> > Thank you, Stephen!
>> > 
>> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
>> > simply result in relying on the ordering provided by the atomic ops
>> > in switch_mm() for mm_cpumask(), so that only the commit log and the
>> > comment need changing.
>> > 
>> > Please let me know if I am missing something here.
>> 
>> I think you are right. Both load_cr3() and mm_cpumask update operations
>> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
>> matter of adapting the comment to the new reality.
> 
> Like this?

The updated comment in the commit message looks good, but I would be
tempted to add a comment in x86 switch_mm_irqs_off() stating the
following requirement just before the line invoking cpumask_set_cpu():

/*
 * The full memory barrier implied by mm_cpumask update operations
 * is required by the membarrier system call.
 */

Thanks,

Mathieu

> 
>   Thanx, Paul
> 
> 
> 
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers 
> Date:   Fri Jul 28 16:40:40 2017 -0400
> 
>membarrier: Expedited private command
>
>Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
>from all runqueues for which current thread's mm is the same as the
>thread calling sys_membarrier. It executes faster than the non-expedited
>variant (no blocking). It also works on NOHZ_FULL configurations.
>
>Scheduler-wise, it requires a memory barrier before and after context
>switching between processes (which have different mm). The memory
>barrier before context switch is already present. For the barrier after
>context switch:
>
>* Our TSO archs can do RELEASE without being a full barrier. Look at
>  x86 spin_unlock() being a regular STORE for example.  But for those
>  archs, all atomics imply smp_mb and all of them have atomic ops in
>  switch_mm() for mm_cpumask().
>
>* From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
>  the rest does indeed do smp_mb(), so there the spin_unlock() is a full
>  barrier and we're good.
>
>* ARM64 has a very heavy barrier in switch_to(), which suffices.
>
>* PPC just removed its barrier from switch_to(), but appears to be
>  talking about adding something to switch_mm(). So add a
>  smp_mb__after_unlock_lock() for now, until this is settled on the PPC
>  side.
>
>Changes since v3:
>- Properly document the memory barriers provided by each architecture.
>
>Changes since v2:
>- Address comments from Peter Zijlstra,
>- Add smp_mb__after_unlock_lock() after finish_lock_switch() in
>  finish_task_switch() to add the memory barrier we need after storing
>  to rq->curr. This is much simpler than the previous approach relying
>  on atomic_dec_and_test() in mmdrop(), which actually added a memory
>  barrier in the common case of switching between userspace processes.
>- Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
>  kernel, rather than having the whole membarrier system call returning
>  -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
>  Adapt the CMD_QUERY mask accordingly.
>
>Changes since v1:
>- move membarrier code under kernel/sched/ because it uses the
>  scheduler runqueue,
>- only add the barrier when we switch from a kernel thread. The case
>  where we switch from a user-space thread is already handled by
>  the atomic_dec_and_test() in mmdrop().
>- add a comment to mmdrop() documenting the 

Re: linux-next: manual merge of the rcu tree with the tip tree

2017-07-31 Thread Mathieu Desnoyers
- On Aug 1, 2017, at 12:03 AM, Paul E. McKenney paul...@linux.vnet.ibm.com 
wrote:

> On Tue, Aug 01, 2017 at 12:04:05AM +, Mathieu Desnoyers wrote:
>> - On Jul 31, 2017, at 12:13 PM, Paul E. McKenney 
>> paul...@linux.vnet.ibm.com
>> wrote:
>> 
>> > On Mon, Jul 31, 2017 at 01:50:29PM +1000, Stephen Rothwell wrote:
>> >> Hi Paul,
>> >> 
>> >> Today's linux-next merge of the rcu tree got a conflict in:
>> >> 
>> >>   arch/x86/mm/tlb.c
>> >> 
>> >> between commit:
>> >> 
>> >>   94b1b03b519b ("x86/mm: Rework lazy TLB mode and TLB freshness tracking")
>> >> 
>> >> from the tip tree and commit:
>> >> 
>> >>   d7713e8f8b23 ("membarrier: Expedited private command")
>> >> 
>> >> from the rcu tree.
>> >> 
>> >> I fixed it up (the former removed the comment and the load_cr3(), so I
>> >> just dropped the commend change in the latter) and can carry the fix as
>> >> necessary. This is now fixed as far as linux-next is concerned, but any
>> >> non trivial conflicts should be mentioned to your upstream maintainer
>> >> when your tree is submitted for merging.  You may also want to consider
>> >> cooperating with the maintainer of the conflicting tree to minimise any
>> >> particularly complex conflicts.
>> > 
>> > Thank you, Stephen!
>> > 
>> > Mathieu, Peter, our commit log reads as if removal of load_cr3() would
>> > simply result in relying on the ordering provided by the atomic ops
>> > in switch_mm() for mm_cpumask(), so that only the commit log and the
>> > comment need changing.
>> > 
>> > Please let me know if I am missing something here.
>> 
>> I think you are right. Both load_cr3() and mm_cpumask update operations
>> (LOCK prefixed) provide the appropriate barriers on x86. So it's just a
>> matter of adapting the comment to the new reality.
> 
> Like this?

The updated comment in the commit message looks good, but I would be
tempted to add a comment in x86 switch_mm_irqs_off() stating the
following requirement just before the line invoking cpumask_set_cpu():

/*
 * The full memory barrier implied by mm_cpumask update operations
 * is required by the membarrier system call.
 */

Thanks,

Mathieu

> 
>   Thanx, Paul
> 
> 
> 
> commit fde19879b6bd1abc0c1d4d5f945efed61bf7eb8c
> Author: Mathieu Desnoyers 
> Date:   Fri Jul 28 16:40:40 2017 -0400
> 
>membarrier: Expedited private command
>
>Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
>from all runqueues for which current thread's mm is the same as the
>thread calling sys_membarrier. It executes faster than the non-expedited
>variant (no blocking). It also works on NOHZ_FULL configurations.
>
>Scheduler-wise, it requires a memory barrier before and after context
>switching between processes (which have different mm). The memory
>barrier before context switch is already present. For the barrier after
>context switch:
>
>* Our TSO archs can do RELEASE without being a full barrier. Look at
>  x86 spin_unlock() being a regular STORE for example.  But for those
>  archs, all atomics imply smp_mb and all of them have atomic ops in
>  switch_mm() for mm_cpumask().
>
>* From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
>  the rest does indeed do smp_mb(), so there the spin_unlock() is a full
>  barrier and we're good.
>
>* ARM64 has a very heavy barrier in switch_to(), which suffices.
>
>* PPC just removed its barrier from switch_to(), but appears to be
>  talking about adding something to switch_mm(). So add a
>  smp_mb__after_unlock_lock() for now, until this is settled on the PPC
>  side.
>
>Changes since v3:
>- Properly document the memory barriers provided by each architecture.
>
>Changes since v2:
>- Address comments from Peter Zijlstra,
>- Add smp_mb__after_unlock_lock() after finish_lock_switch() in
>  finish_task_switch() to add the memory barrier we need after storing
>  to rq->curr. This is much simpler than the previous approach relying
>  on atomic_dec_and_test() in mmdrop(), which actually added a memory
>  barrier in the common case of switching between userspace processes.
>- Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
>  kernel, rather than having the whole membarrier system call returning
>  -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
>  Adapt the CMD_QUERY mask accordingly.
>
>Changes since v1:
>- move membarrier code under kernel/sched/ because it uses the
>  scheduler runqueue,
>- only add the barrier when we switch from a kernel thread. The case
>  where we switch from a user-space thread is already handled by
>  the atomic_dec_and_test() in mmdrop().
>- add a comment to mmdrop() documenting the requirement on the implicit
>  

Re: [PATCH] futex: split PI support to a file of its own

2017-07-31 Thread Nicolas Pitre
On Mon, 31 Jul 2017, Thomas Gleixner wrote:

> But I really do not agree with your reasoning about easier to understand
> and maintain. I have the dubious pleasure to stare into that code on a
> regular base. PI and non PI share a lot of code and it's really not helping
> to have two separate files to stare at. That makes following the PI code
> even harder than it is already. So I rather like to see that PI code in an
> #ifdef block and not split out into its own file.

OK. And in fact I think I now managed to keep #ifdef's to a very small 
number, counting on dead code elimination instead.  Please see next 
patch.

> Please provide a diffstat along with the patch next time.

Hmmm... was supposed to be there.  For the record it was:

 include/linux/futex.h |7 +-
 init/Kconfig  |7 +-
 kernel/futex.c| 1559 +-
 kernel/futex_pi.c | 1563 +++
 4 files changed, 1598 insertions(+), 1538 deletions(-)

Admitedly not small. But when PI is disabled then futex.o shrinks by 
roughly the half of its original size. So a lot of code is dedicated to 
PI.


Nicolas


Re: [PATCH] futex: split PI support to a file of its own

2017-07-31 Thread Nicolas Pitre
On Mon, 31 Jul 2017, Thomas Gleixner wrote:

> But I really do not agree with your reasoning about easier to understand
> and maintain. I have the dubious pleasure to stare into that code on a
> regular base. PI and non PI share a lot of code and it's really not helping
> to have two separate files to stare at. That makes following the PI code
> even harder than it is already. So I rather like to see that PI code in an
> #ifdef block and not split out into its own file.

OK. And in fact I think I now managed to keep #ifdef's to a very small 
number, counting on dead code elimination instead.  Please see next 
patch.

> Please provide a diffstat along with the patch next time.

Hmmm... was supposed to be there.  For the record it was:

 include/linux/futex.h |7 +-
 init/Kconfig  |7 +-
 kernel/futex.c| 1559 +-
 kernel/futex_pi.c | 1563 +++
 4 files changed, 1598 insertions(+), 1538 deletions(-)

Admitedly not small. But when PI is disabled then futex.o shrinks by 
roughly the half of its original size. So a lot of code is dedicated to 
PI.


Nicolas


[stable 4.4: PATCH] sched/cputime: Fix prev steal time accouting during CPU hotplug

2017-07-31 Thread Andres Oportus
commit 3d89e5478bf550a50c99e93adf659369798263b0 upstream.

Commit:

  e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")

... set rq->prev_* to 0 after a CPU hotplug comes back, in order to
fix the case where (after CPU hotplug) steal time is smaller than
rq->prev_steal_time.

However, this should never happen. Steal time was only smaller because of the
KVM-specific bug fixed by the previous patch.  Worse, the previous patch
triggers a bug on CPU hot-unplug/plug operation: because
rq->prev_steal_time is cleared, all of the CPU's past steal time will be
accounted again on hot-plug.

Since the root cause has been fixed, we can just revert
commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU 
hotplug").

Signed-off-by: Wanpeng Li 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Paolo Bonzini 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU 
hotplug")'
Link: 
http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng...@hotmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andres Oportus 
---
 kernel/sched/core.c  |  1 -
 kernel/sched/sched.h | 13 -
 2 files changed, 14 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c436426..b103b9c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5553,7 +5553,6 @@ migration_call(struct notifier_block *nfb, unsigned long 
action, void *hcpu)
 
case CPU_UP_PREPARE:
rq->calc_load_update = calc_load_update;
-   account_reset_rq(rq);
break;
 
case CPU_ONLINE:
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4e5db65..55d92a1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1770,16 +1770,3 @@ static inline u64 irq_time_read(int cpu)
 }
 #endif /* CONFIG_64BIT */
 #endif /* CONFIG_IRQ_TIME_ACCOUNTING */
-
-static inline void account_reset_rq(struct rq *rq)
-{
-#ifdef CONFIG_IRQ_TIME_ACCOUNTING
-   rq->prev_irq_time = 0;
-#endif
-#ifdef CONFIG_PARAVIRT
-   rq->prev_steal_time = 0;
-#endif
-#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-   rq->prev_steal_time_rq = 0;
-#endif
-}
-- 
1.9.1



[stable 4.4: PATCH] sched/cputime: Fix prev steal time accouting during CPU hotplug

2017-07-31 Thread Andres Oportus
commit 3d89e5478bf550a50c99e93adf659369798263b0 upstream.

Commit:

  e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU hotplug")

... set rq->prev_* to 0 after a CPU hotplug comes back, in order to
fix the case where (after CPU hotplug) steal time is smaller than
rq->prev_steal_time.

However, this should never happen. Steal time was only smaller because of the
KVM-specific bug fixed by the previous patch.  Worse, the previous patch
triggers a bug on CPU hot-unplug/plug operation: because
rq->prev_steal_time is cleared, all of the CPU's past steal time will be
accounted again on hot-plug.

Since the root cause has been fixed, we can just revert
commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU 
hotplug").

Signed-off-by: Wanpeng Li 
Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Paolo Bonzini 
Cc: Frederic Weisbecker 
Cc: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rik van Riel 
Cc: Thomas Gleixner 
Fixes: 'commit e9532e69b8d1 ("sched/cputime: Fix steal time accounting vs. CPU 
hotplug")'
Link: 
http://lkml.kernel.org/r/1465813966-3116-3-git-send-email-wanpeng...@hotmail.com
Signed-off-by: Ingo Molnar 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Andres Oportus 
---
 kernel/sched/core.c  |  1 -
 kernel/sched/sched.h | 13 -
 2 files changed, 14 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c436426..b103b9c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -5553,7 +5553,6 @@ migration_call(struct notifier_block *nfb, unsigned long 
action, void *hcpu)
 
case CPU_UP_PREPARE:
rq->calc_load_update = calc_load_update;
-   account_reset_rq(rq);
break;
 
case CPU_ONLINE:
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 4e5db65..55d92a1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1770,16 +1770,3 @@ static inline u64 irq_time_read(int cpu)
 }
 #endif /* CONFIG_64BIT */
 #endif /* CONFIG_IRQ_TIME_ACCOUNTING */
-
-static inline void account_reset_rq(struct rq *rq)
-{
-#ifdef CONFIG_IRQ_TIME_ACCOUNTING
-   rq->prev_irq_time = 0;
-#endif
-#ifdef CONFIG_PARAVIRT
-   rq->prev_steal_time = 0;
-#endif
-#ifdef CONFIG_PARAVIRT_TIME_ACCOUNTING
-   rq->prev_steal_time_rq = 0;
-#endif
-}
-- 
1.9.1



  1   2   3   4   5   6   7   8   9   10   >