[PATCHv6 01/10] x86/mm/gup: Switch GUP to the generic get_user_page_fast() implementation

[Kirill A. Shutemov]

This patch provides all required callbacks required by the generic
get_user_pages_fast() code and switches x86 over - and removes
the platform specific implementation.

Signed-off-by: Kirill A. Shutemov 
---
 arch/arm/Kconfig  |   2 +-
 arch/arm64/Kconfig|   2 +-
 arch/powerpc/Kconfig  |   2 +-
 arch/x86/Kconfig  |   3 +
 arch/x86/include/asm/mmu_context.h|  12 -
 arch/x86/include/asm/pgtable-3level.h |  47 
 arch/x86/include/asm/pgtable.h|  53 
 arch/x86/include/asm/pgtable_64.h |  16 +-
 arch/x86/mm/Makefile  |   2 +-
 arch/x86/mm/gup.c | 496 --
 mm/Kconfig|   2 +-
 mm/gup.c  |  10 +-
 12 files changed, 128 insertions(+), 519 deletions(-)
 delete mode 100644 arch/x86/mm/gup.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 4c1a35f15838..c3c49c9491d5 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1637,7 +1637,7 @@ config ARCH_SELECT_MEMORY_MODEL
 config HAVE_ARCH_PFN_VALID
def_bool ARCH_HAS_HOLES_MEMORYMODEL || !SPARSEMEM
 
-config HAVE_GENERIC_RCU_GUP
+config HAVE_GENERIC_GUP
def_bool y
depends on ARM_LPAE
 
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 3dcd7ec69bca..a7c5f8c3f13d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -205,7 +205,7 @@ config GENERIC_CALIBRATE_DELAY
 config ZONE_DMA
def_bool y
 
-config HAVE_GENERIC_RCU_GUP
+config HAVE_GENERIC_GUP
def_bool y
 
 config ARCH_DMA_ADDR_T_64BIT
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index f7c8f9972f61..7d898796c819 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -184,7 +184,7 @@ config PPC
select HAVE_FUNCTION_GRAPH_TRACER
select HAVE_FUNCTION_TRACER
select HAVE_GCC_PLUGINS
-   select HAVE_GENERIC_RCU_GUP
+   select HAVE_GENERIC_GUP
select HAVE_HW_BREAKPOINT   if PERF_EVENTS && (PPC_BOOK3S 
|| PPC_8xx)
select HAVE_IDE
select HAVE_IOREMAP_PROT
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index cd18994a9555..bd0f2ff59029 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2797,6 +2797,9 @@ config X86_DMA_REMAP
bool
depends on STA2X11
 
+config HAVE_GENERIC_GUP
+   def_bool y
+
 source "net/Kconfig"
 
 source "drivers/Kconfig"
diff --git a/arch/x86/include/asm/mmu_context.h 
b/arch/x86/include/asm/mmu_context.h
index 68b329d77b3a..6e933d2d88d9 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -220,18 +220,6 @@ static inline int vma_pkey(struct vm_area_struct *vma)
 }
 #endif
 
-static inline bool __pkru_allows_pkey(u16 pkey, bool write)
-{
-   u32 pkru = read_pkru();
-
-   if (!__pkru_allows_read(pkru, pkey))
-   return false;
-   if (write && !__pkru_allows_write(pkru, pkey))
-   return false;
-
-   return true;
-}
-
 /*
  * We only want to enforce protection keys on the current process
  * because we effectively have no access to PKRU for other
diff --git a/arch/x86/include/asm/pgtable-3level.h 
b/arch/x86/include/asm/pgtable-3level.h
index 50d35e3185f5..c8821bab938f 100644
--- a/arch/x86/include/asm/pgtable-3level.h
+++ b/arch/x86/include/asm/pgtable-3level.h
@@ -212,4 +212,51 @@ static inline pud_t native_pudp_get_and_clear(pud_t *pudp)
 #define __pte_to_swp_entry(pte)((swp_entry_t){ (pte).pte_high 
})
 #define __swp_entry_to_pte(x)  ((pte_t){ { .pte_high = (x).val } })
 
+#define gup_get_pte gup_get_pte
+/*
+ * WARNING: only to be used in the get_user_pages_fast() implementation.
+ *
+ * With get_user_pages_fast(), we walk down the pagetables without taking
+ * any locks.  For this we would like to load the pointers atomically,
+ * but that is not possible (without expensive cmpxchg8b) on PAE.  What
+ * we do have is the guarantee that a PTE will only either go from not
+ * present to present, or present to not present or both -- it will not
+ * switch to a completely different present page without a TLB flush in
+ * between; something that we are blocking by holding interrupts off.
+ *
+ * Setting ptes from not present to present goes:
+ *
+ *   ptep->pte_high = h;
+ *   smp_wmb();
+ *   ptep->pte_low = l;
+ *
+ * And present to not present goes:
+ *
+ *   ptep->pte_low = 0;
+ *   smp_wmb();
+ *   ptep->pte_high = 0;
+ *
+ * We must ensure here that the load of pte_low sees 'l' iff pte_high
+ * sees 'h'. We load pte_high *after* loading pte_low, which ensures we
+ * don't see an older value of pte_high.  *Then* we recheck pte_low,
+ * which ensures that we haven't picked up a changed pte high. We might
+ * have gotten rubbish values from pte_low and pte_high, but we are
+ * guaranteed that pte_low will not have the present bit set *unless*
+ * it is 'l'. Because 

[PATCHv6 10/10] x86/mm: Allow to have userspace mappings above 47-bits

[Kirill A. Shutemov]

On x86, 5-level paging enables 56-bit userspace virtual address space.
Not all user space is ready to handle wide addresses. It's known that
at least some JIT compilers use higher bits in pointers to encode their
information. It collides with valid pointers with 5-level paging and
leads to crashes.

To mitigate this, we are not going to allocate virtual address space
above 47-bit by default.

But userspace can ask for allocation from full address space by
specifying hint address (with or without MAP_FIXED) above 47-bits.

If hint address set above 47-bit, but MAP_FIXED is not specified, we try
to look for unmapped area by specified address. If it's already
occupied, we look for unmapped area in *full* address space, rather than
from 47-bit window.

A high hint address would only affect the allocation in question, but not
any future mmap()s.

Specifying high hint address on older kernel or on machine without 5-level
paging support is safe. The hint will be ignored and kernel will fall back
to allocation from 47-bit address space.

This approach helps to easily make application's memory allocator aware
about large address space without manually tracking allocated virtual
address space.

One important case we need to handle here is interaction with MPX.
MPX (without MAWA( extension cannot handle addresses above 47-bit, so we
need to make sure that MPX cannot be enabled we already have VMA above
the boundary and forbid creating such VMAs once MPX is enabled.

Signed-off-by: Kirill A. Shutemov 
Reviewed-by: Dmitry Safonov 
Acked-by: Michal Hocko 
Cc: linux-...@vger.kernel.org
---
 arch/x86/include/asm/elf.h   |  4 ++--
 arch/x86/include/asm/mpx.h   |  9 +
 arch/x86/include/asm/processor.h | 12 +---
 arch/x86/kernel/sys_x86_64.c | 30 ++
 arch/x86/mm/hugetlbpage.c| 27 +++
 arch/x86/mm/mmap.c   |  6 +++---
 arch/x86/mm/mpx.c| 33 -
 7 files changed, 104 insertions(+), 17 deletions(-)

diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
index e8ab9a46bc68..7a30513a4046 100644
--- a/arch/x86/include/asm/elf.h
+++ b/arch/x86/include/asm/elf.h
@@ -250,7 +250,7 @@ extern int force_personality32;
the loader.  We need to make sure that it is out of the way of the program
that it will "exec", and that there is sufficient room for the brk.  */
 
-#define ELF_ET_DYN_BASE(TASK_SIZE / 3 * 2)
+#define ELF_ET_DYN_BASE(TASK_SIZE_LOW / 3 * 2)
 
 /* This yields a mask that user programs can use to figure out what
instruction set this CPU supports.  This could be done in user space,
@@ -304,7 +304,7 @@ static inline int mmap_is_ia32(void)
 }
 
 extern unsigned long tasksize_32bit(void);
-extern unsigned long tasksize_64bit(void);
+extern unsigned long tasksize_64bit(int full_addr_space);
 extern unsigned long get_mmap_base(int is_legacy);
 
 #ifdef CONFIG_X86_32
diff --git a/arch/x86/include/asm/mpx.h b/arch/x86/include/asm/mpx.h
index a0d662be4c5b..7d7404756bb4 100644
--- a/arch/x86/include/asm/mpx.h
+++ b/arch/x86/include/asm/mpx.h
@@ -73,6 +73,9 @@ static inline void mpx_mm_init(struct mm_struct *mm)
 }
 void mpx_notify_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
  unsigned long start, unsigned long end);
+
+unsigned long mpx_unmapped_area_check(unsigned long addr, unsigned long len,
+   unsigned long flags);
 #else
 static inline siginfo_t *mpx_generate_siginfo(struct pt_regs *regs)
 {
@@ -94,6 +97,12 @@ static inline void mpx_notify_unmap(struct mm_struct *mm,
unsigned long start, unsigned long end)
 {
 }
+
+static inline unsigned long mpx_unmapped_area_check(unsigned long addr,
+   unsigned long len, unsigned long flags)
+{
+   return addr;
+}
 #endif /* CONFIG_X86_INTEL_MPX */
 
 #endif /* _ASM_X86_MPX_H */
diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 3cada998a402..65663de9287b 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -794,7 +794,9 @@ static inline void spin_lock_prefetch(const void *x)
  */
 #define IA32_PAGE_OFFSET   PAGE_OFFSET
 #define TASK_SIZE  PAGE_OFFSET
+#define TASK_SIZE_LOW  TASK_SIZE
 #define TASK_SIZE_MAX  TASK_SIZE
+#define DEFAULT_MAP_WINDOW TASK_SIZE
 #define STACK_TOP  TASK_SIZE
 #define STACK_TOP_MAX  STACK_TOP
 
@@ -834,7 +836,9 @@ static inline void spin_lock_prefetch(const void *x)
  * particular problem by preventing anything from being mapped
  * at the maximum canonical address.
  */
-#define TASK_SIZE_MAX  ((1UL << 47) - PAGE_SIZE)
+#define TASK_SIZE_MAX  ((1UL << __VIRTUAL_MASK_SHIFT) - PAGE_SIZE)
+
+#define DEFAULT_MAP_WINDOW ((1UL << 47) - PAGE_SIZE)
 
 /* This decides where the 

[PATCHv6 09/10] x86: Enable 5-level paging support

[Kirill A. Shutemov]

Most of things are in place and we can enable support of 5-level paging.

The patch makes XEN_PV dependent on !X86_5LEVEL. XEN_PV is not ready to
work with 5-level paging.

Signed-off-by: Kirill A. Shutemov 
---
 arch/x86/Kconfig | 5 +
 arch/x86/xen/Kconfig | 1 +
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index bd0f2ff59029..0bf81e837cbf 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -318,6 +318,7 @@ config FIX_EARLYCON_MEM
 
 config PGTABLE_LEVELS
int
+   default 5 if X86_5LEVEL
default 4 if X86_64
default 3 if X86_PAE
default 2
@@ -1390,6 +1391,10 @@ config X86_PAE
  has the cost of more pagetable lookup overhead, and also
  consumes more pagetable space per process.
 
+config X86_5LEVEL
+   bool "Enable 5-level page tables support"
+   depends on X86_64
+
 config ARCH_PHYS_ADDR_T_64BIT
def_bool y
depends on X86_64 || X86_PAE
diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig
index 027987638e98..1be9667bd476 100644
--- a/arch/x86/xen/Kconfig
+++ b/arch/x86/xen/Kconfig
@@ -17,6 +17,7 @@ config XEN_PV
bool "Xen PV guest support"
default y
depends on XEN
+   depends on !X86_5LEVEL
select XEN_HAVE_PVMMU
select XEN_HAVE_VPMU
help
-- 
2.11.0

[PATCHv6 07/10] x86/mm: Make kernel_physical_mapping_init() support 5-level paging

[Kirill A. Shutemov]

Populate additional page table level if CONFIG_X86_5LEVEL is enabled.

Signed-off-by: Kirill A. Shutemov 
---
 arch/x86/mm/init_64.c | 69 ---
 1 file changed, 60 insertions(+), 9 deletions(-)

diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index ce410c05d68d..124f1a77c181 100644
--- a/arch/x86/mm/init_64.c
+++ b/arch/x86/mm/init_64.c
@@ -624,6 +624,57 @@ phys_pud_init(pud_t *pud_page, unsigned long paddr, 
unsigned long paddr_end,
return paddr_last;
 }
 
+static unsigned long __meminit
+phys_p4d_init(p4d_t *p4d_page, unsigned long paddr, unsigned long paddr_end,
+ unsigned long page_size_mask)
+{
+   unsigned long paddr_next, paddr_last = paddr_end;
+   unsigned long vaddr = (unsigned long)__va(paddr);
+   int i = p4d_index(vaddr);
+
+   if (!IS_ENABLED(CONFIG_X86_5LEVEL))
+   return phys_pud_init((pud_t *) p4d_page, paddr, paddr_end, 
page_size_mask);
+
+   for (; i < PTRS_PER_P4D; i++, paddr = paddr_next) {
+   p4d_t *p4d;
+   pud_t *pud;
+
+   vaddr = (unsigned long)__va(paddr);
+   p4d = p4d_page + p4d_index(vaddr);
+   paddr_next = (paddr & P4D_MASK) + P4D_SIZE;
+
+   if (paddr >= paddr_end) {
+   if (!after_bootmem &&
+   !e820__mapped_any(paddr & P4D_MASK, paddr_next,
+E820_TYPE_RAM) &&
+   !e820__mapped_any(paddr & P4D_MASK, paddr_next,
+E820_TYPE_RESERVED_KERN))
+   set_p4d(p4d, __p4d(0));
+   continue;
+   }
+
+   if (!p4d_none(*p4d)) {
+   pud = pud_offset(p4d, 0);
+   paddr_last = phys_pud_init(pud, paddr,
+   paddr_end,
+   page_size_mask);
+   __flush_tlb_all();
+   continue;
+   }
+
+   pud = alloc_low_page();
+   paddr_last = phys_pud_init(pud, paddr, paddr_end,
+  page_size_mask);
+
+   spin_lock(_mm.page_table_lock);
+   p4d_populate(_mm, p4d, pud);
+   spin_unlock(_mm.page_table_lock);
+   }
+   __flush_tlb_all();
+
+   return paddr_last;
+}
+
 /*
  * Create page table mapping for the physical memory for specific physical
  * addresses. The virtual and physical addresses have to be aligned on PMD 
level
@@ -645,26 +696,26 @@ kernel_physical_mapping_init(unsigned long paddr_start,
for (; vaddr < vaddr_end; vaddr = vaddr_next) {
pgd_t *pgd = pgd_offset_k(vaddr);
p4d_t *p4d;
-   pud_t *pud;
 
vaddr_next = (vaddr & PGDIR_MASK) + PGDIR_SIZE;
 
-   BUILD_BUG_ON(pgd_none(*pgd));
-   p4d = p4d_offset(pgd, vaddr);
-   if (p4d_val(*p4d)) {
-   pud = (pud_t *)p4d_page_vaddr(*p4d);
-   paddr_last = phys_pud_init(pud, __pa(vaddr),
+   if (pgd_val(*pgd)) {
+   p4d = (p4d_t *)pgd_page_vaddr(*pgd);
+   paddr_last = phys_p4d_init(p4d, __pa(vaddr),
   __pa(vaddr_end),
   page_size_mask);
continue;
}
 
-   pud = alloc_low_page();
-   paddr_last = phys_pud_init(pud, __pa(vaddr), __pa(vaddr_end),
+   p4d = alloc_low_page();
+   paddr_last = phys_p4d_init(p4d, __pa(vaddr), __pa(vaddr_end),
   page_size_mask);
 
spin_lock(_mm.page_table_lock);
-   p4d_populate(_mm, p4d, pud);
+   if (IS_ENABLED(CONFIG_X86_5LEVEL))
+   pgd_populate(_mm, pgd, p4d);
+   else
+   p4d_populate(_mm, p4d_offset(pgd, vaddr), (pud_t 
*) p4d);
spin_unlock(_mm.page_table_lock);
pgd_changed = true;
}
-- 
2.11.0

Re: [PATCH 0/6] refine and rename slub sysfs

[Wei Yang]

On Tue, May 23, 2017 at 08:39:11AM +0200, Michal Hocko wrote:
>On Tue 23-05-17 11:27:05, Wei Yang wrote:
>> On Thu, May 18, 2017 at 11:06:37AM +0200, Michal Hocko wrote:
>> >On Wed 17-05-17 22:11:40, Wei Yang wrote:
>> >> This patch serial could be divided into two parts.
>> >> 
>> >> First three patches refine and adds slab sysfs.
>> >> Second three patches rename slab sysfs.
>> >> 
>> >> 1. Refine slab sysfs
>> >> 
>> >> There are four level slabs:
>> >> 
>> >> CPU
>> >> CPU_PARTIAL
>> >> PARTIAL
>> >> FULL
>> >> 
>> >> And in sysfs, it use show_slab_objects() and cpu_partial_slabs_show() to
>> >> reflect the statistics.
>> >> 
>> >> In patch 2, it splits some function in show_slab_objects() which makes 
>> >> sure
>> >> only cpu_partial_slabs_show() covers statistics for CPU_PARTIAL slabs.
>> >> 
>> >> After doing so, it would be more clear that show_slab_objects() has 
>> >> totally 9
>> >> statistic combinations for three level of slabs. Each slab has three cases
>> >> statistic.
>> >> 
>> >> slabs
>> >> objects
>> >> total_objects
>> >> 
>> >> And when we look at current implementation, some of them are missing. So 
>> >> patch
>> >> 2 & 3 add them up.
>> >> 
>> >> 2. Rename sysfs
>> >> 
>> >> The slab statistics in sysfs are
>> >> 
>> >> slabs
>> >> objects
>> >> total_objects
>> >> cpu_slabs
>> >> partial
>> >> partial_objects
>> >> cpu_partial_slabs
>> >> 
>> >> which is a little bit hard for users to understand. The second three 
>> >> patches
>> >> rename sysfs file in this pattern.
>> >> 
>> >> xxx_slabs[[_total]_objects]
>> >> 
>> >> Finally it looks Like
>> >> 
>> >> slabs
>> >> slabs_objects
>> >> slabs_total_objects
>> >> cpu_slabs
>> >> cpu_slabs_objects
>> >> cpu_slabs_total_objects
>> >> partial_slabs
>> >> partial_slabs_objects
>> >> partial_slabs_total_objects
>> >> cpu_partial_slabs
>> >
>> >_Why_ do we need all this?
>> 
>> To have a clear statistics for each slab level.
>
>Is this worth risking breakage of the userspace which consume this data
>now? Do you have any user space code which will greatly benefit from the
>new data and which couldn't do the same with the current format/output?
>
>If yes this all should be in the changelog.

The answer is no.

I have the same concern as yours. So this patch set could be divided into two
parts: 1. add some new entry with current name convention, 2. change the name
convention.

If there are many userspace tools use these entries, the changing is really
risky, I agree. Hmm, I still send this out, since current name convention is a
little difficult for users to understand, especially after we have several
levels slabs. Is it possible to use the name convention I proposed and add
link to them to keep the userspace interface?

And the second part is to fully utilize current functions. In function
show_slab_objects(), we have 9 combinations of slab statistics. 3 for each
slab level. And currently code just enable 6 of them. So the first three tries
to enable the missing 3 to make it a more complete statistics.

BTW, I found we don't have any entry for full slabs statistics. Not sure this
is omitted intendedly or not. If the community agrees, I still have a path to
enable the statistics for full slabs.

Thanks for your comments~ Michal

>
>-- 
>Michal Hocko
>SUSE Labs

-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

Re: [PATCH v2] fault-inject: support systematic fault injection

[Dmitry Vyukov]

Hi,

I've made the current interface work with all types of our sandboxes.
For setuid the secret souse was prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) to
make /proc entries non-root owned. So I am fine with the current
version of the code.

Andrew,

I see that this is already in linux-next. Please proceed with pushing
it further.

Thanks


On Sun, Apr 9, 2017 at 12:39 PM, Akinobu Mita  wrote:
> 2017-04-09 2:40 GMT+09:00 Dmitry Vyukov :
>> On Fri, Apr 7, 2017 at 6:47 PM, Akinobu Mita  wrote:
>>> 2017-04-07 3:33 GMT+09:00 Michal Hocko :
 [Let's add linux-api - please always cc this list when adding/modifying
 user visible interfaces]

 On Tue 28-03-17 15:01:28, Dmitry Vyukov wrote:
> Add /proc/self/task//fail-nth file that allows failing
> 0-th, 1-st, 2-nd and so on calls systematically.
> Excerpt from the added documentation:

 I didn't really get to read through details here but it just feels wrong
 to add this debugging only feature into proc. It also smells like one
 off thing as well.
>>>
>>> We have 'sched' (CONFIG_SCHED_DEBUG), 'latency' (CONFIG_LATENCYTOP)
>>> and 'make-it-fail' as debugging per-process proc files.  So it doesn't
>>> look very wrong to me.  But I would like to avoid per-process proc
>>> directory becoming messy. Do you think introducing /proc//debug/
>>> directory for debugging stuff makes sense?
>>>
>>> Side note: 'fail-nth' was originally a single debugfs file
>>> /sys/kernel/debug/fail_once.  But it actually read/write current task's
>>> fail_nth field, so I suggested changing per process procfs file.i
>>> This change enables to inject N-th fail to kernel threads, too.
>>
>>
>> /sys/kernel/debug/fail_once (or fail_nth) looks more appropriate to me
>> for a optional testing feature. The fact that it currently
>> reads/writes a task_struct field is merely an implementation detail.
>> I would also prefer ioctl's. Then we don't need to preserve "symmetry"
>> for no useful reason and deal with nonsensical uses like setting it
>> for a non-current task and running cat on it.
>
> Sounds reasonable for adding ioctl interface as it can work with your
> setuid sandbox test.  But could you keep the procfs interface, too?
> Because both ioctl debugfs interface and procfs interface can co-exist
> and I would like to play it with procfs for a while.
>
> ===
> Write to this file of integer N makes N-th call in the current task fail
> (N is 0-based). Read from this file returns a single char 'Y' or 'N'
> that says if the fault setup with a previous write to this file was
> injected or not, and disables the fault if it wasn't yet injected.
> Note that this file enables all types of faults (slab, futex, etc).
> This setting takes precedence over all other generic settings like
> probability, interval, times, etc. But per-capability settings
> (e.g. fail_futex/ignore-private) take precedence over it.
> This feature is intended for systematic testing of faults in a single
> system call. See an example below.
> ===
>
> Why adding new setting:
> 1. Existing settings are global rather than per-task.
>So parallel testing is not possible.
> 2. attr->interval is close but it depends on attr->count
>which is non reset to 0, so interval does not work as expected.
> 3. Trying to model this with existing settings requires manipulations
>of all of probability, interval, times, space, task-filter and
>unexposed count and per-task make-it-fail files.
> 4. Existing settings are per-failure-type, and the set of failure
>types is potentially expanding.
> 5. make-it-fail can't be changed by unprivileged user and aggressive
>stress testing better be done from an unprivileged user.
>Similarly, this would require opening the debugfs files to the
>unprivileged user, as he would need to reopen at least times file
>(not possible to pre-open before dropping privs).
>
> The proposed interface solves all of the above (see the example).
>
> Signed-off-by: Dmitry Vyukov 
> Cc: Akinobu Mita 
> Cc: Andrew Morton 
> Cc: linux-kernel@vger.kernel.org
> Cc: linux...@kvack.org
>
> ---
> We want to integrate this into syzkaller fuzzer.
> A prototype has found 10 bugs in kernel in first day of usage:
> https://groups.google.com/forum/#!searchin/syzkaller/%22FAULT_INJECTION%22%7Csort:relevance
>
> Changes since v1:
>  - change file name from /sys/kernel/debug/fail_once
>to /proc/self/task//fail-nth as per
>Akinobu suggestion
>
> ---
>  Documentation/fault-injection/fault-injection.txt | 78 
> +++
>  fs/proc/base.c| 52 +++
>  

Re: [PATCH v4 2/2] kernel.h: handle pointers to arrays better in container_of()

[Ian Abbott]

On 24/05/17 01:54, kbuild test robot wrote:

Hi Ian,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170523]
[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/Ian-Abbott/asm-generic-bug-h-declare-struct-pt_regs-before-function-prototype/20170524-070310
config: i386-allmodconfig (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 >>):

   In file included from include/linux/kernel.h:14:0,
from include/asm-generic/bug.h:15,
from arch/x86/include/asm/bug.h:81,
from drivers/block/drbd/drbd_interval.c:1:

include/linux/bug.h:103:47: warning: 'struct bug_entry' declared inside 
parameter list will not be visible outside of this definition or declaration

static inline int is_warning_bug(const struct bug_entry *bug)
  ^
   include/linux/bug.h: In function 'is_warning_bug':

include/linux/bug.h:105:12: error: dereferencing pointer to incomplete type 
'const struct bug_entry'

 return bug->flags & BUGFLAG_WARNING;
   ^~

vim +105 include/linux/bug.h

ff20c2e0 Kirill A. Shutemov  2016-03-01   97
35edd910 Paul Gortmaker  2011-11-16   98  #endif/* __CHECKER__ */
35edd910 Paul Gortmaker  2011-11-16   99
7664c5a1 Jeremy Fitzhardinge 2006-12-08  100  #ifdef CONFIG_GENERIC_BUG
7664c5a1 Jeremy Fitzhardinge 2006-12-08  101  #include 
7664c5a1 Jeremy Fitzhardinge 2006-12-08  102
7664c5a1 Jeremy Fitzhardinge 2006-12-08 @103  static inline int 
is_warning_bug(const struct bug_entry *bug)
7664c5a1 Jeremy Fitzhardinge 2006-12-08  104  {
7664c5a1 Jeremy Fitzhardinge 2006-12-08 @105return bug->flags & 
BUGFLAG_WARNING;
7664c5a1 Jeremy Fitzhardinge 2006-12-08  106  }
7664c5a1 Jeremy Fitzhardinge 2006-12-08  107
19d43626 Peter Zijlstra  2017-02-25  108  struct bug_entry 
*find_bug(unsigned long bugaddr);

:: The code at line 105 was first introduced by commit
:: 7664c5a1da4711bb6383117f51b94c8dc8f3f1cd [PATCH] Generic BUG 
implementation

:: TO: Jeremy Fitzhardinge <jer...@goop.org>
:: CC: Linus Torvalds <torva...@woody.osdl.org>


This breakage occurs when  is included before 
 due to a circular dependancy I introduced with this 
commit.


It can be fixed by replacing the `#include ` with 
`#include ` in "include/asm-generic/bug.h".  I can send a 
patch to fix that, but ideally, it should be committed before this 
commit to avoid breakage during git bisect builds.  So my question is, 
should I send a single patch to fix this breakage, or resend the series 
of patches to incorporate this fix before the current commit?


--
-=( Ian Abbott @ MEV Ltd.E-mail: <abbo...@mev.co.uk> )=-
-=(  Web: http://www.mev.co.uk/  )=-

[PATCH 2/2] ARM: sun8i: v3s: add pinmux for LCD pins of V3s SoC

[Icenowy Zheng]

Allwinner V3s SoC features a set of pins that have functionality of RGB
LCD, the pins are at different pin ban than other SoCs.

Add pinctrl node for them.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 3a06dc5b3746..81e5406661b4 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -297,6 +297,15 @@
function = "i2c0";
};
 
+   lcd_rgb666_pins: lcd_rgb666 {
+   pins = "PE0", "PE1", "PE2", "PE3", "PE4",
+  "PE5", "PE6", "PE7", "PE8", "PE9",
+  "PE10", "PE11", "PE12", "PE13", "PE14",
+  "PE15", "PE16", "PE17", "PE18", "PE19",
+  "PE23", "PE24";
+   function = "lcd";
+   };
+
uart0_pins_a: uart0@0 {
pins = "PB8", "PB9";
function = "uart0";
-- 
2.12.2

Re: irqchip/irq-gic: BAD_MADT_GICC_ENTRY may fail when booting with ACPI 5.1

[Julien Grall]

Hi Lorenzo,

On 05/23/2017 06:06 PM, Lorenzo Pieralisi wrote:

[+Al]

On Tue, May 23, 2017 at 05:40:28PM +0100, Julien Grall wrote:

Hi all,

I am currently looking at adding support of ACPI 5.1 in Xen.
When trying to boot DOM00 I get a panic in Linux (for the full
log see [1]):

(XEN) DOM0: [0.00] No valid GICC entries exist

The error message is coming from gic_v2_acpi_init.
Digging down in the code, it is failing because of
BAD_MADT_GICC_ENTRY is returning false in
gic_acpi_parse_madt_cpu:

/* Macros for consistency checks of the GICC subtable of MADT */
#define ACPI_MADT_GICC_LENGTH   \
(acpi_gbl_FADT.header.revision < 6 ? 76 : 80)

#define BAD_MADT_GICC_ENTRY(entry, end) 
\
(!(entry) || (unsigned long)(entry) + sizeof(*(entry)) > (end) ||\
 (entry)->header.length != ACPI_MADT_GICC_LENGTH)

The 'end' parameter corresponds to the end of the MADT table.
In the case of ACPI 5.1, the size of GICC is smaller compare
to 6.0+ (76 vs 80 bytes) but the parameter 'entry' is type
of acpi_madt_generic_interrupt (sizeof(...) = 80).


#define BAD_MADT_GICC_ENTRY(entry, end) \
(!(entry) || (entry)->header.length != ACPI_MADT_GICC_LENGTH ||  \
((unsigned long)(entry) + ACPI_MADT_GICC_LENGTH) > (end))

Would this solve it ?


Yes, I am now able to boot DOM0 up to the prompt. My concern with this 
solution is the code will still use the acpi_madt_generic_interrupt 
code. If someone tries to access field not existing in 5.1 (such as 
efficiency_class), it may return wrong value or even worst crash.


Although, I don't see any user of efficiency_class in Linux so far.

Cheers,

--
Julien Grall

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

[Michal Hocko]

On Wed 24-05-17 13:39:48, Mike Rapoport wrote:
> On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote:
> > On 05/24/2017 09:50 AM, Mike Rapoport wrote:
> > > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote:
> > >> On 05/22/2017 04:29 PM, Mike Rapoport wrote:
> > >>>
> > >>> Probably I didn't explained it too well.
> > >>>
> > >>> The range is intentionally not populated. When we combine pre- and
> > >>> post-copy for process migration, we create memory pre-dump without 
> > >>> stopping
> > >>> the process, then we freeze the process without dumping the pages it has
> > >>> dirtied between pre-dump and freeze, and then, during restore, we 
> > >>> populate
> > >>> the dirtied pages using userfaultfd.
> > >>>
> > >>> When CRIU restores a process in such scenario, it does something like:
> > >>>
> > >>> * mmap() memory region
> > >>> * fill in the pages that were collected during the pre-dump
> > >>> * do some other stuff
> > >>> * register memory region with userfaultfd
> > >>> * populate the missing memory on demand
> > >>>
> > >>> khugepaged collapses the pages in the partially populated regions 
> > >>> before we
> > >>> have a chance to register these regions with userfaultfd, which would
> > >>> prevent the collapse.
> > >>>
> > >>> We could have used MADV_NOHUGEPAGE right after the mmap() call, and then
> > >>> there would be no race because there would be nothing for khugepaged to
> > >>> collapse at that point. But the problem is that we have no way to reset
> > >>> *HUGEPAGE flags after the memory restore is complete.
> > >>
> > >> Hmm, I wouldn't be that sure if this is indeed race-free. Check that
> > >> this scenario is indeed impossible?
> > >>
> > >> - you do the mmap
> > >> - khugepaged will choose the process' mm to scan
> > >> - khugepaged will get to the vma in question, it doesn't have
> > >> MADV_NOHUGEPAGE yet
> > >> - you set MADV_NOHUGEPAGE on the vma
> > >> - you start populating the vma
> > >> - khugepaged sees the vma is non-empty, collapses
> > >>
> > >> unless I'm wrong, the racers will have mmap_sem for reading only when
> > >> setting/checking the MADV_NOHUGEPAGE? Might be actually considered a bug.
> > >>
> > >> However, can't you use prctl(PR_SET_THP_DISABLE) instead? "If arg2 has a
> > >> nonzero value, the flag is set, otherwise it is cleared." says the
> > >> manpage. Do it before the mmap and you avoid the race as well?
> > > 
> > > Unfortunately, prctl(PR_SET_THP_DISABLE) didn't help :(
> > > When I've tried to use it, I've ended up with VM_NOHUGEPAGE set on all 
> > > VMAs
> > > created after prctl(). This returns me to the state when 
> > > checkpoint-restore
> > > alters the application vma->vm_flags although it shouldn't and I do not 
> > > see
> > > a way to fix it using existing interfaces.
> > 
> > [CC linux-api, should have been done in the initial posting already]
> 
> Sorry, missed that.
>  
> > Hm so the prctl does:
> > 
> > if (arg2)
> > me->mm->def_flags |= VM_NOHUGEPAGE;
> > else
> > me->mm->def_flags &= ~VM_NOHUGEPAGE;
> > 
> > That's rather lazy implementation IMHO. Could we change it so the flag
> > is stored elsewhere in the mm, and the code that decides to (not) use
> > THP will check both the per-vma flag and the per-mm flag?
> 
> I afraid I don't understand how that can help.
> What we need is an ability to temporarily disable collapse of the pages in
> VMAs that do not have VM_*HUGEPAGE flags set and that after we re-enable
> THP, the vma->vm_flags for those VMAs will remain intact.

Why cannot khugepaged simply skip over all VMAs which have userfault
regions registered? This would sound like a less error prone approach to
me.
-- 
Michal Hocko
SUSE Labs

[PATCH 1/2] ARM: sun8i: v3s: add device nodes for DE2 display pipeline

[Icenowy Zheng]

Allwinner V3s SoC features a "Display Engine 2.0" with only one mixer
and only one TCON connected to this mixer, which have RGB LCD output.

Add device nodes for this display pipeline.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 83 
 1 file changed, 83 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a49ebef53c91..3a06dc5b3746 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -61,6 +61,12 @@
};
};
 
+   de: display-engine {
+   compatible = "allwinner,sun8i-v3s-display-engine";
+   allwinner,pipelines = <>;
+   status = "disabled";
+   };
+
timer {
compatible = "arm,armv7-timer";
interrupts = ,
@@ -95,6 +101,83 @@
#size-cells = <1>;
ranges;
 
+   display_clocks: clock@100 {
+   compatible = "allwinner,sun8i-v3s-de2-clk";
+   reg = <0x0100 0x10>;
+   clocks = < CLK_DE>,
+< CLK_BUS_DE>;
+   clock-names = "mod",
+ "bus";
+   resets = < RST_BUS_DE>;
+   #clock-cells = <1>;
+   #reset-cells = <1>;
+   };
+
+   mixer0: mixer@110 {
+   compatible = "allwinner,sun8i-v3s-de2-mixer";
+   reg = <0x0110 0x10>;
+   clocks = <_clocks 0>,
+<_clocks 6>;
+   clock-names = "bus",
+ "mod";
+   resets = <_clocks 0>;
+   assigned-clocks = <_clocks 6>;
+   assigned-clock-rates = <15000>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mixer0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   mixer0_out_tcon0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_in_mixer0>;
+   };
+   };
+   };
+   };
+
+   tcon0: lcd-controller@1c0c000 {
+   compatible = "allwinner,sun8i-v3s-tcon";
+   reg = <0x01c0c000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_TCON0>,
+< CLK_TCON0>;
+   clock-names = "ahb",
+ "tcon-ch0";
+   clock-output-names = "tcon-pixel-clock";
+   resets = < RST_BUS_TCON0>;
+   reset-names = "lcd";
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   tcon0_in: port@0 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <0>;
+
+   tcon0_in_mixer0: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = 
<_out_tcon0>;
+   };
+   };
+
+   tcon0_out: port@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+   };
+   };
+   };
+
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.12.2

Re: [PATCH 4/4] iio: hi8435: cleanup reset gpio

[Vladimir Barinov]

On 23.05.2017 11:18, Nikita Yushchenko wrote:

Reset GPIO is active low.

Currently driver uses gpiod_set_value(1) to clean reset, which depends
on device tree to contain GPIO_ACTIVE_HIGH - that does not match reality.

This fixes driver to use _raw version of gpiod_set_value() to enforce
active-low semantics despite of what's written in device tree. Allowing
device tree to override that only opens possibility for errors and does
not add any value.

Additionally, use _cansleep version to make things work with i2c-gpio
and other sleeping gpio drivers.

The reset gpio comes from platform hence it should be handled by DTS.

In driver the gpio should not be raw.

Even the hi8435 is active low but platform may invert signal (f.e. by
adding trigger on the circuit path).

I see.  However - isn't this pure theoretic?  Does such case exist?

I assure you that this is frequently used.

Simply search google for "simple voltage level shifter"
It might be on PNP or NPN transistor, hence logic might be inverted.



In vast majority of cases, GPIO polarity is chip-specific, not
chip-use-specific.  Thus this knowlege belongs to driver and not to
device tree describing particular chip usage.  Having this always
defined at usage side is IMO major source of errors.

GPIO comes from SoC then "circuit path" and finally chip reset input.

What do you propose if h/w circuit path has simple voltage level shifter 
on transistor. How to differentiate PNP and NPN cases?


Regards,
Vladimir

Re: [PATCH 6/7] sh: Use lib/ashldi3,ashrdi3,lshrdi3}.c

[kbuild test robot]

Hi Palmer,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2]
[cannot apply to next-20170524]
[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/Palmer-Dabbelt/lib-Add-shared-copies-of-some-GCC-library-routines/20170524-170717
config: sh-titan_defconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
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=sh 

All errors (new ones prefixed by >>):

>> arch/sh/kernel/built-in.o:(___ksymtab+__lshrsi3_r0+0x0): undefined reference 
>> to `__lshrsi3_r0'
>> arch/sh/kernel/built-in.o:(___ksymtab+__lshrsi3+0x0): undefined reference to 
>> `__lshrsi3'

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


.config.gz
Description: application/gzip

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

[Vlastimil Babka]

On 05/24/2017 12:39 PM, Mike Rapoport wrote:
>> Hm so the prctl does:
>>
>> if (arg2)
>> me->mm->def_flags |= VM_NOHUGEPAGE;
>> else
>> me->mm->def_flags &= ~VM_NOHUGEPAGE;
>>
>> That's rather lazy implementation IMHO. Could we change it so the flag
>> is stored elsewhere in the mm, and the code that decides to (not) use
>> THP will check both the per-vma flag and the per-mm flag?
> 
> I afraid I don't understand how that can help.
> What we need is an ability to temporarily disable collapse of the pages in
> VMAs that do not have VM_*HUGEPAGE flags set and that after we re-enable
> THP, the vma->vm_flags for those VMAs will remain intact.

That's what I'm saying - instead of implementing the prctl flag via
mm->def_flags (which gets permanently propagated to newly created vma's
but e.g. doesn't affect already existing ones), it would be setting a
flag somewhere in mm, which khugepaged (and page faults) would check in
addition to the per-vma flags.


> --
> Sincerely yours,
> Mike.
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 

Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

[Peter Zijlstra]

On Wed, May 24, 2017 at 10:50:53AM +0100, Juri Lelli wrote:

> Agreed. However, problem seems to be that
> 
>  - in my opinion (current implementation) this translated into scaling
>runtime considering current freq and cpu-max-capacity; and this is
>required when frequency scaling is enabled and we still want to meet
>a task's guaranteed bandwidth

Just so. The bandwidth they request is based on instructions/work. We
need to get a certain amount of instructions sorted. Nobody cares we get
an exact 10% at random frequency if they loose they finger because we
didn't get that final instruction out that stops the saw blade.

>  - Luca seemed instead to be inclined to say that, if we scale runtime
>for !reclaim tasks, such tasks are basically allowed to run for more
>time (when frequency is lower than max) by using some of the
>bandwidth not allocated to themselves

Yes, that's a wrong view :-) We don't care about 'time', we care about
getting the instruction stream / work completed.

Re: [Question] Mlocked count will not be decreased

[Xishi Qiu]

On 2017/5/24 18:32, Vlastimil Babka wrote:

> On 05/24/2017 10:32 AM, Yisheng Xie wrote:
>> Hi Kefeng，
>> Could you please try this patch.
>>
>> Thanks
>> Yisheng Xie
>> -
>> From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
>> From: Yisheng Xie 
>> Date: Wed, 24 May 2017 16:01:24 +0800
>> Subject: [PATCH] mlock: fix mlock count can not decrease in race condition
>>
>> Kefeng reported that when run the follow test the mlock count in meminfo
>> cannot be decreased:
>>  [1] testcase
>>  linux:~ # cat test_mlockal
>>  grep Mlocked /proc/meminfo
>>   for j in `seq 0 10`
>>   do
>>  for i in `seq 4 15`
>>  do
>>  ./p_mlockall >> log &
>>  done
>>  sleep 0.2
>>  done
>>  sleep 5 # wait some time to let mlock decrease
>>  grep Mlocked /proc/meminfo
>>
>>  linux:~ # cat p_mlockall.c
>>  #include 
>>  #include 
>>  #include 
>>
>>  #define SPACE_LEN   4096
>>
>>  int main(int argc, char ** argv)
>>  {
>>  int ret;
>>  void *adr = malloc(SPACE_LEN);
>>  if (!adr)
>>  return -1;
>>
>>  ret = mlockall(MCL_CURRENT | MCL_FUTURE);
>>  printf("mlcokall ret = %d\n", ret);
>>
>>  ret = munlockall();
>>  printf("munlcokall ret = %d\n", ret);
>>
>>  free(adr);
>>  return 0;
>>  }
>>
>> When __munlock_pagevec, we ClearPageMlock but isolation_failed in race
>> condition, and we do not count these page into delta_munlocked, which cause 
>> mlock
> 
> Race condition with what? Who else would isolate our pages?
> 

Hi Vlastimil,

I find the root cause, if the page was not cached on the current cpu,
lru_add_drain() will not push it to LRU. So we should handle fail
case in mlock_vma_page().

follow_page_pte()
...
if (page->mapping && trylock_page(page)) {
lru_add_drain();  /* push cached pages to LRU */
/*
 * Because we lock page here, and migration is
 * blocked by the pte's page reference, and we
 * know the page is still mapped, we don't even
 * need to check for file-cache page truncation.
 */
mlock_vma_page(page);
unlock_page(page);
}
...

I think we should add yisheng's patch, also we should add the following change.
I think it is better than use lru_add_drain_all().

diff --git a/mm/mlock.c b/mm/mlock.c
index 3d3ee6c..ca2aeb9 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -88,6 +88,11 @@ void mlock_vma_page(struct page *page)
count_vm_event(UNEVICTABLE_PGMLOCKED);
if (!isolate_lru_page(page))
putback_lru_page(page);
+   else {
+   ClearPageMlocked(page);
+   mod_zone_page_state(page_zone(page), NR_MLOCK,
+   -hpage_nr_pages(page));
+   }
}
 }

Thanks,
Xishi Qiu

Re: [PATCH 7/7] perf script: mark inlined frames and do not print DSO for them

[Milian Wolff]

On Monday, May 22, 2017 2:11:58 PM CEST Namhyung Kim wrote:
> On Thu, May 18, 2017 at 09:34:11PM +0200, Milian Wolff wrote:
> > Instead of showing the (repeated) DSO name of the non-inlined
> > frame, we now show the "(inlined)" suffix instead.
> > 
> > Before:
> >214f7 __hypot_finite (/usr/lib/libm-2.25.so)
> >
> > ace3 hypot (/usr/lib/libm-2.25.so)
> > 
> >  std::__complex_abs
> >  (/home/milian/projects/src/perf-tests/inlining)
> >  std::abs
> >  (/home/milian/projects/src/perf-tests/inlining)
> >  std::_Norm_helper::_S_do_it
> >  (/home/milian/projects/src/perf-tests/inlining)
> >  std::norm
> >  (/home/milian/projects/src/perf-tests/inlining)
> >  
> >  a4a main
> >  (/home/milian/projects/src/perf-tests/inlining)
> >
> >20510 __libc_start_main (/usr/lib/libc-2.25.so)
> >
> >  bd9 _start
> >  (/home/milian/projects/src/perf-tests/inlining)
> > 
> > After:
> >214f7 __hypot_finite (/usr/lib/libm-2.25.so)
> >
> > ace3 hypot (/usr/lib/libm-2.25.so)
> > 
> >  std::__complex_abs (inlined)
> >  std::abs (inlined)
> >  std::_Norm_helper::_S_do_it
> >  (inlined)
> >  std::norm (inlined)
> 
> Shouldn't they have 'a4a' too?

Yes, I think I forgot to update the commit message after I changed the 
behavior to keep compatibility with stackcollapse-perf.pl.

Will update the message.

Thanks

-- 
Milian Wolff | milian.wo...@kdab.com | Software Engineer
KDAB (Deutschland) GmbH KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH 4/7] mips: Use lib/{ashldi3,ashrdi3,cmpdi2,lshrdi3,ucmpdi2}.c

[kbuild test robot]

Hi Palmer,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2]
[cannot apply to next-20170524]
[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/Palmer-Dabbelt/lib-Add-shared-copies-of-some-GCC-library-routines/20170524-170717
config: mips-defconfig (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
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=mips 

All errors (new ones prefixed by >>):

>> ERROR: "__ucmpdi2" [fs/xfs/xfs.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH 1/2] staging: fsl-dpaa2/eth: Fix address translations

[Laurentiu Tudor]

Hi Ioana,

Debatable nit inline.

On 05/24/2017 03:13 PM, Ioana Radulescu wrote:
> Use the correct mechanisms for translating a DMA-mapped IOVA
> address into a virtual one. Without this fix, once SMMU is
> enabled on Layerscape platforms, the Ethernet driver throws
> IOMMU translation faults.
>
> Signed-off-by: Nipun Gupta 
> Signed-off-by: Ioana Radulescu 
> ---
>   drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 25 
> +++--
>   drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  1 +
>   2 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
> b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
> index 6f9eed66c64d..3fee0d6f17e0 100644
> --- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
> +++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
> @@ -37,6 +37,7 @@
>   #include 
>   #include 
>   #include 
> +#include 
>
>   #include "../../fsl-mc/include/mc.h"
>   #include "../../fsl-mc/include/mc-sys.h"
> @@ -54,6 +55,16 @@ MODULE_DESCRIPTION("Freescale DPAA2 Ethernet Driver");
>
>   const char dpaa2_eth_drv_version[] = "0.1";
>
> +static void *dpaa2_iova_to_virt(struct iommu_domain *domain,

if you pass a "struct dpaa2_eth_priv *priv" instead of "iommu_domain" 
you can move the priv->iommu_domain reference in the function and 
slightly simplify the call sites.

---
Best Regards, Laurentiu

[PATCH v3 1/9] ASoC: sun8i-codec-analog: split out mbias

[Icenowy Zheng]

From: Icenowy Zheng 

Allwinner V3s features an analog codec without MBIAS pin.

Split out this part, in order to prepare for the V3s analog codec.

Signed-off-by: Icenowy Zheng 
---
Changes in v3:
- Fixed a missing line in v2.

 sound/soc/sunxi/sun8i-codec-analog.c | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/sound/soc/sunxi/sun8i-codec-analog.c 
b/sound/soc/sunxi/sun8i-codec-analog.c
index 6c17c99c2c8d..edcc3eb7cd9a 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -289,11 +289,6 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_common_widgets[] = {
/* Microphone input */
SND_SOC_DAPM_INPUT("MIC1"),
 
-   /* Microphone Bias */
-   SND_SOC_DAPM_SUPPLY("MBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
-   SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MMICBIASEN,
-   0, NULL, 0),
-
/* Mic input path */
SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
 SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN, 0, NULL, 0),
@@ -453,6 +448,27 @@ static int sun8i_codec_add_headphone(struct 
snd_soc_component *cmpnt)
return 0;
 }
 
+/* mbias specific widget */
+static const struct snd_soc_dapm_widget sun8i_codec_mbias_widgets[] = {
+   SND_SOC_DAPM_SUPPLY("MBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
+   SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MMICBIASEN,
+   0, NULL, 0),
+};
+
+static int sun8i_codec_add_mbias(struct snd_soc_component *cmpnt)
+{
+   struct snd_soc_dapm_context *dapm = snd_soc_component_get_dapm(cmpnt);
+   struct device *dev = cmpnt->dev;
+   int ret;
+
+   ret = snd_soc_dapm_new_controls(dapm, sun8i_codec_mbias_widgets,
+   ARRAY_SIZE(sun8i_codec_mbias_widgets));
+   if (ret)
+   dev_err(dev, "Failed to add MBIAS DAPM widgets: %d\n", ret);
+
+   return ret;
+}
+
 /* hmic specific widget */
 static const struct snd_soc_dapm_widget sun8i_codec_hmic_widgets[] = {
SND_SOC_DAPM_SUPPLY("HBIAS", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
@@ -679,6 +695,7 @@ struct sun8i_codec_analog_quirks {
bool has_hmic;
bool has_linein;
bool has_lineout;
+   bool has_mbias;
bool has_mic2;
 };
 
@@ -686,12 +703,14 @@ static const struct sun8i_codec_analog_quirks 
sun8i_a23_quirks = {
.has_headphone  = true,
.has_hmic   = true,
.has_linein = true,
+   .has_mbias  = true,
.has_mic2   = true,
 };
 
 static const struct sun8i_codec_analog_quirks sun8i_h3_quirks = {
.has_linein = true,
.has_lineout= true,
+   .has_mbias  = true,
.has_mic2   = true,
 };
 
@@ -734,6 +753,12 @@ static int sun8i_codec_analog_cmpnt_probe(struct 
snd_soc_component *cmpnt)
return ret;
}
 
+   if (quirks->has_mbias) {
+   ret = sun8i_codec_add_mbias(cmpnt);
+   if (ret)
+   return ret;
+   }
+
if (quirks->has_mic2) {
ret = sun8i_codec_add_mic2(cmpnt);
if (ret)
-- 
2.12.2

Re: [PATCH] net: fix potential null pointer dereference

[Pablo Neira Ayuso]

On Tue, May 23, 2017 at 06:18:37PM -0500, Gustavo A. R. Silva wrote:
> Add null check to avoid a potential null pointer dereference.
> 
> Addresses-Coverity-ID: 1408831
> Signed-off-by: Gustavo A. R. Silva 

Acked-by: Pablo Neira Ayuso 

This is a fix for the net.git tree BTW.

Re: Use case for TASKS_RCU

[Masami Hiramatsu]

Sorry, I missed this thread,

On Tue, 16 May 2017 09:07:08 -0400
Steven Rostedt  wrote:

> On Tue, 16 May 2017 05:23:54 -0700
> "Paul E. McKenney"  wrote:
> 
> > On Tue, May 16, 2017 at 08:22:33AM +0200, Ingo Molnar wrote:
> > > 
> > > * Paul E. McKenney  wrote:
> > >   
> > > > Hello!
> > > > 
> > > > The question of the use case for TASKS_RCU came up, and here is my
> > > > understanding.  Steve will not be shy about correcting any 
> > > > misconceptions
> > > > I might have.  ;-)
> > > > 
> > > > The use case is to support freeing of trampolines used in 
> > > > tracing/probing
> > > > in CONFIG_PREEMPT=y kernels.  It is necessary to wait until any task
> > > > executing in the trampoline in question has left it, taking into account
> > > > that the trampoline's code might be interrupted and preempted.  However,
> > > > the code in the trampolines is guaranteed never to context switch.
> > > > 
> > > > Note that in CONFIG_PREEMPT=n kernels, synchronize_sched() suffices.
> > > > It is therefore tempting to think in terms of disabling preemption 
> > > > across
> > > > the trampolines, but there is apparently not enough room to accommodate
> > > > the needed preempt_disable() and preempt_enable() in the code invoking
> > > > the trampoline, and putting the preempt_disable() and preempt_enable()
> > > > in the trampoline itself fails because of the possibility of preemption
> > > > just before the preempt_disable() and just after the preempt_enable().
> > > > Similar reasoning rules out use of rcu_read_lock() and 
> > > > rcu_read_unlock().  
> > > 
> > > So how was this solved before TASKS_RCU? Also, nothing uses 
> > > call_rcu_tasks() at 
> > > the moment, so it's hard for me to review its users. What am I missing?  
> > 
> > Before TASKS_RCU, the trampolines were just leaked when CONFIG_PREEMPT=y.
> 
> Actually, things simply were not implemented. This is why optimized
> kprobes is dependent on !CONFIG_PREEMPT. In fact, we can now optimize
> kprobes on CONFIG_PREEMPT with this utility. Right Masami?

Yes, I just haven't implemented it. OK, I'll use synchronize_rcu_tasks.

> With ftrace, perf and other "dynamic" users (where the ftrace_ops was
> created via a kmalloc), would not get the benefit of being called
> directly. They all needed to have their mcount/fentry's call a static
> trampoline that disabled preemption before calling the callback. This
> static trampoline is shared by all, so even if perf was the only
> callback for the function, it had to call this trampoline that iterated
> through all registered ftrace_ops to see which one had a callback for
> the given function.

For the optimized kprobes, it always jumps into dynamically allocated
trampoline, so we have no chance to disable preemption.

Thank you,

> 
> With this utility, perf not only gets the benefit of not having to use
> that static loop trampoline, it can even have its own trampoline
> created that doesn't even need to do the check if perf wants this
> function or not, as the only way the trampoline is called, is if perf
> wanted it.
> 
> > 
> > Current mainline kernel/trace/ftrace.c uses synchronize_rcu_tasks().
> > So yes, currently one user.
> > 
> 
> And the kpatch folks want to use it too.
> 
> -- Steve


-- 
Masami Hiramatsu 

Re: [PATCH] ARM: dts: rockchip: add adc button for Firefly

[Heiko Stuebner]

Hi Randy,

Am Sonntag, 7. Mai 2017, 22:26:27 CEST schrieb Randy Li:
> The only adc button connected to adc input is recovery button.
> 
> Signed-off-by: Randy Li 
> ---
>  arch/arm/boot/dts/rk3288-firefly-reload.dts | 17 +
>  arch/arm/boot/dts/rk3288-firefly.dtsi   | 13 +
>  2 files changed, 30 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/rk3288-firefly-reload.dts 
> b/arch/arm/boot/dts/rk3288-firefly-reload.dts
> index d0b3204a..ed1baa8 100644
> --- a/arch/arm/boot/dts/rk3288-firefly-reload.dts
> +++ b/arch/arm/boot/dts/rk3288-firefly-reload.dts
> @@ -48,6 +48,19 @@
>   model = "Firefly-RK3288-reload";
>   compatible = "firefly,firefly-rk3288-reload", "rockchip,rk3288";
>  
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = < 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <180>;
> +
> + button-recovery {
> + label = "Recovery";
> + linux,code = ;

I don't think KEY_BACK is really a suitable keycode for your recovery key.

Looking at other devices and already available keycodes. I guess nice
choices would be one of

- KEY_VENDOR
- KEY_MENU
- KEY_CONFIG

With for example meson adding KEY_VENDOR as update key recently
https://lkml.org/lkml/2017/3/7/196

So KEY_VENDOR would look like a good choice for us as well.


Heiko

> + press-threshold-microvolt = <0>;
> + };
> + };
> +
>   gpio-keys {
>   compatible = "gpio-keys";
>  
> @@ -246,6 +259,10 @@
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
>   {
>   bus-width = <4>;
>   cap-mmc-highspeed;
> diff --git a/arch/arm/boot/dts/rk3288-firefly.dtsi 
> b/arch/arm/boot/dts/rk3288-firefly.dtsi
> index 10793ac..63b8b2d 100644
> --- a/arch/arm/boot/dts/rk3288-firefly.dtsi
> +++ b/arch/arm/boot/dts/rk3288-firefly.dtsi
> @@ -49,6 +49,19 @@
>   reg = <0 0x8000>;
>   };
>  
> + adc-keys {
> + compatible = "adc-keys";
> + io-channels = < 1>;
> + io-channel-names = "buttons";
> + keyup-threshold-microvolt = <180>;
> +
> + button-recovery {
> + label = "Recovery";
> + linux,code = ;
> + press-threshold-microvolt = <0>;
> + };
> + };
> +
>   dovdd_1v8: dovdd-1v8-regulator {
>   compatible = "regulator-fixed";
>   regulator-name = "dovdd_1v8";
> 

[PATCH v3 9/9] ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board

[Icenowy Zheng]

The Lichee Pi Zero Dock board has an audio jack and an onboard MIC.

Enable them.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts 
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
index d1311098ea45..80f477738668 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts
@@ -55,6 +55,15 @@
};
 };
 
+ {
+   allwinner,audio-routing =
+   "Headphone", "HP",
+   "Headphone", "HPCOM",
+   "MIC1", "Mic",
+   "Mic",  "HBIAS";
+   status = "okay";
+};
+
  {
broken-cd;
bus-width = <4>;
-- 
2.12.2

Re: [PATCHv2] ARM32: Support mremap() for sigpage/vDSO

[Dmitry Safonov]

+ Adding back to CC x86 guys - as I've removed in ping messages.

On 05/23/2017 11:09 PM, Russell King - ARM Linux wrote:

On Thu, May 18, 2017 at 02:13:29PM +0300, Dmitry Safonov wrote:

On 04/25/2017 08:18 PM, Dmitry Safonov wrote:

On 04/14/2017 04:25 PM, Dmitry Safonov wrote:

CRIU restores application mappings on the same place where they
were before Checkpoint. That means, that we need to move vDSO
and sigpage during restore on exactly the same place where
they were before C/R.

Make mremap() code update mm->context.{sigpage,vdso} pointers
during VMA move. Sigpage is used for landing after handling
a signal - if the pointer is not updated during moving, the
application might crash on any signal after mremap().

vDSO pointer on ARM32 is used only for setting auxv at this moment,
update it during mremap() in case of future usage.

Without those updates, current work of CRIU on ARM32 is not reliable.
Historically, we error Checkpointing if we find vDSO page on ARM32
and suggest user to disable CONFIG_VDSO.
But that's not correct - it goes from x86 where signal processing
is ended in vDSO blob. For arm32 it's sigpage, which is not disabled
with `CONFIG_VDSO=n'.

Looks like C/R was working by luck - because userspace on ARM32 at
this moment always sets SA_RESTORER.

Cc: linux-arm-ker...@lists.infradead.org
Cc: Russell King 
Cc: Will Deacon 
Cc: Andy Lutomirski 
Cc: Thomas Gleixner 
Cc: Cyrill Gorcunov 
Cc: Pavel Emelyanov 
Cc: Christopher Covington 
Signed-off-by: Dmitry Safonov 
---
v2: (buildbot) Fix (unsinged long) to (void*) cast warning.

  arch/arm/kernel/process.c |  8 
  arch/arm/kernel/vdso.c| 18 ++
  arch/x86/entry/vdso/vma.c |  3 ---
  mm/mmap.c |  4 
  4 files changed, 30 insertions(+), 3 deletions(-)


Ping?


Ping?


I'm mostly happy with the ARM bits, but I can't take the patch without
acks from others because it touches other architectures/generic code.



Fair enough, thanks.

Andy, does moving of this WARN_ON() looks good to you?
I've done it to reuse it over arches and between vdso/sigpage mappings,
reducing code duplication.

Here is the patch, so you don't need to search it in the mailbox:
https://patchwork.kernel.org/patch/9681273/

--
 Dmitry

[PATCH v3 7/9] ARM: dts: sun8i: add DMA engine in V3s DTSI

[Icenowy Zheng]

From: Icenowy Zheng 

Allwinner V3s SoC features a DMA engine.

Add it in the DTSI file.

Signed-off-by: Icenowy Zheng 
Acked-by: Chen-Yu Tsai 
---
Changes in v3:
- Added Chen-Yu's ACK.

 arch/arm/boot/dts/sun8i-v3s.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a49ebef53c91..e0e99bbebdb3 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -95,6 +95,15 @@
#size-cells = <1>;
ranges;
 
+   dma: dma-controller@01c02000 {
+   compatible = "allwinner,sun8i-v3s-dma";
+   reg = <0x01c02000 0x1000>;
+   interrupts = ;
+   clocks = < CLK_BUS_DMA>;
+   resets = < RST_BUS_DMA>;
+   #dma-cells = <1>;
+   };
+
mmc0: mmc@01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
-- 
2.12.2

Re: [RESEND PATCH V7 5/7] regulator: da9061: BUCK and LDO regulator driver

[Mark Brown]

On Wed, May 24, 2017 at 09:32:43AM +0100, Lee Jones wrote:

> Plan is to push this through the MFD tree.

Great, thanks.

> Do you want a PR for this one?

Ideally but it's not super urgent if (I've started handling these by
keeping a note of the pull information and only merging if there's an
actual problem, that way there's less cross tree merges show up when I
send stuff to Linus).


signature.asc
Description: PGP signature

Re: [PATCH v3 0/9] Add support for the audio codec on Allwinner V3s

[Vinod Koul]

On Wed, May 24, 2017 at 06:05:58PM +0800, Icenowy Zheng wrote:
> Allwinner V3s features a audio codec with dedicated digital and analog parts,
> like the ones on A23/H3, but much simpler (lack of MIC2, LINE IN and MBIAS).
> 
> Add support for it.
> 
> In order to make the codec usable, DMA support is also added in this series.
> 
> Patch 1 split out MBIAS in analog codec driver.
> 
> Patch 2 prepared a set of objects that have MIC2 and LINEIN stripped out
> for V3s.
> 
> Patch 3/4 adds support for V3s in analog/digital codec.
> 
> Patch 5 add the gate bit as a common quirk of sun6i-dma driver, as V3s also
> needs it.
> 
> Patch 6 really adds support for V3s in DMA engine.
> 
> Patch 7/8/9 adds three parts of device tree: DMA engine, codec support
> and enable the codec for Lichee Pi Zero dock.
> 
> Icenowy Zheng (9):
>   ASoC: sun8i-codec-analog: split out mbias
>   ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for
> V3s
>   ASoC: sun8i-codec-analog: add support for V3s SoC
>   ASoC: sun4i-codec: Add support for V3s codec
>   dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk
>   dmaengine: sun6i: support V3s SoC variant
>   ARM: dts: sun8i: add DMA engine in V3s DTSI
>   ARM: dts: sun8i: add audio codec support into V3s DTSI
>   ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board

And why do we need the cross tree submission?? I have asked before and was
met with silence! [1]

Can you please split it up per subsystem to make it easy for everyone and
clearly spell out dependencies.

[1]: https://www.spinics.net/lists/dmaengine/msg12884.html

-- 
~Vinod

Re: [PATCH v3 0/9] Add support for the audio codec on Allwinner V3s

[Vinod Koul]

Fixed Arnd email now..

On Wed, May 24, 2017 at 04:10:08PM +0530, Vinod Koul wrote:
> On Wed, May 24, 2017 at 06:05:58PM +0800, Icenowy Zheng wrote:
> > Allwinner V3s features a audio codec with dedicated digital and analog 
> > parts,
> > like the ones on A23/H3, but much simpler (lack of MIC2, LINE IN and MBIAS).
> > 
> > Add support for it.
> > 
> > In order to make the codec usable, DMA support is also added in this series.
> > 
> > Patch 1 split out MBIAS in analog codec driver.
> > 
> > Patch 2 prepared a set of objects that have MIC2 and LINEIN stripped out
> > for V3s.
> > 
> > Patch 3/4 adds support for V3s in analog/digital codec.
> > 
> > Patch 5 add the gate bit as a common quirk of sun6i-dma driver, as V3s also
> > needs it.
> > 
> > Patch 6 really adds support for V3s in DMA engine.
> > 
> > Patch 7/8/9 adds three parts of device tree: DMA engine, codec support
> > and enable the codec for Lichee Pi Zero dock.
> > 
> > Icenowy Zheng (9):
> >   ASoC: sun8i-codec-analog: split out mbias
> >   ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for
> > V3s
> >   ASoC: sun8i-codec-analog: add support for V3s SoC
> >   ASoC: sun4i-codec: Add support for V3s codec
> >   dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk
> >   dmaengine: sun6i: support V3s SoC variant
> >   ARM: dts: sun8i: add DMA engine in V3s DTSI
> >   ARM: dts: sun8i: add audio codec support into V3s DTSI
> >   ARM: sun8i: v3s: enable audio on Lichee Pi Zero Dock board
> 
> And why do we need the cross tree submission?? I have asked before and was
> met with silence! [1]
> 
> Can you please split it up per subsystem to make it easy for everyone and
> clearly spell out dependencies.
> 
> [1]: https://www.spinics.net/lists/dmaengine/msg12884.html

-- 
~Vinod

Re: [Question] Mlocked count will not be decreased

[Vlastimil Babka]

On 05/24/2017 12:32 PM, Vlastimil Babka wrote:
> 
> Weird, I can reproduce the issue on my desktop's 4.11 distro kernel, but
> not in qemu and small kernel build, for some reason. So I couldn't test

Ah, Tetsuo's more aggressive testcase worked and I can confirm the fix.
However this would be slightly better, as it doesn't do the increment in
fastpath:

diff --git a/mm/mlock.c b/mm/mlock.c
index 0dd9ca18e19e..721679a2c1aa 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -286,7 +286,7 @@ static void __munlock_pagevec(struct pagevec *pvec, struct 
zone *zone)
 {
int i;
int nr = pagevec_count(pvec);
-   int delta_munlocked;
+   int delta_munlocked = -nr;
struct pagevec pvec_putback;
int pgrescued = 0;
 
@@ -306,6 +306,8 @@ static void __munlock_pagevec(struct pagevec *pvec, struct 
zone *zone)
continue;
else
__munlock_isolation_failed(page);
+   } else {
+   delta_munlocked++;
}
 
/*
@@ -317,7 +319,6 @@ static void __munlock_pagevec(struct pagevec *pvec, struct 
zone *zone)
pagevec_add(_putback, pvec->pages[i]);
pvec->pages[i] = NULL;
}
-   delta_munlocked = -nr + pagevec_count(_putback);
__mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
spin_unlock_irq(zone_lru_lock(zone));

[PATCH] nfc: Ensure presence of required attributes in the activate_target netlink handler

[Mateusz Jurczyk]

Check that the NFC_ATTR_TARGET_INDEX and NFC_ATTR_PROTOCOLS attributes (in
addition to NFC_ATTR_DEVICE_INDEX) are provided by the netlink client
prior to accessing them. This prevents potential unhandled NULL pointer
dereference exceptions which can be triggered by malicious user-mode
programs, if they omit one or both of these attributes.

Signed-off-by: Mateusz Jurczyk 
---
 net/nfc/netlink.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 6b0850e63e09..b251fb936a27 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -907,7 +907,9 @@ static int nfc_genl_activate_target(struct sk_buff *skb, 
struct genl_info *info)
u32 device_idx, target_idx, protocol;
int rc;
 
-   if (!info->attrs[NFC_ATTR_DEVICE_INDEX])
+   if (!info->attrs[NFC_ATTR_DEVICE_INDEX] ||
+   !info->attrs[NFC_ATTR_TARGET_INDEX] ||
+   !info->attrs[NFC_ATTR_PROTOCOLS])
return -EINVAL;
 
device_idx = nla_get_u32(info->attrs[NFC_ATTR_DEVICE_INDEX]);
-- 
2.13.0.219.gdb65acc882-goog

Re: [PATCH v4 00/10] Introduce new mode validation callbacks

[Daniel Vetter]

On Tue, May 23, 2017 at 03:40:24PM +0100, Jose Abreu wrote:
> Hi Daniel,
> 
> 
> On 22-05-2017 16:31, Daniel Vetter wrote:
> > On Mon, May 22, 2017 at 09:56:00AM +0200, Daniel Vetter wrote:
> >> On Fri, May 19, 2017 at 01:52:09AM +0100, Jose Abreu wrote:
> >>> This series is a follow up from the discussion at [1]. We start by
> >>> introducing crtc->mode_valid(), encoder->mode_valid() and
> >>> bridge->mode_valid() callbacks which will be used in followup
> >>> patches and also by cleaning the documentation a little bit. This
> >>> patch is available at [2] and the series depends on it.
> >>>
> >>> We proceed by introducing new helpers to call this new callbacks
> >>> at 1/10.
> >>>
> >>> At 2/10 a helper function is introduced that calls all mode_valid()
> >>> from a set of bridges.
> >>>
> >>> Next, at 3/10 we modify the connector probe helper so that only modes
> >>> which are supported by a given bridge+encoder+crtc combination are
> >>> probbed.
> >>>
> >>> At 4/10 we call all the mode_valid() callbacks for a given pipeline,
> >>> except the connector->mode_valid one, so that the mode is validated.
> >>> This is done before calling mode_fixup().
> >>>
> >>> Finally, from 5/10 to 10/10 we use the new callbacks in drivers that
> >>> can implement it.
> >>>
> >>> [1] 
> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.kernel.org_patch_9702233_=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=YohmJizS2YWha2kjTAHGImBe-ghyCyY_4jKYalIhqcU=mtXW7k5AwOp9H790Zg-U0ZB_OXCyW-SRQD9H5kTX5Ec=
> >>>  
> >>> [2] 
> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_archives_dri-2Ddevel_2017-2DMay_141761.html=DwIBAg=DPL6_X_6JkXFx7AXWqB0tg=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw=YohmJizS2YWha2kjTAHGImBe-ghyCyY_4jKYalIhqcU=N3-YUnWxQAD9jw0y7xFB0fAuCGa_B6Q6yRsL2OmGWM0=
> >>>  
> >>>
> >>> Jose Abreu (10):
> >>>   drm: Add drm_{crtc/encoder/connector}_mode_valid()
> >>>   drm: Introduce drm_bridge_mode_valid()
> >>>   drm: Use new mode_valid() helpers in connector probe helper
> >>>   drm: Use mode_valid() in atomic modeset
> >>>   drm: arc: Use crtc->mode_valid() callback
> >>>   drm/bridge: analogix-anx78xx: Use bridge->mode_valid() callback
> >>>   drm/bridge/synopsys: dw-hdmi: Use bridge->mode_valid() callback
> >>>   drm/arm: malidp: Use crtc->mode_valid() callback
> >>>   drm/atmel-hlcdc: Use crtc->mode_valid() callback
> >>>   drm: vc4: Use crtc->mode_valid() and encoder->mode_valid() callbacks
> >> Looks all real nice, I think a bit more time to get acks/reviews/tested-by
> >> for the driver conversions and I'll go and vacuum this all up.
> > On that: You didn't cc driver maintainers on the driver conversion patches
> > (not all are bridge drivers maintainer by Archit), without that they
> > might miss it. Please remember to do that (you might need to resend to get
> > their attention), scripts/get_maintainers.pl helps with that.
> 
> Yeah, I'm really sorry about that. I was in a different time zone
> with all my head messed up with jetlag so I missed this and maybe
> more :/ Lets wait for some input and I will resend the series if
> needed.

No worries. btw I've applied the 3 kernel-doc patches now, that should
also make it easier to get the driver patches reviewed (since now they
apply directly on linux-next).
-Daniel

> 
> Thanks!
> 
> Best regards,
> Jose Miguel Abreu
> 
> >
> > Thanks, Daniel
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 2/3] ARM: sun8i: v3s: add PWM pinmux nodes

[Icenowy Zheng]

Allwinner V3s have two PWM channels, the first channel can be only at
PB4 pin, and the second channel PB5.

Add their pinmux configurations.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index bb080c4bd22c..db3328a2c89a 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -239,6 +239,16 @@
pins = "PC0", "PC1", "PC2", "PC3";
function = "spi0";
};
+
+   pwm0_pins: pwm0 {
+   pins = "PB4";
+   function = "pwm0";
+   };
+
+   pwm1_pins: pwm1 {
+   pins = "PB5";
+   function = "pwm1";
+   };
};
 
timer@01c20c00 {
-- 
2.12.2

[PATCH 3/3] ARM: sun8i: v3s: add backlight device node for Lichee Pi Zero LCD

[Icenowy Zheng]

The 40-pin LCD connector on Lichee Pi Zero has backlight pins, which is
controlled by the PWM0 controller of the V3s SoC, and the controlling
part is on the board.

Add the PWM and backlight device nodes in the device tree file, but
leave them disabled, as they can only be useful when the LCD is
attached. The LCD device tree overlay files can enable these controllers
and make use of them.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts 
b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
index 387fc2aa546d..e0721bf725d1 100644
--- a/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
+++ b/arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts
@@ -52,6 +52,14 @@
serial0 = 
};
 
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pwms = < 0 5 0>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <8>;
+   status = "disabled";
+   };
+
chosen {
stdout-path = "serial0:115200n8";
};
@@ -86,6 +94,12 @@
status = "okay";
 };
 
+ {
+   pinctrl-0 = <_pins>;
+   pinctrl-names = "default";
+   status = "disabled";
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
-- 
2.12.2

[PATCH 1/3] ARM: sun8i: v3s: add PWM device node

[Icenowy Zheng]

As we have already the support for the PWM controller on V3s SoC, add
its device node in the SoC's DTSI file.

Signed-off-by: Icenowy Zheng 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index a49ebef53c91..bb080c4bd22c 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -255,6 +255,14 @@
interrupts = ;
};
 
+   pwm: pwm@1c21400 {
+   compatible = "allwinner,sun7i-a20-pwm";
+   reg = <0x01c21400 0x400>;
+   clocks = <>;
+   #pwm-cells = <3>;
+   status = "disabled";
+   };
+
lradc: lradc@1c22800 {
compatible = "allwinner,sun4i-a10-lradc-keys";
reg = <0x01c22800 0x400>;
-- 
2.12.2

Re: [PATCH 4.4 000/103] 4.4.70-stable review

[Mark Brown]

On Wed, May 24, 2017 at 05:47:13AM -0700, Guenter Roeck wrote:
> On 05/24/2017 12:03 AM, Greg Kroah-Hartman wrote:

> > 54 passed?  I had a bug here such that all x86 builds were crashing, in
> > the core tty layer, which seems odd that anything would be able to boot
> > with this tree...

> Final qemu test result was
>   total: 115 pass: 89 fail: 26
> with only the x86 and x86_64 images crashing, so this isn't entirely 
> surprising,
> assuming kernelci does not (yet) run any x86/x86_64 qemu tests.

Not qemu but it has some physical x86 tests like:


https://storage.kernelci.org/stable-rc/linux-4.4.y/v4.4.69-104-g2ebff3b7590b/x86/x86_64_defconfig/lab-collabora/boot-minnowboard-max.html

which seem to have managed to boot somehow.  It's a minnowboard with no
video and it's booting to a ramdisk, I don't know if either of those
helped avoid the issue.


signature.asc
Description: PGP signature

Re: [PATCH] frv: remove wrapper header for asm/device.h

[David Howells]

Tobias Klauser  wrote:

> frv's asm/device.h is merely including asm-generic/device.h. Thus, the
> arch specific header can be omitted and the generic header can be used
> directly.
> 
> Signed-off-by: Tobias Klauser 

Reviewed-by: David Howells 

[PATCH] clk: meson-gxbb: Add EE 32K Clock for CEC

[Neil Armstrong]

On Amlogic GX SoCs, there is two CEC controllers :
- An Amlogic CEC custom in the AO domain
- The Synopsys HDMI-TX Controller in the EE domain

Each of these controllers needs a 32.768KHz clock, but there is two paths :
- In the EE domain, the "32k_clk" this patchs is adding
- In the AO domain, with a more complex dual divider more precise setup

The AO 32K clock support will be pushed later in the corresponding
gxbb-aoclk driver when the AE CEC driver is ready.

The EE 32k_clk must be pushed earlier since mainline support for CEC in the
Synopsys HDMI-TX controller is nearby.

Signed-off-by: Neil Armstrong 
---
 drivers/clk/meson/gxbb.c | 54 
 drivers/clk/meson/gxbb.h |  5 -
 2 files changed, 58 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index ad5f027..4b7d85a 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -951,6 +951,51 @@ struct pll_params_table gxl_gp0_params_table[] = {
},
 };
 
+static struct clk_divider gxbb_32k_clk_div = {
+   .reg = (void *)HHI_32K_CLK_CNTL,
+   .shift = 0,
+   .width = 14,
+   .lock = _lock,
+   .hw.init = &(struct clk_init_data){
+   .name = "32k_clk_div",
+   .ops = _divider_ops,
+   .parent_names = (const char *[]){ "32k_clk_sel" },
+   .num_parents = 1,
+   .flags = CLK_SET_RATE_PARENT | CLK_DIVIDER_ROUND_CLOSEST,
+   },
+};
+
+static struct clk_gate gxbb_32k_clk = {
+   .reg = (void *)HHI_32K_CLK_CNTL,
+   .bit_idx = 15,
+   .lock = _lock,
+   .hw.init = &(struct clk_init_data){
+   .name = "32k_clk",
+   .ops = _gate_ops,
+   .parent_names = (const char *[]){ "32k_clk_div" },
+   .num_parents = 1,
+   .flags = CLK_SET_RATE_PARENT,
+   },
+};
+
+static const char *gxbb_32k_clk_parent_names[] = {
+   "xtal", "cts_slow_oscin", "fclk_div3", "fclk_div5"
+};
+
+static struct clk_mux gxbb_32k_clk_sel = {
+   .reg = (void *)HHI_32K_CLK_CNTL,
+   .mask = 0x3,
+   .shift = 16,
+   .lock = _lock,
+   .hw.init = &(struct clk_init_data){
+   .name = "32k_clk_sel",
+   .ops = _mux_ops,
+   .parent_names = gxbb_32k_clk_parent_names,
+   .num_parents = 4,
+   .flags = CLK_SET_RATE_PARENT,
+   },
+};
+
 /* Everything Else (EE) domain gates */
 static MESON_GATE(gxbb_ddr, HHI_GCLK_MPEG0, 0);
 static MESON_GATE(gxbb_dos, HHI_GCLK_MPEG0, 1);
@@ -1158,6 +1203,9 @@ struct pll_params_table gxl_gp0_params_table[] = {
[CLKID_CTS_MCLK_I958_SEL]   = _cts_mclk_i958_sel.hw,
[CLKID_CTS_MCLK_I958_DIV]   = _cts_mclk_i958_div.hw,
[CLKID_CTS_I958]= _cts_i958.hw,
+   [CLKID_32K_CLK] = _32k_clk.hw,
+   [CLKID_32K_CLK_SEL] = _32k_clk_sel.hw,
+   [CLKID_32K_CLK_DIV] = _32k_clk_div.hw,
},
.num = NR_CLKS,
 };
@@ -1278,6 +1326,9 @@ struct pll_params_table gxl_gp0_params_table[] = {
[CLKID_CTS_MCLK_I958_SEL]   = _cts_mclk_i958_sel.hw,
[CLKID_CTS_MCLK_I958_DIV]   = _cts_mclk_i958_div.hw,
[CLKID_CTS_I958]= _cts_i958.hw,
+   [CLKID_32K_CLK] = _32k_clk.hw,
+   [CLKID_32K_CLK_SEL] = _32k_clk_sel.hw,
+   [CLKID_32K_CLK_DIV] = _32k_clk_div.hw,
},
.num = NR_CLKS,
 };
@@ -1392,6 +1443,7 @@ struct pll_params_table gxl_gp0_params_table[] = {
_mali_1,
_cts_amclk,
_cts_mclk_i958,
+   _32k_clk,
 };
 
 static struct clk_mux *const gxbb_clk_muxes[] = {
@@ -1403,6 +1455,7 @@ struct pll_params_table gxl_gp0_params_table[] = {
_cts_amclk_sel,
_cts_mclk_i958_sel,
_cts_i958,
+   _32k_clk_sel,
 };
 
 static struct clk_divider *const gxbb_clk_dividers[] = {
@@ -1411,6 +1464,7 @@ struct pll_params_table gxl_gp0_params_table[] = {
_mali_0_div,
_mali_1_div,
_cts_mclk_i958_div,
+   _32k_clk_div,
 };
 
 static struct meson_clk_audio_divider *const gxbb_audio_dividers[] = {
diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 93b8f07..de5fad0 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -284,8 +284,11 @@
 #define CLKID_CTS_MCLK_I958_SEL  111
 #define CLKID_CTS_MCLK_I958_DIV  112
 #define CLKID_CTS_I958   113
+#define CLKID_32K_CLK114
+#define CLKID_32K_CLK_SEL115
+#define CLKID_32K_CLK_DIV116
 
-#define NR_CLKS  114
+#define NR_CLKS  117
 
 /* include the CLKIDs that have been made part of the stable DT binding */
 #include 
-- 
1.9.1

Re: Asking for guidance in writing IRQ controller driver

[Mason]

Past ramblings archived at

https://www.spinics.net/lists/arm-kernel/msg581128.html

Hello IRQ maintainers,

I'd like to ask for your help writing an interrupt controller
driver. So far, level interrupts work, but edge interrupts
apparently don't.

I'll recap the situation with a diagram.

This interrupt controller is really just a big mux:
128 lines in, 24 lines out.
The controller doesn't latch anything, it just routes IRQ
signals from one input line to one (programmable) output line.
The input lines come from devices.
The output lines are connected to GIC SPIs 0-23 (GIC v1 Cortex A9 MP)



|devices   |

|  ...  |  ...  |  ...  |   (x128)
v   v   v   v

|   \   |   /  |
|\  |  /   | IRQ router
| \ | /|

   |   ...   |  (x24)
   v v

|   GIC v1 |



A high-level description of my current implementation:

- Define a linear irq domain for 128 interrupts.
- in the .map callback, program input i to
- output 0 for level high interrupts
- output 1 for edge rising interrupts


Obviously, I'm missing something, since the driver doesn't quite
work as expected: edge IRQs are not detected.

I have a few random ideas to try, but if someone spots something
wrong, I would be very grateful for a pointer.

I'll paste my WIP code below, for the gory details.

Regards.



#include 
#include 
#include 
#include 

#define IRQ_MAX 128

struct tango_intc {
DECLARE_BITMAP(enabled, IRQ_MAX);
spinlock_t lock;
void __iomem *base;
void __iomem *status;
struct irq_domain *dom;
};

static void tango_isr(struct irq_desc *desc)
{
unsigned int pos, virq;
struct irq_chip *chip = irq_desc_get_chip(desc);
struct tango_intc *intc = irq_desc_get_handler_data(desc);
DECLARE_BITMAP(status, IRQ_MAX);

chained_irq_enter(chip, desc);

memcpy_fromio(status, intc->status, IRQ_MAX / BITS_PER_BYTE);
bitmap_and(status, status, intc->enabled, IRQ_MAX);
for_each_set_bit(pos, status, IRQ_MAX) {
virq = irq_find_mapping(intc->dom, pos);
generic_handle_irq(virq);
}

chained_irq_exit(chip, desc);
}

static void tango_mask(struct irq_data *data)
{
unsigned long flags;
struct tango_intc *intc = data->chip_data;

spin_lock_irqsave(>lock, flags);
__clear_bit(data->hwirq, intc->enabled);
writel_relaxed(data->mask, intc->base + data->hwirq * 4);
spin_unlock_irqrestore(>lock, flags);
}

static void tango_unmask(struct irq_data *data)
{
unsigned long flags;
struct tango_intc *intc = data->chip_data;

#if 0
if (!in_irq() && !in_interrupt()) {
printk("HWIRQ=%lu mask=%u\n", data->hwirq, data->mask);
dump_stack();
}
#endif

spin_lock_irqsave(>lock, flags);
__set_bit(data->hwirq, intc->enabled);
writel_relaxed(BIT(31) | data->mask, intc->base + data->hwirq * 4);
spin_unlock_irqrestore(>lock, flags);
}

int tango_set_type(struct irq_data *data, unsigned int flow_type)
{
printk("%s: IRQ=%lu type=%x\n", __func__, data->hwirq, flow_type);
if (flow_type & IRQ_TYPE_LEVEL_HIGH) {
data->mask = 0x0;
return 0;
}

if (flow_type & IRQ_TYPE_EDGE_RISING) {
data->mask = 0x1;
return 0;
}

dump_stack();
return -ENOSYS;
}


static struct irq_chip tango_chip = {
.name   = "tango",
.irq_mask   = tango_mask,
.irq_unmask = tango_unmask,
.irq_set_type   = tango_set_type,
};

static void my_flow_handler(struct irq_desc *desc)
{
struct irq_data *data = irq_desc_get_irq_data(desc);
if (data->mask == 0)
handle_level_irq(desc);
else if (data->mask == 0)
handle_edge_irq(desc);
}

static int tango_map(struct irq_domain *dom, unsigned int virq, irq_hw_number_t 
hw)
{
struct tango_intc *intc = dom->host_data;
printk("%s: dom=%p virq=%u hwirq=%lu\n", __func__, dom, virq, hw);
irq_domain_set_info(dom, virq, hw, _chip, intc, my_flow_handler, 
NULL, NULL);

return 0;
}

static void tango_unmap(struct irq_domain *d, unsigned int virq)
{
printk("%s: dom=%p virq=%u\n", __func__, d, virq);
dump_stack();
}

struct irq_domain_ops dom_ops =
{
.map= tango_map,
.unmap  = tango_unmap,
.xlate  = irq_domain_xlate_twocell,
};

static int __init tango_irq_init(struct 

[PATCH] Input: elan_i2c - Clean INT stats in FW updating for old Elan touchpad

[KT Liao]

Some old touchapd FWs have interrupt issue after FW updating.
Use reading 34 bytes before IC reset command to clean INT stauts
The modification has been tested in some chromebook system
It should not affect general touchpad in Linux system.

Signed-off-by: KT Liao 
---
 drivers/input/mouse/elan_i2c_i2c.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/input/mouse/elan_i2c_i2c.c 
b/drivers/input/mouse/elan_i2c_i2c.c
index 3be75c6e..842f852 100644
--- a/drivers/input/mouse/elan_i2c_i2c.c
+++ b/drivers/input/mouse/elan_i2c_i2c.c
@@ -612,7 +612,14 @@ static int elan_i2c_finish_fw_update(struct i2c_client 
*client,
long ret;
int error;
int len;
-   u8 buffer[ETP_I2C_INF_LENGTH];
+   u8 buffer[ETP_I2C_REPORT_LEN];
+
+   len = i2c_master_recv(client, buffer, ETP_I2C_REPORT_LEN);
+   if (len != ETP_I2C_REPORT_LEN) {
+   error = len < 0 ? len : -EIO;
+   dev_warn(dev, "failed to read I2C data after FW WDT reset: %d 
(%d)\n",
+   error, len);
+   }
 
reinit_completion(completion);
enable_irq(client->irq);
-- 
2.7.4

[PATCHv6 05/10] x86/boot/64: Add support of additional page table level during early boot

[Kirill A. Shutemov]

This patch adds support for 5-level paging during early boot.
It generalizes boot for 4- and 5-level paging on 64-bit systems with
compile-time switch between them.

Signed-off-by: Kirill A. Shutemov 
---
 arch/x86/boot/compressed/head_64.S  | 23 +++---
 arch/x86/include/asm/pgtable_64.h   |  2 ++
 arch/x86/include/uapi/asm/processor-flags.h |  2 ++
 arch/x86/kernel/head64.c| 48 +
 arch/x86/kernel/head_64.S   | 26 
 5 files changed, 85 insertions(+), 16 deletions(-)

diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index d2ae1f821e0c..3ed26769810b 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -122,9 +122,12 @@ ENTRY(startup_32)
addl%ebp, gdt+2(%ebp)
lgdtgdt(%ebp)
 
-   /* Enable PAE mode */
+   /* Enable PAE and LA57 mode */
movl%cr4, %eax
orl $X86_CR4_PAE, %eax
+#ifdef CONFIG_X86_5LEVEL
+   orl $X86_CR4_LA57, %eax
+#endif
movl%eax, %cr4
 
  /*
@@ -136,13 +139,24 @@ ENTRY(startup_32)
movl$(BOOT_INIT_PGT_SIZE/4), %ecx
rep stosl
 
+   xorl%edx, %edx
+
+   /* Build Top Level */
+   lealpgtable(%ebx,%edx,1), %edi
+   leal0x1007 (%edi), %eax
+   movl%eax, 0(%edi)
+
+#ifdef CONFIG_X86_5LEVEL
/* Build Level 4 */
-   lealpgtable + 0(%ebx), %edi
+   addl$0x1000, %edx
+   lealpgtable(%ebx,%edx), %edi
leal0x1007 (%edi), %eax
movl%eax, 0(%edi)
+#endif
 
/* Build Level 3 */
-   lealpgtable + 0x1000(%ebx), %edi
+   addl$0x1000, %edx
+   lealpgtable(%ebx,%edx), %edi
leal0x1007(%edi), %eax
movl$4, %ecx
 1: movl%eax, 0x00(%edi)
@@ -152,7 +166,8 @@ ENTRY(startup_32)
jnz 1b
 
/* Build Level 2 */
-   lealpgtable + 0x2000(%ebx), %edi
+   addl$0x1000, %edx
+   lealpgtable(%ebx,%edx), %edi
movl$0x0183, %eax
movl$2048, %ecx
 1: movl%eax, 0(%edi)
diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index affcb2a9c563..2160c1fee920 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -14,6 +14,8 @@
 #include 
 #include 
 
+extern p4d_t level4_kernel_pgt[512];
+extern p4d_t level4_ident_pgt[512];
 extern pud_t level3_kernel_pgt[512];
 extern pud_t level3_ident_pgt[512];
 extern pmd_t level2_kernel_pgt[512];
diff --git a/arch/x86/include/uapi/asm/processor-flags.h 
b/arch/x86/include/uapi/asm/processor-flags.h
index 567de50a4c2a..185f3d10c194 100644
--- a/arch/x86/include/uapi/asm/processor-flags.h
+++ b/arch/x86/include/uapi/asm/processor-flags.h
@@ -104,6 +104,8 @@
 #define X86_CR4_OSFXSR _BITUL(X86_CR4_OSFXSR_BIT)
 #define X86_CR4_OSXMMEXCPT_BIT 10 /* enable unmasked SSE exceptions */
 #define X86_CR4_OSXMMEXCPT _BITUL(X86_CR4_OSXMMEXCPT_BIT)
+#define X86_CR4_LA57_BIT   12 /* enable 5-level page tables */
+#define X86_CR4_LA57   _BITUL(X86_CR4_LA57_BIT)
 #define X86_CR4_VMXE_BIT   13 /* enable VMX virtualization */
 #define X86_CR4_VMXE   _BITUL(X86_CR4_VMXE_BIT)
 #define X86_CR4_SMXE_BIT   14 /* enable safer mode (TXT) */
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index f8a2f34fa15d..9403633f4c7c 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -47,6 +47,7 @@ void __init __startup_64(unsigned long physaddr)
 {
unsigned long load_delta, *p;
pgdval_t *pgd;
+   p4dval_t *p4d;
pudval_t *pud;
pmdval_t *pmd, pmd_entry;
int i;
@@ -70,6 +71,11 @@ void __init __startup_64(unsigned long physaddr)
pgd = fixup_pointer(_top_pgt, physaddr);
pgd[pgd_index(__START_KERNEL_map)] += load_delta;
 
+   if (IS_ENABLED(CONFIG_X86_5LEVEL)) {
+   p4d = fixup_pointer(_kernel_pgt, physaddr);
+   p4d[511] += load_delta;
+   }
+
pud = fixup_pointer(_kernel_pgt, physaddr);
pud[510] += load_delta;
pud[511] += load_delta;
@@ -87,9 +93,21 @@ void __init __startup_64(unsigned long physaddr)
pud = fixup_pointer(early_dynamic_pgts[next_early_pgt++], physaddr);
pmd = fixup_pointer(early_dynamic_pgts[next_early_pgt++], physaddr);
 
-   i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
-   pgd[i + 0] = (pgdval_t)pud + _KERNPG_TABLE;
-   pgd[i + 1] = (pgdval_t)pud + _KERNPG_TABLE;
+   if (IS_ENABLED(CONFIG_X86_5LEVEL)) {
+   p4d = fixup_pointer(early_dynamic_pgts[next_early_pgt++], 
physaddr);
+
+   i = (physaddr >> PGDIR_SHIFT) % PTRS_PER_PGD;
+   pgd[i + 0] = (pgdval_t)p4d + _KERNPG_TABLE;
+   pgd[i + 1] = (pgdval_t)p4d + _KERNPG_TABLE;
+
+   i = (physaddr >> P4D_SHIFT) 

[PATCH v5 0/7] ARM: Fix dma_alloc_coherent() and friends for NOMMU

[Vladimir Murzin]

Short story:

Without these patches coherent DMA is broken for András and Alexandre,
so they cannot safely enable DMA on their platforms.

Patches have been circulated on a list since last year without much
attention to changes in dma-coherent.c and dma-noop.c. Meanwhile, ARM
bits have been reviewed and there is no strict objection to get them
merged. Unfortunately, applying only ARM bits doesn't help much and
the original issue would still exist.

Please, let me know how to move with this fix forward?

Long story:

It seems that addition of cache support for M-class CPUs uncovered
latent bug in DMA usage. NOMMU memory model has been treated as being
always consistent; however, for R/M CPU classes memory can be covered
by MPU which in turn might configure RAM as Normal i.e. bufferable and
cacheable. It breaks dma_alloc_coherent() and friends, since data can
stuck in caches now or be buffered.

This patch set is trying to address the issue by providing region of
memory suitable for consistent DMA operations. It is supposed that
such region is marked by MPU as non-cacheable. Robin suggested to
advertise such memory as reserved shared-dma-pool, rather then using
homebrew command line option, and extend dma-coherent to provide
default DMA area in the similar way as it is done for CMA (PATCH
4/7). It allows us to offload all bookkeeping on generic coherent DMA
framework, and it seems that it might be reused by other architectures
like c6x and blackfin.

While reviewing/testing previous versions of the patch set it turned
out that dma-coherent does not take into account "dma-ranges" device
tree property, so it is addressed in PATCH 3/7.

For ARM, dedicated DMA region is required for cases other than:
 - MMU/MPU is off
 - cpu is v7m w/o cache support
 - device is coherent

In case any of the above conditions is true dma operations are forced
to be coherent and wired with dma_noop_ops.

To make life easier NOMMU dma operations are kept in separate
compilation unit.

Since the issue was reported at the same time as Benjamin sent his
patch [1] to allow mmap for NOMMU, his case is also addressed in this
series (PATCH 1/7 and PATCH 2/7).

Thanks!

[1] http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8633/1

Cc: Joerg Roedel 
Cc: Christian Borntraeger 
Cc: Michal Nazarewicz 
Cc: Marek Szyprowski 
Cc: Alan Stern 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: Roger Quadros 
Cc: Greg Kroah-Hartman 
Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Doug Ledford 

Changelog:
v4 -> v5
   - rebased on v4.12-rc2
   - updated description for CONFIG_ARM_DMA_MEM_BUFFERABLE

v3 -> v4
   - rebased on v4.11-rc7
   - made CONFIG_ARM_DMA_MEM_BUFFERABLE optional for CPU_V7M
   - added Arnd's Acked-by

v2 -> v3
   - fixed warnings reported by Alexandre and kbuild robot

v1 -> v2
   - rebased on v4.11-rc1
   - added Robin's Reviewed-by
   - dedicated flag is introduced to use dev->dma_pfn_offset
 rather than mem->device_base in case memory region is
 configured via device tree (so Tested-by discarded there)

RFC v6 -> v1
   - dropped RFC tag
   - added Alexandre's Tested-by

Vladimir Murzin (7):
  dma: Take into account dma_pfn_offset
  dma: Add simple dma_noop_mmap
  drivers: dma-coherent: Account dma_pfn_offset when used with device
tree
  drivers: dma-coherent: Introduce default DMA pool
  ARM: NOMMU: Introduce dma operations for noMMU
  ARM: NOMMU: Set ARM_DMA_MEM_BUFFERABLE for M-class cpus
  ARM: dma-mapping: Remove traces of NOMMU code

 .../bindings/reserved-memory/reserved-memory.txt   |   3 +
 arch/arm/Kconfig   |   1 +
 arch/arm/include/asm/dma-mapping.h |   2 +-
 arch/arm/mm/Kconfig|   8 +-
 arch/arm/mm/Makefile   |   5 +-
 arch/arm/mm/dma-mapping-nommu.c| 253 +
 arch/arm/mm/dma-mapping.c  |  29 +--
 drivers/base/dma-coherent.c|  74 +-
 lib/dma-noop.c |  29 ++-
 9 files changed, 359 insertions(+), 45 deletions(-)
 create mode 100644 arch/arm/mm/dma-mapping-nommu.c

-- 
2.0.0

[tip:x86/boot] x86/KASLR: Parse all 'memmap=' boot option entries

[tip-bot for Baoquan He]

Commit-ID:  d52e7d5a952c5e35783f96e8c5b7fcffbb0d7c60
Gitweb: http://git.kernel.org/tip/d52e7d5a952c5e35783f96e8c5b7fcffbb0d7c60
Author: Baoquan He 
AuthorDate: Sat, 13 May 2017 13:46:28 +0800
Committer:  Ingo Molnar 
CommitDate: Wed, 24 May 2017 09:50:27 +0200

x86/KASLR: Parse all 'memmap=' boot option entries

In commit:

  f28442497b5c ("x86/boot: Fix KASLR and memmap= collision")

... the memmap= option is parsed so that KASLR can avoid those reserved
regions. It uses cmdline_find_option() to get the value if memmap=
is specified, however the problem is that cmdline_find_option() can only
find the last entry if multiple memmap entries are provided. This
is not correct.

Address this by checking each command line token for a "memmap=" match
and parse each instance instead of using cmdline_find_option().

Signed-off-by: Baoquan He 
Acked-by: Kees Cook 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: dan.j.willi...@intel.com
Cc: douly.f...@cn.fujitsu.com
Cc: dyo...@redhat.com
Cc: m.miz...@jp.fujitsu.com
Link: http://lkml.kernel.org/r/1494654390-23861-2-git-send-email-...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/boot/compressed/cmdline.c |   2 +-
 arch/x86/boot/compressed/kaslr.c   | 136 ++---
 arch/x86/boot/string.c |   8 +++
 3 files changed, 91 insertions(+), 55 deletions(-)

diff --git a/arch/x86/boot/compressed/cmdline.c 
b/arch/x86/boot/compressed/cmdline.c
index 73ccf63..9dc1ce6 100644
--- a/arch/x86/boot/compressed/cmdline.c
+++ b/arch/x86/boot/compressed/cmdline.c
@@ -13,7 +13,7 @@ static inline char rdfs8(addr_t addr)
return *((char *)(fs + addr));
 }
 #include "../cmdline.c"
-static unsigned long get_cmd_line_ptr(void)
+unsigned long get_cmd_line_ptr(void)
 {
unsigned long cmd_line_ptr = boot_params->hdr.cmd_line_ptr;
 
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 54c24f0..106e13b 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -9,16 +9,41 @@
  * contain the entire properly aligned running kernel image.
  *
  */
+
+/*
+ * isspace() in linux/ctype.h is expected by next_args() to filter
+ * out "space/lf/tab". While boot/ctype.h conflicts with linux/ctype.h,
+ * since isdigit() is implemented in both of them. Hence disable it
+ * here.
+ */
+#define BOOT_CTYPE_H
+
+/*
+ * _ctype[] in lib/ctype.c is needed by isspace() of linux/ctype.h.
+ * While both lib/ctype.c and lib/cmdline.c will bring EXPORT_SYMBOL
+ * which is meaningless and will cause compiling error in some cases.
+ * So do not include linux/export.h and define EXPORT_SYMBOL(sym)
+ * as empty.
+ */
+#define _LINUX_EXPORT_H
+#define EXPORT_SYMBOL(sym)
+
 #include "misc.h"
 #include "error.h"
-#include "../boot.h"
 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
+/* Macros used by the included decompressor code below. */
+#define STATIC
+#include 
+
+extern unsigned long get_cmd_line_ptr(void);
+
 /* Simplified build-specific string for starting entropy. */
 static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
@@ -62,6 +87,7 @@ struct mem_vector {
 
 static bool memmap_too_large;
 
+
 enum mem_avoid_index {
MEM_AVOID_ZO_RANGE = 0,
MEM_AVOID_INITRD,
@@ -85,49 +111,14 @@ static bool mem_overlaps(struct mem_vector *one, struct 
mem_vector *two)
return true;
 }
 
-/**
- * _memparse - Parse a string with mem suffixes into a number
- * @ptr: Where parse begins
- * @retptr: (output) Optional pointer to next char after parse completes
- *
- * Parses a string into a number.  The number stored at @ptr is
- * potentially suffixed with K, M, G, T, P, E.
- */
-static unsigned long long _memparse(const char *ptr, char **retptr)
+char *skip_spaces(const char *str)
 {
-   char *endptr;   /* Local pointer to end of parsed string */
-
-   unsigned long long ret = simple_strtoull(ptr, , 0);
-
-   switch (*endptr) {
-   case 'E':
-   case 'e':
-   ret <<= 10;
-   case 'P':
-   case 'p':
-   ret <<= 10;
-   case 'T':
-   case 't':
-   ret <<= 10;
-   case 'G':
-   case 'g':
-   ret <<= 10;
-   case 'M':
-   case 'm':
-   ret <<= 10;
-   case 'K':
-   case 'k':
-   ret <<= 10;
-   endptr++;
-   default:
-   break;
-   }
-
-   if (retptr)
-   *retptr = endptr;
-
-   return ret;
+   while (isspace(*str))
+   ++str;
+   return (char *)str;
 }
+#include "../../../../lib/ctype.c"
+#include "../../../../lib/cmdline.c"
 
 static int
 parse_memmap(char *p, unsigned long long 

Re: [PATCH v4 1/2] PCI: Add tango MSI controller support

[Marc Zyngier]

On 24/05/17 11:00, Robin Murphy wrote:
> On 23/05/17 20:15, Mason wrote:
>> On 23/05/2017 20:03, Robin Murphy wrote:
>>> On 23/05/17 18:54, Mason wrote:
 On 23/05/2017 19:03, Bjorn Helgaas wrote:
> On Wed, May 17, 2017 at 04:56:08PM +0200, Marc Gonzalez wrote:
>> On 20/04/2017 16:28, Marc Gonzalez wrote:
>>
>>> +static int tango_set_affinity(struct irq_data *data,
>>> +   const struct cpumask *mask, bool force)
>>> +{
>>> +   return -EINVAL;
>>> +}
>>> +
>>> +static struct irq_chip tango_chip = {
>>> +   .irq_ack= tango_ack,
>>> +   .irq_mask   = tango_mask,
>>> +   .irq_unmask = tango_unmask,
>>> +   .irq_set_affinity   = tango_set_affinity,
>>> +   .irq_compose_msi_msg= tango_compose_msi_msg,
>>> +};
>>
>> Hmmm... I'm wondering why .irq_set_affinity is required.
>>
>> static int setup_affinity(struct irq_desc *desc, struct cpumask *mask)
>> first calls __irq_can_set_affinity() to check whether
>> desc->irq_data.chip->irq_set_affinity) exists.
>>
>> then calls irq_do_set_affinity(>irq_data, mask, false);
>> which calls chip->irq_set_affinity(data, mask, force);
>> = msi_domain_set_affinity()
>> which calls parent->chip->irq_set_affinity() unconditionally.
>>
>> Would it make sense to test that the callback is implemented
>> before calling it?
>>
>>
>> [0.723895] Unable to handle kernel NULL pointer dereference at 
>> virtual address 
>
> I'm not sure what you're asking.
>
> Is this a bug report for the v4 tango driver?

 No.

> Or are you asking whether msi_domain_set_affinity() should be changed
> to check whether parent->chip->irq_set_affinity is implemented?

 Yes. The way things are implemented now, drivers are forced
 to define an irq_set_affinity callback, even if it just returns
 an error, otherwise, the kernel crashes, because of the
 unconditional function pointer deref. 

> msi_domain_set_affinity() has called parent->chip->irq_set_affinity()
> without checking since it was added in 2014 by f3cf8bb0d6c3 ("genirq: Add
> generic msi irq domain support"), so if there's a problem here, it's most
> likely in the tango code.

 The issue is having to define an "empty" function.
 (Unnecessary code bloat and maintenance.)
>>>
>>> AFAICS, only one driver (other than this one) implements a "do nothing"
>>> set_affinity callback - everyone else who doesn't do anything hardware
>>> specific just passes it along via irq_chip_set_affinity_parent().
>>
>> I counted 4. Where did I mess up?
>>
>> advk_msi_set_affinity
>> altera_msi_set_affinity
>> nwl_msi_set_affinity
>> vmd_irq_set_affinity
>> tango_set_affinity
> 
> Fair point - I went through drivers/irqchip and the various
> arch-specific instances and found ls_scfg_msi_set_affinity(), but
> somehow skipped over drivers/pci. Anyway, I think the question stands of
> why are these handful of drivers *not* using irq_chip_set_affinity_parent()?

Probably because they don't have a parent, in the hierarchical sense.
All they have is a chained interrupt (*puke*). Which implies that
changing the affinity of one MSI would affect all of them, completely
confusing unsuspecting userspace such as irqbalance.

> As an outsider, it naively seems logical that the affinity of an MSI
> which just gets translated to a wired interrupt should propagate through
> to the affinity of that wired interrupt, but maybe there are reasons not
> to; I really don't know.

See above. The main issue is that HW folks haven't understood the actual
use of MSIs, and persist in implementing them as an afterthought, based
on some cascading interrupt controller design.

Sad. So sad.

M.
-- 
Jazz is not dead. It just smells funny...

[PATCH] ASoC: simple-card: Fix misleading error message

[Julian Scheel]

In case cpu could not be found the error message would always refer to
/codec/ not being found in DT. Fix this by catching the cpu node not found
case explicitly.

Signed-off-by: Julian Scheel 
---
 sound/soc/generic/simple-card.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/sound/soc/generic/simple-card.c b/sound/soc/generic/simple-card.c
index 7ed84f811205..38d7b601546f 100644
--- a/sound/soc/generic/simple-card.c
+++ b/sound/soc/generic/simple-card.c
@@ -233,13 +233,19 @@ static int asoc_simple_card_dai_link_of(struct 
device_node *node,
snprintf(prop, sizeof(prop), "%scpu", prefix);
cpu = of_get_child_by_name(node, prop);
 
+   if (!cpu) {
+   ret = -EINVAL;
+   dev_err(dev, "%s: Can't find %s DT node\n", __func__, prop);
+   goto dai_link_of_err;
+   }
+
snprintf(prop, sizeof(prop), "%splat", prefix);
plat = of_get_child_by_name(node, prop);
 
snprintf(prop, sizeof(prop), "%scodec", prefix);
codec = of_get_child_by_name(node, prop);
 
-   if (!cpu || !codec) {
+   if (!codec) {
ret = -EINVAL;
dev_err(dev, "%s: Can't find %s DT node\n", __func__, prop);
goto dai_link_of_err;
-- 
2.12.2

Re: [linux-sunxi] [PATCH v3 5/9] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

[Chen-Yu Tsai]

On Wed, May 24, 2017 at 6:06 PM, Icenowy Zheng  wrote:
> From: Icenowy Zheng 
>
> Originally we enable a special gate bit when the compatible indicates
> A23/33.
>
> But according to BSP sources and user manuals, more SoCs will need this
> gate bit.
>
> So make it a common quirk configured in the config struct.
>
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v3:
> - Stripped out the A83T gate bit set.
>
>  drivers/dma/sun6i-dma.c | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a2358780ab2c..69840cf6fe98 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -101,6 +101,11 @@ struct sun6i_dma_config {
> u32 nr_max_channels;
> u32 nr_max_requests;
> u32 nr_max_vchans;
> +   /*
> +* The hardware has a special gate bit, which is needed to
> +* be enabled for some SoCs with a sun6i-style DMA engine.
> +*/
> +   bool gate_needed;

The user manual identifies the gate bit as "DMA MCLK interface circuit
auto gating bit", which, when set to 1, disables auto gating. It also
has a footnote saying "When initializing DMA Controller, bit 2 (this
bit) should be set up."

Please include this information in the comment. Also you might want to
merge the two comment blocks and keep all the information in one place.

Curiously on the A83T I didn't need to set the bit for DMA to work.
ChenYu

>  };
>
>  /*
> @@ -1009,6 +1014,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
> .nr_max_channels = 8,
> .nr_max_requests = 24,
> .nr_max_vchans   = 37,
> +   .gate_needed = true,
>  };
>
>  static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> @@ -1177,10 +1183,10 @@ static int sun6i_dma_probe(struct platform_device 
> *pdev)
> /*
>  * sun8i variant requires us to toggle a dma gating register,
>  * as seen in Allwinner's SDK. This register is not documented
> -* in the A23 user manual.
> +* in the A23 user manual, but documented at least in V3s user
> +* manual.
>  */
> -   if (of_device_is_compatible(pdev->dev.of_node,
> -   "allwinner,sun8i-a23-dma"))
> +   if (sdc->cfg->gate_needed)
> writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
>
> return 0;
> --
> 2.12.2
>
> --
> You received this message because you are subscribed to the Google Groups 
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[tip:x86/urgent] x86/build: Permit building with old make versions

[tip-bot for Jan Kiszka]

Commit-ID:  7e6091209f7f73e2a81943020793b5ad26d645c6
Gitweb: http://git.kernel.org/tip/7e6091209f7f73e2a81943020793b5ad26d645c6
Author: Jan Kiszka 
AuthorDate: Tue, 23 May 2017 18:27:54 +0200
Committer:  Ingo Molnar 
CommitDate: Wed, 24 May 2017 09:05:17 +0200

x86/build: Permit building with old make versions

At least Make 3.82 dislikes the tab in front of the $(warning) function:

  arch/x86/Makefile:162: *** recipe commences before first target.  Stop.

Let's be gentle.

Signed-off-by: Jan Kiszka 
Acked-by: Thomas Gleixner 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1944fcd8-e3df-d1f7-c0e4-60aeb1917...@siemens.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5851411..bf240b9 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -159,7 +159,7 @@ ifdef CONFIG_FUNCTION_GRAPH_TRACER
# If '-Os' is enabled, disable it and print a warning.
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
   undefine CONFIG_CC_OPTIMIZE_FOR_SIZE
- $(warning Disabling CONFIG_CC_OPTIMIZE_FOR_SIZE.  Your compiler does 
not have -mfentry so you cannot optimize for size with 
CONFIG_FUNCTION_GRAPH_TRACER.)
+  $(warning Disabling CONFIG_CC_OPTIMIZE_FOR_SIZE.  Your compiler does 
not have -mfentry so you cannot optimize for size with 
CONFIG_FUNCTION_GRAPH_TRACER.)
 endif
 
 endif

[PATCH v5 5/7] ARM: NOMMU: Introduce dma operations for noMMU

[Vladimir Murzin]

R/M classes of cpus can have memory covered by MPU which in turn might
configure RAM as Normal i.e. bufferable and cacheable. It breaks
dma_alloc_coherent() and friends, since data can stuck in caches now
or be buffered.

This patch factors out DMA support for NOMMU configuration into
separate entity which provides dedicated dma_ops. We have to handle
there several cases:
- configurations with MMU/MPU setup
- configurations without MMU/MPU setup
- special case for M-class, since caches and MPU there are optional

In general we rely on default DMA area for coherent allocations or/and
per-device memory reserves suitable for coherent DMA, so if such
regions are set coherent allocations go from there.

In case MMU/MPU was not setup we fallback to normal page allocator for
DMA memory allocation.

In case we run M-class cpus, for configuration without cache support
(like Cortex-M3/M4) dma operations are forced to be coherent and wired
with dma-noop (such decision is made based on cacheid global
variable); however, if caches are detected there and no DMA coherent
region is given (either default or per-device), dma is disallowed even
MPU is not set - it is because M-class implement system memory map
which defines part of address space as Normal memory.

Reported-by: Alexandre Torgue 
Reported-by: Andras Szemzo 
Tested-by: Benjamin Gaignard 
Tested-by: Andras Szemzo 
Tested-by: Alexandre TORGUE 
Reviewed-by: Robin Murphy 
Signed-off-by: Vladimir Murzin 
Acked-by: Arnd Bergmann 
---
 arch/arm/Kconfig   |   1 +
 arch/arm/include/asm/dma-mapping.h |   2 +-
 arch/arm/mm/Makefile   |   5 +-
 arch/arm/mm/dma-mapping-nommu.c| 253 +
 4 files changed, 257 insertions(+), 4 deletions(-)
 create mode 100644 arch/arm/mm/dma-mapping-nommu.c

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ed801f0..98e15d0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -22,6 +22,7 @@ config ARM
select CLONE_BACKWARDS
select CPU_PM if (SUSPEND || CPU_IDLE)
select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
+   select DMA_NOOP_OPS if !MMU
select EDAC_SUPPORT
select EDAC_ATOMIC_SCRUB
select GENERIC_ALLOCATOR
diff --git a/arch/arm/include/asm/dma-mapping.h 
b/arch/arm/include/asm/dma-mapping.h
index 680d3f3..0eec080 100644
--- a/arch/arm/include/asm/dma-mapping.h
+++ b/arch/arm/include/asm/dma-mapping.h
@@ -18,7 +18,7 @@ extern const struct dma_map_ops arm_coherent_dma_ops;
 
 static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
 {
-   return _dma_ops;
+   return IS_ENABLED(CONFIG_MMU) ? _dma_ops : _noop_ops;
 }
 
 #define HAVE_ARCH_DMA_SUPPORTED 1
diff --git a/arch/arm/mm/Makefile b/arch/arm/mm/Makefile
index 54857bc..ea80df7 100644
--- a/arch/arm/mm/Makefile
+++ b/arch/arm/mm/Makefile
@@ -2,9 +2,8 @@
 # Makefile for the linux arm-specific parts of the memory manager.
 #
 
-obj-y  := dma-mapping.o extable.o fault.o init.o \
-  iomap.o
-
+obj-y  := extable.o fault.o init.o iomap.o
+obj-y  += dma-mapping$(MMUEXT).o
 obj-$(CONFIG_MMU)  += fault-armv.o flush.o idmap.o ioremap.o \
   mmap.o pgd.o mmu.o pageattr.o
 
diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
new file mode 100644
index 000..3ba3003
--- /dev/null
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -0,0 +1,253 @@
+/*
+ *  Based on linux/arch/arm/mm/dma-mapping.c
+ *
+ *  Copyright (C) 2000-2004 Russell King
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include "dma.h"
+
+/*
+ *  dma_noop_ops is used if
+ *   - MMU/MPU is off
+ *   - cpu is v7m w/o cache support
+ *   - device is coherent
+ *  otherwise arm_nommu_dma_ops is used.
+ *
+ *  arm_nommu_dma_ops rely on consistent DMA memory (please, refer to
+ *  [1] on how to declare such memory).
+ *
+ *  [1] Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
+ */
+
+static void *arm_nommu_dma_alloc(struct device *dev, size_t size,
+dma_addr_t *dma_handle, gfp_t gfp,
+unsigned long attrs)
+
+{
+   const struct dma_map_ops *ops = _noop_ops;
+
+   /*
+* We are here because:
+* - no consistent DMA region has been defined, so we can't
+*   continue.
+* - there is no space left in consistent DMA region, so we
+*   only can fallback to generic allocator if we 

[tip:x86/urgent] Revert "x86/entry: Fix the end of the stack for newly forked tasks"

[tip-bot for Josh Poimboeuf]

Commit-ID:  ebd574994c63164d538a197172157318f58ac647
Gitweb: http://git.kernel.org/tip/ebd574994c63164d538a197172157318f58ac647
Author: Josh Poimboeuf 
AuthorDate: Tue, 23 May 2017 10:37:29 -0500
Committer:  Ingo Molnar 
CommitDate: Wed, 24 May 2017 09:05:16 +0200

Revert "x86/entry: Fix the end of the stack for newly forked tasks"

Petr Mladek reported the following warning when loading the livepatch
sample module:

  WARNING: CPU: 1 PID: 3699 at arch/x86/kernel/stacktrace.c:132 
save_stack_trace_tsk_reliable+0x133/0x1a0
  ...
  Call Trace:
   __schedule+0x273/0x820
   schedule+0x36/0x80
   kthreadd+0x305/0x310
   ? kthread_create_on_cpu+0x80/0x80
   ? icmp_echo.part.32+0x50/0x50
   ret_from_fork+0x2c/0x40

That warning means the end of the stack is no longer recognized as such
for newly forked tasks.  The problem was introduced with the following
commit:

  ff3f7e2475bb ("x86/entry: Fix the end of the stack for newly forked tasks")

... which was completely misguided.  It only partially fixed the
reported issue, and it introduced another bug in the process.  None of
the other entry code saves the frame pointer before calling into C code,
so it doesn't make sense for ret_from_fork to do so either.

Contrary to what I originally thought, the original issue wasn't related
to newly forked tasks.  It was actually related to ftrace.  When entry
code calls into a function which then calls into an ftrace handler, the
stack frame looks different than normal.

The original issue will be fixed in the unwinder, in a subsequent patch.

Reported-by: Petr Mladek 
Signed-off-by: Josh Poimboeuf 
Acked-by: Thomas Gleixner 
Cc: Dave Jones 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: live-patch...@vger.kernel.org
Fixes: ff3f7e2475bb ("x86/entry: Fix the end of the stack for newly forked 
tasks")
Link: 
http://lkml.kernel.org/r/f350760f7e82f0750c8d1dd093456eb212751caa.1495553739.git.jpoim...@redhat.com
Signed-off-by: Ingo Molnar 
---
 arch/x86/entry/entry_32.S | 30 +++---
 arch/x86/entry/entry_64.S | 11 ---
 2 files changed, 23 insertions(+), 18 deletions(-)

diff --git a/arch/x86/entry/entry_32.S b/arch/x86/entry/entry_32.S
index 50bc269..48ef7bb 100644
--- a/arch/x86/entry/entry_32.S
+++ b/arch/x86/entry/entry_32.S
@@ -252,6 +252,23 @@ ENTRY(__switch_to_asm)
 END(__switch_to_asm)
 
 /*
+ * The unwinder expects the last frame on the stack to always be at the same
+ * offset from the end of the page, which allows it to validate the stack.
+ * Calling schedule_tail() directly would break that convention because its an
+ * asmlinkage function so its argument has to be pushed on the stack.  This
+ * wrapper creates a proper "end of stack" frame header before the call.
+ */
+ENTRY(schedule_tail_wrapper)
+   FRAME_BEGIN
+
+   pushl   %eax
+   callschedule_tail
+   popl%eax
+
+   FRAME_END
+   ret
+ENDPROC(schedule_tail_wrapper)
+/*
  * A newly forked process directly context switches into this address.
  *
  * eax: prev task we switched from
@@ -259,24 +276,15 @@ END(__switch_to_asm)
  * edi: kernel thread arg
  */
 ENTRY(ret_from_fork)
-   FRAME_BEGIN /* help unwinder find end of stack */
-
-   /*
-* schedule_tail() is asmlinkage so we have to put its 'prev' argument
-* on the stack.
-*/
-   pushl   %eax
-   callschedule_tail
-   popl%eax
+   callschedule_tail_wrapper
 
testl   %ebx, %ebx
jnz 1f  /* kernel threads are uncommon */
 
 2:
/* When we fork, we trace the syscall return in the child, too. */
-   lealFRAME_OFFSET(%esp), %eax
+   movl%esp, %eax
callsyscall_return_slowpath
-   FRAME_END
jmp restore_all
 
/* kernel thread */
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 607d72c..4a4c083 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -36,7 +36,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 .code64
@@ -406,19 +405,17 @@ END(__switch_to_asm)
  * r12: kernel thread arg
  */
 ENTRY(ret_from_fork)
-   FRAME_BEGIN /* help unwinder find end of stack */
movq%rax, %rdi
-   callschedule_tail   /* rdi: 'prev' task parameter */
+   callschedule_tail   /* rdi: 'prev' task parameter */
 
-   testq   %rbx, %rbx  /* from kernel_thread? */
-   jnz 1f  /* kernel threads are uncommon */
+   testq   %rbx, %rbx  /* from kernel_thread? */
+   jnz 1f  /* kernel threads are uncommon 
*/
 
 2:
-   leaqFRAME_OFFSET(%rsp),%rdi /* 

[PATCH v5 7/7] ARM: dma-mapping: Remove traces of NOMMU code

[Vladimir Murzin]

DMA operations for NOMMU case have been just factored out into
separate compilation unit, so don't keep dead code.

Tested-by: Benjamin Gaignard 
Tested-by: Andras Szemzo 
Tested-by: Alexandre TORGUE 
Signed-off-by: Vladimir Murzin 
Acked-by: Arnd Bergmann 
---
 arch/arm/mm/dma-mapping.c | 29 ++---
 1 file changed, 2 insertions(+), 27 deletions(-)

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index c742dfd..395fa01 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -344,8 +344,6 @@ static void __dma_free_buffer(struct page *page, size_t 
size)
}
 }
 
-#ifdef CONFIG_MMU
-
 static void *__alloc_from_contiguous(struct device *dev, size_t size,
 pgprot_t prot, struct page **ret_page,
 const void *caller, bool want_vaddr,
@@ -647,22 +645,6 @@ static inline pgprot_t __get_dma_pgprot(unsigned long 
attrs, pgprot_t prot)
return prot;
 }
 
-#define nommu() 0
-
-#else  /* !CONFIG_MMU */
-
-#define nommu() 1
-
-#define __get_dma_pgprot(attrs, prot)  __pgprot(0)
-#define __alloc_remap_buffer(dev, size, gfp, prot, ret, c, wv) NULL
-#define __alloc_from_pool(size, ret_page)  NULL
-#define __alloc_from_contiguous(dev, size, prot, ret, c, wv, coherent_flag, 
gfp)   NULL
-#define __free_from_pool(cpu_addr, size)   do { } while (0)
-#define __free_from_contiguous(dev, page, cpu_addr, size, wv)  do { } while (0)
-#define __dma_free_remap(cpu_addr, size)   do { } while (0)
-
-#endif /* CONFIG_MMU */
-
 static void *__alloc_simple_buffer(struct device *dev, size_t size, gfp_t gfp,
   struct page **ret_page)
 {
@@ -805,7 +787,7 @@ static void *__dma_alloc(struct device *dev, size_t size, 
dma_addr_t *handle,
 
if (cma)
buf->allocator = _allocator;
-   else if (nommu() || is_coherent)
+   else if (is_coherent)
buf->allocator = _allocator;
else if (allowblock)
buf->allocator = _allocator;
@@ -854,8 +836,7 @@ static int __arm_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
 void *cpu_addr, dma_addr_t dma_addr, size_t size,
 unsigned long attrs)
 {
-   int ret = -ENXIO;
-#ifdef CONFIG_MMU
+   int ret;
unsigned long nr_vma_pages = (vma->vm_end - vma->vm_start) >> 
PAGE_SHIFT;
unsigned long nr_pages = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long pfn = dma_to_pfn(dev, dma_addr);
@@ -870,10 +851,6 @@ static int __arm_dma_mmap(struct device *dev, struct 
vm_area_struct *vma,
  vma->vm_end - vma->vm_start,
  vma->vm_page_prot);
}
-#else
-   ret = vm_iomap_memory(vma, vma->vm_start,
- (vma->vm_end - vma->vm_start));
-#endif /* CONFIG_MMU */
 
return ret;
 }
@@ -892,9 +869,7 @@ int arm_dma_mmap(struct device *dev, struct vm_area_struct 
*vma,
 void *cpu_addr, dma_addr_t dma_addr, size_t size,
 unsigned long attrs)
 {
-#ifdef CONFIG_MMU
vma->vm_page_prot = __get_dma_pgprot(attrs, vma->vm_page_prot);
-#endif /* CONFIG_MMU */
return __arm_dma_mmap(dev, vma, cpu_addr, dma_addr, size, attrs);
 }
 
-- 
2.0.0

[PATCH v5 2/7] dma: Add simple dma_noop_mmap

[Vladimir Murzin]

This patch adds a simple implementation of mmap to dma_noop_ops.

Cc: Joerg Roedel 
Cc: Christian Borntraeger 
Reported-by: Benjamin Gaignard 
Tested-by: Benjamin Gaignard 
Tested-by: Andras Szemzo 
Tested-by: Alexandre TORGUE 
Signed-off-by: Vladimir Murzin 
---
 lib/dma-noop.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index ff4ef5e..0acc3f6 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -66,6 +66,26 @@ static int dma_noop_supported(struct device *dev, u64 mask)
return 1;
 }
 
+static int dma_noop_mmap(struct device *dev, struct vm_area_struct *vma,
+void *cpu_addr, dma_addr_t dma_addr, size_t size,
+unsigned long attrs)
+{
+   unsigned long user_count = vma_pages(vma);
+   unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   unsigned long pfn = page_to_pfn(virt_to_page(cpu_addr));
+   unsigned long off = vma->vm_pgoff;
+   int ret = -ENXIO;
+
+   if (off < count && user_count <= (count - off)) {
+   ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+   }
+
+   return ret;
+}
+
 const struct dma_map_ops dma_noop_ops = {
.alloc  = dma_noop_alloc,
.free   = dma_noop_free,
@@ -73,6 +93,7 @@ const struct dma_map_ops dma_noop_ops = {
.map_sg = dma_noop_map_sg,
.mapping_error  = dma_noop_mapping_error,
.dma_supported  = dma_noop_supported,
+   .mmap   = dma_noop_mmap,
 };
 
 EXPORT_SYMBOL(dma_noop_ops);
-- 
2.0.0

[PATCH v5 1/7] dma: Take into account dma_pfn_offset

[Vladimir Murzin]

Even though dma-noop-ops assumes 1:1 memory mapping DMA memory range
can be different to RAM. For example, ARM STM32F4 MCU offers the
possibility to remap SDRAM from 0xc000_ to 0x0 to get CPU
performance boost, but DMA continue to see SDRAM at 0xc000_. This
difference in mapping is handled via device-tree "dma-range" property
which leads to dev->dma_pfn_offset is set nonzero. To handle such
cases take dma_pfn_offset into account.

Cc: Joerg Roedel 
Cc: Christian Borntraeger 
Reported-by: Benjamin Gaignard 
Tested-by: Benjamin Gaignard 
Tested-by: Andras Szemzo 
Tested-by: Alexandre TORGUE 
Reviewed-by: Robin Murphy 
Signed-off-by: Vladimir Murzin 
---
 lib/dma-noop.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/lib/dma-noop.c b/lib/dma-noop.c
index de26c8b..ff4ef5e 100644
--- a/lib/dma-noop.c
+++ b/lib/dma-noop.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static void *dma_noop_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp,
@@ -16,7 +17,8 @@ static void *dma_noop_alloc(struct device *dev, size_t size,
 
ret = (void *)__get_free_pages(gfp, get_order(size));
if (ret)
-   *dma_handle = virt_to_phys(ret);
+   *dma_handle = virt_to_phys(ret) - PFN_PHYS(dev->dma_pfn_offset);
+
return ret;
 }
 
@@ -32,7 +34,7 @@ static dma_addr_t dma_noop_map_page(struct device *dev, 
struct page *page,
  enum dma_data_direction dir,
  unsigned long attrs)
 {
-   return page_to_phys(page) + offset;
+   return page_to_phys(page) + offset - PFN_PHYS(dev->dma_pfn_offset);
 }
 
 static int dma_noop_map_sg(struct device *dev, struct scatterlist *sgl, int 
nents,
@@ -47,7 +49,7 @@ static int dma_noop_map_sg(struct device *dev, struct 
scatterlist *sgl, int nent
 
BUG_ON(!sg_page(sg));
va = sg_virt(sg);
-   sg_dma_address(sg) = (dma_addr_t)virt_to_phys(va);
+   sg_dma_address(sg) = (dma_addr_t)(virt_to_phys(va) - 
PFN_PHYS(dev->dma_pfn_offset));
sg_dma_len(sg) = sg->length;
}
 
-- 
2.0.0

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

[Mika Westerberg]

On Tue, May 23, 2017 at 05:30:43PM +, mario.limoncie...@dell.com wrote:
> (Sorry my email client is not going to wrap these at 80 columns)o

That's fine. It is more readable this way :)

> [0.467319] pci :00:1c.0: [8086:9d10] type 01 class 0x060400
> [0.467389] pci :00:1c.0: PME# supported from D0 D3hot D3cold
> [0.467513] pci :00:1c.0: System wakeup disabled by ACPI

[...]

> [0.469363] pci :01:00.0: [8086:1576] type 01 class 0x060400
> [0.469483] pci :01:00.0: supports D1 D2
> [0.469484] pci :01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [0.469570] pci :01:00.0: System wakeup disabled by ACPI
> [0.469609] pci :00:1c.0: PCI bridge to [bus 01-39]
> [0.469614] pci :00:1c.0:   bridge window [mem 0xc400-0xda0f]
> [0.469618] pci :00:1c.0:   bridge window [mem 0xa000-0xc1ff 
> 64bit pref]
> [0.469621] pci :01:00.0: bridge configuration invalid ([bus 00-00]), 
> reconfiguring

This is the problem. Here the PCIe upstream port (:01:00.0) is
visible to Linux but it is not fully configured by the BIOS ->
(primary/secondary/subordinate) is set to 0.

At this point Linux decides to configure the port itself and goes wrong
since our allocation strategy tries to keep resource windows, including
reserved buses as small as possible so that everything we currently find
barely fits there.

This continues few lines below:

> [0.469670] pci_bus :02: busn_res: can not insert [bus 02-ff] under 
> [bus 01-39] (conflicts with (null) [bus 01-39])
> [0.469688] pci :02:00.0: [8086:1576] type 01 class 0x060400
> [0.469809] pci :02:00.0: supports D1 D2
> [0.469810] pci :02:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [0.469877] pci :02:01.0: [8086:1576] type 01 class 0x060400
> [0.47] pci :02:01.0: supports D1 D2
> [0.470001] pci :02:01.0: PME# supported from D0 D1 D2 D3hot D3cold
> [0.470067] pci :02:02.0: [8086:1576] type 01 class 0x060400
> [0.470188] pci :02:02.0: supports D1 D2
> [0.470189] pci :02:02.0: PME# supported from D0 D1 D2 D3hot D3cold
> [0.470277] pci :01:00.0: PCI bridge to [bus 02-ff]
> [0.470283] pci :01:00.0:   bridge window [io  0x-0x0fff]
> [0.470287] pci :01:00.0:   bridge window [mem 0x-0x000f]
> [0.470294] pci :01:00.0:   bridge window [mem 0x-0x000f 
> 64bit pref]
> [0.470296] pci :02:00.0: bridge configuration invalid ([bus 00-00]), 
> reconfiguring
> [0.470304] pci :02:01.0: bridge configuration invalid ([bus 00-00]), 
> reconfiguring
> [0.470312] pci :02:02.0: bridge configuration invalid ([bus 00-00]), 
> reconfiguring

Here.

And ends up in failure when we create PCIe tunnels later on.

Now, this is probably where Windows does something else, like it may
skip re-configuring phase which could explain why it works. However, to
me this looks pretty much like a bug in the BIOS/firmware as we are
expecting the BIOS to configure the PCIe devices properly before the OS
is send ACPI hotplug event.

We need to handle this in Linux in the same way Windows does but
currently I have no idea. It is however, more related to our PCI
enumeration code than the patches in question, I think.

I also have a Dell 9350 here so I can reproduce the problem and I'm
going to investigate this further probably involving Linux PCI people.

My testing on the machine shows this behaviour only when the cable is
connected during boot.

If I connect the cable after OS is booted I don't see the problem, even
if I do unplug / plug cycle.

Can you try that also (again)? And if you see the problem, send me the
dmesg? I have the latest BIOS (1.4.17) and NVM 16 so this machine
configuration should match yours if I'm not mistaken.

Re: [BUG][next-20170523][Bisected cf22cd5f3a] kernel oops while running trinity fuzzer

[Milan Broz]

On 05/24/2017 11:29 AM, Abdul Haleem wrote:
> Hi
> 
> commit cf22cd5f3a: dm crypt: add cryptographic data integrity protection
> suspected to be bad.

Isn't this false positive? That commit changes only dm-crypt and that module
seems not to be even loaded...
(Moreover config has disabled block integrity so this code should
be mostly compiled out.)

Milan

> 
> Test : trinity
> Machine : Power 8 (LPAR)
> kernel : 4.12.0-rc2-next-20170523
> Config : attached
> 
> Unable to handle kernel paging request for data at address 0x
> Faulting instruction address: 0xc15d8824
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=2048 
> NUMA 
> pSeries
> Dumping ftrace buffer: 
>(ftrace buffer empty)
> Modules linked in: bridge nfnetlink rpadlpar_io stp llc rpaphp xt_tcpudp
> ipt_REJECT nf_reject_ipv4 xt_conntrack iptable_nat nf_conntrack_ipv4
> nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle
> iptable_filter vmx_crypto pseries_rng rng_core binfmt_misc nfsd
> ip_tables x_tables autofs4 [last unloaded: bridge]
> CPU: 4 PID: 2474 Comm: trinity-c4 Not tainted 
> 4.12.0-rc2-next-20170523-autotest #1
> task: c003a6ae2500 task.stack: c002bf7ec000
> NIP: c15d8824 LR: c1ef855c CTR: 
> REGS: c002bf7efb00 TRAP: 0300   Not tainted  
> (4.12.0-rc2-next-20170523-autotest)
> MSR: 80009033 
>   CR: 44002841  XER: 2000  
> CFAR: c15d8810 DAR:  DSISR: 4200 SOFTE: 1 
> GPR00: 0001 c002bf7efd80 c33d3600  
> GPR04:    c3743600 
> GPR08: c3743600 0006d123 c3773600 1000 
> GPR12: 2200 ce9c1600  10035e80 
> GPR16: 10033950  10033a50  
> GPR20: 10985cc4 7d9d 1001bae0 000185f8 
> GPR24:   fffa ffea 
> GPR28: 0008 c003a8c48850 ffea  
> NIP [c15d8824] memset+0xc4/0xfc
> LR [c1ef855c] memzero_explicit+0x3c/0x70
> Call Trace:
> [c002bf7efd80] [0008] 0x8 (unreliable)
> [c002bf7efdb0] [c1e3fb30] SyS_add_key+0x1a0/0x410
> [c002bf7efe30] [c152b7e0] system_call+0x38/0xfc
> Instruction dump:
> 41820038 409d0018 f886 f8860008 f8860010 f8860018 38c60020 409e0010 
> f886 f8860008 38c60010 409f000c  38c60008 2c05
> 7cb01120 
> ---[ end trace c454dcc1309b8479 ]---
> 
> 

Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc

[Michael Ellerman]

Michael Bringmann  writes:

> On 05/23/2017 04:49 PM, Reza Arbab wrote:
>> On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote:
>>> On 05/23/2017 10:52 AM, Reza Arbab wrote:
 On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote:
> +static void setup_nodes(void)
> +{
> +int i, l = 32 /* MAX_NUMNODES */;
> +
> +for (i = 0; i < l; i++) {
> +if (!node_possible(i)) {
> +setup_node_data(i, 0, 0);
> +node_set(i, node_possible_map);
> +}
> +}
> +}

 This seems to be a workaround for 3af229f2071f ("powerpc/numa: Reset 
 node_possible_map to only node_online_map").
>>>
>>> They may be related, but that commit is not a replacement.  The above patch 
>>> ensures that
>>> there are enough of the nodes initialized at startup to allow for memory 
>>> hot-add into a
>>> node that was not used at boot.  (See 'setup_node_data' function in 
>>> 'numa.c'.)  That and
>>> recording that the node was initialized.
>> 
>> Is it really necessary to preinitialize these empty nodes using 
>> setup_node_data()? When you do memory hotadd into a node that was not used 
>> at boot, the node data already gets set up by
>> 
>> add_memory
>>  add_memory_resource
>>hotadd_new_pgdat
>>  arch_alloc_nodedata <-- allocs the pg_data_t
>>  ...
>>  free_area_init_node <-- sets NODE_DATA(nid)->node_id, etc.
>> 
>> Removing setup_node_data() from that loop leaves only the call to 
>> node_set(). If 3af229f2071f (which reduces node_possible_map) was reverted, 
>> you wouldn't need to do that either.
>
> With or without 3af229f2071f, we would still need to add something, somewhere 
> to add new
> bits to the 'node_possible_map'.  That is not being done.

You mustn't add bits to the possible map after boot.

That's its purpose, to tell you what nodes could ever *possibly* exist.

cheers

Re: [PATCH 3/7] microblaze: Use libgcc files from lib/

[kbuild test robot]

Hi Palmer,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2 next-20170524]
[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/Palmer-Dabbelt/lib-Add-shared-copies-of-some-GCC-library-routines/20170524-170717
config: microblaze-mmu_defconfig (attached as .config)
compiler: microblaze-linux-gcc (GCC) 6.2.0
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=microblaze 

All errors (new ones prefixed by >>):

>> make[2]: *** No rule to make target 'lib/multi3.o', needed by 
>> 'lib/built-in.o'.
   make[2]: Target '__build' not remade because of errors.

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


.config.gz
Description: application/gzip

Re: [PATCH 4/7] mips: Use lib/{ashldi3,ashrdi3,cmpdi2,lshrdi3,ucmpdi2}.c

[kbuild test robot]

Hi Palmer,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc2]
[cannot apply to next-20170524]
[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/Palmer-Dabbelt/lib-Add-shared-copies-of-some-GCC-library-routines/20170524-170717
config: mips-jz4740 (attached as .config)
compiler: mips-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
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=mips 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `perf_swevent_init':
>> core.c:(.text+0x75da8): undefined reference to `__ucmpdi2'
   drivers/built-in.o: In function `drm_getcap':
>> drm_ioctl.c:(.text+0x5d864): undefined reference to `__ucmpdi2'

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


.config.gz
Description: application/gzip

[PATCH v3 3/9] ASoC: sun8i-codec-analog: add support for V3s SoC

[Icenowy Zheng]

From: Icenowy Zheng 

The V3s SoC features an analog codec with headphone support but without
mic2 and linein.

Add support for it.

Signed-off-by: Icenowy Zheng 
---
 Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt | 1 +
 sound/soc/sunxi/sun8i-codec-analog.c   | 9 +
 2 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt 
b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
index 779b735781ba..1b6e7c4e50ab 100644
--- a/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
+++ b/Documentation/devicetree/bindings/sound/sun8i-codec-analog.txt
@@ -4,6 +4,7 @@ Required properties:
 - compatible: must be one of the following compatibles:
- "allwinner,sun8i-a23-codec-analog"
- "allwinner,sun8i-h3-codec-analog"
+   - "allwinner,sun8i-v3s-codec-analog"
 
 Required properties if not a sub-node of the PRCM node:
 - reg: must contain the registers location and length
diff --git a/sound/soc/sunxi/sun8i-codec-analog.c 
b/sound/soc/sunxi/sun8i-codec-analog.c
index 4c34a12b3739..465d53fa93ac 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -808,6 +808,11 @@ static int sun8i_codec_analog_add_mixer(struct 
snd_soc_component *cmpnt,
return 0;
 }
 
+static const struct sun8i_codec_analog_quirks sun8i_v3s_quirks = {
+   .has_headphone  = true,
+   .has_hmic   = true,
+};
+
 static int sun8i_codec_analog_cmpnt_probe(struct snd_soc_component *cmpnt)
 {
struct device *dev = cmpnt->dev;
@@ -882,6 +887,10 @@ static const struct of_device_id 
sun8i_codec_analog_of_match[] = {
.compatible = "allwinner,sun8i-h3-codec-analog",
.data = _h3_quirks,
},
+   {
+   .compatible = "allwinner,sun8i-v3s-codec-analog",
+   .data = _v3s_quirks,
+   },
{}
 };
 MODULE_DEVICE_TABLE(of, sun8i_codec_analog_of_match);
-- 
2.12.2

[PATCH v4 1/8] arm64: hugetlb: Refactor find_num_contig

[Punit Agrawal]

From: Steve Capper 

As we regularly check for contiguous pte's in the huge accessors, remove
this extra check from find_num_contig.

Cc: David Woods 
Signed-off-by: Steve Capper 
[ Resolved rebase conflicts due to patch re-ordering ]
Signed-off-by: Punit Agrawal 
---
 arch/arm64/mm/hugetlbpage.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/mm/hugetlbpage.c b/arch/arm64/mm/hugetlbpage.c
index 69b8200b1cfd..710bf935a473 100644
--- a/arch/arm64/mm/hugetlbpage.c
+++ b/arch/arm64/mm/hugetlbpage.c
@@ -42,15 +42,13 @@ int pud_huge(pud_t pud)
 }
 
 static int find_num_contig(struct mm_struct *mm, unsigned long addr,
-  pte_t *ptep, pte_t pte, size_t *pgsize)
+  pte_t *ptep, size_t *pgsize)
 {
pgd_t *pgd = pgd_offset(mm, addr);
pud_t *pud;
pmd_t *pmd;
 
*pgsize = PAGE_SIZE;
-   if (!pte_cont(pte))
-   return 1;
pud = pud_offset(pgd, addr);
pmd = pmd_offset(pud, addr);
if ((pte_t *)pmd == ptep) {
@@ -65,15 +63,16 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long 
addr,
 {
size_t pgsize;
int i;
-   int ncontig = find_num_contig(mm, addr, ptep, pte, );
+   int ncontig;
unsigned long pfn;
pgprot_t hugeprot;
 
-   if (ncontig == 1) {
+   if (!pte_cont(pte)) {
set_pte_at(mm, addr, ptep, pte);
return;
}
 
+   ncontig = find_num_contig(mm, addr, ptep, );
pfn = pte_pfn(pte);
hugeprot = __pgprot(pte_val(pfn_pte(pfn, __pgprot(0))) ^ pte_val(pte));
for (i = 0; i < ncontig; i++) {
@@ -188,7 +187,7 @@ pte_t huge_ptep_get_and_clear(struct mm_struct *mm,
bool is_dirty = false;
 
cpte = huge_pte_offset(mm, addr);
-   ncontig = find_num_contig(mm, addr, cpte, *cpte, );
+   ncontig = find_num_contig(mm, addr, cpte, );
/* save the 1st pte to return */
pte = ptep_get_and_clear(mm, addr, cpte);
for (i = 1, addr += pgsize; i < ncontig; ++i, addr += pgsize) {
@@ -228,7 +227,7 @@ int huge_ptep_set_access_flags(struct vm_area_struct *vma,
cpte = huge_pte_offset(vma->vm_mm, addr);
pfn = pte_pfn(*cpte);
ncontig = find_num_contig(vma->vm_mm, addr, cpte,
- *cpte, );
+ );
for (i = 0; i < ncontig; ++i, ++cpte, addr += pgsize) {
changed |= ptep_set_access_flags(vma, addr, cpte,
pfn_pte(pfn,
@@ -251,7 +250,7 @@ void huge_ptep_set_wrprotect(struct mm_struct *mm,
size_t pgsize = 0;
 
cpte = huge_pte_offset(mm, addr);
-   ncontig = find_num_contig(mm, addr, cpte, *cpte, );
+   ncontig = find_num_contig(mm, addr, cpte, );
for (i = 0; i < ncontig; ++i, ++cpte, addr += pgsize)
ptep_set_wrprotect(mm, addr, cpte);
} else {
@@ -269,7 +268,7 @@ void huge_ptep_clear_flush(struct vm_area_struct *vma,
 
cpte = huge_pte_offset(vma->vm_mm, addr);
ncontig = find_num_contig(vma->vm_mm, addr, cpte,
- *cpte, );
+ );
for (i = 0; i < ncontig; ++i, ++cpte, addr += pgsize)
ptep_clear_flush(vma, addr, cpte);
} else {
-- 
2.11.0

Re: [Question] Mlocked count will not be decreased

[Vlastimil Babka]

On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>
>> Race condition with what? Who else would isolate our pages?
>>
> 
> Hi Vlastimil,
> 
> I find the root cause, if the page was not cached on the current cpu,
> lru_add_drain() will not push it to LRU. So we should handle fail
> case in mlock_vma_page().

Yeah that would explain it.

> follow_page_pte()
>   ...
>   if (page->mapping && trylock_page(page)) {
>   lru_add_drain();  /* push cached pages to LRU */
>   /*
>* Because we lock page here, and migration is
>* blocked by the pte's page reference, and we
>* know the page is still mapped, we don't even
>* need to check for file-cache page truncation.
>*/
>   mlock_vma_page(page);
>   unlock_page(page);
>   }
>   ...
> 
> I think we should add yisheng's patch, also we should add the following 
> change.
> I think it is better than use lru_add_drain_all().

I agree about yisheng's fix (but v2 didn't address my comments). I don't
think we should add the hunk below, as that deviates from the rest of
the design.

Thanks,
Vlastimil

> diff --git a/mm/mlock.c b/mm/mlock.c
> index 3d3ee6c..ca2aeb9 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -88,6 +88,11 @@ void mlock_vma_page(struct page *page)
>   count_vm_event(UNEVICTABLE_PGMLOCKED);
>   if (!isolate_lru_page(page))
>   putback_lru_page(page);
> + else {
> + ClearPageMlocked(page);
> + mod_zone_page_state(page_zone(page), NR_MLOCK,
> + -hpage_nr_pages(page));
> + }
>   }
>  }
> 
> Thanks,
> Xishi Qiu
> 

[PATCH v4 0/8] Support for contiguous pte hugepages

[Punit Agrawal]

Hi,

This patchset updates the hugetlb code to fix issues arising from
contiguous pte hugepages (such as on arm64). Compared to v3, This
version addresses a build failure on arm64 by including two cleanup
patches. Other than the arm64 cleanups, the rest are generic code
changes. The remaining arm64 support based on these patches will be
posted separately. The patches are based on v4.12-rc2. Previous
related postings can be found at [0], [1], [2], and [3].

The patches fall into three categories -

* Patch 1-2 - arm64 cleanups required to greatly simplify changing
  huge_pte_offset() prototype in Patch 5.

  Catalin, Will - are you happy for these patches to go via mm?

* Patches 3-4 address issues with gup

* Patches 5-8 relate to passing a size argument to hugepage helpers to
  disambiguate the size of the referred page. These changes are
  required to enable arch code to properly handle swap entries for
  contiguous pte hugepages.

  The changes to huge_pte_offset() (patch 5) touch multiple
  architectures but I've managed to minimise these changes for the
  other affected functions - huge_pte_clear() and set_huge_pte_at().

These patches gate the enabling of contiguous hugepages support on
arm64 which has been requested for systems using !4k page granule.

Feedback welcome.

Thanks,
Punit

v3 -> v4

* Reworked huge_pte_clear() and set_huge_swap_pte_at() to use #ifndef
  block pattern
* Included two arm64 hugetlb patches to address build failure
* Updated tags

v2 -> v3

* Added gup fixes

v1 -> v2

* switch huge_pte_offset() to use size instead of hstate for
  consistency with the rest of the api
* Expand the series to address huge_pte_clear() and set_huge_pte_at()

RFC -> v1

* Fixed a missing conversion of huge_pte_offset() prototype to add
  hstate parameter. Reported by 0-day.

[0] https://www.spinics.net/lists/arm-kernel/msg582682.html
[1] http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1370686.html
[2] https://lkml.org/lkml/2017/3/30/770
[3] https://lkml.org/lkml/2017/3/23/293


Punit Agrawal (5):
  mm, gup: Ensure real head page is ref-counted when using hugepages
  mm/hugetlb: add size parameter to huge_pte_offset()
  mm/hugetlb: Allow architectures to override huge_pte_clear()
  mm/hugetlb: Introduce set_huge_swap_pte_at() helper
  mm: rmap: Use correct helper when poisoning hugepages

Steve Capper (2):
  arm64: hugetlb: Refactor find_num_contig
  arm64: hugetlb: Remove spurious calls to huge_ptep_offset

Will Deacon (1):
  mm, gup: Remove broken VM_BUG_ON_PAGE compound check for hugepages

 arch/arm64/mm/hugetlbpage.c | 53 +
 arch/ia64/mm/hugetlbpage.c  |  4 ++--
 arch/metag/mm/hugetlbpage.c |  3 ++-
 arch/mips/mm/hugetlbpage.c  |  3 ++-
 arch/parisc/mm/hugetlbpage.c|  3 ++-
 arch/powerpc/mm/hugetlbpage.c   |  2 +-
 arch/s390/include/asm/hugetlb.h |  2 +-
 arch/s390/mm/hugetlbpage.c  |  3 ++-
 arch/sh/mm/hugetlbpage.c|  3 ++-
 arch/sparc/mm/hugetlbpage.c |  3 ++-
 arch/tile/mm/hugetlbpage.c  |  3 ++-
 arch/x86/mm/hugetlbpage.c   |  2 +-
 fs/userfaultfd.c|  7 --
 include/asm-generic/hugetlb.h   |  4 +++-
 include/linux/hugetlb.h | 13 --
 mm/gup.c| 15 +---
 mm/hugetlb.c| 33 +++--
 mm/page_vma_mapped.c|  3 ++-
 mm/pagewalk.c   |  3 ++-
 mm/rmap.c   |  7 --
 20 files changed, 95 insertions(+), 74 deletions(-)

-- 
2.11.0

Re: [PATCH BUGFIX] block, bfq: access and cache blkg data only when safe

[Paolo Valente]

> Il giorno 23 mag 2017, alle ore 21:42, Tejun Heo  ha scritto:
> 
> Hello, Paolo.
> 
> On Sat, May 20, 2017 at 09:27:33AM +0200, Paolo Valente wrote:
>> Consider a process or a group that is moved from a given source group
>> to a different group, or simply removed from a group (although I
>> didn't yet succeed in just removing a process from a group :) ).  The
>> pointer to the [b|c]fq_group contained in the schedulable entity
>> belonging to the source group *is not* updated, in BFQ, if the entity
>> is idle, and *is not* updated *unconditionally* in CFQ.  The update
>> will happen in bfq_get_rq_private or cfq_set_request, on the arrival
>> of a new request.  But, if the move happens right after the arrival of
>> a request, then all the scheduler functions executed until a new
>> request arrives for that entity will see a stale [b|c]fq_group.  Much
> 
> Limited staleness is fine.  Especially in this case, it isn't too
> weird to claim that the order between the two operations isn't clearly
> defined.
> 

ok

>> worse, if also a blkcg_deactivate_policy or a blkg_destroy are
>> executed right after the move, then both the policy data pointed by
>> the [b|c]fq_group and the [b|c]fq_group itself may be deallocated.
>> So, all the functions of the scheduler invoked before next request
>> arrival may use dangling references!
> 
> Hmm... but cfq_group is allocated along with blkcg and blkcg always
> ensures that there are no blkg left before freeing the pd area in
> blkcg_css_offline().
> 

Exact, but even after all blkgs, as well as the cfq_group and pd, are
gone, the children cfq_queues of the gone cfq_group continue to point
to unexisting objects, until new cfq_set_requests are executed for
those cfq_queues.  To try to make this statement clearer, here is the
critical sequence for a cfq_queue, say cfqq, belonging to a cfq_group,
say cfqg:

1 cfq_set_request for a request rq of cfqq
2 removal of (the process associated with cfqq) from bfqg
3 destruction of the blkg that bfqg is associated with
4 destruction of the blkcg the above blkg belongs to
5 destruction of the pd pointed to by cfqg, and of cfqg itself
!!!-> from now on cfqq->cfqg is a dangling reference <-!!!
6 execution of cfq functions, different from cfq_set_request, on cfqq
. cfq_insert, cfq_dispatch, cfq_completed_rq, ...
7 execution of a new cfq_set_request for cfqq
-> now cfqq->cfqg is again a sane pointer <-

Every function executed at step 6 sees a dangling reference for
cfqq->cfqg.

My fix for caching data doesn't solve this more serious problem.

Where have I been mistaken?

Thanks,
Paolo

> Thanks.
> 
> -- 
> tejun

Re: [PATCH] ARM: dts: imx6: use #include "..." to include local DT

[Fabio Estevam]

On Wed, May 24, 2017 at 2:02 AM, Masahiro Yamada
 wrote:
> Most of DT files in ARM use #include "..." to make pre-processor
> include DT in the same directory, but we have some exceptional files
> that use #include <...> for that.
>
> Fix them to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts path from
> dtc_cpp_flags.
>
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Fabio Estevam 

Re: [Question] Mlocked count will not be decreased

[Xishi Qiu]

On 2017/5/24 19:52, Vlastimil Babka wrote:

> On 05/24/2017 01:38 PM, Xishi Qiu wrote:
>>>
>>> Race condition with what? Who else would isolate our pages?
>>>
>>
>> Hi Vlastimil,
>>
>> I find the root cause, if the page was not cached on the current cpu,
>> lru_add_drain() will not push it to LRU. So we should handle fail
>> case in mlock_vma_page().
> 
> Yeah that would explain it.
> 
>> follow_page_pte()
>>  ...
>>  if (page->mapping && trylock_page(page)) {
>>  lru_add_drain();  /* push cached pages to LRU */
>>  /*
>>   * Because we lock page here, and migration is
>>   * blocked by the pte's page reference, and we
>>   * know the page is still mapped, we don't even
>>   * need to check for file-cache page truncation.
>>   */
>>  mlock_vma_page(page);
>>  unlock_page(page);
>>  }
>>  ...
>>
>> I think we should add yisheng's patch, also we should add the following 
>> change.
>> I think it is better than use lru_add_drain_all().
> 
> I agree about yisheng's fix (but v2 didn't address my comments). I don't
> think we should add the hunk below, as that deviates from the rest of
> the design.

Hi Vlastimil,

The rest of the design is that mlock should always success here, right?

If we don't handle the fail case, the page will be in anon/file lru list
later when call __pagevec_lru_add(), but NR_MLOCK increased,
this is wrong, right?

Thanks,
Xishi Qiu

> 
> Thanks,
> Vlastimil
> 
>> diff --git a/mm/mlock.c b/mm/mlock.c
>> index 3d3ee6c..ca2aeb9 100644
>> --- a/mm/mlock.c
>> +++ b/mm/mlock.c
>> @@ -88,6 +88,11 @@ void mlock_vma_page(struct page *page)
>>  count_vm_event(UNEVICTABLE_PGMLOCKED);
>>  if (!isolate_lru_page(page))
>>  putback_lru_page(page);
>> +else {
>> +ClearPageMlocked(page);
>> +mod_zone_page_state(page_zone(page), NR_MLOCK,
>> +-hpage_nr_pages(page));
>> +}
>>  }
>>  }
>>
>> Thanks,
>> Xishi Qiu
>>
> 
> 
> .
> 

RE: [PATCH] phy: rcar-gen3-usb3: add support for R-Car Gen3 USB 3.0 PHY

[Yoshihiro Shimoda]

Hi,

> From: Yoshihiro Shimoda
> Sent: Wednesday, May 24, 2017 9:04 PM
> 
> The USB 3.0 PHY modules of R-Car Gen3 SoCs have:
>  - Spread spectrum clock (ssc).
>  - Using USB 2.0 EXTAL clock instead of USB 3.0 clock.
>  - Enabling VBUS detection for usb3.0 peripheral.
> 
> So, this driver supports these features.
> 
> Signed-off-by: Yoshihiro Shimoda 

> +static int rcar_gen3_phy_usb3_init(struct phy *p)
> +{
> + struct rcar_gen3_usb3 *r = phy_get_drvdata(p);
> +
> + dev_info(>phy->dev, "%s: enter (%d, %d, %d)\n", __func__,
> +  r->usb3s_clk, r->usb_extal, r->ssc_range);

Oops, I should change this to dev_vdbg...
I will submit v2 patch later.

Best regards,
Yoshihiro Shimoda

[PATCH 1/2] staging: fsl-dpaa2/eth: Fix address translations

[Ioana Radulescu]

Use the correct mechanisms for translating a DMA-mapped IOVA
address into a virtual one. Without this fix, once SMMU is
enabled on Layerscape platforms, the Ethernet driver throws
IOMMU translation faults.

Signed-off-by: Nipun Gupta 
Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 25 +++--
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h |  1 +
 2 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 6f9eed66c64d..3fee0d6f17e0 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -37,6 +37,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "../../fsl-mc/include/mc.h"
 #include "../../fsl-mc/include/mc-sys.h"
@@ -54,6 +55,16 @@ MODULE_DESCRIPTION("Freescale DPAA2 Ethernet Driver");
 
 const char dpaa2_eth_drv_version[] = "0.1";
 
+static void *dpaa2_iova_to_virt(struct iommu_domain *domain,
+   dma_addr_t iova_addr)
+{
+   phys_addr_t phys_addr;
+
+   phys_addr = domain ? iommu_iova_to_phys(domain, iova_addr) : iova_addr;
+
+   return phys_to_virt(phys_addr);
+}
+
 static void validate_rx_csum(struct dpaa2_eth_priv *priv,
 u32 fd_status,
 struct sk_buff *skb)
@@ -98,12 +109,11 @@ static void free_rx_fd(struct dpaa2_eth_priv *priv,
sgt = vaddr + dpaa2_fd_get_offset(fd);
for (i = 0; i < DPAA2_ETH_MAX_SG_ENTRIES; i++) {
addr = dpaa2_sg_get_addr([i]);
+   sg_vaddr = dpaa2_iova_to_virt(priv->iommu_domain, addr);
dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE,
 DMA_FROM_DEVICE);
 
-   sg_vaddr = phys_to_virt(addr);
skb_free_frag(sg_vaddr);
-
if (dpaa2_sg_is_final([i]))
break;
}
@@ -159,10 +169,10 @@ static struct sk_buff *build_frag_skb(struct 
dpaa2_eth_priv *priv,
 
/* Get the address and length from the S/G entry */
sg_addr = dpaa2_sg_get_addr(sge);
+   sg_vaddr = dpaa2_iova_to_virt(priv->iommu_domain, sg_addr);
dma_unmap_single(dev, sg_addr, DPAA2_ETH_RX_BUF_SIZE,
 DMA_FROM_DEVICE);
 
-   sg_vaddr = phys_to_virt(sg_addr);
sg_length = dpaa2_sg_get_len(sge);
 
if (i == 0) {
@@ -222,8 +232,8 @@ static void dpaa2_eth_rx(struct dpaa2_eth_priv *priv,
/* Tracing point */
trace_dpaa2_rx_fd(priv->net_dev, fd);
 
+   vaddr = dpaa2_iova_to_virt(priv->iommu_domain, addr);
dma_unmap_single(dev, addr, DPAA2_ETH_RX_BUF_SIZE, DMA_FROM_DEVICE);
-   vaddr = phys_to_virt(addr);
 
prefetch(vaddr + priv->buf_layout.private_data_size);
prefetch(vaddr + dpaa2_fd_get_offset(fd));
@@ -490,7 +500,7 @@ static void free_tx_fd(const struct dpaa2_eth_priv *priv,
struct dpaa2_fas *fas;
 
fd_addr = dpaa2_fd_get_addr(fd);
-   skbh = phys_to_virt(fd_addr);
+   skbh = dpaa2_iova_to_virt(priv->iommu_domain, fd_addr);
 
if (fd_format == dpaa2_fd_single) {
skb = *skbh;
@@ -802,10 +812,11 @@ static void drain_bufs(struct dpaa2_eth_priv *priv, int 
count)
}
for (i = 0; i < ret; i++) {
/* Same logic as on regular Rx path */
+   vaddr = dpaa2_iova_to_virt(priv->iommu_domain,
+  buf_array[i]);
dma_unmap_single(dev, buf_array[i],
 DPAA2_ETH_RX_BUF_SIZE,
 DMA_FROM_DEVICE);
-   vaddr = phys_to_virt(buf_array[i]);
skb_free_frag(vaddr);
}
} while (ret);
@@ -2358,6 +2369,8 @@ static int dpaa2_eth_probe(struct fsl_mc_device *dpni_dev)
priv = netdev_priv(net_dev);
priv->net_dev = net_dev;
 
+   priv->iommu_domain = iommu_get_domain_for_dev(dev);
+
/* Obtain a MC portal */
err = fsl_mc_portal_allocate(dpni_dev, FSL_MC_IO_ATOMIC_CONTEXT_PORTAL,
 >mc_io);
diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
index c67cced55b72..55b47623008c 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.h
@@ -301,6 +301,7 @@ struct dpaa2_eth_priv {
 
struct fsl_mc_device *dpbp_dev;
struct dpbp_attr dpbp_attrs;
+   struct iommu_domain *iommu_domain;
 
u16 tx_qdid;
struct fsl_mc_io *mc_io;
-- 
2.11.0

[PATCH 2/2] staging: fsl-dpaa2/eth: Map Tx buffers as bidirectional

[Ioana Radulescu]

WRIOP hardware may need to write to the hardware annotation
area of Tx buffers (e.g. frame status bits) and also to
the data area (e.g. L4 checksum in frame header).

Map these buffers as DMA_BIDIRECTIONAL, otherwise the
write transaction through SMMU will not be allowed.

Signed-off-by: Nipun Gupta 
Signed-off-by: Ioana Radulescu 
---
 drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c 
b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
index 3fee0d6f17e0..49c435bad706 100644
--- a/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
+++ b/drivers/staging/fsl-dpaa2/ethernet/dpaa2-eth.c
@@ -355,7 +355,7 @@ static int build_sg_fd(struct dpaa2_eth_priv *priv,
 
sg_init_table(scl, nr_frags + 1);
num_sg = skb_to_sgvec(skb, scl, 0, skb->len);
-   num_dma_bufs = dma_map_sg(dev, scl, num_sg, DMA_TO_DEVICE);
+   num_dma_bufs = dma_map_sg(dev, scl, num_sg, DMA_BIDIRECTIONAL);
if (unlikely(!num_dma_bufs)) {
err = -ENOMEM;
goto dma_map_sg_failed;
@@ -406,7 +406,7 @@ static int build_sg_fd(struct dpaa2_eth_priv *priv,
swa->num_dma_bufs = num_dma_bufs;
 
/* Separately map the SGT buffer */
-   addr = dma_map_single(dev, sgt_buf, sgt_buf_size, DMA_TO_DEVICE);
+   addr = dma_map_single(dev, sgt_buf, sgt_buf_size, DMA_BIDIRECTIONAL);
if (unlikely(dma_mapping_error(dev, addr))) {
err = -ENOMEM;
goto dma_map_single_failed;
@@ -423,7 +423,7 @@ static int build_sg_fd(struct dpaa2_eth_priv *priv,
 dma_map_single_failed:
kfree(sgt_buf);
 sgt_buf_alloc_failed:
-   dma_unmap_sg(dev, scl, num_sg, DMA_TO_DEVICE);
+   dma_unmap_sg(dev, scl, num_sg, DMA_BIDIRECTIONAL);
 dma_map_sg_failed:
kfree(scl);
return err;
@@ -461,7 +461,7 @@ static int build_single_fd(struct dpaa2_eth_priv *priv,
 
addr = dma_map_single(dev, buffer_start,
  skb_tail_pointer(skb) - buffer_start,
- DMA_TO_DEVICE);
+ DMA_BIDIRECTIONAL);
if (unlikely(dma_mapping_error(dev, addr)))
return -ENOMEM;
 
@@ -510,7 +510,7 @@ static void free_tx_fd(const struct dpaa2_eth_priv *priv,
 */
dma_unmap_single(dev, fd_addr,
 skb_tail_pointer(skb) - buffer_start,
-DMA_TO_DEVICE);
+DMA_BIDIRECTIONAL);
} else if (fd_format == dpaa2_fd_sg) {
swa = (struct dpaa2_eth_swa *)skbh;
skb = swa->skb;
@@ -519,13 +519,13 @@ static void free_tx_fd(const struct dpaa2_eth_priv *priv,
num_dma_bufs = swa->num_dma_bufs;
 
/* Unmap the scatterlist */
-   dma_unmap_sg(dev, scl, num_sg, DMA_TO_DEVICE);
+   dma_unmap_sg(dev, scl, num_sg, DMA_BIDIRECTIONAL);
kfree(scl);
 
/* Unmap the SGT buffer */
unmap_size = priv->tx_data_offset +
   sizeof(struct dpaa2_sg_entry) * (1 + num_dma_bufs);
-   dma_unmap_single(dev, fd_addr, unmap_size, DMA_TO_DEVICE);
+   dma_unmap_single(dev, fd_addr, unmap_size, DMA_BIDIRECTIONAL);
} else {
/* Unsupported format, mark it as errored and give up */
if (status)
-- 
2.11.0

Re: [PATCH 2/5] extcon: Add FUSB302 USB TYPE-C controller support

[Andy Shevchenko]

On Tue, May 23, 2017 at 12:27 PM, Chanwoo Choi  wrote:
> Hi Hans,
>
> I'm sorry for late reply.
> I'll check this thread and then give you my opinion.

Just don't forget to Cc your mails to USB Type-C people (Heikki et al).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH] drm/mediatek: hdmi: Filter interlaced resolutions

[Daniel Vetter]

On Wed, May 24, 2017 at 05:20:45PM +0800, CK Hu wrote:
> On Tue, 2017-05-23 at 15:12 +0200, Daniel Vetter wrote:
> > On Tue, May 23, 2017 at 05:28:15PM +0800, CK Hu wrote:
> > > Hi, Bibby:
> > > 
> > > I've applied this patch to my branch mediatek-drm-fixes-4.12-rc1,
> > > thanks.
> > > 
> > > Regards,
> > > CK
> > > 
> > > On Tue, 2017-01-24 at 13:10 +0800, Bibby Hsieh wrote:
> > > > Current Mediatek DRM driver does not support interlaced mode, and
> > > > will hang if such resolution is used: Filter those to prevent
> > > > kernel hangs, until the DRM driver is fixed properly.
> > > > 
> > > > Signed-off-by: Bibby Hsieh 
> > > > ---
> > > >  drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > > 
> > > > diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi.c 
> > > > b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > > index 0e8c4d9..e33678d 100644
> > > > --- a/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > > +++ b/drivers/gpu/drm/mediatek/mtk_hdmi.c
> > > > @@ -1244,6 +1244,8 @@ static int mtk_hdmi_conn_mode_valid(struct 
> > > > drm_connector *conn,
> > > > return MODE_BAD;
> > > > }
> > > >  
> > > > +   if (mode->flags & DRM_MODE_FLAG_INTERLACE)
> > > > +   return MODE_NO_INTERLACE;
> > > > if (mode->clock < 27000)
> > > > return MODE_CLOCK_LOW;
> > > > if (mode->clock > 297000)
> > 
> > You probably want to check out Jose's mode_valid work, since only
> > filtering in the connector's ->mode_valid callback isn't enough. You also
> > need to filter in ->mode_fixup (or some other place called at atomic_check
> > time).
> > -Daniel
> 
> Hi, Daniel:
> 
> Yes, I still need to filter in ->mode_fixup.
> 
> Hi, Bibby:
> 
> Because Jose's work plan to use mode_valid to replace mode_fixup, so
> it's better to refine this patch after Jose's work is done. And I would
> now remove this patch from my branch.

Btw if you have a revised version of your patch on top of Jose's series, a
tested-by on that would be awesome. The more people find it useful, the
faster it will land.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[RFC PATCH 0/2] remove CONFIG_MOVABLE_NODE

[Michal Hocko]

Hi,
I am continuing to cleanup the memory hotplug code and
CONFIG_MOVABLE_NODE seems dubious at best. The following two patches
simply removes the flag and make it de-facto always enabled.

The current semantic of the config option is twofold 1) it automatically
binds hotplugable nodes to have memory in zone_movable by default when
movable_node is enabled 2) forbids memory hotplug to online all the memory
as movable when !CONFIG_MOVABLE_NODE.

The later restriction is quite dubious because there is no clear cut of
how much normal memory do we need for a reasonable system operation. A
single memory block which is sufficient to allow further movable
onlines is far from sufficient (e.g a node with >2GB and memblocks
128MB will fill up this zone with struct pages leaving nothing for
other allocations). Removing the config option will not only reduce the
configuration space it also removes quite some code.

The semantic of the movable_node command line parameter is preserved.

The first patch removes the restriction mentioned above and the second
one simply removes all the CONFIG_MOVABLE_NODE related stuff.

Shortlog
Michal Hocko (2):
  mm, memory_hotplug: drop artificial restriction on online/offline
  mm, memory_hotplug: drop CONFIG_MOVABLE_NODE

Diffstat:
 Documentation/admin-guide/kernel-parameters.txt |  7 ++-
 drivers/base/node.c |  4 --
 include/linux/memblock.h| 18 ---
 include/linux/nodemask.h|  4 --
 mm/Kconfig  | 26 ---
 mm/memblock.c   |  2 -
 mm/memory_hotplug.c | 62 -
 mm/page_alloc.c |  2 -
 8 files changed, 5 insertions(+), 120 deletions(-)

[RFC PATCH 1/2] mm, memory_hotplug: drop artificial restriction on online/offline

[Michal Hocko]

From: Michal Hocko 

74d42d8fe146 ("memory_hotplug: ensure every online node has NORMAL
memory") has added can_offline_normal which checks the amount of
memory in !movable zones as long as CONFIG_MOVABLE_NODE is disable.
It disallows to offline memory if there is nothing left with a
justification that "memory-management acts bad when we have nodes which
is online but don't have any normal memory".

74d42d8fe146 ("memory_hotplug: ensure every online node has NORMAL
memory") has introduced a restriction that every numa node has to have
at least some memory in !movable zones before a first movable memory
can be onlined if !CONFIG_MOVABLE_NODE with the same justification

While it is true that not having _any_ memory for kernel allocations on
a NUMA node is far from great and such a node would be quite subotimal
because all kernel allocations will have to fallback to another NUMA
node but there is no reason to disallow such a configuration in
principle.

Besides that there is not really a big difference to have one memblock
for ZONE_NORMAL available or none. With 128MB size memblocks the system
might trash on the kernel allocations requests anyway. It is really
hard to draw a line on how much normal memory is really sufficient so
we have to rely on administrator to configure system sanely therefore
drop the artificial restriction and remove can_offline_normal and
can_online_high_movable altogether.

Signed-off-by: Michal Hocko 

mm, memory_hotplug: drop can_online_high_movable

 because "memory-management acts
bad when we have nodes which is online but don't have any normal memory.

Signed-off-by: Michal Hocko 
---
 mm/memory_hotplug.c | 58 -
 1 file changed, 58 deletions(-)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 599c675ad538..10052c2fd400 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -763,23 +763,6 @@ static int online_pages_range(unsigned long start_pfn, 
unsigned long nr_pages,
return 0;
 }
 
-#ifdef CONFIG_MOVABLE_NODE
-/*
- * When CONFIG_MOVABLE_NODE, we permit onlining of a node which doesn't have
- * normal memory.
- */
-static bool can_online_high_movable(int nid)
-{
-   return true;
-}
-#else /* CONFIG_MOVABLE_NODE */
-/* ensure every online node has NORMAL memory */
-static bool can_online_high_movable(int nid)
-{
-   return node_state(nid, N_NORMAL_MEMORY);
-}
-#endif /* CONFIG_MOVABLE_NODE */
-
 /* check which state of node_states will be changed when online memory */
 static void node_states_check_changes_online(unsigned long nr_pages,
struct zone *zone, struct memory_notify *arg)
@@ -979,9 +962,6 @@ int __ref online_pages(unsigned long pfn, unsigned long 
nr_pages, int online_typ
if (!allow_online_pfn_range(nid, pfn, nr_pages, online_type))
return -EINVAL;
 
-   if (online_type == MMOP_ONLINE_MOVABLE && !can_online_high_movable(nid))
-   return -EINVAL;
-
/* associate pfn range with the zone */
zone = move_pfn_range(online_type, nid, pfn, nr_pages);
 
@@ -1579,41 +1559,6 @@ check_pages_isolated(unsigned long start_pfn, unsigned 
long end_pfn)
return offlined;
 }
 
-#ifdef CONFIG_MOVABLE_NODE
-/*
- * When CONFIG_MOVABLE_NODE, we permit offlining of a node which doesn't have
- * normal memory.
- */
-static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
-{
-   return true;
-}
-#else /* CONFIG_MOVABLE_NODE */
-/* ensure the node has NORMAL memory if it is still online */
-static bool can_offline_normal(struct zone *zone, unsigned long nr_pages)
-{
-   struct pglist_data *pgdat = zone->zone_pgdat;
-   unsigned long present_pages = 0;
-   enum zone_type zt;
-
-   for (zt = 0; zt <= ZONE_NORMAL; zt++)
-   present_pages += pgdat->node_zones[zt].present_pages;
-
-   if (present_pages > nr_pages)
-   return true;
-
-   present_pages = 0;
-   for (; zt <= ZONE_MOVABLE; zt++)
-   present_pages += pgdat->node_zones[zt].present_pages;
-
-   /*
-* we can't offline the last normal memory until all
-* higher memory is offlined.
-*/
-   return present_pages == 0;
-}
-#endif /* CONFIG_MOVABLE_NODE */
-
 static int __init cmdline_parse_movable_node(char *p)
 {
 #ifdef CONFIG_MOVABLE_NODE
@@ -1741,9 +1686,6 @@ static int __ref __offline_pages(unsigned long start_pfn,
node = zone_to_nid(zone);
nr_pages = end_pfn - start_pfn;
 
-   if (zone_idx(zone) <= ZONE_NORMAL && !can_offline_normal(zone, 
nr_pages))
-   return -EINVAL;
-
/* set above range as isolated */
ret = start_isolate_page_range(start_pfn, end_pfn,
   MIGRATE_MOVABLE, true);
-- 
2.11.0

[RFC PATCH 2/2] mm, memory_hotplug: drop CONFIG_MOVABLE_NODE

[Michal Hocko]

From: Michal Hocko 

20b2f52b73fe ("numa: add CONFIG_MOVABLE_NODE for movable-dedicated
node") has introduced CONFIG_MOVABLE_NODE without a good explanation on
why it is actually useful. It makes a lot of sense to make movable node
semantic opt in but we already have that because the feature has to be
explicitly enabled on the kernel command line. A config option on top
only makes the configuration space larger without a good reason. It also
adds an additional ifdefery that pollutes the code. Just drop the config
option and make it de-facto always enabled. This shouldn't introduce any
change to the semantic.

Signed-off-by: Michal Hocko 
---
 Documentation/admin-guide/kernel-parameters.txt |  7 +--
 drivers/base/node.c |  4 
 include/linux/memblock.h| 18 -
 include/linux/nodemask.h|  4 
 mm/Kconfig  | 26 -
 mm/memblock.c   |  2 --
 mm/memory_hotplug.c |  4 
 mm/page_alloc.c |  2 --
 8 files changed, 5 insertions(+), 62 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index facc20a3f962..ec7d6ae01c96 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -2246,8 +2246,11 @@
that the amount of memory usable for all allocations
is not too small.
 
-   movable_node[KNL] Boot-time switch to enable the effects
-   of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details.
+   movable_node[KNL] Boot-time switch to make hotplugable to be
+   movable. This means that the memory of such nodes
+   will be usable only for movable allocations which
+   rules out almost all kernel allocations. Use with
+   caution!
 
MTD_Partition=  [MTD]
Format: ,,,
diff --git a/drivers/base/node.c b/drivers/base/node.c
index dff5b53f7905..26f4b9c02f2c 100644
--- a/drivers/base/node.c
+++ b/drivers/base/node.c
@@ -639,9 +639,7 @@ static struct node_attr node_state_attr[] = {
 #ifdef CONFIG_HIGHMEM
[N_HIGH_MEMORY] = _NODE_ATTR(has_high_memory, N_HIGH_MEMORY),
 #endif
-#ifdef CONFIG_MOVABLE_NODE
[N_MEMORY] = _NODE_ATTR(has_memory, N_MEMORY),
-#endif
[N_CPU] = _NODE_ATTR(has_cpu, N_CPU),
 };
 
@@ -652,9 +650,7 @@ static struct attribute *node_state_attrs[] = {
 #ifdef CONFIG_HIGHMEM
_state_attr[N_HIGH_MEMORY].attr.attr,
 #endif
-#ifdef CONFIG_MOVABLE_NODE
_state_attr[N_MEMORY].attr.attr,
-#endif
_state_attr[N_CPU].attr.attr,
NULL
 };
diff --git a/include/linux/memblock.h b/include/linux/memblock.h
index bdfc65af4152..9622fb8c101b 100644
--- a/include/linux/memblock.h
+++ b/include/linux/memblock.h
@@ -57,10 +57,8 @@ struct memblock {
 
 extern struct memblock memblock;
 extern int memblock_debug;
-#ifdef CONFIG_MOVABLE_NODE
 /* If movable_node boot option specified */
 extern bool movable_node_enabled;
-#endif /* CONFIG_MOVABLE_NODE */
 
 #ifdef CONFIG_ARCH_DISCARD_MEMBLOCK
 #define __init_memblock __meminit
@@ -168,7 +166,6 @@ void __next_reserved_mem_region(u64 *idx, phys_addr_t 
*out_start,
 i != (u64)ULLONG_MAX;  \
 __next_reserved_mem_region(, p_start, p_end))
 
-#ifdef CONFIG_MOVABLE_NODE
 static inline bool memblock_is_hotpluggable(struct memblock_region *m)
 {
return m->flags & MEMBLOCK_HOTPLUG;
@@ -178,16 +175,6 @@ static inline bool __init_memblock 
movable_node_is_enabled(void)
 {
return movable_node_enabled;
 }
-#else
-static inline bool memblock_is_hotpluggable(struct memblock_region *m)
-{
-   return false;
-}
-static inline bool movable_node_is_enabled(void)
-{
-   return false;
-}
-#endif
 
 static inline bool memblock_is_mirror(struct memblock_region *m)
 {
@@ -295,7 +282,6 @@ phys_addr_t memblock_alloc_try_nid(phys_addr_t size, 
phys_addr_t align, int nid)
 
 phys_addr_t memblock_alloc(phys_addr_t size, phys_addr_t align);
 
-#ifdef CONFIG_MOVABLE_NODE
 /*
  * Set the allocation direction to bottom-up or top-down.
  */
@@ -313,10 +299,6 @@ static inline bool memblock_bottom_up(void)
 {
return memblock.bottom_up;
 }
-#else
-static inline void __init memblock_set_bottom_up(bool enable) {}
-static inline bool memblock_bottom_up(void) { return false; }
-#endif
 
 /* Flags for memblock_alloc_base() amd __memblock_alloc_base() */
 #define MEMBLOCK_ALLOC_ANYWHERE(~(phys_addr_t)0)
diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index f746e44d4046..cf0b91c3ec12 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -387,11 +387,7 

[PATCH] x86: Prevent uninitialized stack byte read in apply_alternatives()

[Mateusz Jurczyk]

In the current form of the code, if a->replacementlen is 0, the reference
to *insnbuf for comparison touches potentially garbage memory. While it
doesn't affect the execution flow due to the subsequent a->replacementlen
comparison, it is (rightly) detected as use of uninitialized memory by a
runtime instrumentation currently under my development, and could be
detected as such by other tools in the future, too (e.g. KMSAN).

Fix the "false-positive" by reordering the conditions to first check the
replacement instruction length before referencing specific opcode bytes.

Signed-off-by: Mateusz Jurczyk 
---
 arch/x86/kernel/alternative.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index c5b8f760473c..d03ba6bc97d8 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -410,7 +410,7 @@ void __init_or_module noinline apply_alternatives(struct 
alt_instr *start,
insnbuf_sz = a->replacementlen;
 
/* 0xe8 is a relative jump; fix the offset. */
-   if (*insnbuf == 0xe8 && a->replacementlen == 5) {
+   if (a->replacementlen == 5 && *insnbuf == 0xe8) {
*(s32 *)(insnbuf + 1) += replacement - instr;
DPRINTK("Fix CALL offset: 0x%x, CALL 0x%lx",
*(s32 *)(insnbuf + 1),
-- 
2.13.0.219.gdb65acc882-goog

Re: 4.9.28: VIA velocity hang: how to find cause?

[Udo van den Heuvel]

Hello,

This issue occurs on VIA Epia M910E.
Both interfaces suffer from this.
Setting msglvl with ethtool has no effect on the info the driver
provides on any issues.
So how to proceed from here?
If this is a software issue, which I cannot determine, the driver is
useless in its present state.

Kind regards,
Udo

On 23-05-17 18:07, Udo van den Heuvel wrote:
> Hello,
> 
> I noticed multiple times that VIA velocity interface stop functioning
> without reason but is revived after and `ifdown ethX; ifup ethX`.
> No data is transferred until the `fix` is applied.
> No errors are shown in dmesg or /var/log/messages w.r.t. the interface.
> How to find the root cause?
> 
> This is with kernel 4.9.28.
> 
> Kind regards,
> Udo
> 

Re: [PATCH] x86: Prevent uninitialized stack byte read in apply_alternatives()

[Borislav Petkov]

On Wed, May 24, 2017 at 02:51:20PM +0200, Mateusz Jurczyk wrote:
> In the current form of the code, if a->replacementlen is 0, the reference
> to *insnbuf for comparison touches potentially garbage memory. While it
> doesn't affect the execution flow due to the subsequent a->replacementlen
> comparison, it is (rightly) detected as use of uninitialized memory by a
> runtime instrumentation currently under my development, and could be
> detected as such by other tools in the future, too (e.g. KMSAN).
> 
> Fix the "false-positive" by reordering the conditions to first check the
> replacement instruction length before referencing specific opcode bytes.
> 
> Signed-off-by: Mateusz Jurczyk 
> ---
>  arch/x86/kernel/alternative.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index c5b8f760473c..d03ba6bc97d8 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -410,7 +410,7 @@ void __init_or_module noinline apply_alternatives(struct 
> alt_instr *start,
>   insnbuf_sz = a->replacementlen;
>  
>   /* 0xe8 is a relative jump; fix the offset. */

Sure but put in short the reason to look at the instruction length first
in the comment above so that it is clear why we're doing it this way.

> - if (*insnbuf == 0xe8 && a->replacementlen == 5) {
> + if (a->replacementlen == 5 && *insnbuf == 0xe8) {
>   *(s32 *)(insnbuf + 1) += replacement - instr;
>   DPRINTK("Fix CALL offset: 0x%x, CALL 0x%lx",
>   *(s32 *)(insnbuf + 1),
> -- 

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH v2] drivers: phy: Add Cortina CS4340 driver

[Bogdan Purcareata]

Add basic support for Cortina PHY drivers. Support only CS4340 for now.
The phys are not compatible with IEEE 802.3 clause 45 registers. Implement
proper read_status support, so that phy polling does not cause bus
register access errors.

The driver should be described using the "ethernet-phy-id" device tree
compatible.

Signed-off-by: Bogdan Purcareata 
---
v1 -> v2:
- Rename "mdio-cortina.c" to "cortina.c" since it's a phy driver.
- Test probing based on the "ethernet-phy-id" compatible. In the previous
  version, getting the phy_id via get_phy_c45_ids() involved an additional
  hack. Drop that approach and document probing in the commit message.

 drivers/net/phy/Kconfig   |  5 +++
 drivers/net/phy/Makefile  |  1 +
 drivers/net/phy/cortina.c | 90 +++
 3 files changed, 96 insertions(+)
 create mode 100644 drivers/net/phy/cortina.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 22dea7f..ad09e2d 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -240,6 +240,11 @@ config CICADA_PHY
---help---
  Currently supports the cis8204
 
+config CORTINA_PHY
+   tristate "Cortina quad-10G Ethernet PHY"
+   ---help---
+ Currently supports the CS4340 phy.
+
 config DAVICOM_PHY
tristate "Davicom PHYs"
---help---
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 79365be..0de3e20 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -47,6 +47,7 @@ obj-$(CONFIG_BCM_CYGNUS_PHY)  += bcm-cygnus.o
 obj-$(CONFIG_BCM_NET_PHYLIB)   += bcm-phy-lib.o
 obj-$(CONFIG_BROADCOM_PHY) += broadcom.o
 obj-$(CONFIG_CICADA_PHY)   += cicada.o
+obj-$(CONFIG_CORTINA_PHY)  += cortina.o
 obj-$(CONFIG_DAVICOM_PHY)  += davicom.o
 obj-$(CONFIG_DP83640_PHY)  += dp83640.o
 obj-$(CONFIG_DP83848_PHY)  += dp83848.o
diff --git a/drivers/net/phy/cortina.c b/drivers/net/phy/cortina.c
new file mode 100644
index 000..6f054ed
--- /dev/null
+++ b/drivers/net/phy/cortina.c
@@ -0,0 +1,90 @@
+/*
+ *Based on code from Cortina Systems, Inc.
+ *
+ *Copyright 2011 Cortina Systems, Inc.
+ *Copyright 2017 NXP
+ *
+ *This program is free software; you can redistribute it and/or modify
+ *it under the terms of the GNU General Public License as published by
+ *the Free Software Foundation; either version 2 of the License, or
+ *(at your option) any later version.
+ *
+ *This program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+
+#define PHY_ID_CS4340  0x13e51002
+
+#define CORTINA_GPIO_GPIO_INTS 0x16D
+
+static int cortina_read_x(struct phy_device *phydev, int off, u16 regnum)
+{
+   return mdiobus_read(phydev->mdio.bus, phydev->mdio.addr + off,
+   MII_ADDR_C45 | regnum);
+}
+
+static int cortina_read(struct phy_device *phydev, u16 regnum)
+{
+   return cortina_read_x(phydev, 0, regnum);
+}
+
+static int cortina_config_aneg(struct phy_device *phydev)
+{
+   phydev->supported = SUPPORTED_1baseT_Full;
+   phydev->advertising = SUPPORTED_1baseT_Full;
+
+   return 0;
+}
+
+static int cortina_read_status(struct phy_device *phydev)
+{
+   int gpio_int_status;
+   int ret = 0;
+
+   gpio_int_status = cortina_read(phydev, CORTINA_GPIO_GPIO_INTS);
+   if (gpio_int_status < 0) {
+   ret = gpio_int_status;
+   goto err;
+   }
+
+   if (gpio_int_status & 0x8) {
+   phydev->speed = SPEED_1;
+   phydev->duplex = DUPLEX_FULL;
+   phydev->link = 1;
+   } else {
+   phydev->link = 0;
+   }
+
+err:
+   return ret;
+}
+
+static int cortina_soft_reset(struct phy_device *phydev)
+{
+   return 0;
+}
+
+static struct phy_driver cortina_driver[] = {
+{
+   .phy_id = PHY_ID_CS4340,
+   .phy_id_mask= 0x,
+   .name   = "Cortina CS4340",
+   .config_aneg= cortina_config_aneg,
+   .read_status= cortina_read_status,
+   .soft_reset = cortina_soft_reset,
+},
+};
+
+module_phy_driver(cortina_driver);
+
+static struct mdio_device_id __maybe_unused cortina_tbl[] = {
+   { PHY_ID_CS4340, 0x},
+   {},
+};
+
+MODULE_DEVICE_TABLE(mdio, cortina_tbl);
-- 
1.9.1

Re: [PATCH 1/2] nvme: fix multiple ctrl removal scheduling

[Christoph Hellwig]

On Wed, May 24, 2017 at 01:15:47AM +0300, Rakesh Pandit wrote:
> Commit c5f6ce97c1210 tries to address multiple resets but fails as
> work_busy doesn't involve any synchronization and can fail.  This is
> reproducible easily as can be seen by WARNING below which is triggered
> with line:
> 
> WARN_ON(dev->ctrl.state == NVME_CTRL_RESETTING)
> 
> Allowing multiple resets can result in multiple controller removal as
> well if different conditions inside nvme_reset_work fail and which
> might deadlock on device_release_driver.
> 
> This patch addresses the problem by using state of controller to
> decide whether reset should be queued or not as state change is
> synchronizated using controller spinlock.

But we don't hold the lock over the check and the decision.  I suspect
what we need to do is to actually change to the resetting state
before queueing up the reset work.  Can you give that a spin?

Re: pxa3xx-nand failing to find device on linux-next

[Chris Packham]

On 23/05/17 17:27, Chris Packham wrote:
> Hi,
>
> I'm doing some testing on linux-next and I'm finding that my nand flash
> has disappeared.
>
> pxa3xx-nand f10d.flash: This platform can't do DMA on this device
> pxa3xx-nand f10d.flash: non-supported command ef
> pxa3xx-nand f10d.flash: non-supported command ee
> pxa3xx-nand f10d.flash: non-supported command ef
> pxa3xx-nand f10d.flash: non-supported command ee
> On-die ECC forcefully enabled, not supported
> nand: No NAND device found
> pxa3xx-nand f10d.flash: failed to scan nand at cs 0
>
> This was working around 4.11. I'll try to do some more digging tomorrow
> to narrow down a failure point but I thought I'd send this out now just
> in case it rings any bells.
>
> The board I'm using (DB-88F6820-AMC) is unfortunately out-of tree but it
> should be pretty close to the armada-388-db. I can make my dts available
> if it's helpful.

Still works on 4.12-rc2. Fails on next-20170524.

This appears to be due to commit b566d9c055de ("mtd: nand: add support 
for Micron on-die ECC"). Which based on the description seems intentional.

Since I have access to a hardware platform that has a micron flash with
ECC forcefully enabled how can I help to get this implemented.

Re: [PATCH v3 3/7] arch/sparc: Define config parameter CPU_BIG_ENDIAN

[Geert Uytterhoeven]

On Tue, May 23, 2017 at 11:45 PM, Babu Moger  wrote:
> Found this problem while enabling queued rwlock on SPARC.
> The parameter CONFIG_CPU_BIG_ENDIAN is used to clear the
> specific byte in qrwlock structure. Without this parameter,
> we clear the wrong byte. Here is the code.
>
> static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
>  {
> return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
>  }
>
> Define CPU_BIG_ENDIAN for SPARC to fix it.
>
> Signed-off-by: Babu Moger 
> Reviewed-by: Håkon Bugge 
> Reviewed-by: Jane Chu 
> Reviewed-by: Shannon Nelson 
> Reviewed-by: Vijay Kumar 
> ---
>  arch/sparc/Kconfig |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
> index 908f019..2f58c16 100644
> --- a/arch/sparc/Kconfig
> +++ b/arch/sparc/Kconfig
> @@ -92,6 +92,10 @@ config ARCH_DEFCONFIG
>  config ARCH_PROC_KCORE_TEXT
> def_bool y
>
> +config CPU_BIG_ENDIAN
> +   bool
> +   default y if SPARC

def_bool y?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH v4 1/2] PCI: Add tango MSI controller support

[Robin Murphy]

On 23/05/17 20:15, Mason wrote:
> On 23/05/2017 20:03, Robin Murphy wrote:
>> On 23/05/17 18:54, Mason wrote:
>>> On 23/05/2017 19:03, Bjorn Helgaas wrote:
 On Wed, May 17, 2017 at 04:56:08PM +0200, Marc Gonzalez wrote:
> On 20/04/2017 16:28, Marc Gonzalez wrote:
>
>> +static int tango_set_affinity(struct irq_data *data,
>> +const struct cpumask *mask, bool force)
>> +{
>> +return -EINVAL;
>> +}
>> +
>> +static struct irq_chip tango_chip = {
>> +.irq_ack= tango_ack,
>> +.irq_mask   = tango_mask,
>> +.irq_unmask = tango_unmask,
>> +.irq_set_affinity   = tango_set_affinity,
>> +.irq_compose_msi_msg= tango_compose_msi_msg,
>> +};
>
> Hmmm... I'm wondering why .irq_set_affinity is required.
>
> static int setup_affinity(struct irq_desc *desc, struct cpumask *mask)
> first calls __irq_can_set_affinity() to check whether
> desc->irq_data.chip->irq_set_affinity) exists.
>
> then calls irq_do_set_affinity(>irq_data, mask, false);
> which calls chip->irq_set_affinity(data, mask, force);
> = msi_domain_set_affinity()
> which calls parent->chip->irq_set_affinity() unconditionally.
>
> Would it make sense to test that the callback is implemented
> before calling it?
>
>
> [0.723895] Unable to handle kernel NULL pointer dereference at 
> virtual address 

 I'm not sure what you're asking.

 Is this a bug report for the v4 tango driver?
>>>
>>> No.
>>>
 Or are you asking whether msi_domain_set_affinity() should be changed
 to check whether parent->chip->irq_set_affinity is implemented?
>>>
>>> Yes. The way things are implemented now, drivers are forced
>>> to define an irq_set_affinity callback, even if it just returns
>>> an error, otherwise, the kernel crashes, because of the
>>> unconditional function pointer deref. 
>>>
 msi_domain_set_affinity() has called parent->chip->irq_set_affinity()
 without checking since it was added in 2014 by f3cf8bb0d6c3 ("genirq: Add
 generic msi irq domain support"), so if there's a problem here, it's most
 likely in the tango code.
>>>
>>> The issue is having to define an "empty" function.
>>> (Unnecessary code bloat and maintenance.)
>>
>> AFAICS, only one driver (other than this one) implements a "do nothing"
>> set_affinity callback - everyone else who doesn't do anything hardware
>> specific just passes it along via irq_chip_set_affinity_parent().
> 
> I counted 4. Where did I mess up?
> 
> advk_msi_set_affinity
> altera_msi_set_affinity
> nwl_msi_set_affinity
> vmd_irq_set_affinity
> tango_set_affinity

Fair point - I went through drivers/irqchip and the various
arch-specific instances and found ls_scfg_msi_set_affinity(), but
somehow skipped over drivers/pci. Anyway, I think the question stands of
why are these handful of drivers *not* using irq_chip_set_affinity_parent()?

As an outsider, it naively seems logical that the affinity of an MSI
which just gets translated to a wired interrupt should propagate through
to the affinity of that wired interrupt, but maybe there are reasons not
to; I really don't know.

Robin.

[PATCH] MAINTAINERS: Update email address for patches to Wolfson parts

[Charles Keepax]

A somewhat overdue update of the address for sending patches on Wolfson
parts to since our acquision a couple of years ago by Cirrus Logic.

Signed-off-by: Charles Keepax 
---

Not 100% sure you are the best person to send this to Mark, but felt
like the right choice since the vast majority of our parts are audio
ones. Please let me know if I should send to someone else.

Alas we still can't send emails from the opensource.cirrus.com domain
but hopefully that will come soon.

Thanks,
Charles

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 9e98464..01dc6a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -13861,7 +13861,7 @@ S:  Odd fixes
 F: drivers/net/wireless/wl3501*
 
 WOLFSON MICROELECTRONICS DRIVERS
-L: patc...@opensource.wolfsonmicro.com
+L: patc...@opensource.cirrus.com
 T: git https://github.com/CirrusLogic/linux-drivers.git
 W: https://github.com/CirrusLogic/linux-drivers/wiki
 S: Supported
-- 
2.1.4

[PATCH 2/2] ASoC: wm_adsp: Remove unused member of struct wm_coeff_ctl_ops

[Richard Fitzgerald]

The xinfo member of struct wm_coeff_ctl_ops is never used.

Signed-off-by: Richard Fitzgerald 
---
 sound/soc/codecs/wm_adsp.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index a7dc760..5aff83b 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -482,8 +482,6 @@ struct wm_coeff_ctl_ops {
struct snd_ctl_elem_value *ucontrol);
int (*xput)(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol);
-   int (*xinfo)(struct snd_kcontrol *kcontrol,
-struct snd_ctl_elem_info *uinfo);
 };
 
 struct wm_coeff_ctl {
-- 
1.9.1

[PATCH 1/2] ASoC: wm_adsp: Fix type warning in sprintf

[Richard Fitzgerald]

The shift member of struct soc_mixer_control is unsigned int.

Signed-off-by: Richard Fitzgerald 
---
 sound/soc/codecs/wm_adsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm_adsp.c b/sound/soc/codecs/wm_adsp.c
index 20695b6..a7dc760 100644
--- a/sound/soc/codecs/wm_adsp.c
+++ b/sound/soc/codecs/wm_adsp.c
@@ -2654,7 +2654,7 @@ int wm_adsp2_preloader_put(struct snd_kcontrol *kcontrol,
(struct soc_mixer_control *)kcontrol->private_value;
char preload[32];
 
-   snprintf(preload, ARRAY_SIZE(preload), "DSP%d Preload", mc->shift);
+   snprintf(preload, ARRAY_SIZE(preload), "DSP%u Preload", mc->shift);
 
dsp->preloaded = ucontrol->value.integer.value[0];
 
-- 
1.9.1

[PATCH v2 0/6] mailbox: arm_mhu: add support for doorbell mode

[Sudeep Holla]

Hi,

This series adds doorbell support to ARM MHU mailbox controller driver.
Since we need to callback the different client based on the doorbel bits
triggered from the remote, we can manage with single channel for the set
of 32 doorbells.

Regards,
Sudeep

v1->v2:
- Removed the notion od subchannels
- Treat each bit in the MHU register as a doorbell and hence
  different channel with respect to mailbox framework

v1: https://www.spinics.net/lists/kernel/msg2500461.html

Sudeep Holla (6):
  mailbox: arm_mhu: reorder header inclusion and drop unneeded ones
  Documentation: devicetree: add bindings to support ARM MHU doorbells
  mailbox: arm_mhu: migrate to threaded irq handler
  mailbox: arm_mhu: re-factor data structure to add doorbell support
  mailbox: arm_mhu: add full support for the doorbells
  mailbox: arm_mhu: add support to read and record mbox-name

 .../devicetree/bindings/mailbox/arm-mhu.txt|  46 ++-
 drivers/mailbox/arm_mhu.c  | 386 ++---
 2 files changed, 383 insertions(+), 49 deletions(-)

--
2.7.4

[PATCH v2 4/6] mailbox: arm_mhu: re-factor data structure to add doorbell support

[Sudeep Holla]

In order to support doorbells, we need a bit of reword around data
structures that are per-channel. Since the number of doorbells are
not fixed though restricted to maximum of 20, the channel assignment
and initialization is move to xlate function.

This patch also adds the platform data for the existing support of one
channel per physical channel.

Cc: Alexey Klimov 
Cc: Jassi Brar 
Signed-off-by: Sudeep Holla 
---
 drivers/mailbox/arm_mhu.c | 208 +-
 1 file changed, 186 insertions(+), 22 deletions(-)

diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
index ebe17c097f43..ae06924eb6f4 100644
--- a/drivers/mailbox/arm_mhu.c
+++ b/drivers/mailbox/arm_mhu.c
@@ -20,6 +20,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define INTR_STAT_OFS  0x0
 #define INTR_SET_OFS   0x8
@@ -30,7 +32,8 @@
 #define MHU_SEC_OFFSET 0x200
 #define TX_REG_OFFSET  0x100
 
-#define MHU_CHANS  3
+#define MHU_NUM_PCHANS 3   /* Secure, Non-Secure High and Low Priority */
+#define MHU_CHAN_MAX   20  /* Max channels to save on unused RAM */
 
 struct mhu_link {
unsigned irq;
@@ -40,53 +43,175 @@ struct mhu_link {
 
 struct arm_mhu {
void __iomem *base;
-   struct mhu_link mlink[MHU_CHANS];
-   struct mbox_chan chan[MHU_CHANS];
+   struct mhu_link mlink[MHU_NUM_PCHANS];
struct mbox_controller mbox;
+   struct device *dev;
 };
 
+/**
+ * ARM MHU Mailbox platform specific configuration
+ *
+ * @num_pchans: Maximum number of physical channels
+ * @num_doorbells: Maximum number of doorbells per physical channel
+ */
+struct mhu_mbox_pdata {
+   unsigned int num_pchans;
+   unsigned int num_doorbells;
+   bool support_doorbells;
+};
+
+/**
+ * ARM MHU Mailbox allocated channel information
+ *
+ * @mhu: Pointer to parent mailbox device
+ * @pchan: Physical channel within which this doorbell resides in
+ * @doorbell: doorbell number pertaining to this channel
+ */
+struct mhu_channel {
+   struct arm_mhu *mhu;
+   unsigned int pchan;
+   unsigned int doorbell;
+};
+
+static inline struct mbox_chan *
+mhu_mbox_to_channel(struct mbox_controller *mbox,
+   unsigned int pchan, unsigned int doorbell)
+{
+   int i;
+   struct mhu_channel *chan_info;
+
+   for (i = 0; i < mbox->num_chans; i++) {
+   chan_info = mbox->chans[i].con_priv;
+   if (chan_info && chan_info->pchan == pchan &&
+   chan_info->doorbell == doorbell)
+   return >chans[i];
+   }
+
+   dev_err(mbox->dev,
+   "Channel not registered: physical channel: %d doorbell: %d\n",
+   pchan, doorbell);
+
+   return NULL;
+}
+
+static unsigned int mhu_mbox_irq_to_pchan_num(struct arm_mhu *mhu, int irq)
+{
+   unsigned int pchan;
+   struct mhu_mbox_pdata *pdata = dev_get_platdata(mhu->dev);
+
+   for (pchan = 0; pchan < pdata->num_pchans; pchan++)
+   if (mhu->mlink[pchan].irq == irq)
+   break;
+   return pchan;
+}
+
+static struct mbox_chan *mhu_mbox_xlate(struct mbox_controller *mbox,
+   const struct of_phandle_args *spec)
+{
+   struct arm_mhu *mhu = dev_get_drvdata(mbox->dev);
+   struct mhu_mbox_pdata *pdata = dev_get_platdata(mhu->dev);
+   struct mhu_channel *chan_info;
+   struct mbox_chan *chan = NULL;
+   unsigned int pchan = spec->args[0];
+   unsigned int doorbell = pdata->support_doorbells ? spec->args[1] : 0;
+   int i;
+
+   /* Bounds checking */
+   if (pchan >= pdata->num_pchans || doorbell >= pdata->num_doorbells) {
+   dev_err(mbox->dev,
+   "Invalid channel requested pchan: %d doorbell: %d\n",
+   pchan, doorbell);
+   return ERR_PTR(-EINVAL);
+   }
+
+   for (i = 0; i < mbox->num_chans; i++) {
+   chan_info = mbox->chans[i].con_priv;
+
+   /* Is requested channel free? */
+   if (chan_info &&
+   mbox->dev == chan_info->mhu->dev &&
+   pchan == chan_info->pchan &&
+   doorbell == chan_info->doorbell) {
+   dev_err(mbox->dev, "Channel in use\n");
+   return ERR_PTR(-EBUSY);
+   }
+
+   /*
+* Find the first free slot, then continue checking
+* to see if requested channel is in use
+*/
+   if (!chan && !chan_info)
+   chan = >chans[i];
+   }
+
+   if (!chan) {
+   dev_err(mbox->dev, "No free channels left\n");
+   return ERR_PTR(-EBUSY);
+   }
+
+   chan_info = devm_kzalloc(mbox->dev, sizeof(*chan_info), GFP_KERNEL);
+   if (!chan_info)
+   return ERR_PTR(-ENOMEM);

[PATCH v2 2/6] Documentation: devicetree: add bindings to support ARM MHU doorbells

[Sudeep Holla]

The ARM MHU has mechanism to assert interrupt signals to facilitate
inter-processor message based communication. It drives the signal using
a 32-bit register, with all 32-bits logically ORed together. It also
enables software to set, clear and check the status of each of the bits
of this register independently. Each bit of the register can be
associated with a type of event that can contribute to raising the
interrupt thereby allowing it to be used as independent doorbells.

Since the first version of this binding can't support doorbells,
this patch extends the existing binding to support them.

Cc: Alexey Klimov 
Cc: Jassi Brar 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Signed-off-by: Sudeep Holla 
---
 .../devicetree/bindings/mailbox/arm-mhu.txt| 46 --
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt 
b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
index 4971f03f0b33..bd9a3a267caf 100644
--- a/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
+++ b/Documentation/devicetree/bindings/mailbox/arm-mhu.txt
@@ -10,21 +10,42 @@ STAT register and the remote clears it after having read 
the data.
 The last channel is specified to be a 'Secure' resource, hence can't be
 used by Linux running NS.
 
+The MHU drives the interrupt signal using a 32-bit register, with all
+32-bits logically ORed together. It provides a set of registers to
+enable software to set, clear and check the status of each of the bits
+of this register independently. The use of 32 bits per interrupt line
+enables software to provide more information about the source of the
+interrupt. For example, each bit of the register can be associated with
+a type of event that can contribute to raising the interrupt. Each of
+the 32-bits can be used as "doorbell" to alert the remote processor.
+
 Mailbox Device Node:
 
 
 Required properties:
 
-- compatible:  Shall be "arm,mhu" & "arm,primecell"
+- compatible:  Shall be "arm,primecell" and one of the below:
+   "arm,mhu" - if the controller doesn't support
+   doorbell model
+   "arm,mhu-doorbell" - if the controller supports
+   doorbell model
 - reg: Contains the mailbox register address range (base
address and length)
-- #mbox-cells  Shall be 1 - the index of the channel needed.
+- #mbox-cells  Shall be 1 - the index of the channel needed when
+   compatible is "arm,mhu"
+   Shall be 2 - the index of the channel needed, and
+   the index of the doorbell bit with the channel when
+   compatible is "arm,mhu-doorbell"
 - interrupts:  Contains the interrupt information corresponding to
-   each of the 3 links of MHU.
+   each of the 3 physical channels of MHU namely low
+   priority non-secure, high priority non-secure and
+   secure channels.
 
 Example:
 
 
+1. Controller which doesn't support doorbells
+
mhu: mailbox@2b1f {
#mbox-cells = <1>;
compatible = "arm,mhu", "arm,primecell";
@@ -41,3 +62,22 @@ used by Linux running NS.
reg = <0 0x2e00 0x4000>;
mboxes = < 1>; /* HP-NonSecure */
};
+
+2. Controller which supports doorbells
+
+   mhu: mailbox@2b1f {
+   #mbox-cells = <2>;
+   compatible = "arm,mhu-doorbell", "arm,primecell";
+   reg = <0 0x2b1f 0x1000>;
+   interrupts = <0 36 4>, /* LP-NonSecure */
+<0 35 4>, /* HP-NonSecure */
+<0 37 4>; /* Secure */
+   clocks = < 0 2 1>;
+   clock-names = "apb_pclk";
+   };
+
+   mhu_client: scb@2e00 {
+   compatible = "arm,scpi";
+   reg = <0 0x2e00 0x200>;
+   mboxes = < 1 4>; /* HP-NonSecure 5th doorbell bit */
+   };
-- 
2.7.4

[PATCH v2 1/6] mailbox: arm_mhu: reorder header inclusion and drop unneeded ones

[Sudeep Holla]

This patch just re-orders some of the headers includes and also drop
the ones that are unnecessary.

Cc: Alexey Klimov 
Cc: Jassi Brar 
Signed-off-by: Sudeep Holla 
---
 drivers/mailbox/arm_mhu.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/mailbox/arm_mhu.c b/drivers/mailbox/arm_mhu.c
index 99befa76e37c..be0f293a9457 100644
--- a/drivers/mailbox/arm_mhu.c
+++ b/drivers/mailbox/arm_mhu.c
@@ -13,16 +13,13 @@
  * GNU General Public License for more details.
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
+#include 
 #include 
-#include 
-#include 
 #include 
+#include 
 
 #define INTR_STAT_OFS  0x0
 #define INTR_SET_OFS   0x8
-- 
2.7.4

RE: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD and RI irqs to be off

[Steve Twiss]

Hi Fabio,

On 23 May 2017 17:26 Fabio Estevam wrote:
> Subject: Re: [PATCH V1] serial: imx: revert setup DCEDTE early and ensure DCD 
> and RI irqs to be off
> On Tue, May 23, 2017 at 9:17 AM, Steve Twiss wrote:
> >
> > Revert the commit e61c38d85b7392e ("serial: imx: setup DCEDTE early and
> > ensure DCD and RI irqs to be off")
> >
> > The patch submitted to setup DCEDTE early and ensure DCD and RI irqs to
> > be off, causes a serial console display problem the i.MX6Q SABRESD board.
> > The console becomes unreadable and unwritable.
> >
> > Tested-by: Steve Twiss 
> > Signed-off-by: Steve Twiss 
> >
> > ---
> > This patch applies against linux-next and v4.12-rc2
> >
> > Hi,
> >
> > I have been seeing a problem with the serial output console on the i.MX6Q
> > SABRESD, but not the i.MX6DL SABRESD. Everything was fine up to
> > linux-mainline/v4.11 but changed after linux-next/next-20170501.
> >
> > Some bisection has pointed at the commit
> > e61c38d85b7392e033ee03bca46f1d6006156175 which, once removed from my
> > linux-next/v4.12-rc2 build allows the i.MX6Q board to display the console
> > correctly again.
> >
> > This patch removes the original commit e61c38d85b7392e ("serial: imx:
> > setup DCEDTE early and ensure DCD and RI irqs to be off") from  linux-next
> > v4.12-rc2 and fixes the serial problem seen in the i.MX6Q SABRESD board.
> 
> How can the error be reproduced?
> 
> Care to share more details of the error, please?

The USB to UART connection gets corrupted.
If this patch is applied to the kernel, the i.MX6 Q (quad), and only this board 
as far as
we know, starts to fail. This does *not* change the i.MX6DL and other sabre 
boards
have been tested on kernelci.org and do not see a problem.

An NXP/Freescale SABRESD i.MX6 Q board is requred.

My system for testing is to TFTP the Linux kernel over an ethernet connection. 
The
U-boot executes okay and the UART is working at that point. When the kernel 
loads
the console trace becomes garbled, in the sense that I get the some characters 
being
output to the console, in the style of the kernel starting up, but they are not 
correct.

I expect the kernel has started ok, but I am unable to read/write through the 
UART
console because of corruptions.

Console log with the output I am seeing with linux-next/v4.12-rc2
--- 8< ---
U-Boot 2009.08-1-gf65536a (Jan 12 2015 - 15:47:19)

CPU: Freescale i.MX6 family TO1.2 at 792 MHz
Thermal sensor with ratio = 200
Temperature:   46 C, calibration data 0x5f15527d
mx6q pll1: 792MHz
mx6q pll2: 528MHz
mx6q pll3: 480MHz
mx6q pll8: 50MHz
ipg clock : 6600Hz
ipg per clock : 6600Hz
uart clock: 8000Hz
cspi clock: 6000Hz
ahb clock : 13200Hz
axi clock   : 26400Hz
emi_slow clock: 13200Hz
ddr clock : 52800Hz
usdhc1 clock  : 19800Hz
usdhc2 clock  : 19800Hz
usdhc3 clock  : 19800Hz
usdhc4 clock  : 19800Hz
nfc clock : 2400Hz
Board: i.MX6Q-SABRESD: unknown-board Board: 0x63012 [WDOG ]
Boot Device: SD
I2C:   ready
DRAM:   1 GB
MMC:   FSL_USDHC: 0,FSL_USDHC: 1,FSL_USDHC: 2,FSL_USDHC: 3
In:serial
Out:   serial
Err:   serial
Found PFUZE100! deviceid=10,revid=11
Net:   got MAC address from IIM: 00:04:9f:02:e3:0a
FEC0 [PRIME]
Hit any key to stop autoboot:  0
PHY indentify @ 0x1 = 0x004dd074
FEC: Link is Up 796d
Using FEC0 device
TFTP from server 192.168.2.1; our IP address is 192.168.2.2
Filename 'uImage_dtb.imx6q.v4.12-rc2'.
Load address: 0x1200
Loading: #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 #
 ##
done
Bytes transferred = 5951108 (5ace84 hex)
## Booting kernel from Legacy Image at 1200 ...
   Image Name:
   Image Type:   

Re: [Question] Mlocked count will not be decreased

[Vlastimil Babka]

On 05/24/2017 10:32 AM, Yisheng Xie wrote:
> Hi Kefeng，
> Could you please try this patch.
> 
> Thanks
> Yisheng Xie
> -
> From a70ae975756e8e97a28d49117ab25684da631689 Mon Sep 17 00:00:00 2001
> From: Yisheng Xie 
> Date: Wed, 24 May 2017 16:01:24 +0800
> Subject: [PATCH] mlock: fix mlock count can not decrease in race condition
> 
> Kefeng reported that when run the follow test the mlock count in meminfo
> cannot be decreased:
>  [1] testcase
>  linux:~ # cat test_mlockal
>  grep Mlocked /proc/meminfo
>   for j in `seq 0 10`
>   do
>   for i in `seq 4 15`
>   do
>   ./p_mlockall >> log &
>   done
>   sleep 0.2
>  done
>  sleep 5 # wait some time to let mlock decrease
>  grep Mlocked /proc/meminfo
> 
>  linux:~ # cat p_mlockall.c
>  #include 
>  #include 
>  #include 
> 
>  #define SPACE_LEN4096
> 
>  int main(int argc, char ** argv)
>  {
>   int ret;
>   void *adr = malloc(SPACE_LEN);
>   if (!adr)
>   return -1;
> 
>   ret = mlockall(MCL_CURRENT | MCL_FUTURE);
>   printf("mlcokall ret = %d\n", ret);
> 
>   ret = munlockall();
>   printf("munlcokall ret = %d\n", ret);
> 
>   free(adr);
>   return 0;
>  }
> 
> When __munlock_pagevec, we ClearPageMlock but isolation_failed in race
> condition, and we do not count these page into delta_munlocked, which cause 
> mlock

Race condition with what? Who else would isolate our pages?

> counter incorrect for we had Clear the PageMlock and cannot count down
> the number in the feture.
> 
> Fix it by count the number of page whoes PageMlock flag is cleared.
> 
> Reported-by: Kefeng Wang 
> Signed-off-by: Yisheng Xie 

Weird, I can reproduce the issue on my desktop's 4.11 distro kernel, but
not in qemu and small kernel build, for some reason. So I couldn't test
the patch yet. But it's true that before 7225522bb429 ("mm: munlock:
batch non-THP page isolation and munlock+putback using pagevec") we
decreased NR_MLOCK for each pages that passed TestClearPageMlocked(),
and that unintentionally changed with my patch. There should be a Fixes:
tag for that.

> ---
>  mm/mlock.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/mm/mlock.c b/mm/mlock.c
> index c483c5c..71ba5cf 100644
> --- a/mm/mlock.c
> +++ b/mm/mlock.c
> @@ -284,7 +284,7 @@ static void __munlock_pagevec(struct pagevec *pvec, 
> struct zone *zone)
>  {
>   int i;
>   int nr = pagevec_count(pvec);
> - int delta_munlocked;
> + int munlocked = 0;
>   struct pagevec pvec_putback;
>   int pgrescued = 0;
> 
> @@ -296,6 +296,7 @@ static void __munlock_pagevec(struct pagevec *pvec, 
> struct zone *zone)
>   struct page *page = pvec->pages[i];
> 
>   if (TestClearPageMlocked(page)) {
> + munlocked --;
>   /*
>* We already have pin from follow_page_mask()
>* so we can spare the get_page() here.
> @@ -315,8 +316,8 @@ static void __munlock_pagevec(struct pagevec *pvec, 
> struct zone *zone)
>   pagevec_add(_putback, pvec->pages[i]);
>   pvec->pages[i] = NULL;
>   }
> - delta_munlocked = -nr + pagevec_count(_putback);
> - __mod_zone_page_state(zone, NR_MLOCK, delta_munlocked);
> + if (munlocked)

You don't have to if () this, it should be very rare that munlocked will
be 0, and the code works fine even if it is.

> + __mod_zone_page_state(zone, NR_MLOCK, munlocked);
>   spin_unlock_irq(zone_lru_lock(zone));
> 
>   /* Now we can release pins of pages that we are not munlocking */
> 

Re: [PATCH] mm: introduce MADV_CLR_HUGEPAGE

[Mike Rapoport]

On Wed, May 24, 2017 at 09:58:06AM +0200, Vlastimil Babka wrote:
> On 05/24/2017 09:50 AM, Mike Rapoport wrote:
> > On Mon, May 22, 2017 at 05:52:47PM +0200, Vlastimil Babka wrote:
> >> On 05/22/2017 04:29 PM, Mike Rapoport wrote:
> >>>
> >>> Probably I didn't explained it too well.
> >>>
> >>> The range is intentionally not populated. When we combine pre- and
> >>> post-copy for process migration, we create memory pre-dump without 
> >>> stopping
> >>> the process, then we freeze the process without dumping the pages it has
> >>> dirtied between pre-dump and freeze, and then, during restore, we populate
> >>> the dirtied pages using userfaultfd.
> >>>
> >>> When CRIU restores a process in such scenario, it does something like:
> >>>
> >>> * mmap() memory region
> >>> * fill in the pages that were collected during the pre-dump
> >>> * do some other stuff
> >>> * register memory region with userfaultfd
> >>> * populate the missing memory on demand
> >>>
> >>> khugepaged collapses the pages in the partially populated regions before 
> >>> we
> >>> have a chance to register these regions with userfaultfd, which would
> >>> prevent the collapse.
> >>>
> >>> We could have used MADV_NOHUGEPAGE right after the mmap() call, and then
> >>> there would be no race because there would be nothing for khugepaged to
> >>> collapse at that point. But the problem is that we have no way to reset
> >>> *HUGEPAGE flags after the memory restore is complete.
> >>
> >> Hmm, I wouldn't be that sure if this is indeed race-free. Check that
> >> this scenario is indeed impossible?
> >>
> >> - you do the mmap
> >> - khugepaged will choose the process' mm to scan
> >> - khugepaged will get to the vma in question, it doesn't have
> >> MADV_NOHUGEPAGE yet
> >> - you set MADV_NOHUGEPAGE on the vma
> >> - you start populating the vma
> >> - khugepaged sees the vma is non-empty, collapses
> >>
> >> unless I'm wrong, the racers will have mmap_sem for reading only when
> >> setting/checking the MADV_NOHUGEPAGE? Might be actually considered a bug.
> >>
> >> However, can't you use prctl(PR_SET_THP_DISABLE) instead? "If arg2 has a
> >> nonzero value, the flag is set, otherwise it is cleared." says the
> >> manpage. Do it before the mmap and you avoid the race as well?
> > 
> > Unfortunately, prctl(PR_SET_THP_DISABLE) didn't help :(
> > When I've tried to use it, I've ended up with VM_NOHUGEPAGE set on all VMAs
> > created after prctl(). This returns me to the state when checkpoint-restore
> > alters the application vma->vm_flags although it shouldn't and I do not see
> > a way to fix it using existing interfaces.
> 
> [CC linux-api, should have been done in the initial posting already]

Sorry, missed that.
 
> Hm so the prctl does:
> 
> if (arg2)
> me->mm->def_flags |= VM_NOHUGEPAGE;
> else
> me->mm->def_flags &= ~VM_NOHUGEPAGE;
> 
> That's rather lazy implementation IMHO. Could we change it so the flag
> is stored elsewhere in the mm, and the code that decides to (not) use
> THP will check both the per-vma flag and the per-mm flag?

I afraid I don't understand how that can help.
What we need is an ability to temporarily disable collapse of the pages in
VMAs that do not have VM_*HUGEPAGE flags set and that after we re-enable
THP, the vma->vm_flags for those VMAs will remain intact.

--
Sincerely yours,
Mike.

Re: [PATCH 06/24] thunderbolt: Introduce thunderbolt bus and connection manager

[Mika Westerberg]

On Wed, May 24, 2017 at 12:28:21PM +0200, Lukas Wunner wrote:
> On Thu, May 18, 2017 at 05:38:56PM +0300, Mika Westerberg wrote:
> > Thunderbolt fabric consists of one or more switches. This fabric is
> > called domain and it is controlled by an entity called connection
> > manager. The connection manager can be either internal (driven by a
> > firmware running on the host controller) or external (software driver).
> > This driver currently implements support for the latter.
> > 
> > In order to manage switches and their properties more easily we model
> > this domain structure as a Linux bus. Each host controller adds a domain
> > device to this bus, and these devices are named as domainN where N
> > stands for index or id of the current domain.
> 
> What is the rationale for using a bus?  Do you intend to attach a driver
> to each domain and/or switch?  Unless you do, a class might be more
> appropriate.

It is used to make switches (and the host) identification available for
the userspace. This identification information is used to make a
decision whether or not a device should be authorized.

There will be (in subsequent patches, currently work in progress) also
other type of devices (XDomain) which XDomain service drivers bind to in
order to send data, like IP traffic over Thunderbolt link(s).

And last, Thunderbolt is actually a bus as far as I can tell so we model
it accordingly ;-)

Re: [PATCH 1/3] ARM: dts: rockchip: Move cros-ec-sbs to rk3288-veyron-chromebook-sbs

[Heiko Stuebner]

Am Sonntag, 7. Mai 2017, 20:00:42 CEST schrieb Paul Kocialkowski:
> Hi,
> 
> Le lundi 01 mai 2017 à 08:49 -0700, Doug Anderson a écrit :
> > On Mon, May 1, 2017 at 7:07 AM, Heiko Stuebner  wrote:
> > > Am Sonntag, 30. April 2017, 22:56:52 CEST schrieb Paul Kocialkowski:
> > > > Le dimanche 30 avril 2017 à 22:37 +0200, Heiko Stuebner a écrit :
> > > > > Hi Paul,
> > > > > 
> > > > > Am Sonntag, 30. April 2017, 20:30:52 CEST schrieb Paul Kocialkowski:
> > > > > > This moves the cros-ec-sbs dtsi to a new 
> > > > > > rk3288-veyron-chromebook-sbs
> > > > > > dtsi since it only concerns rk3288 veyron Chromebooks.
> > > > > > 
> > > > > > Other Chromebooks (such as the tegra124 nyans) also have sbs 
> > > > > > batteries
> > > > > > and don't use this dtsi, that only makes sense when used with
> > > > > > rk3288-veyron-chromebook anyway.
> > > > > 
> > > > > That isn't true. The gru series (rk3399-based) also uses the
> > > > > sbs-battery [0]. And while it is currently limited to Rockchip-based
> > > > > Chromebooks it is nevertheless used on more than one platform, so
> > > > > the probability is high that it will be used in future series as well.
> > > > 
> > > > That's good to know, but as pointed out, other cros devices are using a
> > > > sbs
> > > > battery without this header, so such a generic name isn't really a good
> > > > fit.
> > 
> > It would be interesting to know if the "retry-count" ought to be the
> > same across all Chromebooks.  I guess you could argue that maybe
> > someone found it needed to be 10 in all "nyan" variants and needed to
> > be 1 in all "veyron" variants, but it seems more likely that the
> > difference is arbitrary, or that one of the two values would work for
> > everyone.  It sure looks like we've just been copying values from
> > device to device.  Given that all the "veyron" devices have vastly
> > different batteries (and probably all the nyan ones too), it seems
> > likely there ought to be one value.
> 
> Well, the retry-count is a maximum number of retries to detect a status change
> on external power connection/disconnection. From my experience, it seems that
> nyans do indeed more retries to detect the change than veyrons, on average.
> 
> I don't think setting this value to 1 is very reasonable (in the end, that's a
> number of seconds), because power supply status changes tend to take a few
> seconds to reflect on the battery status.
> 
> I think setting a high value (like 10) would always work and either way, the
> status detection mechanism stops itself as soon as a change is detected (it
> turns out this is not a good idea for bq27xxx batteries, because they go from
> charging to full in the first seconds after AC connection instead of directly
> reporting full, when full), but let's assume this is okay for sbs (and maybe
> change it later).
> 
> > In terms of setting the "charger", that also could potentially be
> > something that could be for all Chromebooks, or at least older ones
> > that don't have their charger implemented by the type C driver.  ...or
> > nyan devices could simply have a line in their dts like:
> > 
> >  {
> >   power-supplies = <>;
> > };
> 
> That's true, but I think it makes as much sense to keep the whole binding.
> 
> In my opinion, the only reason to have a separate dtsi for this binding is 
> that
> veyrons have another dtsi for chromebooks where this binding should be. 
> However,
> it cannot be there because of minnie using another battery IC.
> 
> So my approach here would be to make it common for devices where other major
> parts are also common, so we can avoid duplication when most of the 
> device-tree
> is already common. In cases where most of the device-tree is specific to a
> device, I think the binding should be duplicated. This is done already for 
> lots
> of other components that could be made (somewhat) common anyway.
> 
> > 
> > > > Note that  has to be defined (after my subsequent patches), 
> > > > which
> > > > it is
> > > > for devices that also include rk3288-veyron-chromebook, but not
> > > > necessarily
> > > > others.
> > > > 
> > > > Overall, I think having one -sbs dtsi file makes sense here because 
> > > > there
> > > > is
> > > > already a rk3288-veyron-chromebook dtsi that veyron chromebooks use. 
> > > > That
> > > > file
> > > > cannot contain the battery bindings because minnie has a different one 
> > > > and
> > > > it
> > > > would be a bit silly to copy it over all devices. That definitely makes
> > > > sense.
> > > > 
> > > > As for other devices, I don't see why we should have a separate include
> > > > file for
> > > > the battery instead of having it in the device's dts. I think this 
> > > > should
> > > > be the
> > > > case on gru/kevin.
> > > > 
> > > > Also maybe not *all* gru-based devices will turn out to use a SBS 
> > > > battery,
> > > > so it
> > > > seems early to include this header in the gru dtsi.
> > 
> > For gru devices, we've moved to a "virtual sbs 

Re: [PATCH v2 0/6] mailbox: arm_mhu: add support for doorbell mode

[Jassi Brar]

On Wed, May 24, 2017 at 3:46 PM, Sudeep Holla  wrote:
>
> Hi,
>
> This series adds doorbell support to ARM MHU mailbox controller driver.
> Since we need to callback the different client based on the doorbel bits
> triggered from the remote, we can manage with single channel for the set
> of 32 doorbells.
>
> Regards,
> Sudeep
>
> v1->v2:
> - Removed the notion od subchannels
> - Treat each bit in the MHU register as a doorbell and hence
>   different channel with respect to mailbox framework
>
Whatever happened to the endless explanations I gave you, how the MHU
driver already supports your usecase?

Re: [patch V3 15/32] s390/kernel: Use stop_machine_cpuslocked()

[Heiko Carstens]

On Wed, May 24, 2017 at 10:15:26AM +0200, Thomas Gleixner wrote:
> From: Sebastian Andrzej Siewior 
> 
> stp_work_fn() holds get_online_cpus() while invoking stop_machine().
> 
> stop_machine() invokes get_online_cpus() as well. This is correct, but
> prevents the conversion of the hotplug locking to a percpu rwsem.
> 
> Use stop_machine_cpuslocked() to avoid the nested call. Convert
> *_online_cpus() to the new interfaces while at it.
> 
> Signed-off-by: Sebastian Andrzej Siewior 
> Signed-off-by: Thomas Gleixner 
> Cc: linux-s...@vger.kernel.org
> Cc: Peter Zijlstra 
> Cc: Heiko Carstens 
> Cc: Steven Rostedt 
> Cc: David Hildenbrand 
> Cc: Martin Schwidefsky 
> 
> ---
>  arch/s390/kernel/time.c |6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Acked-by: Heiko Carstens 

Re: [PATCH v6 3/4] PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC

[Jingoo Han]

On Wednesday, May 24, 2017 4:13 AM, Xiaowei Song wrote:
> 
> Hisilicon PCIe Driver shares the common functions for PCIe dw-host
> 
> The poweron functions is developed on hi3660 SoC,
> while Others Functions are common for Kirin series SoCs.
> 
> Low power mode(L1 sub-state and Suspend/Resume), hotplug
> and MSI feature are not supported currently.
> 
> Signed-off-by: Xiaowei Song 
> ---
>  drivers/pci/dwc/Kconfig  |  10 +
>  drivers/pci/dwc/Makefile |   1 +
>  drivers/pci/dwc/pcie-kirin.c | 511
> +++
>  3 files changed, 522 insertions(+)
>  create mode 100644 drivers/pci/dwc/pcie-kirin.c
> 
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index d2d2ba5b8a68..13e617b78430 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -130,4 +130,14 @@ config PCIE_ARTPEC6
> Say Y here to enable PCIe controller support on Axis ARTPEC-6
> SoCs.  This PCIe controller uses the DesignWare core.
> 
> +config PCIE_KIRIN
> + depends on OF && ARM64
> + bool "HiSilicon Kirin series SoCs PCIe controllers"
> + depends on PCI
> + select PCIEPORTBUS
> + select PCIE_DW_HOST
> + help
> +   Say Y here if you want PCIe controller support on HiSilicon Kirin
> series SoCs
> +   kirin960 SoC
> +
>  endmenu
> diff --git a/drivers/pci/dwc/Makefile b/drivers/pci/dwc/Makefile
> index a2df13c28798..4bd69bacd4ab 100644
> --- a/drivers/pci/dwc/Makefile
> +++ b/drivers/pci/dwc/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_PCI_LAYERSCAPE) += pci-layerscape.o
>  obj-$(CONFIG_PCIE_QCOM) += pcie-qcom.o
>  obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
>  obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
> +obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
> 
>  # The following drivers are for devices that use the generic ACPI
>  # pci_root.c driver but don't support standard ECAM config access.
> diff --git a/drivers/pci/dwc/pcie-kirin.c b/drivers/pci/dwc/pcie-kirin.c
> new file mode 100644
> index ..3a0b078e1943
> --- /dev/null
> +++ b/drivers/pci/dwc/pcie-kirin.c
> @@ -0,0 +1,511 @@
> +/*
> + * PCIe host controller driver for Kirin Phone SoCs
> + *
> + * Copyright (C) 2017 Hilisicon Electronics Co., Ltd.
> + *   http://www.huawei.com
> + *
> + * Author: Xiaowei Song 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "pcie-designware.h"
> +
> +#define to_kirin_pcie(x) dev_get_drvdata((x)->dev)
> +
> +#define REF_CLK_FREQ 1
> +
> +/* PCIe ELBI registers */
> +#define SOC_PCIECTRL_CTRL0_ADDR 0x000
> +#define SOC_PCIECTRL_CTRL1_ADDR 0x004
> +#define SOC_PCIEPHY_CTRL2_ADDR 0x008
> +#define SOC_PCIEPHY_CTRL3_ADDR 0x00c
> +#define PCIE_ELBI_SLV_DBI_ENABLE (0x1 << 21)
> +
> +#define PCIE_APP_LTSSM_ENABLE0x01c
> +#define PCIE_APB_PHY_CTRL0   0x0
> +#define PCIE_APB_PHY_CTRL1   0x4
> +#define PCIE_APB_PHY_STATUS0 0x400
> +#define PCIE_LINKUP_ENABLE   (0x8020)
> +#define PCIE_LTSSM_ENABLE_BIT  (0x1 << 11)
> +#define PIPE_CLK_STABLE  (0x1 << 19)
> +#define PIPE_CLK_MAX_TRY_TIMES   10
> +#define PHY_REF_PAD_BIT  (0x1 << 8)
> +#define PHY_PWR_DOWN_BIT (0x1 << 22)
> +#define PHY_RST_ACK_BIT  (0x1 << 16)
> +
> +/* info lacated in sysctrl */
> +#define SCTRL_PCIE_CMOS_OFFSET   0x60
> +#define SCTRL_PCIE_CMOS_BIT  0x10
> +#define SCTRL_PCIE_ISO_OFFSET0x44
> +#define SCTRL_PCIE_ISO_BIT   0x30
> +#define SCTRL_PCIE_HPCLK_OFFSET  0x190
> +#define SCTRL_PCIE_HPCLK_BIT 0x184000
> +#define SCTRL_PCIE_OE_OFFSET 0x14a
> +#define PCIE_DEBOUNCE_PARAM  0xF0F400
> +#define PCIE_OE_BYPASS   (0x3 << 28)
> +
> +/* peri_crg ctrl */
> +#define CRGCTRL_PCIE_ASSERT_OFFSET   0x88
> +#define CRGCTRL_PCIE_ASSERT_BIT  0x8c00
> +
> +/* Time for delay */
> +#define REF_2_PERST_MIN  (2)
> +#define REF_2_PERST_MAX  (25000)
> +#define PERST_2_ACCESS_MIN   (1)
> +#define PERST_2_ACCESS_MAX   (12000)
> +#define LINK_WAIT_MIN(900)
> +#define LINK_WAIT_MAX(1000)
> +#define PIPE_CLK_WAIT_MIN(550)
> +#define PIPE_CLK_WAIT_MAX(600)

Please remove unnecessary blankets as below.

#define REF_2_PERST_MIN 2
#define REF_2_PERST_MAX 25000
.

> +
> +struct kirin_pcie {
> + struct dw_pcie  *pci;
> + void __iomem*apb_base;
> + void __iomem*phy_base;
> + struct regmap *crgctrl;
> + 

Re: [PATCH v6 0/4] DT and Driver review comments fix

[Jingoo Han]

On Wednesday, May 24, 2017 4:13 AM, Xiaowei Song wrote:
> 
> Before Version Patches
> ==
> 
> patch V4
> https://www.spinics.net/lists/linux-pci/msg61406.html
> 
> patch V3
> https://www.spinics.net/lists/linux-pci/msg61399.html

Hi Xiaowei Song,

I think that you need to receive 'tested-by' from other people such as
colleagues or other developers. Or, would you share the result of 'lspci'
for your HiSilicon Kirin PCIe Host controller? That will help other
maintainers to review your patches.

Best regards,
Jingoo Han

> 
> Changes between V6 and V5
> =
> 1. seperate Document from .dtsi patch.
> 2. fix issues according to review comments
>from Bjorn Helgaas and Rob Herring: annotation stype, DT node,
>patch post method and so on.
> 
> Patches list
> 
> 
> Xiaowei Song (4):
>   PCI: hisi: Add DT binding for PCIe of Kirin SoC series
>   arm64: dts: hisi: add kirin pcie node
>   PCI: dwc: kirin: add PCIe Driver for HiSilicon Kirin SoC
>   defconfig: PCI: Enable  Kirin PCIe defconfig
> 
>  .../devicetree/bindings/pci/kirin-pcie.txt |  49 ++
>  arch/arm64/boot/dts/hisilicon/hi3660.dtsi  |  31 ++
>  arch/arm64/configs/defconfig   |   1 +
>  drivers/pci/dwc/Kconfig|  10 +
>  drivers/pci/dwc/Makefile   |   1 +
>  drivers/pci/dwc/pcie-kirin.c   | 511
> +
>  6 files changed, 603 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/kirin-pcie.txt
>  create mode 100644 drivers/pci/dwc/pcie-kirin.c
> 
> --
> 2.11.GIT

Re: [PATCH RFC 0/8] SCHED_DEADLINE freq/cpu invariance and OPP selection

[Peter Zijlstra]

On Wed, May 24, 2017 at 12:01:51PM +0200, Luca Abeni wrote:
> > > So I'm terribly confused...
> > > 
> > > By using the active bandwidth to select frequency we effectively
> > > reduce idle time (to 0 if we had infinite granular frequency steps
> > > and no margins).
> > > 
> > > So !RECLAIM works as expected. They get the time they reserved,
> > > since that was taken into account by active bandwidth.


> Well, I also admitted that I am almost completely ignorant about many
> people's requirements...
> 
> What I know is that there are some people using SCHED_DEADLINE to make
> sure that a task can make progress (executing with a "high priority")
> without consuming more than a specified fraction of CPU time... So,
> they for example schedule a CPU-hungry task with runtime=10ms and
> period=100ms to make sure that the task can execute every 100ms (giving
> the impression of a "fluid progress") without stealing more than 10% of
> CPU time to other tasks.
> 
> In this case, if the CPU frequency change the goal is still to
> "reserve" 10% of CPU time (not more, even if the CPU is slower) to the
> task. So, no runtime rescaling (or reclaiming) is required in this case.
> 
> 
> My proposal was that if a task is not interested in a fixed
> runtime / fraction of CPU time but wants to adapt the runtime when the
> CPU frequency scales, then it can select the RECLAIMING flag.

I think these people are doing it wrong :-)

Firstly, the runtime budget is a WCET. This very much means it is
subject to CPU frequency; after all, when the CPU runs slower, that same
amount of work takes longer. So being subject to cpufreq is the natural
state and should not require a special marker.

Secondly, if you want a steady progress of 10%, I don't see the problem
with giving them more at slower frequency, they get the 'same' amount of
'work' done without bothering other people.

[PATCH v3 2/9] ASoC: sun8i-codec-analog: prepare a mixer control/widget/route set for V3s

[Icenowy Zheng]

Allwinner V3s has an analog codec without MIC2 and Line In, which will
need a special set of mixer controls/widgets/routes, otherwise meaningless
controls will be exported to userspace and confuse the user.

Add the special set, and use it when the SoC has no MIC2 and Line In.

Signed-off-by: Icenowy Zheng 
---
New patch in v3.

 sound/soc/sunxi/sun8i-codec-analog.c | 97 +++-
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/sound/soc/sunxi/sun8i-codec-analog.c 
b/sound/soc/sunxi/sun8i-codec-analog.c
index edcc3eb7cd9a..4c34a12b3739 100644
--- a/sound/soc/sunxi/sun8i-codec-analog.c
+++ b/sound/soc/sunxi/sun8i-codec-analog.c
@@ -219,6 +219,22 @@ static const struct snd_kcontrol_new 
sun8i_codec_mixer_controls[] = {
  SUN8I_ADDA_LOMIXSC_MIC2, 1, 0),
 };
 
+/* mixer controls */
+static const struct snd_kcontrol_new sun8i_v3s_codec_mixer_controls[] = {
+   SOC_DAPM_DOUBLE_R("DAC Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_DACL, 1, 0),
+   SOC_DAPM_DOUBLE_R("DAC Reversed Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_DACR, 1, 0),
+   SOC_DAPM_DOUBLE_R("Mic1 Playback Switch",
+ SUN8I_ADDA_LOMIXSC,
+ SUN8I_ADDA_ROMIXSC,
+ SUN8I_ADDA_LOMIXSC_MIC1, 1, 0),
+};
+
 /* ADC mixer controls */
 static const struct snd_kcontrol_new sun8i_codec_adc_mixer_controls[] = {
SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
@@ -243,6 +259,22 @@ static const struct snd_kcontrol_new 
sun8i_codec_adc_mixer_controls[] = {
  SUN8I_ADDA_LADCMIXSC_MIC2, 1, 0),
 };
 
+/* ADC mixer controls */
+static const struct snd_kcontrol_new sun8i_v3s_codec_adc_mixer_controls[] = {
+   SOC_DAPM_DOUBLE_R("Mixer Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_OMIXRL, 1, 0),
+   SOC_DAPM_DOUBLE_R("Mixer Reversed Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_OMIXRR, 1, 0),
+   SOC_DAPM_DOUBLE_R("Mic1 Capture Switch",
+ SUN8I_ADDA_LADCMIXSC,
+ SUN8I_ADDA_RADCMIXSC,
+ SUN8I_ADDA_LADCMIXSC_MIC1, 1, 0),
+};
+
 /* volume / mute controls */
 static const DECLARE_TLV_DB_SCALE(sun8i_codec_out_mixer_pregain_scale,
  -450, 150, 0);
@@ -292,8 +324,9 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_common_widgets[] = {
/* Mic input path */
SND_SOC_DAPM_PGA("Mic1 Amplifier", SUN8I_ADDA_MIC1G_MICBIAS_CTRL,
 SUN8I_ADDA_MIC1G_MICBIAS_CTRL_MIC1AMPEN, 0, NULL, 0),
+};
 
-   /* Mixers */
+static const struct snd_soc_dapm_widget sun8i_codec_mixer_widgets[] = {
SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
   SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
   sun8i_codec_mixer_controls,
@@ -312,10 +345,31 @@ static const struct snd_soc_dapm_widget 
sun8i_codec_common_widgets[] = {
   ARRAY_SIZE(sun8i_codec_adc_mixer_controls)),
 };
 
+static const struct snd_soc_dapm_widget sun8i_v3s_codec_mixer_widgets[] = {
+   SND_SOC_DAPM_MIXER("Left Mixer", SUN8I_ADDA_DAC_PA_SRC,
+  SUN8I_ADDA_DAC_PA_SRC_LMIXEN, 0,
+  sun8i_v3s_codec_mixer_controls,
+  ARRAY_SIZE(sun8i_v3s_codec_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Right Mixer", SUN8I_ADDA_DAC_PA_SRC,
+  SUN8I_ADDA_DAC_PA_SRC_RMIXEN, 0,
+  sun8i_v3s_codec_mixer_controls,
+  ARRAY_SIZE(sun8i_v3s_codec_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Left ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
+  SUN8I_ADDA_ADC_AP_EN_ADCLEN, 0,
+  sun8i_v3s_codec_adc_mixer_controls,
+  ARRAY_SIZE(sun8i_v3s_codec_adc_mixer_controls)),
+   SND_SOC_DAPM_MIXER("Right ADC Mixer", SUN8I_ADDA_ADC_AP_EN,
+  SUN8I_ADDA_ADC_AP_EN_ADCREN, 0,
+  sun8i_v3s_codec_adc_mixer_controls,
+  ARRAY_SIZE(sun8i_v3s_codec_adc_mixer_controls)),
+};
+
 static const struct snd_soc_dapm_route sun8i_codec_common_routes[] = {
/* Microphone Routes */
{ "Mic1 Amplifier", NULL, "MIC1"},
+};
 
+static const struct snd_soc_dapm_route sun8i_codec_mixer_routes[] = {
/* Left Mixer Routes */
{ "Left Mixer", "DAC Playback Switch", "Left DAC" },
{ "Left Mixer", "DAC Reversed Playback Switch", "Right 

Re: [PATCH net-next v9 5/5] virtio_net: check return value of skb_to_sgvec always

[Jason A. Donenfeld]

I'm shocked this somehow made it into the commit. I wonder how that happened?

Anyway, fixed in my git repo, and will be part of the next series.
(Unless DaveM wants to fix it up trivially when/if he merges this v9,
which would be faster.)

Barring that, does this look good to you? Could I have your signed-off-by?

Regards,
Jason

[PATCH v3] ext4: fix quota charging for shared xattr blocks

[Tahsin Erdogan]

ext4_xattr_block_set() calls dquot_alloc_block() to charge for an xattr
block when new references are made. However if dquot_initialize() hasn't
been called on an inode, request for charging is effectively ignored
because ext4_inode_info->i_dquot is not initialized yet.

Add dquot_initialize() to call paths that lead to ext4_xattr_block_set().

Signed-off-by: Tahsin Erdogan 
Reviewed-by: Jan Kara 
---
v3: added Reviewed-by tag
v2:
 - moved dquot_initialize() to outside the main transaction
 - added dquot_initialize_needed() function that is used by
   ext4_xattr_release_block() to warn about call paths that don't
   call dquot_initialize()

 fs/ext4/acl.c|  4 
 fs/ext4/super.c  |  3 +++
 fs/ext4/xattr.c  |  8 
 fs/quota/dquot.c | 16 
 include/linux/quotaops.h |  6 ++
 5 files changed, 37 insertions(+)

diff --git a/fs/ext4/acl.c b/fs/ext4/acl.c
index fd389935ecd1..3ec0e46de95f 100644
--- a/fs/ext4/acl.c
+++ b/fs/ext4/acl.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2001-2003 Andreas Gruenbacher, 
  */
 
+#include 
 #include "ext4_jbd2.h"
 #include "ext4.h"
 #include "xattr.h"
@@ -232,6 +233,9 @@ ext4_set_acl(struct inode *inode, struct posix_acl *acl, 
int type)
handle_t *handle;
int error, retries = 0;
 
+   error = dquot_initialize(inode);
+   if (error)
+   return error;
 retry:
handle = ext4_journal_start(inode, EXT4_HT_XATTR,
ext4_jbd2_credits_xattr(inode));
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 0b177da9ea82..e2e0eb7ac9a0 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1179,6 +1179,9 @@ static int ext4_set_context(struct inode *inode, const 
void *ctx, size_t len,
return res;
}
 
+   res = dquot_initialize(inode);
+   if (res)
+   return res;
 retry:
handle = ext4_journal_start(inode, EXT4_HT_MISC,
ext4_jbd2_credits_xattr(inode));
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 8fb7ce14e6eb..5d3c2536641c 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -888,6 +888,8 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
else {
u32 ref;
 
+   WARN_ON_ONCE(dquot_initialize_needed(inode));
+
/* The old block is released after updating
   the inode. */
error = dquot_alloc_block(inode,
@@ -954,6 +956,8 @@ ext4_xattr_block_set(handle_t *handle, struct inode *inode,
/* We need to allocate a new block */
ext4_fsblk_t goal, block;
 
+   WARN_ON_ONCE(dquot_initialize_needed(inode));
+
goal = ext4_group_first_block_no(sb,
EXT4_I(inode)->i_block_group);
 
@@ -1166,6 +1170,7 @@ ext4_xattr_set_handle(handle_t *handle, struct inode 
*inode, int name_index,
return -EINVAL;
if (strlen(name) > 255)
return -ERANGE;
+
ext4_write_lock_xattr(inode, _expand);
 
error = ext4_reserve_inode_write(handle, inode, );
@@ -1267,6 +1272,9 @@ ext4_xattr_set(struct inode *inode, int name_index, const 
char *name,
int error, retries = 0;
int credits = ext4_jbd2_credits_xattr(inode);
 
+   error = dquot_initialize(inode);
+   if (error)
+   return error;
 retry:
handle = ext4_journal_start(inode, EXT4_HT_XATTR, credits);
if (IS_ERR(handle)) {
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c
index ebf80c7739e1..48813aeaab80 100644
--- a/fs/quota/dquot.c
+++ b/fs/quota/dquot.c
@@ -1512,6 +1512,22 @@ int dquot_initialize(struct inode *inode)
 }
 EXPORT_SYMBOL(dquot_initialize);
 
+bool dquot_initialize_needed(struct inode *inode)
+{
+   struct dquot **dquots;
+   int i;
+
+   if (!dquot_active(inode))
+   return false;
+
+   dquots = i_dquot(inode);
+   for (i = 0; i < MAXQUOTAS; i++)
+   if (!dquots[i] && sb_has_quota_active(inode->i_sb, i))
+   return true;
+   return false;
+}
+EXPORT_SYMBOL(dquot_initialize_needed);
+
 /*
  * Release all quotas referenced by inode.
  *
diff --git a/include/linux/quotaops.h b/include/linux/quotaops.h
index 9c6f768b7d32..dda22f45fc1b 100644
--- a/include/linux/quotaops.h
+++ b/include/linux/quotaops.h
@@ -44,6 +44,7 @@ void inode_sub_rsv_space(struct inode *inode, qsize_t number);
 void inode_reclaim_rsv_space(struct inode *inode, qsize_t number);
 
 int dquot_initialize(struct inode *inode);
+bool dquot_initialize_needed(struct inode *inode);
 void dquot_drop(struct inode *inode);
 struct dquot *dqget(struct super_block *sb, struct kqid qid);
 static inline struct dquot *dqgrab(struct dquot *dquot)
@@ -207,6 +208,11