date:20151230

This introduces the preprocessor symbol KIMAGE_VADDR which will serve as
the symbolic virtual base of the kernel region, i.e., the kernel's virtual
offset will be KIMAGE_VADDR + TEXT_OFFSET. For now, we define it as being
equal to PAGE_OFFSET, but in the future, it will be moved below it once
we move the kernel virtual mapping out of the linear mapping.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/include/asm/memory.h | 10 --
 arch/arm64/kernel/head.S|  2 +-
 arch/arm64/kernel/vmlinux.lds.S |  4 ++--
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 853953cd1f08..bea9631b34a8 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -51,7 +51,8 @@
 #define VA_BITS(CONFIG_ARM64_VA_BITS)
 #define VA_START   (UL(0x) << VA_BITS)
 #define PAGE_OFFSET(UL(0x) << (VA_BITS - 1))
-#define MODULES_END(PAGE_OFFSET)
+#define KIMAGE_VADDR   (PAGE_OFFSET)
+#define MODULES_END(KIMAGE_VADDR)
 #define MODULES_VADDR  (MODULES_END - SZ_64M)
 #define PCI_IO_END (MODULES_VADDR - SZ_2M)
 #define PCI_IO_START   (PCI_IO_END - PCI_IO_SIZE)
@@ -75,8 +76,13 @@
  * private definitions which should NOT be used outside memory.h
  * files.  Use virt_to_phys/phys_to_virt/__pa/__va instead.
  */
-#define __virt_to_phys(x)  (((phys_addr_t)(x) - PAGE_OFFSET + PHYS_OFFSET))
+#define __virt_to_phys(x) ({   \
+   phys_addr_t __x = (phys_addr_t)(x); \
+   __x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :\
+(__x - KIMAGE_VADDR + PHYS_OFFSET); })
+
 #define __phys_to_virt(x)  ((unsigned long)((x) - PHYS_OFFSET + 
PAGE_OFFSET))
+#define __phys_to_kimg(x)  ((unsigned long)((x) - PHYS_OFFSET + 
KIMAGE_VADDR))
 
 /*
  * Convert a page to/from a physical address
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 23cfc08fc8ba..6434c844a0e4 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -389,7 +389,7 @@ __create_page_tables:
 * Map the kernel image (starting with PHYS_OFFSET).
 */
mov x0, x26 // swapper_pg_dir
-   mov x5, #PAGE_OFFSET
+   ldr x5, =KIMAGE_VADDR
create_pgd_entry x0, x5, x3, x6
ldr x6, =KERNEL_END // __va(KERNEL_END)
mov x3, x24 // phys offset
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 7de6c39858a5..ced0dedcabcc 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -88,7 +88,7 @@ SECTIONS
*(.discard.*)
}
 
-   . = PAGE_OFFSET + TEXT_OFFSET;
+   . = KIMAGE_VADDR + TEXT_OFFSET;
 
.head.text : {
_text = .;
@@ -185,4 +185,4 @@ ASSERT(__idmap_text_end - (__idmap_text_start & ~(SZ_4K - 
1)) <= SZ_4K,
 /*
  * If padding is applied before .head.text, virt<->phys conversions will fail.
  */
-ASSERT(_text == (PAGE_OFFSET + TEXT_OFFSET), "HEAD is misaligned")
+ASSERT(_text == (KIMAGE_VADDR + TEXT_OFFSET), "HEAD is misaligned")
-- 
2.5.0

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

[PATCH v2 06/13] arm64: move kernel image to base of vmalloc area

This moves the module area to right before the vmalloc area, and
moves the kernel image to the base of the vmalloc area. This is
an intermediate step towards implementing kASLR, where the kernel
image can be located anywhere in the vmalloc area.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/include/asm/kasan.h  | 17 -
 arch/arm64/include/asm/kernel-pgtable.h |  5 +--
 arch/arm64/include/asm/memory.h | 17 ++---
 arch/arm64/include/asm/pgtable.h|  7 
 arch/arm64/kernel/setup.c   | 13 +++
 arch/arm64/mm/dump.c| 12 +++
 arch/arm64/mm/init.c| 20 +--
 arch/arm64/mm/mmu.c | 37 ++--
 8 files changed, 56 insertions(+), 72 deletions(-)

diff --git a/arch/arm64/include/asm/kasan.h b/arch/arm64/include/asm/kasan.h
index 2774fa384c47..476d56e0f04c 100644
--- a/arch/arm64/include/asm/kasan.h
+++ b/arch/arm64/include/asm/kasan.h
@@ -1,19 +1,16 @@
 #ifndef __ASM_KASAN_H
 #define __ASM_KASAN_H
 
-#ifndef __ASSEMBLY__
-
 #ifdef CONFIG_KASAN
 
 #include 
-#include 
 
 /*
  * KASAN_SHADOW_START: beginning of the kernel virtual addresses.
  * KASAN_SHADOW_END: KASAN_SHADOW_START + 1/8 of kernel virtual addresses.
  */
-#define KASAN_SHADOW_START  (VA_START)
-#define KASAN_SHADOW_END(KASAN_SHADOW_START + (1UL << (VA_BITS - 3)))
+#define KASAN_SHADOW_START (VA_START)
+#define KASAN_SHADOW_END   (KASAN_SHADOW_START + (_AC(1, UL) << (VA_BITS - 
3)))
 
 /*
  * This value is used to map an address to the corresponding shadow
@@ -25,14 +22,18 @@
  * should satisfy the following equation:
  *  KASAN_SHADOW_OFFSET = KASAN_SHADOW_END - (1ULL << 61)
  */
-#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << (64 - 3)))
+#define KASAN_SHADOW_OFFSET(KASAN_SHADOW_END - (_AC(1, ULL) << (64 - 3)))
 
+#ifndef __ASSEMBLY__
 void kasan_init(void);
 asmlinkage void kasan_early_init(void);
+#endif
 
 #else
+
+#ifndef __ASSEMBLY__
 static inline void kasan_init(void) { }
 #endif
 
-#endif
-#endif
+#endif /* CONFIG_KASAN */
+#endif /* __ASM_KASAN_H */
diff --git a/arch/arm64/include/asm/kernel-pgtable.h 
b/arch/arm64/include/asm/kernel-pgtable.h
index a459714ee29e..daa8a7b9917a 100644
--- a/arch/arm64/include/asm/kernel-pgtable.h
+++ b/arch/arm64/include/asm/kernel-pgtable.h
@@ -70,8 +70,9 @@
 /*
  * Initial memory map attributes.
  */
-#define SWAPPER_PTE_FLAGS  (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED)
-#define SWAPPER_PMD_FLAGS  (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S)
+#define SWAPPER_PTE_FLAGS  (PTE_TYPE_PAGE | PTE_AF | PTE_SHARED | PTE_UXN)
+#define SWAPPER_PMD_FLAGS  (PMD_TYPE_SECT | PMD_SECT_AF | PMD_SECT_S | \
+PMD_SECT_UXN)
 
 #if ARM64_SWAPPER_USES_SECTION_MAPS
 #define SWAPPER_MM_MMUFLAGS(PMD_ATTRINDX(MT_NORMAL) | SWAPPER_PMD_FLAGS)
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index bea9631b34a8..1dcbf142d36c 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -51,14 +51,23 @@
 #define VA_BITS(CONFIG_ARM64_VA_BITS)
 #define VA_START   (UL(0x) << VA_BITS)
 #define PAGE_OFFSET(UL(0x) << (VA_BITS - 1))
-#define KIMAGE_VADDR   (PAGE_OFFSET)
-#define MODULES_END(KIMAGE_VADDR)
-#define MODULES_VADDR  (MODULES_END - SZ_64M)
-#define PCI_IO_END (MODULES_VADDR - SZ_2M)
+#define PCI_IO_END (PAGE_OFFSET - SZ_2M)
 #define PCI_IO_START   (PCI_IO_END - PCI_IO_SIZE)
 #define FIXADDR_TOP(PCI_IO_START - SZ_2M)
 #define TASK_SIZE_64   (UL(1) << VA_BITS)
 
+#ifndef CONFIG_KASAN
+#define MODULES_VADDR  (VA_START)
+#else
+#include 
+#define MODULES_VADDR  (KASAN_SHADOW_END)
+#endif
+
+#define MODULES_END(MODULES_VADDR + SZ_64M)
+
+#define KIMAGE_VADDR   (MODULES_END)
+#define VMALLOC_START  (MODULES_END)
+
 #ifdef CONFIG_COMPAT
 #define TASK_SIZE_32   UL(0x1)
 #define TASK_SIZE  (test_thread_flag(TIF_32BIT) ? \
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 0664468466fb..93203a6b9574 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -42,13 +42,6 @@
  */
 #define VMEMMAP_SIZE   ALIGN((1UL << (VA_BITS - PAGE_SHIFT)) * 
sizeof(struct page), PUD_SIZE)
 
-#ifndef CONFIG_KASAN
-#define VMALLOC_START  (VA_START)
-#else
-#include 
-#define VMALLOC_START  (KASAN_SHADOW_END + SZ_64K)
-#endif
-
 #define VMALLOC_END(PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K)
 
 #define vmemmap((struct page *)(VMALLOC_END + SZ_64K))
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index cfed56f0ad26..96177a7c0f05 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -53,6 +53,7 @@
 #includ

[PATCH v2 04/13] arm64: decouple early fixmap init from linear mapping

Since the early fixmap page tables are populated using pages that are
part of the static footprint of the kernel, they are covered by the
initial kernel mapping, and we can refer to them without using __va/__pa
translations, which are tied to the linear mapping.

Instead, let's introduce __phys_to_kimg, which will be tied to the kernel
virtual mapping, regardless of whether or not it intersects with the linear
mapping. This will allow us to move the kernel out of the linear mapping in
a subsequent patch.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/include/asm/compiler.h |  2 +
 arch/arm64/kernel/vmlinux.lds.S   | 12 +--
 arch/arm64/mm/mmu.c   | 85 
 3 files changed, 42 insertions(+), 57 deletions(-)

diff --git a/arch/arm64/include/asm/compiler.h 
b/arch/arm64/include/asm/compiler.h
index ee35fd0f2236..dd342af63673 100644
--- a/arch/arm64/include/asm/compiler.h
+++ b/arch/arm64/include/asm/compiler.h
@@ -27,4 +27,6 @@
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+#define __pgdir
__attribute__((section(".pgdir"),aligned(PAGE_SIZE)))
+
 #endif /* __ASM_COMPILER_H */
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index ced0dedcabcc..363c2f529951 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -160,11 +160,13 @@ SECTIONS
 
BSS_SECTION(0, 0, 0)
 
-   . = ALIGN(PAGE_SIZE);
-   idmap_pg_dir = .;
-   . += IDMAP_DIR_SIZE;
-   swapper_pg_dir = .;
-   . += SWAPPER_DIR_SIZE;
+   .pgdir (NOLOAD) : ALIGN(PAGE_SIZE) {
+   idmap_pg_dir = .;
+   . += IDMAP_DIR_SIZE;
+   swapper_pg_dir = .;
+   . += SWAPPER_DIR_SIZE;
+   *(.pgdir)
+   }
 
_end = .;
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 50b1de8e127b..a78fc5a882da 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -540,39 +540,11 @@ void vmemmap_free(unsigned long start, unsigned long end)
 }
 #endif /* CONFIG_SPARSEMEM_VMEMMAP */
 
-static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
-#if CONFIG_PGTABLE_LEVELS > 2
-static pmd_t bm_pmd[PTRS_PER_PMD] __page_aligned_bss;
-#endif
-#if CONFIG_PGTABLE_LEVELS > 3
-static pud_t bm_pud[PTRS_PER_PUD] __page_aligned_bss;
-#endif
-
-static inline pud_t * fixmap_pud(unsigned long addr)
-{
-   pgd_t *pgd = pgd_offset_k(addr);
-
-   BUG_ON(pgd_none(*pgd) || pgd_bad(*pgd));
-
-   return pud_offset(pgd, addr);
-}
-
-static inline pmd_t * fixmap_pmd(unsigned long addr)
-{
-   pud_t *pud = fixmap_pud(addr);
-
-   BUG_ON(pud_none(*pud) || pud_bad(*pud));
+static pte_t *__fixmap_pte;
 
-   return pmd_offset(pud, addr);
-}
-
-static inline pte_t * fixmap_pte(unsigned long addr)
+static inline pte_t *fixmap_pte(unsigned long addr)
 {
-   pmd_t *pmd = fixmap_pmd(addr);
-
-   BUG_ON(pmd_none(*pmd) || pmd_bad(*pmd));
-
-   return pte_offset_kernel(pmd, addr);
+   return __fixmap_pte + pte_index(addr);
 }
 
 void __init early_fixmap_init(void)
@@ -583,33 +555,42 @@ void __init early_fixmap_init(void)
unsigned long addr = FIXADDR_START;
 
pgd = pgd_offset_k(addr);
-   pgd_populate(&init_mm, pgd, bm_pud);
-   pud = pud_offset(pgd, addr);
-   pud_populate(&init_mm, pud, bm_pmd);
-   pmd = pmd_offset(pud, addr);
-   pmd_populate_kernel(&init_mm, pmd, bm_pte);
+#if CONFIG_PGTABLE_LEVELS > 3
+   if (pgd_none(*pgd)) {
+   static pud_t bm_pud[PTRS_PER_PUD] __pgdir;
+
+   pgd_populate(&init_mm, pgd, bm_pud);
+   memblock_reserve(__pa(bm_pud), sizeof(bm_pud));
+   }
+   pud = (pud_t *)__phys_to_kimg(pud_offset_phys(pgd, addr));
+#else
+   pud = (pud_t *)pgd;
+#endif
+#if CONFIG_PGTABLE_LEVELS > 2
+   if (pud_none(*pud)) {
+   static pmd_t bm_pmd[PTRS_PER_PMD] __pgdir;
+
+   pud_populate(&init_mm, pud, bm_pmd);
+   memblock_reserve(__pa(bm_pmd), sizeof(bm_pmd));
+   }
+   pmd = (pmd_t *)__phys_to_kimg(pmd_offset_phys(pud, addr));
+#else
+   pmd = (pmd_t *)pud;
+#endif
+   if (pmd_none(*pmd)) {
+   static pte_t bm_pte[PTRS_PER_PTE] __pgdir;
+
+   pmd_populate_kernel(&init_mm, pmd, bm_pte);
+   memblock_reserve(__pa(bm_pte), sizeof(bm_pte));
+   }
+   __fixmap_pte = (pte_t *)__phys_to_kimg(pmd_page_paddr(*pmd));
 
/*
 * The boot-ioremap range spans multiple pmds, for which
-* we are not preparted:
+* we are not prepared:
 */
BUILD_BUG_ON((__fix_to_virt(FIX_BTMAP_BEGIN) >> PMD_SHIFT)
 != (__fix_to_virt(FIX_BTMAP_END) >> PMD_SHIFT));
-
-   if ((pmd != fixmap_pmd(fix_to_virt(FIX_BTMAP_BEGIN)))
-|| pmd != fixmap_pmd(fix_to_virt(FIX_BTMAP_END))) {
-   WARN_ON(1);
-   pr_warn("pmd %p != %p, %p\n",
-   pmd, fixmap_pmd(fix_to_virt(FIX_BTM

[PATCH v2 05/13] arm64: kvm: deal with kernel symbols outside of linear mapping

KVM on arm64 uses a fixed offset between the linear mapping at EL1 and
the HYP mapping at EL2. Before we can move the kernel virtual mapping
out of the linear mapping, we have to make sure that references to kernel
symbols that are accessed via the HYP mapping are translated to their
linear equivalent.

To prevent inadvertent direct references from sneaking in later, change
the type of all extern declarations to HYP kernel symbols to the opaque
'struct kvm_ksym', which does not decay to a pointer type like char arrays
and function references. This is not bullet proof, but at least forces the
user to take the address explicitly rather than referencing it directly.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm/include/asm/kvm_asm.h   |  2 ++
 arch/arm/include/asm/kvm_mmu.h   |  2 ++
 arch/arm/kvm/arm.c   |  9 +
 arch/arm/kvm/mmu.c   | 12 +--
 arch/arm64/include/asm/kvm_asm.h | 21 +++-
 arch/arm64/include/asm/kvm_mmu.h |  2 ++
 arch/arm64/include/asm/virt.h|  4 
 arch/arm64/kernel/vmlinux.lds.S  |  4 ++--
 arch/arm64/kvm/debug.c   |  4 +++-
 virt/kvm/arm/vgic-v3.c   |  2 +-
 10 files changed, 34 insertions(+), 28 deletions(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 194c91b610ff..484ffdf7c70b 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -99,6 +99,8 @@ extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm, 
phys_addr_t ipa);
 extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
 
 extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
+
+extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
 #endif
 
 #endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 405aa1883307..412b363f79e9 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -30,6 +30,8 @@
 #define HYP_PAGE_OFFSETPAGE_OFFSET
 #define KERN_TO_HYP(kva)   (kva)
 
+#define kvm_ksym_ref(kva)  (kva)
+
 /*
  * Our virtual mapping for the boot-time MMU-enable code. Must be
  * shared across all the page-tables. Conveniently, we use the vectors
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index e06fd299de08..014b542ea658 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -427,7 +427,7 @@ static void update_vttbr(struct kvm *kvm)
 * shareable domain to make sure all data structures are
 * clean.
 */
-   kvm_call_hyp(__kvm_flush_vm_context);
+   kvm_call_hyp(kvm_ksym_ref(__kvm_flush_vm_context));
}
 
kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen);
@@ -600,7 +600,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
__kvm_guest_enter();
vcpu->mode = IN_GUEST_MODE;
 
-   ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
+   ret = kvm_call_hyp(kvm_ksym_ref(__kvm_vcpu_run), vcpu);
 
vcpu->mode = OUTSIDE_GUEST_MODE;
/*
@@ -969,7 +969,7 @@ static void cpu_init_hyp_mode(void *dummy)
pgd_ptr = kvm_mmu_get_httbr();
stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
hyp_stack_ptr = stack_page + PAGE_SIZE;
-   vector_ptr = (unsigned long)__kvm_hyp_vector;
+   vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
 
__cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
 
@@ -1061,7 +1061,8 @@ static int init_hyp_mode(void)
/*
 * Map the Hyp-code called directly from the host
 */
-   err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
+   err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
+ kvm_ksym_ref(__kvm_hyp_code_end));
if (err) {
kvm_err("Cannot map world-switch code\n");
goto out_free_mappings;
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 7dace909d5cf..7c448b943e3a 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -31,8 +31,6 @@
 
 #include "trace.h"
 
-extern char  __hyp_idmap_text_start[], __hyp_idmap_text_end[];
-
 static pgd_t *boot_hyp_pgd;
 static pgd_t *hyp_pgd;
 static pgd_t *merged_hyp_pgd;
@@ -63,7 +61,7 @@ static bool memslot_is_logging(struct kvm_memory_slot 
*memslot)
  */
 void kvm_flush_remote_tlbs(struct kvm *kvm)
 {
-   kvm_call_hyp(__kvm_tlb_flush_vmid, kvm);
+   kvm_call_hyp(kvm_ksym_ref(__kvm_tlb_flush_vmid), kvm);
 }
 
 static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, phys_addr_t ipa)
@@ -75,7 +73,7 @@ static void kvm_tlb_flush_vmid_ipa(struct kvm *kvm, 
phys_addr_t ipa)
 * anything there.
 */
if (kvm)
-   kvm_call_hyp(__kvm_tlb_flush_vmid_ipa, kvm, ipa);
+   kvm_call_hyp(kvm_ksym_ref(__kvm_tlb_flush_vmid_ipa), kvm, ipa);
 }
 
 /*
@@ -1647,9 +1645,9 @@ int kvm_mmu_init(void)
 {
int err;

[PATCH v2 13/13] arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness

Since arm64 does not use a decompressor that supplies an execution
environment where it is feasible to some extent to provide a source of
randomness, the arm64 KASLR kernel depends on the bootloader to supply
some random bits in register x1 upon kernel entry.

On UEFI systems, we can use the EFI_RNG_PROTOCOL, if supplied, to obtain
some random bits. At the same time, use it to randomize the offset of the
kernel Image in physical memory.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/kernel/efi-entry.S |   7 +-
 drivers/firmware/efi/libstub/arm-stub.c   |   1 -
 drivers/firmware/efi/libstub/arm64-stub.c | 134 +---
 include/linux/efi.h   |   5 +-
 4 files changed, 127 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index f82036e02485..f41073dde7e0 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -110,7 +110,7 @@ ENTRY(entry)
 2:
/* Jump to kernel entry point */
mov x0, x20
-   mov x1, xzr
+   ldr x1, efi_rnd
mov x2, xzr
mov x3, xzr
br  x21
@@ -119,6 +119,9 @@ efi_load_fail:
mov x0, #EFI_LOAD_ERROR
ldp x29, x30, [sp], #32
ret
+ENDPROC(entry)
+
+ENTRY(efi_rnd)
+   .quad   0, 0
 
 entry_end:
-ENDPROC(entry)
diff --git a/drivers/firmware/efi/libstub/arm-stub.c 
b/drivers/firmware/efi/libstub/arm-stub.c
index 950c87f5d279..f580bcdfae4f 100644
--- a/drivers/firmware/efi/libstub/arm-stub.c
+++ b/drivers/firmware/efi/libstub/arm-stub.c
@@ -145,7 +145,6 @@ void efi_char16_printk(efi_system_table_t *sys_table_arg,
out->output_string(out, str);
 }
 
-
 /*
  * This function handles the architcture specific differences between arm and
  * arm64 regarding where the kernel image must be loaded and any memory that
diff --git a/drivers/firmware/efi/libstub/arm64-stub.c 
b/drivers/firmware/efi/libstub/arm64-stub.c
index 78dfbd34b6bf..4e5c306346b4 100644
--- a/drivers/firmware/efi/libstub/arm64-stub.c
+++ b/drivers/firmware/efi/libstub/arm64-stub.c
@@ -13,6 +13,68 @@
 #include 
 #include 
 
+struct efi_rng_protocol_t {
+   efi_status_t (*get_info)(struct efi_rng_protocol_t *,
+unsigned long *,
+efi_guid_t *);
+   efi_status_t (*get_rng)(struct efi_rng_protocol_t *,
+   efi_guid_t *,
+   unsigned long,
+   u8 *out);
+};
+
+extern struct {
+   u64 virt_seed;
+   u64 phys_seed;
+} efi_rnd;
+
+static int efi_get_random_bytes(efi_system_table_t *sys_table)
+{
+   efi_guid_t rng_proto = EFI_RNG_PROTOCOL_GUID;
+   efi_status_t status;
+   struct efi_rng_protocol_t *rng;
+
+   status = sys_table->boottime->locate_protocol(&rng_proto, NULL,
+ (void **)&rng);
+   if (status == EFI_NOT_FOUND) {
+   pr_efi(sys_table, "EFI_RNG_PROTOCOL unavailable, no randomness 
supplied\n");
+   return EFI_SUCCESS;
+   }
+
+   if (status != EFI_SUCCESS)
+   return status;
+
+   return rng->get_rng(rng, NULL, sizeof(efi_rnd), (u8 *)&efi_rnd);
+}
+
+static efi_status_t get_dram_top(efi_system_table_t *sys_table_arg, u64 *top)
+{
+   unsigned long map_size, desc_size;
+   efi_memory_desc_t *memory_map;
+   efi_status_t status;
+   int l;
+
+   status = efi_get_memory_map(sys_table_arg, &memory_map, &map_size,
+   &desc_size, NULL, NULL);
+   if (status != EFI_SUCCESS)
+   return status;
+
+   for (l = 0; l < map_size; l += desc_size) {
+   efi_memory_desc_t *md = (void *)memory_map + l;
+
+   if (md->attribute & EFI_MEMORY_WB) {
+   u64 phys_end = md->phys_addr +
+  md->num_pages * EFI_PAGE_SIZE;
+   if (phys_end > *top)
+   *top = phys_end;
+   }
+   }
+
+   efi_call_early(free_pool, memory_map);
+
+   return EFI_SUCCESS;
+}
+
 efi_status_t __init handle_kernel_image(efi_system_table_t *sys_table_arg,
unsigned long *image_addr,
unsigned long *image_size,
@@ -27,6 +89,14 @@ efi_status_t __init handle_kernel_image(efi_system_table_t 
*sys_table_arg,
void *old_image_addr = (void *)*image_addr;
unsigned long preferred_offset;
 
+   if (IS_ENABLED(CONFIG_ARM64_RELOCATABLE_KERNEL)) {
+   status = efi_get_random_bytes(sys_table_arg);
+   if (status != EFI_SUCCESS) {
+   pr_efi_err(sys_table_arg, "efi_get_random_bytes() 
failed\n");
+   return status;
+   }
+   }
+
/*
 * The preferred offset of the kernel Image is

[PATCH v2 12/13] arm64: add support for relocatable kernel

This adds support for runtime relocation of the kernel Image, by
building it as a PIE (ET_DYN) executable and applying the dynamic
relocations in the early boot code.

Signed-off-by: Ard Biesheuvel 
---
 Documentation/arm64/booting.txt |  3 +-
 arch/arm64/Kconfig  | 13 
 arch/arm64/Makefile |  6 +-
 arch/arm64/include/asm/memory.h |  3 +
 arch/arm64/kernel/head.S| 75 +++-
 arch/arm64/kernel/setup.c   | 22 +++---
 arch/arm64/kernel/vmlinux.lds.S |  9 +++
 scripts/sortextable.c   |  4 +-
 8 files changed, 117 insertions(+), 18 deletions(-)

diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 03e02ebc1b0c..b17181eb4a43 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -109,7 +109,8 @@ Header notes:
1 - 4K
2 - 16K
3 - 64K
-  Bits 3-63:   Reserved.
+  Bit 3:   Relocatable kernel.
+  Bits 4-63:   Reserved.
 
 - When image_size is zero, a bootloader should attempt to keep as much
   memory as possible free for use by the kernel immediately after the
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 54eeab140bca..f458fb9e0dce 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -363,6 +363,7 @@ config ARM64_ERRATUM_843419
bool "Cortex-A53: 843419: A load or store might access an incorrect 
address"
depends on MODULES
default y
+   select ARM64_MODULE_CMODEL_LARGE
help
  This option builds kernel modules using the large memory model in
  order to avoid the use of the ADRP instruction, which can cause
@@ -709,6 +710,18 @@ config ARM64_MODULE_PLTS
bool
select HAVE_MOD_ARCH_SPECIFIC
 
+config ARM64_MODULE_CMODEL_LARGE
+   bool
+
+config ARM64_RELOCATABLE_KERNEL
+   bool "Kernel address space layout randomization (KASLR)"
+   select ARM64_MODULE_PLTS
+   select ARM64_MODULE_CMODEL_LARGE
+   help
+ This feature randomizes the virtual address of the kernel image, to
+ harden against exploits that rely on knowledge about the absolute
+ addresses of certain kernel data structures.
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index d4654830e536..75dc477d45f5 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -15,6 +15,10 @@ CPPFLAGS_vmlinux.lds = -DTEXT_OFFSET=$(TEXT_OFFSET)
 OBJCOPYFLAGS   :=-O binary -R .note -R .note.gnu.build-id -R .comment -S
 GZFLAGS:=-9
 
+ifneq ($(CONFIG_ARM64_RELOCATABLE_KERNEL),)
+LDFLAGS_vmlinux+= -pie
+endif
+
 KBUILD_DEFCONFIG := defconfig
 
 # Check for binutils support for specific extensions
@@ -41,7 +45,7 @@ endif
 
 CHECKFLAGS += -D__aarch64__
 
-ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
+ifeq ($(CONFIG_ARM64_MODULE_CMODEL_LARGE), y)
 KBUILD_CFLAGS_MODULE   += -mcmodel=large
 endif
 
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 557228658666..afab3e669e19 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -121,6 +121,9 @@ extern phys_addr_t  memstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
 #define PHYS_OFFSET({ memstart_addr; })
 
+/* the virtual base of the kernel image (minus TEXT_OFFSET) */
+extern u64 kimage_vaddr;
+
 /* the offset between the kernel virtual and physical mappings */
 extern u64 kimage_voffset;
 
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 01a33e42ed70..ab582ee58b58 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -59,8 +59,15 @@
 
 #define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
 
+#ifdef CONFIG_ARM64_RELOCATABLE_KERNEL
+#define __HEAD_FLAG_RELOC  1
+#else
+#define __HEAD_FLAG_RELOC  0
+#endif
+
 #define __HEAD_FLAGS   ((__HEAD_FLAG_BE << 0) |\
-(__HEAD_FLAG_PAGE_SIZE << 1))
+(__HEAD_FLAG_PAGE_SIZE << 1) | \
+(__HEAD_FLAG_RELOC << 3))
 
 /*
  * Kernel startup entry point.
@@ -231,6 +238,9 @@ ENTRY(stext)
 */
ldr x27, 0f // address to jump to after
// MMU has been enabled
+#ifdef CONFIG_ARM64_RELOCATABLE_KERNEL
+   add x27, x27, x23   // add KASLR displacement
+#endif
adr_l   lr, __enable_mmu// return (PIC) address
b   __cpu_setup // initialise processor
 ENDPROC(stext)
@@ -243,6 +253,16 @@ ENDPROC(stext)
 preserve_boot_args:
mov x21, x0 // x21=FDT
 
+#ifdef CONFIG_ARM64_RELOCATABLE_KERNEL
+   /*
+* Mask off the bits of the random value supplied in x1 so it can serve
+* as a KASLR displacement value which will move the ker

Re: [PATCH V10 7/7] dma: qcom_hidma: add support for object hierarchy

2015-12-30 Thread Sinan Kaya

On 12/19/2015 1:37 PM, Andy Shevchenko wrote:
> On Thu, Dec 17, 2015 at 7:01 PM, Sinan Kaya  wrote:
>> In order to create a relationship model between the channels and the
>> management object, we are adding support for object hierarchy to the
>> drivers. This patch simplifies the userspace application development.
>> We will not have to traverse different firmware paths based on device
>> tree or ACPI baed kernels.
>>
>> No matter what flavor of kernel is used, objects will be represented as
>> platform devices.
>>
>> The new layout is as follows:
>>
>> hidmam_10: hidma-mgmt@0x5A00 {
>> compatible = "qcom,hidma-mgmt-1.0";
>> ...
>>
>> hidma_10: hidma@0x5a01 {
>> compatible = "qcom,hidma-1.0";
>> ...
>> }
>> }
>>
>> The hidma_mgmt_init detects each instance of the hidma-mgmt-1.0 objects
>> in device tree and calls into the channel driver to create platform devices
>> for each child of the management object.
>>
>> Signed-off-by: Sinan Kaya 
> 
> 
>> +What:  /sys/devices/platform/hidma-*/chid
>> +   /sys/devices/platform/QCOM8061:*/chid
>> +Date:  Dec 2015
>> +KernelVersion: 4.4
>> +Contact:   "Sinan Kaya "
>> +Description:
>> +   Contains the ID of the channel within the HIDMA instance.
>> +   It is used to associate a given HIDMA channel with the
>> +   priority and weight calls in the management interface.
> 
>> -module_platform_driver(hidma_mgmt_driver);
>> +#ifdef CONFIG_OF
>> +static int object_counter;
>> +
>> +static int __init hidma_mgmt_of_populate_channels(struct device_node *np)
>> +{
>> +   struct platform_device *pdev_parent = of_find_device_by_node(np);
>> +   struct platform_device_info pdevinfo;
>> +   struct of_phandle_args out_irq;
>> +   struct device_node *child;
>> +   struct resource *res;
>> +   const __be32 *cell;
> 
> Always BE ?

Yes, as Timur indicated device tree is big endian all the time.
> 
>> +   int ret = 0, size, i, num;
>> +   u64 addr, addr_size;
> 
> resource_size_t

These values are read from the device tree blob using of_read_number function. 
of_read_number
returns a u64.
> 
>> +
>> +   for_each_available_child_of_node(np, child) {
>> +   int iter = 0;
>> +
>> +   cell = of_get_property(child, "reg", &size);
>> +   if (!cell) {
>> +   ret = -EINVAL;
>> +   goto out;
>> +   }
>> +
>> +   size /= (sizeof(*cell));
> 
> Redundant parens. I think it might be good to use common sense for
> operator precedence, here is a radical example of ignoring it. And
> this is not the first case.

Removed. Note that I copied most of this function from another driver. 

> 
>> +   num = size /
>> +   (of_n_addr_cells(child) + of_n_size_cells(child)) + 
>> 1;
>> +
>> +   /* allocate a resource array */
>> +   res = kcalloc(num, sizeof(*res), GFP_KERNEL);
>> +   if (!res) {
>> +   ret = -ENOMEM;
>> +   goto out;
>> +   }
>> +
>> +   /* read each reg value */
>> +   i = 0;
>> +   while (i < size) {
>> +   addr = of_read_number(&cell[i],
>> + of_n_addr_cells(child));
>> +   i += of_n_addr_cells(child);
>> +
>> +   addr_size = of_read_number(&cell[i],
>> +  of_n_size_cells(child));
>> +   i += of_n_size_cells(child);
>> +
>> +   res[iter].start = addr;
>> +   res[iter].end = res[iter].start + addr_size - 1;
>> +   res[iter].flags = IORESOURCE_MEM;
> 
> res->start = …
> …
> res++;

ok

> 
>> +   iter++;
>> +   }
>> +
>> +   ret = of_irq_parse_one(child, 0, &out_irq);
>> +   if (ret)
>> +   goto out;
>> +
>> +   res[iter].start = irq_create_of_mapping(&out_irq);
>> +   res[iter].name = "hidma event irq";
>> +   res[iter].flags = IORESOURCE_IRQ;
> 
> Ditto.
ok

> 
>> +
>> +   pdevinfo.fwnode = &child->fwnode;
>> +   pdevinfo.parent = pdev_parent ? &pdev_parent->dev : NULL;
>> +   pdevinfo.name = child->name;
>> +   pdevinfo.id = object_counter++;
>> +   pdevinfo.res = res;
>> +   pdevinfo.num_res = num;
>> +   pdevinfo.data = NULL;
>> +   pdevinfo.size_data = 0;
>> +   pdevinfo.dma_mask = DMA_BIT_MASK(64);
>> +   platform_device_register_full(&pdevinfo);
>> +
>> +   kfree(res);
>> +   res = NULL;
>> +   }
>> +out:
> 
>> +   kfree(res);
> 
> 
>> +
>> +   return ret;

[PATCH v2 11/13] arm64: allow kernel Image to be loaded anywhere in physical memory

This relaxes the kernel Image placement requirements, so that it
may be placed at any 2 MB aligned offset in physical memory.

This is accomplished by ignoring PHYS_OFFSET when installing
memblocks, and accounting for the apparent virtual offset of
the kernel Image. As a result, virtual address references
below PAGE_OFFSET are correctly mapped onto physical references
into the kernel Image regardless of where it sits in memory.

Signed-off-by: Ard Biesheuvel 
---
 Documentation/arm64/booting.txt  | 12 ++---
 arch/arm64/include/asm/boot.h|  5 ++
 arch/arm64/include/asm/kvm_mmu.h |  2 +-
 arch/arm64/include/asm/memory.h  | 15 +++---
 arch/arm64/kernel/head.S |  6 ++-
 arch/arm64/mm/init.c | 50 +++-
 arch/arm64/mm/mmu.c  | 12 +
 7 files changed, 86 insertions(+), 16 deletions(-)

diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 701d39d3171a..03e02ebc1b0c 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -117,14 +117,14 @@ Header notes:
   depending on selected features, and is effectively unbound.
 
 The Image must be placed text_offset bytes from a 2MB aligned base
-address near the start of usable system RAM and called there. Memory
-below that base address is currently unusable by Linux, and therefore it
-is strongly recommended that this location is the start of system RAM.
-The region between the 2 MB aligned base address and the start of the
-image has no special significance to the kernel, and may be used for
-other purposes.
+address anywhere in usable system RAM and called there. The region
+between the 2 MB aligned base address and the start of the image has no
+special significance to the kernel, and may be used for other purposes.
 At least image_size bytes from the start of the image must be free for
 use by the kernel.
+NOTE: versions prior to v4.6 cannot make use of memory below the
+physical offset of the Image so it is recommended that the Image be
+placed as close as possible to the start of system RAM.
 
 Any memory described to the kernel (even that below the start of the
 image) which is not marked as reserved from the kernel (e.g., with a
diff --git a/arch/arm64/include/asm/boot.h b/arch/arm64/include/asm/boot.h
index 81151b67b26b..984cb0fa61ce 100644
--- a/arch/arm64/include/asm/boot.h
+++ b/arch/arm64/include/asm/boot.h
@@ -11,4 +11,9 @@
 #define MIN_FDT_ALIGN  8
 #define MAX_FDT_SIZE   SZ_2M
 
+/*
+ * arm64 requires the kernel image to be 2 MB aligned
+ */
+#define MIN_KIMG_ALIGN SZ_2M
+
 #endif
diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
index 0899026a2821..7e9516365b76 100644
--- a/arch/arm64/include/asm/kvm_mmu.h
+++ b/arch/arm64/include/asm/kvm_mmu.h
@@ -73,7 +73,7 @@
 
 #define KERN_TO_HYP(kva)   ((unsigned long)kva - PAGE_OFFSET + 
HYP_PAGE_OFFSET)
 
-#define kvm_ksym_ref(sym)  ((void *)&sym - KIMAGE_VADDR + PAGE_OFFSET)
+#define kvm_ksym_ref(sym)  phys_to_virt((u64)&sym - kimage_voffset)
 
 /*
  * We currently only support a 40bit IPA.
diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 1dcbf142d36c..557228658666 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -88,10 +88,10 @@
 #define __virt_to_phys(x) ({   \
phys_addr_t __x = (phys_addr_t)(x); \
__x >= PAGE_OFFSET ? (__x - PAGE_OFFSET + PHYS_OFFSET) :\
-(__x - KIMAGE_VADDR + PHYS_OFFSET); })
+(__x - kimage_voffset); })
 
 #define __phys_to_virt(x)  ((unsigned long)((x) - PHYS_OFFSET + 
PAGE_OFFSET))
-#define __phys_to_kimg(x)  ((unsigned long)((x) - PHYS_OFFSET + 
KIMAGE_VADDR))
+#define __phys_to_kimg(x)  ((unsigned long)((x) + kimage_voffset))
 
 /*
  * Convert a page to/from a physical address
@@ -121,13 +121,14 @@ extern phys_addr_tmemstart_addr;
 /* PHYS_OFFSET - the physical address of the start of memory. */
 #define PHYS_OFFSET({ memstart_addr; })
 
+/* the offset between the kernel virtual and physical mappings */
+extern u64 kimage_voffset;
+
 /*
- * The maximum physical address that the linear direct mapping
- * of system RAM can cover. (PAGE_OFFSET can be interpreted as
- * a 2's complement signed quantity and negated to derive the
- * maximum size of the linear mapping.)
+ * Allow all memory at the discovery stage. We will clip it later.
  */
-#define MAX_MEMBLOCK_ADDR  ({ memstart_addr - PAGE_OFFSET - 1; })
+#define MIN_MEMBLOCK_ADDR  0
+#define MAX_MEMBLOCK_ADDR  U64_MAX
 
 /*
  * PFNs are used to describe any physical page; this means
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 1230fa93fd8c..01a33e42ed70 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -445,7 +445,11 @@ __mmap_s

[PATCH v2 09/13] arm64: avoid R_AARCH64_ABS64 relocations for Image header fields

Unfortunately, the current way of using the linker to emit build time
constants into the Image header will no longer work once we switch to
the use of PIE executables. The reason is that such constants are emitted
into the binary using R_AARCH64_ABS64 relocations, which we will resolve
at runtime, not at build time, and the places targeted by those
relocations will contain zeroes before that.

So move back to assembly time constants or R_AARCH64_ABS32 relocations
(which, interestingly enough, do get resolved at build time)

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/include/asm/assembler.h | 15 
 arch/arm64/kernel/head.S   | 17 +++--
 arch/arm64/kernel/image.h  | 37 ++--
 3 files changed, 40 insertions(+), 29 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index 8094d50f05bc..39bf158255d7 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -204,4 +204,19 @@ lr .reqx30 // link register
.size   __pi_##x, . - x;\
ENDPROC(x)
 
+   .macro  le16, val
+   .byte   \val & 0xff
+   .byte   (\val >> 8) & 0xff
+   .endm
+
+   .macro  le32, val
+   le16\val
+   le16\val >> 16
+   .endm
+
+   .macro  le64, val
+   le32\val
+   le32\val >> 32
+   .endm
+
 #endif /* __ASM_ASSEMBLER_H */
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 6434c844a0e4..ccbb1bd46026 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -51,6 +51,17 @@
 #define KERNEL_START   _text
 #define KERNEL_END _end
 
+#ifdef CONFIG_CPU_BIG_ENDIAN
+#define __HEAD_FLAG_BE 1
+#else
+#define __HEAD_FLAG_BE 0
+#endif
+
+#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
+
+#define __HEAD_FLAGS   ((__HEAD_FLAG_BE << 0) |\
+(__HEAD_FLAG_PAGE_SIZE << 1))
+
 /*
  * Kernel startup entry point.
  * ---
@@ -83,9 +94,9 @@ efi_head:
b   stext   // branch to kernel start, magic
.long   0   // reserved
 #endif
-   .quad   _kernel_offset_le   // Image load offset from start 
of RAM, little-endian
-   .quad   _kernel_size_le // Effective size of kernel 
image, little-endian
-   .quad   _kernel_flags_le// Informative flags, 
little-endian
+   le64TEXT_OFFSET // Image load offset from start 
of RAM, little-endian
+   .long   _kernel_size_le, 0  // Effective size of kernel 
image, little-endian
+   le64__HEAD_FLAGS// Informative flags, 
little-endian
.quad   0   // reserved
.quad   0   // reserved
.quad   0   // reserved
diff --git a/arch/arm64/kernel/image.h b/arch/arm64/kernel/image.h
index bc2abb8b1599..bb6b0e69d0a4 100644
--- a/arch/arm64/kernel/image.h
+++ b/arch/arm64/kernel/image.h
@@ -26,41 +26,26 @@
  * There aren't any ELF relocations we can use to endian-swap values known only
  * at link time (e.g. the subtraction of two symbol addresses), so we must get
  * the linker to endian-swap certain values before emitting them.
+ * Note that this will not work for 64-bit values: these are resolved using
+ * R_AARCH64_ABS64 relocations, which are fixed up at runtime rather than at
+ * build time when building the PIE executable (for KASLR).
  */
 #ifdef CONFIG_CPU_BIG_ENDIAN
-#define DATA_LE64(data)\
-   data) & 0x00ff) << 56) |\
-(((data) & 0xff00) << 40) |\
-(((data) & 0x00ff) << 24) |\
-(((data) & 0xff00) << 8)  |\
-(((data) & 0x00ff) >> 8)  |\
-(((data) & 0xff00) >> 24) |\
-(((data) & 0x00ff) >> 40) |\
-(((data) & 0xff00) >> 56))
+#define DATA_LE32(data)\
+   data) & 0x00ff) << 24) |\
+(((data) & 0xff00) << 8)  |\
+(((data) & 0x00ff) >> 8)  |\
+(((data) & 0xff00) >> 24))
 #else
-#define DATA_LE64(data) ((data) & 0x)
+#define DATA_LE32(data) ((data) & 0x)
 #endif
 
-#ifdef CONFIG_CPU_BIG_ENDIAN
-#define __HEAD_FLAG_BE 1
-#else
-#define __HEAD_FLAG_BE 0
-#endif
-
-#define __HEAD_FLAG_PAGE_SIZE ((PAGE_SHIFT - 10) / 2)
-
-#define __HEAD_FLAGS   ((__HEAD_FLAG_BE << 0) |\
-(__HEAD_FLAG_PAGE_SIZE << 1))
-
 /*
  * These will output as part of the Image header, which should be little-endian
- * regardless of the endianness of the kernel. While constant values could be
- * endian swapped in head.S, all are done here for consis

[PATCH v2 03/13] arm64: use more granular reservations for static page table allocations

Before introducing new statically allocated page tables and increasing
their alignment in subsequent patches, update the reservation logic
so that only pages that are in actual use end up as reserved with
memblock.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/mm/init.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 6bacba847923..8e678d05ad84 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -36,6 +36,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -165,11 +166,13 @@ void __init arm64_memblock_init(void)
 * Register the kernel text, kernel data, initrd, and initial
 * pagetables with memblock.
 */
-   memblock_reserve(__pa(_text), _end - _text);
+   memblock_reserve(__pa(_text), __bss_stop - _text);
 #ifdef CONFIG_BLK_DEV_INITRD
if (initrd_start)
memblock_reserve(__virt_to_phys(initrd_start), initrd_end - 
initrd_start);
 #endif
+   memblock_reserve(__pa(idmap_pg_dir), IDMAP_DIR_SIZE);
+   memblock_reserve(__pa(swapper_pg_dir), SWAPPER_DIR_SIZE);
 
early_init_fdt_scan_reserved_mem();
 
-- 
2.5.0

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

[PATCH v2 10/13] arm64: avoid dynamic relocations in early boot code

Before implementing KASLR for arm64 by building a self-relocating PIE
executable, we have to ensure that values we use before the relocation
routine is executed are not subject to dynamic relocation themselves.
This applies not only to virtual addresses, but also to values that are
supplied by the linker at build time and relocated using R_AARCH64_ABS64
relocations.

So instead, use assemble time constants, or force the use of static
relocations by folding the constants into the instructions.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/kernel/efi-entry.S |  2 +-
 arch/arm64/kernel/head.S  | 39 +---
 2 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/arch/arm64/kernel/efi-entry.S b/arch/arm64/kernel/efi-entry.S
index a773db92908b..f82036e02485 100644
--- a/arch/arm64/kernel/efi-entry.S
+++ b/arch/arm64/kernel/efi-entry.S
@@ -61,7 +61,7 @@ ENTRY(entry)
 */
mov x20, x0 // DTB address
ldr x0, [sp, #16]   // relocated _text address
-   ldr x21, =stext_offset
+   movzx21, #:abs_g0:stext_offset
add x21, x0, x21
 
/*
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index ccbb1bd46026..1230fa93fd8c 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -78,12 +78,11 @@
  * in the entry routines.
  */
__HEAD
-
+_head:
/*
 * DO NOT MODIFY. Image header expected by Linux boot-loaders.
 */
 #ifdef CONFIG_EFI
-efi_head:
/*
 * This add instruction has no meaningful effect except that
 * its opcode forms the magic "MZ" signature required by UEFI.
@@ -105,14 +104,14 @@ efi_head:
.byte   0x4d
.byte   0x64
 #ifdef CONFIG_EFI
-   .long   pe_header - efi_head// Offset to the PE header.
+   .long   pe_header - _head   // Offset to the PE header.
 #else
.word   0   // reserved
 #endif
 
 #ifdef CONFIG_EFI
.globl  __efistub_stext_offset
-   .set__efistub_stext_offset, stext - efi_head
+   .set__efistub_stext_offset, stext - _head
.align 3
 pe_header:
.ascii  "PE"
@@ -135,7 +134,7 @@ optional_header:
.long   _end - stext// SizeOfCode
.long   0   // SizeOfInitializedData
.long   0   // SizeOfUninitializedData
-   .long   __efistub_entry - efi_head  // AddressOfEntryPoint
+   .long   __efistub_entry - _head // AddressOfEntryPoint
.long   __efistub_stext_offset  // BaseOfCode
 
 extra_header_fields:
@@ -150,7 +149,7 @@ extra_header_fields:
.short  0   // MinorSubsystemVersion
.long   0   // Win32VersionValue
 
-   .long   _end - efi_head // SizeOfImage
+   .long   _end - _head// SizeOfImage
 
// Everything before the kernel image is considered part of the header
.long   __efistub_stext_offset  // SizeOfHeaders
@@ -230,11 +229,13 @@ ENTRY(stext)
 * On return, the CPU will be ready for the MMU to be turned on and
 * the TCR will have been set.
 */
-   ldr x27, =__mmap_switched   // address to jump to after
+   ldr x27, 0f // address to jump to after
// MMU has been enabled
adr_l   lr, __enable_mmu// return (PIC) address
b   __cpu_setup // initialise processor
 ENDPROC(stext)
+   .align  3
+0: .quad   __mmap_switched - (_head - TEXT_OFFSET) + KIMAGE_VADDR
 
 /*
  * Preserve the arguments passed by the bootloader in x0 .. x3
@@ -402,7 +403,8 @@ __create_page_tables:
mov x0, x26 // swapper_pg_dir
ldr x5, =KIMAGE_VADDR
create_pgd_entry x0, x5, x3, x6
-   ldr x6, =KERNEL_END // __va(KERNEL_END)
+   ldr w6, kernel_img_size
+   add x6, x6, x5
mov x3, x24 // phys offset
create_block_map x0, x7, x3, x5, x6
 
@@ -419,6 +421,9 @@ __create_page_tables:
mov lr, x27
ret
 ENDPROC(__create_page_tables)
+
+kernel_img_size:
+   .long   _end - (_head - TEXT_OFFSET)
.ltorg
 
 /*
@@ -426,6 +431,10 @@ ENDPROC(__create_page_tables)
  */
.setinitial_sp, init_thread_union + THREAD_START_SP
 __mmap_switched:
+   adr_l   x8, vectors // load VBAR_EL1 with
+   msr vbar_el1, x8// relocated address
+   isb
+
adr_l   x6, __bss_start
adr_l   x7, __bss_stop
 
@@ -609,13 +618,19 @@ ENTRY(secondary_startup)
adrpx26, swapper_pg_dir
bl  __cpu_setup // initialise processor
 
-   ldr x21, =secondary_d

[PATCH v2 07/13] arm64: add support for module PLTs

This adds support for emitting PLTs at module load time for relative
branches that are out of range. This is a prerequisite for KASLR,
which may place the kernel and the modules anywhere in the vmalloc
area, making it likely that branch target offsets exceed the maximum
range of +/- 128 MB.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/Kconfig  |   4 +
 arch/arm64/Makefile |   4 +
 arch/arm64/include/asm/module.h |  11 ++
 arch/arm64/kernel/Makefile  |   1 +
 arch/arm64/kernel/module-plts.c | 137 
 arch/arm64/kernel/module.c  |   7 +
 arch/arm64/kernel/module.lds|   4 +
 7 files changed, 168 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 871f21783866..827e78f33944 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -704,6 +704,10 @@ config ARM64_LSE_ATOMICS
 
 endmenu
 
+config ARM64_MODULE_PLTS
+   bool
+   select HAVE_MOD_ARCH_SPECIFIC
+
 endmenu
 
 menu "Boot options"
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index cd822d8454c0..d4654830e536 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -45,6 +45,10 @@ ifeq ($(CONFIG_ARM64_ERRATUM_843419), y)
 KBUILD_CFLAGS_MODULE   += -mcmodel=large
 endif
 
+ifeq ($(CONFIG_ARM64_MODULE_PLTS),y)
+KBUILD_LDFLAGS_MODULE  += -T $(srctree)/arch/arm64/kernel/module.lds
+endif
+
 # Default value
 head-y := arch/arm64/kernel/head.o
 
diff --git a/arch/arm64/include/asm/module.h b/arch/arm64/include/asm/module.h
index e80e232b730e..7b8cd3dc9d8e 100644
--- a/arch/arm64/include/asm/module.h
+++ b/arch/arm64/include/asm/module.h
@@ -20,4 +20,15 @@
 
 #define MODULE_ARCH_VERMAGIC   "aarch64"
 
+#ifdef CONFIG_ARM64_MODULE_PLTS
+struct mod_arch_specific {
+   struct elf64_shdr   *core_plt;
+   struct elf64_shdr   *init_plt;
+   int core_plt_count;
+   int init_plt_count;
+};
+#endif
+
+u64 get_module_plt(struct module *mod, void *loc, u64 val);
+
 #endif /* __ASM_MODULE_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 474691f8b13a..f42b0fff607f 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -30,6 +30,7 @@ arm64-obj-$(CONFIG_COMPAT)+= sys32.o kuser32.o 
signal32.o \
   ../../arm/kernel/opcodes.o
 arm64-obj-$(CONFIG_FUNCTION_TRACER)+= ftrace.o entry-ftrace.o
 arm64-obj-$(CONFIG_MODULES)+= arm64ksyms.o module.o
+arm64-obj-$(CONFIG_ARM64_MODULE_PLTS)  += module-plts.o
 arm64-obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o perf_callchain.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
 arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
diff --git a/arch/arm64/kernel/module-plts.c b/arch/arm64/kernel/module-plts.c
new file mode 100644
index ..4a8ef9ea01ee
--- /dev/null
+++ b/arch/arm64/kernel/module-plts.c
@@ -0,0 +1,137 @@
+/*
+ * Copyright (C) 2014-2015 Linaro Ltd. 
+ *
+ * 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 
+
+struct plt_entry {
+   __le32  mov0;   /* movn x16, #0x*/
+   __le32  mov1;   /* movk x16, #0x, lsl #16   */
+   __le32  mov2;   /* movk x16, #0x, lsl #32   */
+   __le32  br; /* br   x16 */
+} __aligned(8);
+
+static bool in_init(const struct module *mod, void *addr)
+{
+   return (u64)addr - (u64)mod->module_init < mod->init_size;
+}
+
+u64 get_module_plt(struct module *mod, void *loc, u64 val)
+{
+   struct plt_entry entry = {
+   cpu_to_le32(0x92800010 | (((~val  ) & 0x)) << 5),
+   cpu_to_le32(0xf2a00010 | ((( val >> 16) & 0x)) << 5),
+   cpu_to_le32(0xf2c00010 | ((( val >> 32) & 0x)) << 5),
+   cpu_to_le32(0xd61f0200)
+   }, *plt;
+   int i, *count;
+
+   if (in_init(mod, loc)) {
+   plt = (struct plt_entry *)mod->arch.init_plt->sh_addr;
+   count = &mod->arch.init_plt_count;
+   } else {
+   plt = (struct plt_entry *)mod->arch.core_plt->sh_addr;
+   count = &mod->arch.core_plt_count;
+   }
+
+   /* Look for an existing entry pointing to 'val' */
+   for (i = 0; i < *count; i++)
+   if (plt[i].mov0 == entry.mov0 &&
+   plt[i].mov1 == entry.mov1 &&
+   plt[i].mov2 == entry.mov2)
+   return (u64)&plt[i];
+
+   i = (*count)++;
+   plt[i] = entry;
+   return (u64)&plt[i];
+}
+
+static int duplicate_rel(Elf64_Addr base, const Elf64_Rela *rela, int num)
+{
+   int i;
+
+   for (i = 0; i < num; i++) {
+   if (rela[i].r_info == rela[num].r_info &&
+   rela[i].r_addend == rela[n

[PATCH v2 08/13] arm64: use relative references in exception tables

Instead of using absolute addresses for both the exception location and
the fixup, use offsets relative to the exception table entry values. This
is a prerequisite for KASLR, since absolute exception table entries are
subject to dynamic relocation, which is incompatible with the sorting of
the exception table that occurs at build time.

Signed-off-by: Ard Biesheuvel 
---
 arch/arm64/Kconfig   |   1 +
 arch/arm64/include/asm/assembler.h   |   2 +-
 arch/arm64/include/asm/futex.h   |   4 +-
 arch/arm64/include/asm/uaccess.h |  16 +--
 arch/arm64/kernel/armv8_deprecated.c |   4 +-
 arch/arm64/mm/extable.c  | 102 +++-
 scripts/sortextable.c|   2 +-
 7 files changed, 116 insertions(+), 15 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 827e78f33944..54eeab140bca 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -7,6 +7,7 @@ config ARM64
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_SG_CHAIN
+   select ARCH_HAS_SORT_EXTABLE
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_USE_CMPXCHG_LOCKREF
select ARCH_SUPPORTS_ATOMIC_RMW
diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index 12eff928ef8b..8094d50f05bc 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -98,7 +98,7 @@
 :  x;  \
.section __ex_table,"a";\
.align  3;  \
-   .quad   b,l;\
+   .long   (b - .), (l - .);   \
.previous
 
 /*
diff --git a/arch/arm64/include/asm/futex.h b/arch/arm64/include/asm/futex.h
index 007a69fc4f40..35e73e255ad3 100644
--- a/arch/arm64/include/asm/futex.h
+++ b/arch/arm64/include/asm/futex.h
@@ -44,7 +44,7 @@
 "  .popsection\n"  \
 "  .pushsection __ex_table,\"a\"\n"\
 "  .align  3\n"\
-"  .quad   1b, 4b, 2b, 4b\n"   \
+"  .long   (1b - .), (4b - .), (2b - .), (4b - .)\n"   \
 "  .popsection\n"  \
ALTERNATIVE("nop", SET_PSTATE_PAN(1), ARM64_HAS_PAN,\
CONFIG_ARM64_PAN)   \
@@ -135,7 +135,7 @@ futex_atomic_cmpxchg_inatomic(u32 *uval, u32 __user *uaddr,
 "  .popsection\n"
 "  .pushsection __ex_table,\"a\"\n"
 "  .align  3\n"
-"  .quad   1b, 4b, 2b, 4b\n"
+"  .long   (1b - .), (4b - .), (2b - .), (4b - .)\n"
 "  .popsection\n"
: "+r" (ret), "=&r" (val), "+Q" (*uaddr), "=&r" (tmp)
: "r" (oldval), "r" (newval), "Ir" (-EFAULT)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index b2ede967fe7d..064efe4b0063 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -36,11 +36,11 @@
 #define VERIFY_WRITE 1
 
 /*
- * The exception table consists of pairs of addresses: the first is the
- * address of an instruction that is allowed to fault, and the second is
- * the address at which the program should continue.  No registers are
- * modified, so it is entirely up to the continuation code to figure out
- * what to do.
+ * The exception table consists of pairs of relative offsets: the first
+ * is the relative offset to an instruction that is allowed to fault,
+ * and the second is the relative offset at which the program should
+ * continue. No registers are modified, so it is entirely up to the
+ * continuation code to figure out what to do.
  *
  * All the routines below use bits of fixup code that are out of line
  * with the main instruction path.  This means when everything is well,
@@ -50,7 +50,7 @@
 
 struct exception_table_entry
 {
-   unsigned long insn, fixup;
+   int insn, fixup;
 };
 
 extern int fixup_exception(struct pt_regs *regs);
@@ -125,7 +125,7 @@ static inline void set_fs(mm_segment_t fs)
"   .previous\n"\
"   .section __ex_table,\"a\"\n"\
"   .align  3\n"\
-   "   .quad   1b, 3b\n"   \
+   "   .long   (1b - .), (3b - .)\n"   \
"   .previous"  \
: "+r" (err), "=&r" (x) \
: "r" (addr), "i" (-EFAULT))
@@ -192,7 +192,7 @@ do {
\
"   .previous\n"\
"   .section __ex_table,\"a\"\n"

[PATCH v2 00/13] arm64: implement support for KASLR

This series implements KASLR for arm64, by building the kernel as a PIE
executable that can relocate itself at runtime, and moving it to a random
offset in the vmalloc area. This v2 also implements physical randomization,
i.e., it allows the kernel to deal with being loaded at any physical offset
(modulo the required alignment), and invokes the EFI_RNG_PROTOCOL from the
UEFI stub to obtain random bits and perform the actual randomization of the
physical load address.

Changes since v1/RFC:
- This series now implements fully independent virtual and physical address
randomization at load time. I have recycled some patches from this series:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/455151, and updated the
final UEFI stub patch to randomize the physical address as well.
- Added a patch to deal with the way KVM on arm64 makes assumptions about the
relation between kernel symbols and the linear mapping (on which the HYP
mapping is based), as these assumptions cease to be valid once we move the
kernel Image out of the linear mapping.
- Updated the module PLT patch so it works on BE kernels as well.
- Moved the constant Image header values to head.S, and updated the linker
script to provide the kernel size using R_AARCH64_ABS32 relocation rather
than a R_AARCH64_ABS64 relocation, since those are always resolved at build
time. This allows me to get rid of the post-build perl script to swab header
values on BE kernels.
- Minor style tweaks.

Notes:
- These patches apply on top of Mark Rutland's pagetable rework series:
http://thread.gmane.org/gmane.linux.ports.arm.kernel/462438
- The arm64 Image is uncompressed by default, and the Elf64_Rela format uses
24 bytes per relocation entry. This results in considerable bloat (i.e., a
couple of MBs worth of relocation data in an .init section). However, no
build time postprocessing is required, we rely fully on the toolchain to
produce the image
- We have to rely on the bootloader to supply some randomness in register x1
upon kernel entry. Since we have no decompressor, it is simply not feasible
to collect randomness in the head.S code path before mapping the kernel and
enabling the MMU.
- The EFI_RNG_PROTOCOL that is invoked in patch #13 to supply randomness on
UEFI systems is not universally available. A QEMU/KVM firmware image that
implements a pseudo-random version is available here:
http://people.linaro.org/~ard.biesheuvel/QEMU_EFI.fd.aarch64-rng.bz2
(requires access to PMCCNTR_EL0 and support for AES instructions)
See below for instructions how to run the pseudo-random version on real
hardware.
- Only mildly tested. Help appreciated.

Code can be found here:
git://git.linaro.org/people/ard.biesheuvel/linux-arm.git arm64-kaslr-v2
https://git.linaro.org/people/ard.biesheuvel/linux-arm.git/shortlog/refs/heads/arm64-kaslr-v2

Patch #1 updates the OF code to allow the minimum memblock physical address to
be overridden by the arch.

Patch #2 introduces KIMAGE_VADDR as the base of the kernel virtual region.

Patch #3 memblock_reserve()'s the .bss, swapper_pg_dir and idmap_pg_dir
individually.

Patch #4 rewrites early_fixmap_init() so it does not rely on the linear mapping
(i.e., the use of phys_to_virt() is avoided)

Patch #5 updates KVM on arm64 so it can deal with kernel symbols whose addresses
are not covered by the linear mapping.

Patch #6 moves the kernel virtual mapping to the vmalloc area, along with the
module region which is kept right below it, as before.

Patch #7 adds support for PLTs in modules so that relative branches can be
resolved via a PLT if the target is out of range.

Patch #8 moves to the x86 version of the extable implementation so that it no
longer contains absolute addresses that require fixing up at relocation time,
but uses relative offsets instead.

Patch #9 reverts some changes to the Image header population code so we no
longer depend on the linker to populate the header fields. This is necessary
since the R_AARCH64_ABS relocations that are emitted for these fields are not
resolved at build time for PIE executables.

Patch #10 updates the code in head.S that needs to execute before relocation to
avoid the use of values that are subject to dynamic relocation. These values
will not be populated in PIE executables.

Patch #11 allows the kernel Image to be loaded anywhere in physical memory, by
decoupling PHYS_OFFSET from the base of the kernel image.

Patch #12 implements the core KASLR, by taking randomness supplied in register
x1
and using it to move the kernel inside the vmalloc area.

Patch #13 adds an invocation of the EFI_RNG_PROTOCOL to supply randomness to the
kernel proper.

Ard Biesheuvel (13):
of/fdt: make memblock minimum physical address arch configurable
arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region
arm64: use more granular reservations for static page table
allocations
arm64: decouple early fixmap init from linear mapping
arm64: kvm:

[PATCH v2 01/13] of/fdt: make memblock minimum physical address arch configurable

By default, early_init_dt_add_memory_arch() ignores memory below
the base of the kernel image since it won't be addressable via the
linear mapping. However, this is not appropriate anymore once we
decouple the kernel text mapping from the linear mapping, so archs
may want to drop the low limit entirely. So allow the minimum to be
overridden by setting MIN_MEMBLOCK_ADDR.

Acked-by: Mark Rutland 
Acked-by: Rob Herring 
Signed-off-by: Ard Biesheuvel 
---
 drivers/of/fdt.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index d2430298a309..0455564f8cbc 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -971,13 +971,16 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 }
 
 #ifdef CONFIG_HAVE_MEMBLOCK
+#ifndef MIN_MEMBLOCK_ADDR
+#define MIN_MEMBLOCK_ADDR  __pa(PAGE_OFFSET)
+#endif
 #ifndef MAX_MEMBLOCK_ADDR
 #define MAX_MEMBLOCK_ADDR  ((phys_addr_t)~0)
 #endif
 
 void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-   const u64 phys_offset = __pa(PAGE_OFFSET);
+   const u64 phys_offset = MIN_MEMBLOCK_ADDR;
 
if (!PAGE_ALIGNED(base)) {
if (size < PAGE_SIZE - (base & ~PAGE_MASK)) {
-- 
2.5.0

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

Re: [PATCH] net: Fix potential NULL pointer dereference in __skb_try_recv_datagram

2015-12-30 Thread Rainer Weikusat

Jacob Siverskog  writes:
> On Tue, Dec 29, 2015 at 9:08 PM, David Miller  wrote:
>> From: Rainer Weikusat 
>> Date: Tue, 29 Dec 2015 19:42:36 +
>>
>>> Jacob Siverskog  writes:
 This should fix a NULL pointer dereference I encountered (dump
 below). Since __skb_unlink is called while walking,
 skb_queue_walk_safe should be used.
>>>
>>> The code in question is:
>>  ...
>>> __skb_unlink is only called prior to returning from the function.
>>> Consequently, it won't affect the skb_queue_walk code.
>>
>> Agreed, this patch doesn't fix anything.
>
> Ok. Thanks for your feedback. How do you believe the issue could be
> solved? Investigating it gives:
>
> static inline void __skb_unlink(struct sk_buff *skb, struct sk_buff_head 
> *list)
> {

[...]

> next->prev = prev;
>  530: e5823004 str r3, [r2, #4]  <--
> trapping instruction (r2 NULL)
>
> Register contents:
> r7 : c58cfe1c  r6 : c06351d0  r5 : c77810ac  r4 : c583eac0
> r3 :   r2 :   r1 :   r0 : 2013
>
> If I understand this correctly, then r4 = skb, r2 = next, r3 = prev.

Some additional information which may be helpful: The next->prev = prev
was pretty obvious from the original error message alone: The invalid
access happened at 4 but no register contained 4. Considering that this
is for ARM, this must have been caused by an instruction using an
address of the form

[Rx, #4]

ie, value of register x + 4. And the next->prev = prev is the only
access to something located 4 bytes beyond something else.

> Should there be a check for this in __skb_try_recv_datagram?

These lists are supposed to be circular, ie, the next pointer of the
last element should point to the first and the prev pointer of the first
to the last. If there's an element with ->next == NULL on the list,
something either didn't do inserts correctly or corrupted an originally
intact list.

General advice: The original error occurred with 4.3.0. Had this
happened to me, I'd either tried to locate the error in the same kernel
version or to reproduce the bug with the one I was planning to
modify. Trying to fix a 'strange memory access' error which was observed
with version x.y by modifying version x.z is IMHO needlessly moving on
shaky ground.

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

Re: rsi: consolidate kmalloc/memset 0 calls to kzalloc

2015-12-30 Thread Kalle Valo


> This is an API consolidation only. The use of kmalloc + memset to 0
> is equivalent to kzalloc.
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks, applied to wireless-drivers-next.git.

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

Re: rsi: bool tests do not need comparison

2015-12-30 Thread Kalle Valo


> This is an API consolidation only. Bool initializations should 
> use true and false thus bool tests don't need an explicit comparison.
> 
> Signed-off-by: Nicholas Mc Guire 

Thanks, applied to wireless-drivers-next.git.

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

Re: [f2fs-dev] [PATCH 2/2] f2fs: support revoking atomic written pages

2015-12-30 Thread Chao Yu

On 12/30/15 9:34 AM, Chao Yu wrote:
> Hi Jaegeuk,
> 
>> -Original Message-
>> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
>> Sent: Wednesday, December 30, 2015 8:05 AM
>> To: Chao Yu
>> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
>> Subject: Re: [PATCH 2/2] f2fs: support revoking atomic written pages
>>
>> Hi Chao,
>>
>> On Tue, Dec 29, 2015 at 11:12:36AM +0800, Chao Yu wrote:
>>> f2fs support atomic write with following semantics:
>>> 1. open db file
>>> 2. ioctl start atomic write
>>> 3. (write db file) * n
>>> 4. ioctl commit atomic write
>>> 5. close db file
>>>
>>> With this flow we can avoid file becoming corrupted when abnormal power
>>> cut, because we hold data of transaction in referenced pages linked in
>>> inmem_pages list of inode, but without setting them dirty, so these data
>>> won't be persisted unless we commit them in step 4.
>>>
>>> But we should still hold journal db file in memory by using volatile write,
>>> because our semantics of 'atomic write support' is not full, in step 4, we
>>> could be fail to submit all dirty data of transaction, once partial dirty
>>> data was committed in storage, db file should be corrupted, in this case,
>>> we should use journal db to recover the original data in db file.
>>
>> Originally, IOC_ABORT_VOLATILE_WRITE was supposed to handle commit failures,
>> since database should get its error literally.
>>
>> So, the only thing that we need to do is keeping journal data for further db
>> recovery.
> 
> IMO, if we really support *atomic* interface, we don't need any journal data
> kept by user, because f2fs already have it in its storage since we always
> trigger OPU for pages written in atomic-write opened file, f2fs can easily try
> to revoke (replace old to new in metadata) when any failure exist in atomic
> write process.
> 
> But in current design, we still hold journal data in memory for recovering for
> *rare* failure case. I think there are several issues:
> a) most of time, we are in concurrent scenario, so if large number of journal
> db files were opened simultaneously, we are under big memory pressure.
> b) If we are out of memory, reclaimer tries to write page of journal db into
> disk, it will destroy db file.
> c) Though, we have journal db file, we will face failure of recovering db file
> from journal db due to ENOMEM or EIO, then db file will be corrupted.
> d) Recovery flow will make data page dirty, triggering both data stream and
> metadata stream, there should be more IOs than in inner revoking in
> atomic-interface.
> e) Moreover, there should be a hole between 1) commit fail and 2) abort write 
> &
> recover, checkpoint will persist the corrupt data in db file, following 
> abnormal
> power-cut will leave that data in disk.
> 
> With revoking supported design, we can not solve all above issues, we will 
> still
> face the same issue like c), but it will be a big improve if we can apply this
> in our interface, since it provide a way to fix the issue a) b) d). And also 
> for
> e) case, we try to rescue data in first time that our revoking operation 
> would be
> protected by f2fs_lock_op to avoid checkpoint + power-cut.
> 
> If you don't want to have a big change in this interface or recovery flow, how
> about keep them both, and add a mount option to control inner recovery flow?

Or introduce F2FS_IOC_COMMIT_ATOMIC_WRITE_V2 for revoking supported interface?

> 
> How do you think? :)
> 
> Thanks,
> 
>> But, unfortunately, it seems that something is missing in the
>> current implementation.
>>
>> So simply how about this?
>>
>> A possible flow would be:
>> 1. write journal data to volatile space
>> 2. write db data to atomic space
>> 3. in the error case, call ioc_abort_volatile_writes for both journal and db
>>  - flush/fsync journal data to disk
>>  - drop atomic data, and will be recovered by database with journal
>>
>> From cb33fc8bc30981c370ec70fe68871130109793ec Mon Sep 17 00:00:00 2001
>> From: Jaegeuk Kim 
>> Date: Tue, 29 Dec 2015 15:46:33 -0800
>> Subject: [PATCH] f2fs: fix f2fs_ioc_abort_volatile_write
>>
>> There are two rules to handle aborting volatile or atomic writes.
>>
>> 1. drop atomic writes
>>  - we don't need to keep any stale db data.
>>
>> 2. write journal data
>>  - we should keep the journal data with fsync for db recovery.
>>
>> Signed-off-by: Jaegeuk Kim 
>> ---
>>  fs/f2fs/file.c | 13 ++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
>> index 91f576a..d16438a 100644
>> --- a/fs/f2fs/file.c
>> +++ b/fs/f2fs/file.c
>> @@ -1433,9 +1433,16 @@ static int f2fs_ioc_abort_volatile_write(struct file 
>> *filp)
>>  if (ret)
>>  return ret;
>>
>> -clear_inode_flag(F2FS_I(inode), FI_ATOMIC_FILE);
>> -clear_inode_flag(F2FS_I(inode), FI_VOLATILE_FILE);
>> -commit_inmem_pages(inode, true);
>> +if (f2fs_is_atomic_file(inode)) {
>> +clear_inode_flag(F2FS_I(inode), FI_ATO

[PATCH] checkpatch: fix left brace warning

2015-12-30 Thread Geyslan G. Bem

This patch escapes a regex that uses left brace.

Using checkpatch.pl with Perl 5.22.0 generates the warning: "Unescaped
left brace in regex is deprecated, passed through in regex;"

Comment from regcomp.c in Perl source: "Currently we don't warn when the
lbrace is at the start of a construct. This catches it in the middle of
a literal string, or when it's the first thing after something like
"\b"."

This works as a complement to 4e5d56bd.

Signed-off-by: Geyslan G. Bem 
Suggested-by: Peter Senna Tschudin 
---
 scripts/checkpatch.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d4960f7..3e11a30 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4108,7 +4108,7 @@ sub process {
 ## }
 
 #need space before brace following if, while, etc
-   if (($line =~ /\(.*\)\{/ && $line !~ /\($Type\){/) ||
+   if (($line =~ /\(.*\)\{/ && $line !~ /\($Type\)\{/) ||
$line =~ /do\{/) {
if (ERROR("SPACING",
  "space required before the open brace '{'\n" 
. $herecurr) &&
-- 
2.6.4

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

Re: [BUG] checkpatch: unescaped left brace in regex is deprecated

2015-12-30 Thread Geyslan G. Bem

2015-12-16 8:21 GMT-03:00 Geyslan G. Bem :
> 2015-12-15 21:13 GMT-03:00 Joe Perches :
>> On Tue, 2015-12-15 at 20:58 -0300, Geyslan G. Bem wrote:
>>> 2015-12-10 8:24 GMT-03:00 Geyslan G. Bem :
>>> > Suggested-by: Peter Senna Tschudin 
>>> > Reported-by: Geyslan G. Bem 
>>> >
>>>
>>> Joe, do you applied this patch? If not, would I send it?
>>
>> You can resend, but I believe there are a few more instances
>> of this that might need fixing too.
Only one regex from that list triggered the warning. Patch sent.

>>
>> I don't have perl 5.22 so it's difficult for me to test.
>>
>> Here's a grep with some possible false positives
>> and maybe missing some too.
> Ok, I'll try to trigger them before make the patch.
>
>>
>> $ git grep -n "=[\!~].*{" scripts/checkpatch.pl|grep -vw qr|grep -vP 
>> '{$|{\s*#|\${|\\{|{[\d$]'
>> scripts/checkpatch.pl:1143: $remainder =~ 
>> /^(else)(?:\s|{)/ &&
>> scripts/checkpatch.pl:1233: $stmt =~ s/^\s*{//;
>> scripts/checkpatch.pl:2458: if ($file =~ 
>> m{^(.*?)(?::\d+)+:?$} &&
>> scripts/checkpatch.pl:2802: if ($line =~ 
>> /^\+(.*)\(\s*$Type\s*\)([ \t]++)((?![={]|\\$|$Attribute|__attribute__))/ &&
>> scripts/checkpatch.pl:3015: $s =~ s/{.*$//s;
>> scripts/checkpatch.pl:3168: $s =~ s/^\s*{//;
>> scripts/checkpatch.pl:3274: if ($line =~ /^.\s*{/ &&
>> scripts/checkpatch.pl:3282: $fixedline =~ 
>> s/\s*=\s*$/ = {/;
>> scripts/checkpatch.pl:3285: $fixedline =~ 
>> s/^(.\s*){\s*/$1/;
>> scripts/checkpatch.pl:3606: if 
>> (($line=~/$Type\s*$Ident\(.*\).*\s*{/) and
>> scripts/checkpatch.pl:3613: $fixed_line =~ 
>> /(^..*$Type\s*$Ident\(.*\)\s*){(.*)$/;
>> scripts/checkpatch.pl:3625: if ($line =~ /^.\s*{/ &&
>> scripts/checkpatch.pl:3635: $fixedline =~ 
>> s/^(.\s*){\s*/$1\t/;
>> scripts/checkpatch.pl:4104:##   if ($line =~ 
>> /^.\s*$Type\s+$Ident(?:\s*=[^,{]*)?\s*,\s*$Ident.*/ &&
>> scripts/checkpatch.pl:4124: $fixed[$fixlinenr] 
>> =~ s/^(\+.*(?:do|\))){/$1 {/;
>> scripts/checkpatch.pl:4734: $seen++ if 
>> ($block =~ /^\s*{/);
>>
>
>
>
> --
> Regards,
>
> Geyslan G. Bem
> hackingbits.com



-- 
Regards,

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

[PATCH v2] mwifiex: correctly handling kzalloc

2015-12-30 Thread Insu Yun

Since kzalloc can be failed in memory pressure,
it needs to be handled, otherwise NULL dereference could be happened

Signed-off-by: Insu Yun 
---
 drivers/net/wireless/mwifiex/sdio.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/wireless/mwifiex/sdio.c 
b/drivers/net/wireless/mwifiex/sdio.c
index 78a8474..a8af72d 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -2053,8 +2053,19 @@ static int mwifiex_init_sdio(struct mwifiex_adapter 
*adapter)
/* Allocate skb pointer buffers */
card->mpa_rx.skb_arr = kzalloc((sizeof(void *)) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.skb_arr) {
+   kfree(card->mp_regs);
+   return -ENOMEM;
+   }
+
card->mpa_rx.len_arr = kzalloc(sizeof(*card->mpa_rx.len_arr) *
   card->mp_agg_pkt_limit, GFP_KERNEL);
+   if (!card->mpa_rx.len_arr) {
+   kfree(card->mp_regs);
+   kfree(card->mpa_rx.skb_arr);
+   return -ENOMEM;
+   }
+
ret = mwifiex_alloc_sdio_mpa_buffers(adapter,
 card->mp_tx_agg_buf_size,
 card->mp_rx_agg_buf_size);
-- 
1.9.1

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

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

2015-12-30 Thread David Sterba

On Wed, Dec 30, 2015 at 06:15:23AM -0500, Sanidhya Solanki wrote:
> Only one problem. I do not run BTRFS on my systems nor do I have a
> RAID setup, due to possessing a limited number of free drives. So, while
> I may be able to code for it, I will not be able to test it. I will need
> the community's help to do the testing.

Multiple devices can be simulated by loop devices or one physical device
partitioned. I'd expect at least some testing on your side, the
community will help with testing, but that's nothing specific to this
patch. This happens all the time.

> I will get started tomorrow.
> 
> To-do (so far):
> - Implement RAID Stripe length as a compile and runtime option.

I was trying to explain that it's not a compile time option.

> - Implement a way to do an in-place Stripe Length change.

How are you going to implement that? I've suggested the balance filter
style of conversion, which is not in-place so I'm curious what do you
mean by in-place.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] i915: correctly handling failed allocation

2015-12-30 Thread Insu Yun

Since devm_kzalloc can be failed, it needs to be checked
if not, NULL dereference could be happened.

Signed-off-by: Insu Yun 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac..aa1f7bc 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -666,6 +666,8 @@ struct drm_panel *vbt_panel_init(struct intel_dsi 
*intel_dsi, u16 panel_id)
 
/* This is cheating a bit with the cleanup. */
vbt_panel = devm_kzalloc(dev->dev, sizeof(*vbt_panel), GFP_KERNEL);
+   if (!vbt_panel)
+   return NULL;
 
vbt_panel->intel_dsi = intel_dsi;
drm_panel_init(&vbt_panel->panel);
-- 
1.9.1

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

Re: [PATCH] BTRFS: Adds an option to select RAID Stripe size

2015-12-30 Thread David Sterba

On Wed, Dec 30, 2015 at 10:10:44PM +0800, Qu Wenruo wrote:
> Now I am on the same side of David.
> Which means a runtime interface to change them. (along with mkfs option)
> 
> If provide some configurable features, then it should be able to be 
> tuned at both right time and mkfs time.
> Or, just don't touch it until there is really enough user demand.
> (In stripe_len case, it's also a possible choice, as configurable stripe 
> length doesn't really affect much except RAID5/6)

I think that we need configurable stripe size regardless. The
performance drop is measurable if the stripe size used by filesystem
does not match the hardware.

> I totally understand that implement will cost you a lot of more time, 
> not only kernel part but also user-tool part.
> 
> But this also means more patches.
> No matter what the motivation for you to contribute to btrfs, more 
> patches (except the more time spent) are always good.
> 
> More patches, more reputation built in community, and more patches also 
> means better split code structures for easier review.

Let me note that a good reputation is also built from patch reviews
(hint hint).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:

> In my opinion, it would be more elegant to adapt the core regulator
> framework to first enable the GPIO and then call the regulator enable
> ops callback instead of handling the GPIO in the driver.

Why would we want to actively manage both things at runtime?  It's more
work, what do we gain from it?


signature.asc
Description: PGP signature

Re: [PATCH] dt: bindings: add bindings for ipq4019 wifi block

2015-12-30 Thread Rob Herring

On Wed, Dec 23, 2015 at 11:05:15AM +0530, Raja Mani wrote:
> Add device tree binding documentation details for wifi block present
> in Qualcomm IPQ4019 SoC into qcom,ath10k.txt.
> 
> Signed-off-by: Raja Mani 
> ---
>  .../bindings/net/wireless/qcom,ath10k.txt  | 87 
> --
>  1 file changed, 82 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
> b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> index edefc26..ffd0742 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
> @@ -1,17 +1,42 @@
>  * Qualcomm Atheros ath10k wireless devices
>  
> -For ath10k devices the calibration data can be provided through Device
> -Tree. The node is a child node of the PCI controller.

So it is now not a PCI device?

> -
>  Required properties:
> --compatible : Should be "qcom,ath10k"
> +- compatible: Should be one of the following:
> + * "qcom,ath10k"
> + * "qcom,ipq4019-wifi"

One is a standalone PCI device and one is embedded block in an SOC? 
These should be more separated as all these new properties would only 
apply in the latter case.

>  
>  Optional properties:
> +- reg: Address and length of the register set for the device.
> +- core-id: Core number associated to the device.

This needs a better explanation.

> +- resets: Must contain an entry for each entry in reset-names.
> +  See ../reset/reseti.txt for details.
> +- reset-names: Must include the list of following reset names,
> +"wifi_cpu_init"
> +"wifi_radio_srif"
> +"wifi_radio_warm"
> +"wifi_radio_cold"
> +"wifi_core_warm"
> +"wifi_core_cold"
> +- clocks: List of clock specifiers, must contain an entry for each required
> +  entry in clock-names.
> +- clock-names: Should contain the clock names "wifi_wcss_cmd", 
> "wifi_wcss_ref",
> +   "wifi_wcss_rtc".
> +- interrupts: List of interrupt lines. Must contain an entry
> +   for each entry in the interrupt-names property.
> +- interrupt-names: Must include the entries for MSI interrupt
> +names ("msi0" to "msi15") and legacy interrupt
> +name ("legacy"),
> +- qca,msi_addr: MSI interrupt address.
> +- qca,msi_base: Base value to add before writing MSI data into
> + MSI address register.

Why don't the standard MSI properties work?

>  - qcom,ath10k-calibration-data : calibration data as an array, the
>length can vary between hw versions
> +- status: Either "disabled" or "ok".
> +

No need to document status here.

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

RE: [PATCH 03/34] ia64: rename nop->iosapic_nop

2015-12-30 Thread Luck, Tony

> asm-generic/barrier.h defines a nop() macro.
> To be able to use this header on ia64, we shouldn't
> call local functions/variables nop().
>
> There's one instance where this breaks on ia64:
> rename the function to iosapic_nop to avoid the conflict.

Acked-by: Tony Luck 

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

RE: [PATCH 04/34] ia64: reuse asm-generic/barrier.h

2015-12-30 Thread Luck, Tony

> On ia64 smp_rmb, smp_wmb, read_barrier_depends, smp_read_barrier_depends
> and smp_store_mb() match the asm-generic variants exactly. Drop the
> local definitions and pull in asm-generic/barrier.h instead.
>
> This is in preparation to refactoring this code area.

Acked-by: Tony Luck 

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

Re: [PATCH] mac80211: Make addr const in SET_IEEE80211_PERM_ADDR()

2015-12-30 Thread Souptick Joarder

HI Bjorn,

On Thu, Dec 24, 2015 at 2:03 PM, Bjorn Andersson  wrote:
> Make the addr parameter const in SET_IEEE80211_PERM_ADDR() to save
> clients from having to cast away a const qualifier.
>
> Signed-off-by: Bjorn Andersson 
> ---
>  include/net/mac80211.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> index 7c30faff245f..a6f3c9c4b7c2 100644
> --- a/include/net/mac80211.h
> +++ b/include/net/mac80211.h
> @@ -2167,7 +2167,7 @@ static inline void SET_IEEE80211_DEV(struct 
> ieee80211_hw *hw, struct device *dev
>   * @hw: the &struct ieee80211_hw to set the MAC address for
>   * @addr: the address to set
>   */
> -static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, u8 *addr)
> +static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, const u8 
> *addr)

I guess without const or with const doesn't make much difference here.
Correct me if I am wrong.
>  {
> memcpy(hw->wiphy->perm_addr, addr, ETH_ALEN);
>  }
> --
> 2.5.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

RE: Domain faults when CONFIG_CPU_SW_DOMAIN_PAN is enabled

2015-12-30 Thread Peter Rosin

[I repeat myself just in case my last message disappeared. It would be
 a shame if 4.4 was also regressed because of a missing response.]

I wrote:
> Russell King wrote:
> > On Thu, Dec 10, 2015 at 03:29:37PM +, Peter Rosin wrote:
> > > Russell King wrote:
> > > > On Thu, Dec 03, 2015 at 09:37:51PM +, Peter Rosin wrote:
> > > > > I took both patches for a quick spin (a dozen boots and one hour 
> > > > > uptime after that for each patch) and no incidents. I have not 
> > > > > gathered data, but the crash on boot feels like it's quite a bit 
> > > > > above 50% when there is a problem so this feels good (I used 5 
> > > > > clean reboots when I bisected and that worked).
> > > > > 
> > > > > Reported-by: Peter Rosin 
> > > > > Tested-by: Peter Rosin 
> > > > > 
> > > > > (and please don't forget to cc stable)
> > > > 
> > > > I've decided to do a more in-depth fix, so that we also solve the 
> > > > issue that when we schedule in these down_read()s, we don't leak 
> > > > the permissive domain register setting into the switched-to context.
> > > > 
> > > > Can you test this patch please?  Thanks.
> > > 
> > > Still looking good.
> > 
> > Does that mean I can add your reported and tested-by to this latest patch?
> 
> Right, I thought that was obvious, sorry for the confusion.

Reported-by: Peter Rosin 
Tested-by: Peter Rosin 

(and please don't forget to cc stable)

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

RE: Domain faults when CONFIG_CPU_SW_DOMAIN_PAN is enabled

2015-12-30 Thread Peter Rosin

I wrote:
> [I repeat myself just in case my last message disappeared. It would be
>  a shame if 4.4 was also regressed because of a missing response.]

Crap, I should have checked one more time before hitting send. The patch
is already in there! Sorry for the confusion.

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

Re: [PATCH 1/2] dt-bindings: GPIO: Add generic serializer binding


On 12/16/2015 10:29 AM, Rob Herring wrote:

On Mon, Dec 14, 2015 at 5:19 PM, Andrew F. Davis  wrote:

On 12/14/2015 04:36 PM, Rob Herring wrote:


On Mon, Dec 14, 2015 at 10:41 AM, Andrew F. Davis  wrote:


On 12/11/2015 03:48 PM, Linus Walleij wrote:



On Fri, Dec 11, 2015 at 8:46 PM, Andrew F. Davis  wrote:


[...]


+ - compatible  : Should be "pisosr-gpio".




I think it should also define compatible strings on the "vendor,device"
format apart from the generic compatible. Sooner or later we may need
to differentiate them and then that comes in handy.



Would it be better to wait until/if this issue arises? This driver
targets the generic features, as these parts are very generic and
have been produced by many companies since the 70s I'm not sure
if privileging any of them makes much sense.

What I'm worried about looks to have happened with the gpio-74x164
driver, this is kind of the companion device to mine (74164 / 74165)
and should work with any 74164 compatible shift register (possibly 100s
of versions of them), but the compatible string that was added is
"fairchild,74hc595", a relatively new device by a single manufacturer.
The problem this has is then that boards will use this compatible string
even if the parts are not actually the Fairchild version, just to get
the match, when they should be using a generic string.



I agree the generic version is fine (or find who made the first part
;)). What "pisosr" is is not very obvious though. Having 74165 in the
compatible would make it somewhat more obvious it is a standard logic
part.



A quick search shows shift-registers being made from vacuum tubes for
the Colossus! Those might work with this driver if you could match the
voltage to an SPI bus... :)

I agree about the name not being very good, but I'm not sure about
74165 ether as it is also just a single part number. The idea was to
have a non-part number compatible string for any shift-register you
can hook to the SPI line. That way when we have boards with a sn65x882
or something we wont have to call it a 74165. But I guess that's why
it's a "compatible:" string, and not "is-a:" string.


If there are a couple then I think it is okay. If there are 10s then
maybe not. Perhaps logic-pisosr or discrete-pisosr?



My concern as well, there are a lot of them, and every device doesn't
need its own string, so why privilege the name of any that don't have
anything different.

I'd like to leave the named ones for odd cases that needs special
handling.


+Optional properties:
+ - ngpios  : Number of GPIO lines, default is 8.




If you didn't do "pisosr-gpio" but instead "foo,sn74165", maybe you
don't need to have this in the device tree but instead it can be
determined from the compatible string?

In that case do that.



These devices can be daisy-chained together, so three 8bit registers
look exactly like one 24bit register. The only way to know this is
from the physical wiring of the board, not from the part number.



Then you should say it must be multiple of 8 (or are there other
lengths?).



Some are 4bit, you can even just hook a single flip-flop to the SPI bus for
a single bit (or multiples) of input.


One would hope you would just connect the CS signal directly to that
input for 1-bit... I guess you could be out of GPIOs and only have a
free output only CS signal.



Interesting use-case idea :), I'm more worried about a device with any
prime number of pins where multiples will fail, not that I have ever
seen one.

Andrew


Rob


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

Re: [PATCH 1/2] spi: cadence: use to_platform_device()

On Wed, Dec 30, 2015 at 10:57:35PM +0800, Geliang Tang wrote:
> Use to_platform_device() instead of open-coding it.

Please don't send new patches in reply to the middle of other serieses,
it gets confusing working out what the currently propose series is.
Send new patches as new patches.


signature.asc
Description: PGP signature

Re: [PATCH] mac80211: Make addr const in SET_IEEE80211_PERM_ADDR()

2015-12-30 Thread Bjorn Andersson

On Wed, Dec 30, 2015 at 8:47 AM, Souptick Joarder  wrote:
>
> HI Bjorn,
>
> On Thu, Dec 24, 2015 at 2:03 PM, Bjorn Andersson  wrote:
> > Make the addr parameter const in SET_IEEE80211_PERM_ADDR() to save
> > clients from having to cast away a const qualifier.
> >
> > Signed-off-by: Bjorn Andersson 
> > ---
> >  include/net/mac80211.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/include/net/mac80211.h b/include/net/mac80211.h
> > index 7c30faff245f..a6f3c9c4b7c2 100644
> > --- a/include/net/mac80211.h
> > +++ b/include/net/mac80211.h
> > @@ -2167,7 +2167,7 @@ static inline void SET_IEEE80211_DEV(struct 
> > ieee80211_hw *hw, struct device *dev
> >   * @hw: the &struct ieee80211_hw to set the MAC address for
> >   * @addr: the address to set
> >   */
> > -static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, u8 
> > *addr)
> > +static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, const 
> > u8 *addr)
>
> I guess without const or with const doesn't make much difference here.
> Correct me if I am wrong.

For most cases it doesn't make any difference, but in my driver I
acquire the mac address as a const u8 *. Therefor I need to cast away
the const part when calling this API.

There's an existing example of this in
drivers/net/wireless/st/cw1200/main.c line 601.


I think it's safe to assume that this API won't ever modify the passed
addr buffer, so there would be no future issues of marking the
parameter const either.

>
> >  {
> > memcpy(hw->wiphy->perm_addr, addr, ETH_ALEN);
> >  }
>

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

Re: [PATCH 1/2] dt-bindings: GPIO: Add generic serializer binding


On 12/22/2015 03:51 AM, Linus Walleij wrote:

On Tue, Dec 15, 2015 at 12:19 AM, Andrew F. Davis  wrote:

[Rob]

I agree the generic version is fine (or find who made the first part
;)). What "pisosr" is is not very obvious though. Having 74165 in the
compatible would make it somewhat more obvious it is a standard logic
part.



A quick search shows shift-registers being made from vacuum tubes for
the Colossus! Those might work with this driver if you could match the
voltage to an SPI bus... :)

I agree about the name not being very good, but I'm not sure about
74165 ether as it is also just a single part number.


We can add many compatible strings so it's not an issue.
"ti,74165" works for me as TI invented the 74xx series.



Free advertising for our parts :)


The idea was to
have a non-part number compatible string for any shift-register you
can hook to the SPI line.


Again, one does not exclude the other. I'm happy with a generic
compatible *and* "ti,74165".


That way when we have boards with a sn65x882
or something we wont have to call it a 74165. But I guess that's why
it's a "compatible:" string, and not "is-a:" string.


Compatible ranges from the specific to the more generic
so compatible = "ti,74165", "pisosr"; is just fine. Something
will match if there is a suitable driver. The OS may choose to
provide something part-specific or something more generic.



And so we won't need to have "ti,74165" in the driver itself,
if we just have "pisosr", then dts files can use what ever they
like to correctly identify the part then fall back to pisosr.

compatible = "company,random_numbers_of_exact_part_actually_on_board", "pisosr";

Andrew


Yours,
Linus Walleij


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

[PATCH] HID: wacom: Fix deadlock on proximity in events with the Intuos Draw

2015-12-30 Thread Lyude

Unfortunately, when we have an Intuos Draw connected using a USB
connection, wacom's IRQ handler will be called while the lock for the
usbhid driver is held by hid_ctrl. This means when we try to schedule a
new proximity event in wacom_intuos_schedule_prox_event() by calling
hid_hw_request(), we'll try to take the lock a second time which
deadlocks the system. This patch fixes that behavior by initializing a
worker when we have a INTUOSHT2 device connected, and using that worker
to schedule the proximity event instead.

Signed-off-by: Lyude 
---
 drivers/hid/wacom_wac.c | 9 +++--
 drivers/hid/wacom_wac.h | 1 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index 01a4f05..b59ded6 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -433,8 +433,10 @@ exit:
return retval;
 }
 
-static void wacom_intuos_schedule_prox_event(struct wacom_wac *wacom_wac)
+static void wacom_intuos_schedule_prox_event(struct work_struct *work)
 {
+   struct wacom_wac *wacom_wac =
+   container_of(work, struct wacom_wac, intuos_prox_event_worker);
struct wacom *wacom = container_of(wacom_wac, struct wacom, wacom_wac);
struct hid_report *r;
struct hid_report_enum *re;
@@ -624,7 +626,7 @@ static int wacom_intuos_inout(struct wacom_wac *wacom)
/* don't report other events if we don't know the ID */
if (!wacom->id[idx]) {
/* but reschedule a read of the current tool */
-   wacom_intuos_schedule_prox_event(wacom);
+   schedule_work(&wacom->intuos_prox_event_worker);
return 1;
}
 
@@ -2675,6 +2677,9 @@ int wacom_setup_pen_input_capabilities(struct input_dev 
*input_dev,
 
if (features->type == INTUOSHT2) {
wacom_setup_basic_pro_pen(wacom_wac);
+
+   INIT_WORK(&wacom_wac->intuos_prox_event_worker,
+ wacom_intuos_schedule_prox_event);
} else {
__clear_bit(ABS_MISC, input_dev->absbit);
__set_bit(BTN_TOOL_PEN, input_dev->keybit);
diff --git a/drivers/hid/wacom_wac.h b/drivers/hid/wacom_wac.h
index 877c24a..c24cfdc 100644
--- a/drivers/hid/wacom_wac.h
+++ b/drivers/hid/wacom_wac.h
@@ -237,6 +237,7 @@ struct wacom_wac {
int ps_connected;
u8 bt_features;
u8 bt_high_speed;
+   struct work_struct intuos_prox_event_worker;
struct hid_data hid_data;
 };
 
-- 
2.5.0

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

Re: [PATCH v2] ASoC: rsnd: fix usrcnt decrementing bug

On Thu, Dec 24, 2015 at 08:02:39AM +0100, Andrzej Hajda wrote:
> Field usrcnt is unsigned so it cannot be lesser than zero.
> The patch fixes the check, moves it to the beginning of the function
> and changes return value to -EIO in case of usercnt error.

Please don't send new patches in reply to old ones, it makes it hard to
figure out what the current version of things is.


signature.asc
Description: PGP signature

Re: [PATCH] BTRFS: Runs the xor function if a Block has failed

2015-12-30 Thread David Sterba

On Wed, Dec 30, 2015 at 01:28:36AM -0500, Sanidhya Solanki wrote:
> The patch adds the xor function after the P stripe
> has failed, without bad data or the Q stripe.

That's just the comment copied, the changelog does not explain why it's
ok to do just the run_xor there. It does not seem trivial to me. Please
describe that the end result after the code change is expected.

> @@ -1864,8 +1864,8 @@ static void __raid_recover_end_io(struct btrfs_raid_bio 
> *rbio)
>   /*
>* Just the P stripe has failed, without
>* a bad data or Q stripe.
> -  * TODO, we should redo the xor here.
>*/
> + run_xor(pointers, rbio->nr_data - 1, 
> PAGE_CACHE_SIZE);
>   err = -EIO;
>   goto cleanup;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pinctrl: mediatek: convert to arch_initcall

On Tue, Dec 22, 2015 at 04:11:47PM +0100, Linus Walleij wrote:
> On Tue, Dec 22, 2015 at 2:46 PM, Daniel Kurtz  wrote:

> > Move pinctrl initialization earlier in boot so that real devices can find
> > their pctldev without probe deferring.
> (...)
> > -module_init(mtk_pinctrl_init);
> > +arch_initcall(mtk_pinctrl_init);

> So I see why you're doing this (because of wanting to avoid nasty boot
> probe deferrals, right?) and I'm going to apply it, because the work
> with probe ordering is still in the works, but I'd like some general
> ARM people to come in with opinions.

I really don't think we should be applying this sort of stuff unless
things are actively broken right now.  It's a bit of a rabbit hole we
could spend a long time going down tweaking things for different
systems in the same way that tweaking the link order can be and it masks
the underlying issues.

signature.asc
Description: PGP signature

Re: [PATCH v3 3/5] iio: health: Add driver for the TI AFE4404 heart monitor


On 12/22/2015 11:37 AM, Jonathan Cameron wrote:

On 14/12/15 22:35, Andrew F. Davis wrote:

Add driver for the TI AFE4404 heart rate monitor and pulse oximeter.
This device detects reflected LED light fluctuations and presents an ADC
value to the user space for further signal processing.

Datasheet: http://www.ti.com/product/AFE4404/datasheet

Signed-off-by: Andrew F. Davis 

Hi Andrew,

Sorry I didn't get to this a the weekend. We are now likely to just
miss the merge window so lets get this cleaned up and ready to go
for the start of the next cycle (probably 3rd week of January)



No problem, I've been on holiday these last few days anyway.


Looking good mostly.  A few minor bits and bobs I either missed before
or that got introduced as side effects of your changes.
I thought about fixing them up and applying, but I think it's just
a shade to many changes and I need your feedback on a couple of them
anyway.

Jonathan


---
  .../ABI/testing/sysfs-bus-iio-health-afe4404   |  60 ++
  drivers/iio/Kconfig|   1 +
  drivers/iio/Makefile   |   1 +
  drivers/iio/health/Kconfig |  25 +
  drivers/iio/health/Makefile|   6 +
  drivers/iio/health/afe4404.c   | 700 +
  drivers/iio/health/afe440x.h   | 202 ++
  7 files changed, 995 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
  create mode 100644 drivers/iio/health/Kconfig
  create mode 100644 drivers/iio/health/Makefile
  create mode 100644 drivers/iio/health/afe4404.c
  create mode 100644 drivers/iio/health/afe440x.h

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404 
b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
new file mode 100644
index 000..b01ca47
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4404
@@ -0,0 +1,60 @@
+What:  /sys/bus/iio/devices/iio:deviceX/tia_resistanceY
+   /sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get and set the resistance and the capacitance settings for the
+   Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
+   Rf2 and Cf2 values.
+   Valid Resistance settings are 50, 25, 10, 5,
+   25000, 1, 100, and 200 Ohms.
+   Valid capacitance settings are 5, 2.5, 10, 7.5, 20, 17.5, 25,
+   and 22.5 picoFarads.

Defined units for IIO are nanofarads - see sysfs-bus-iio.
Would really like to keep this consistent and doesn't look like that should
be terribly hard to do here.



Ah, for some reason I thought pico, will fix.


+
+What:  /sys/bus/iio/devices/iio:deviceX/tia_separate_en
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Enable or disable separate settings for the TransImpedance
+   Amplifier above, when disabled both values are set by the
+   first channel.
+
+What:  /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
+   /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get measured values from the ADC for these stages. Y is the
+   specific LED number. The values are expressed in 24-bit twos
+   complement.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get differential values from the ADC for these stages. Y is the
+   specific LED number. The values are expressed in 24-bit twos
+   complement for the specified LEDs.
+
+What:  /sys/bus/iio/devices/iio:deviceX/out_current_ledY_offset
+   /sys/bus/iio/devices/iio:deviceX/out_current_ledY_ambient_offset
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get and set the offset cancellation DAC setting for these
+   stages. The values are expressed in 5-bit sign–magnitude.
+
+What:  /sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get and set the LED current for the specified LED. Y is the
+   specific LED number.
+   Values range from 0 -> 63. Current is calculated by
+   current = value * 0.8mA

Otherwise, we both know that the ABI is less than ideal, but it's probably
the best solution we can easily manage so lets go with this.
While it's not easy to revise this in future it can be done should we
end up

Re: [Bugfix v2 4/5] x86/irq: Fix a race condition between vector assigning and cleanup

On Wed, 23 Dec 2015, Jiang Liu wrote:
>  static void clear_irq_vector(int irq, struct apic_chip_data *data)
>  {
> - struct irq_desc *desc;
> + struct irq_desc *desc = irq_to_desc(irq);
>   int cpu, vector = data->cfg.vector;
>  
>   BUG_ON(!vector);
> @@ -236,10 +235,6 @@ static void clear_irq_vector(int irq, struct 
> apic_chip_data *data)
>   data->cfg.vector = 0;
>   cpumask_clear(data->domain);
>  
> - if (likely(!data->move_in_progress))
> - return;

Why are you removing this?

> -
> - desc = irq_to_desc(irq);
>   for_each_cpu_and(cpu, data->old_domain, cpu_online_mask) {
>   for (vector = FIRST_EXTERNAL_VECTOR; vector < NR_VECTORS;
>vector++) {
> @@ -421,10 +416,13 @@ static void __setup_vector_irq(int cpu)
>   struct irq_data *idata = irq_desc_get_irq_data(desc);
>  
>   data = apic_chip_data(idata);
> - if (!data || !cpumask_test_cpu(cpu, data->domain))
> - continue;
> - vector = data->cfg.vector;
> - per_cpu(vector_irq, cpu)[vector] = desc;
> + if (data) {
> + cpumask_clear_cpu(cpu, data->old_domain);

Why would the newly online cpu be in data->old_domain?

> + if (cpumask_test_cpu(cpu, data->domain)) {
> + vector = data->cfg.vector;
> + per_cpu(vector_irq, cpu)[vector] = desc;
> + }
> + }
> @@ -563,14 +558,10 @@ asmlinkage __visible void 
> smp_irq_move_cleanup_interrupt(void)
>   goto unlock;
>  
>   /*
> -  * Check if the irq migration is in progress. If so, we
> -  * haven't received the cleanup request yet for this irq.
> +  * Nothing to cleanup if this cpu is not set
> +  * in the old_domain mask.
>*/
> - if (data->move_in_progress)
> - goto unlock;

Removing this is broken. If data->move_in_progress is set, then you cannot
clear the vector. If there are two interrupt moves pending then the IPI of the
first one will clear the second one as well, which might be still targeted to
this cpu.

This whole patch set is way too complex. A lot of tiny changes here and there
and none of them is documented.

Thanks,

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

Re: [PATCH v6 13/20] arm64: ilp32: share aarch32 syscall wrappers to ilp32

2015-12-30 Thread Yury Norov

On Wed, Dec 23, 2015 at 09:41:54PM +0100, Arnd Bergmann wrote:
> On Wednesday 23 December 2015, Catalin Marinas wrote:
> > > That means we have to set ARCH_PACK_STATFS64 in the arm64 header files
> > > though, and propagate the OABI alignment to arm64/ilp32 as well, rather
> > > than using the 88-byte version that every other 32-bit architecture
> > > except for x86-32 and arm32 has.
> > 
> > Yuri replied that for EABI glibc, sizeof(struct statfs64) is already 88.
> > If that's correct and the packing attribute is ignored by glibc, we
> > could drop ARCH_PACK_COMPAT_STATFS64 as well (OABI not supported by
> > arm64). But I would be slightly worried since glibc is not the only user
> > of the kernel ABI.
> 
> It looks like glibc has its own definition of 'struct statfs64', which
> is incompatible with the one in the kernel headers for ARM EABI.
> 
> However, there are other libc implementations besides glibc, and we
> can't assume that they all do it the same way, so we clearly have to
> keep using the wrapper for ARM EABI. For ARM64/ILP32, we are probably
> better off defining it the same way in kernel and libc without that
> wrapper.
> 
> > For ILP32, I think we can skip defining ARCH_PACK_STATFS64 (of course,
> > only if __ILP32__) and state that sizeof(struct statfs64) is 88
> > (unpacked). In which case we need the wrappers above to be able to reuse
> > the compat_sys_statfs64 code.
> > 
> > > Another option would be to set "#define __statfs_word __u64" and use
> > > the 64-bit statfs call, instead of compat_sys_statfs64, but that in turn
> > > requires special-casing statfs in libc.
> > 
> > I wouldn't go this route as we kind of agreed that ILP32 should look
> > like any other 32-bit ABI.
> 
> It's really tricky then: in order to support EABI binaries from a libc
> that uses the kernel headers with the OABI compatible definition, we
> must not copy the 88 byte structure to user space, because that would
> overwrite user space stack data, and that in turn means we have to set
> ARCH_PACK_COMPAT_STATFS64, but that in turn prevents us from using the
> generic 32-bit syscall ABI for the arm64/ilp32 fstatfs64 call. 
> 
> It seems that today, put_compat_statfs64() doesn't actually use
> the size argument, and it just copies the individual fields, which
> is fine either way. This means we could turn around the logic
> in the arm32 wrapper, remove ARCH_PACK_COMPAT_STATFS64, and make
> the ilp32 code call directly into compat_sys_fstatfs64(), but it
> would be a bit fragile, as we rely on put_compat_statfs64() not
> actually writing the padding fields that the native do_statfs64()
> writes. If someone changed them to both use copy_to_user, we'd
> silently introduce data corruption on rarely used libc implementations.
> 
>   Arnd

So. For ilp32, the only wrapper left here, is compat_sys_mmap2_wrapper.
But this is workaroud, as comment tells:
Note: off_4k (w5) is always in units of 4K. If we can't do the
requested offset because it is not page-aligned, we return -EINVAL.

Not sure we should pull it to ILP32. If so, we can call sys_mmap_pgoff()
directly. And we don't need this patch at all therefore. Any throughts?

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

[tip:irq/core] irqchip/zevio: Use irq_data_get_chip_type() helper

2015-12-30 Thread tip-bot for Geliang Tang

Commit-ID:  1fd9a71076ccbcf731cf02408122600a6f2b5d17
Gitweb: http://git.kernel.org/tip/1fd9a71076ccbcf731cf02408122600a6f2b5d17
Author: Geliang Tang 
AuthorDate: Wed, 30 Dec 2015 22:16:37 +0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 30 Dec 2015 18:29:02 +0100

irqchip/zevio: Use irq_data_get_chip_type() helper

Use irq_data_get_chip_type() instead of container_of().

Signed-off-by: Geliang Tang 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Link: 
http://lkml.kernel.org/r/4cc3a3a7a74c7a1894892a85aa7eabbd1534fe96.1451484758.git.geliangt...@163.com
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/irq-zevio.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-zevio.c b/drivers/irqchip/irq-zevio.c
index 4c48fa8..cb9d8ec 100644
--- a/drivers/irqchip/irq-zevio.c
+++ b/drivers/irqchip/irq-zevio.c
@@ -43,8 +43,7 @@ static void __iomem *zevio_irq_io;
 static void zevio_irq_ack(struct irq_data *irqd)
 {
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(irqd);
-   struct irq_chip_regs *regs =
-   &container_of(irqd->chip, struct irq_chip_type, chip)->regs;
+   struct irq_chip_regs *regs = &irq_data_get_chip_type(irqd)->regs;
 
readl(gc->reg_base + regs->ack);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/5] iio: health: Add driver for the TI AFE4403 heart monitor


On 12/22/2015 11:59 AM, Jonathan Cameron wrote:

On 14/12/15 22:36, Andrew F. Davis wrote:

Add driver for the TI AFE4403 heart rate monitor and pulse oximeter.
This device detects reflected LED light fluctuations and presents an ADC
value to the user space for further signal processing.

Data sheet located here:
http://www.ti.com/product/AFE4403/datasheet

Signed-off-by: Andrew F. Davis 

I assume the plan is to break some of this out into a common shared
'helper' module for the two drivers?   You will probably want
to do that before we merge either of them.  Again, doesn't look like
it will be a big job as you just have cut and paste functions in
here (I think!)



Yeah, that's the plan.

To make review easier I was going to just get everything fixed and
upstreamed in the one, then the next patch could be a more trivial
addition adding the other part. Otherwise every problem in one
would need fixed in both.


I also picked up on a lack of locking around read update pairs
that I'd missed in reviewing the 4404 driver. Please fix it there
as well.



Will do.


Otherwise a few spi specific bits inline and as you expect
the comments from one driver mostly apply to the other as well
(in both directions!)

---
  .../ABI/testing/sysfs-bus-iio-health-afe4403   |  52 ++
  drivers/iio/health/Kconfig |  12 +
  drivers/iio/health/Makefile|   1 +
  drivers/iio/health/afe4403.c   | 696 +
  4 files changed, 761 insertions(+)
  create mode 100644 Documentation/ABI/testing/sysfs-bus-iio-health-afe4403
  create mode 100644 drivers/iio/health/afe4403.c

diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe4403 
b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4403
new file mode 100644
index 000..325efcb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe4403
@@ -0,0 +1,52 @@
+What:  /sys/bus/iio/devices/iio:deviceX/tia_resistanceY
+   /sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get and set the resistance and the capacitance settings for the
+   Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
+   Rf2 and Cf2 values.
+   Valid Resistance settings are 50, 25, 10, 5,
+   25000, 1, 100, and 0 Ohms.
+   Valid capacitance settings are 5, 10, 20, 25, 30, 35, 45, 50, 
55,
+   60, 70, 75, 80, 85, 95, 100, 155, 160, 170, 175, 180, 185, 195,
+   200, 205, 210, 220, 225, 230, 235, 245, and 250 picoFarads.

Given we have two devices with very similar ABI up to the values, I'd
suggest providing *_available attributes so these can be queried from
userspace and you can create a single ABI document covering the two drivers.


Will add.


+
+What:  /sys/bus/iio/devices/iio:deviceX/tia_separate_en
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Enable or disable separate settings for the TransImpedance
+   Amplifier above, when disabled both values are set by the
+   first channel.
+
+What:  /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
+   /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get measured values from the ADC for these stages. Y is the
+   specific LED number. The values are expressed in 24-bit twos
+   complement.
+
+What:  
/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get differential values from the ADC for these stages. Y is the
+   specific LED number. The values are expressed in 24-bit twos
+   complement for the specified LEDs.
+
+What:  /sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
+Date:  December 2015
+KernelVersion:
+Contact:   Andrew F. Davis 
+Description:
+   Get and set the LED current for the specified LED. Y is the
+   specific LED number.
+   Values range from 0 -> 255. Current is calculated by
+   current = (value / 256) * 50mA

This level of detail is exposed anyway in the userspace interface, so I
would not expect it to be explicitly mentioned here.  Without this I 'think'
we can combine this with the docs for the afe4404.



Makes sense. The afe4404 will have an extra couple channels in this doc
eventually but we can deal with that when they are added.

[...]


+static ssize_t afe440x_store_register(struct device *dev,
+ struct device_attribute *attr,
+ const ch

Re: [PATCH RESEND] iwlwifi:Fix error handling in the function iwl_pcie_enqueue_hcmd

2015-12-30 Thread Grumbach, Emmanuel

Hi,


On 12/30/2015 07:15 PM, Nicholas Krause wrote:
> This fixes error handling in the function iwl_pcie_enqueue_hcmd
> by checking if all calls to the function wl_pcie_txq_build_tfd
> have failed by returning a error code and if so jump to the goto
> label out from the cleaning up of acquired resources before


For sure you haven't ran your code otherwise you would have noticed it
break pretty much everything.
Moreover this patch is not based on my -next tree.
Simple rebasing won't fix the obvious issues in your patch though.

> Signed-off-by: Nicholas Krause 
> ---
>  drivers/net/wireless/iwlwifi/pcie/tx.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/iwlwifi/pcie/tx.c 
> b/drivers/net/wireless/iwlwifi/pcie/tx.c
> index 2b86c21..49c8c77 100644
> --- a/drivers/net/wireless/iwlwifi/pcie/tx.c
> +++ b/drivers/net/wireless/iwlwifi/pcie/tx.c
> @@ -1472,9 +1472,11 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans 
> *trans,
>   /* start the TFD with the scratchbuf */
>   scratch_size = min_t(int, copy_size, IWL_HCMD_SCRATCHBUF_SIZE);
>   memcpy(&txq->scratchbufs[q->write_ptr], &out_cmd->hdr, scratch_size);
> - iwl_pcie_txq_build_tfd(trans, txq,
> -iwl_pcie_get_scratchbuf_dma(txq, q->write_ptr),
> -scratch_size, true);
> + idx = iwl_pcie_txq_build_tfd(trans, txq,
> +  iwl_pcie_get_scratchbuf_dma(txq, 
> q->write_ptr),
> +  scratch_size, true);
> + if (idx)
> + goto out;
>  
>   /* map first command fragment, if any remains */
>   if (copy_size > scratch_size) {
> @@ -1489,8 +1491,9 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans 
> *trans,
>   goto out;
>   }
>  
> - iwl_pcie_txq_build_tfd(trans, txq, phys_addr,
> -copy_size - scratch_size, false);
> + idx = iwl_pcie_txq_build_tfd(trans, txq, phys_addr, copy_size - 
> scratch_size, false);
> + if (idx)
> + goto out;
>   }
>  
>   /* map the remaining (adjusted) nocopy/dup fragments */
> @@ -1513,7 +1516,9 @@ static int iwl_pcie_enqueue_hcmd(struct iwl_trans 
> *trans,
>   goto out;
>   }
>  
> - iwl_pcie_txq_build_tfd(trans, txq, phys_addr, cmdlen[i], false);
> + idx = iwl_pcie_txq_build_tfd(trans, txq, phys_addr, cmdlen[i], 
> false);
> + if (idx)
> + goto out;
>   }
>  
>   out_meta->flags = cmd->flags;
> @@ -1830,8 +1835,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct 
> sk_buff *skb,
>   /* The first TB points to the scratchbuf data - min_copy bytes */
>   memcpy(&txq->scratchbufs[q->write_ptr], &dev_cmd->hdr,
>  IWL_HCMD_SCRATCHBUF_SIZE);
> - iwl_pcie_txq_build_tfd(trans, txq, tb0_phys,
> -IWL_HCMD_SCRATCHBUF_SIZE, true);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb0_phys, 
> IWL_HCMD_SCRATCHBUF_SIZE, true))
> + goto out_err;
>  
>   /* there must be data left over for TB1 or this code must be changed */
>   BUILD_BUG_ON(sizeof(struct iwl_tx_cmd) < IWL_HCMD_SCRATCHBUF_SIZE);
> @@ -1841,7 +1846,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct 
> sk_buff *skb,
>   tb1_phys = dma_map_single(trans->dev, tb1_addr, tb1_len, DMA_TO_DEVICE);
>   if (unlikely(dma_mapping_error(trans->dev, tb1_phys)))
>   goto out_err;
> - iwl_pcie_txq_build_tfd(trans, txq, tb1_phys, tb1_len, false);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb1_phys, tb1_len, false))
> + goto out_err;
>  
>   /*
>* Set up TFD's third entry to point directly to remainder
> @@ -1857,7 +1863,8 @@ int iwl_trans_pcie_tx(struct iwl_trans *trans, struct 
> sk_buff *skb,
>  &txq->tfds[q->write_ptr]);
>   goto out_err;
>   }
> - iwl_pcie_txq_build_tfd(trans, txq, tb2_phys, tb2_len, false);
> + if (iwl_pcie_txq_build_tfd(trans, txq, tb2_phys, tb2_len, 
> false))
> + goto out_err;
>   }
>  
>   /* Set up entry for this TFD in Tx byte-count array */

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

Re: RCU stall and the system boot hang with nfsroot

2015-12-30 Thread Paul E. McKenney

On Wed, Dec 30, 2015 at 03:03:33PM +0800, Aaron Ma wrote:
> On Wed, Dec 30, 2015 at 7:42 AM, Paul E. McKenney
>  wrote:
> > On Tue, Dec 29, 2015 at 05:34:38PM +0800, Aaron Ma wrote:
> >> Add paul...@linux.vnet.ibm.com
> >>
> >> On Tue, Dec 29, 2015 at 5:32 PM, Aaron Ma  wrote:
> >> > Hi, Paul:
> >> > I found the linux-stable-4.1.15 with rt15 patches boot hang sometimes.
> >> > Hardware is Grantley-EP and WildcatPass.
> >
> > I must confess that I am unfamiliar with this hardware, for whatever
> > that might be worth.
> >
> >> > No response by sysrq.
> >> >
> >> > Did you found any issue about this? Or how can I address this issue?
> >
> > I see something similar in post-4.1 mainline, but only when CPU hotplug
> > is enabled and only under extreme stress.  Which is probably not the
> > case during your boot-up.  But please see below.
> >
> >> > Attached kernel config.
> >> >
> >> > Thanks,
> >> > Pengyu
> >> >
> >> > xhci_hcd :00:14.0: cache line size of 32 is not supported
> >> > hub 1-0:1.0: USB hub found
> >> > hub 1-0:1.0: 15 ports detected
> >> > xhci_hcd :00:14.0: xHCI Host Controller
> >> > xhci_hcd :00:14.0: new USB bus registered, assigned bus number 2
> >> > hub 2-0:1.0: USB hub found
> >> > hub 2-0:1.0: 6 ports detected
> >> > initcall xhci_pci_init+0x0/0x44 returned 0 after 306571 usecs
> >> > calling  ehci_hcd_init+0x0/0x5d @ 1
> >> > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> >> > initcall ehci_hcd_init+0x0/0x5d returned 0 after 5695 usecs
> >> > calling  ehci_pci_init+0x0/0x69 @ 1
> >> > ehci-pci: EHCI PCI platform driver
> >> > ehci-pci :00:1a.0: enabling bus mastering
> >> > ehci-pci :00:1a.0: EHCI Host Controller
> >> > ehci-pci :00:1a.0: new USB bus registered, assigned bus number 3
> >> > ehci-pci :00:1a.0: debug port 2
> >> > ehci-pci :00:1a.0: cache line size of 32 is not supported
> >> > ehci-pci :00:1a.0: irq 18, io mem 0x91d02000
> >> > cfg80211: Calling CRDA to update world regulatory domain
> >> > cfg80211: Calling CRDA to update world regulatory domain
> >> > cfg80211: Calling CRDA to update world regulatory domain
> >> > cfg80211: Calling CRDA to update world regulatory domain
> >> > cfg80211: Calling CRDA to update world regulatory domain
> >> > cfg80211: Calling CRDA to update world regulatory domain
> >> > cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
> >> > INFO: rcu_preempt detected stalls on CPUs/tasks:
> >> > 18: (0 ticks this GP) idle=284/0/0 softirq=0/0 fqs=0
> >
> > The "stalling" CPU is idle, which is a quiescent state and therefore
> > should not stall grace periods.  But please see below...
> >
> >> > (detected by 12, t=26002 jiffies, g=5351, c=5350, q=451332)
> >> > Task dump for CPU 18:
> >> > swapper/18  R  running task0 0  1 0x0020
> >> >  814946a7 88045fbc7e58 814f42f7 0004
> >> >  0004 8804663e0f60 820dc5c0 88045fbc7ea8
> >> >  8181fca5   0046
> >> > Call Trace:
> >> >  [] ? debug_smp_processor_id+0x17/0x20
> >> >  [] ? intel_idle+0x137/0x140
> >> >  [] ? cpuidle_enter_state+0x65/0x3e0
> >> >  [] ? cpuidle_enter+0x17/0x20
> >> >  [] ? cpu_startup_entry+0x33d/0x630
> >> >  [] ? start_secondary+0x12e/0x140
> >> > rcu_preempt kthread starved for 26002 jiffies!
> >
> > The reason that the idle CPU is not being recognized as a legitimate
> > quiescent state is that the rcu_preempt grace-period kthread is not
> > being allowed to run.  In fact, it has not been permitted to run for more
> > than 26 seconds.  Despite the fact that in this situation, it would have
> > invoked wait_event_interruptible_timeout() with a three-jiffy timeout.
> >
> > One thing to do is to modify the rcu_check_gp_kthread_starvation()
> > function to print the value of rsp->gp_kthread, then to also print
> > fields from the resulting pointer to task_struct to see what the thread
> > is up to.  (It is tempting to suspect that this kthread might never have
> > been spawned, but in that case the grace period would not have started.)
> >
> > For example, add the following in the "if (j - gpa > 2 * HZ)"
> > body:
> >
> > if (rsp->gp_kthread)
> > sched_show_task(rsp->gp_kthread);
> >
> > Don't forget to add the "{" "}" to accommodate the additional statement
> > within the "if" statement.
> >
> > If the additional output shows that the rcu_preempt kthread is runnable,
> > the next question is "why is it not running?".  If the output instead
> > shows that the task is blocked, the next question is "why didn't the
> > wait_event_interruptible_timeout() awaken it?
> >
> > Thanx, Paul
> 
> Add sched_show_task to show the current task on stalled CPU:
> 
> calling  efi_load_efivars+0x0/0x40 @ 1
> initcall efi_load_efivars+0x0/0x40 returned 0 after 0 usecs
> calling  esrt_sysfs_init+0x0/0x2d6 @ 1
> initcall esrt_sysfs_

Re: [PATCH] gpio: Add driver for TI TPIC2810


On 12/23/2015 05:29 PM, Linus Walleij wrote:

On Tue, Dec 15, 2015 at 9:10 PM, Andrew F. Davis  wrote:


Add driver for TI TPIC2810 8-Bit LED Driver with I2C Interface.

The TPIC2810 has 8 open-drain outputs that can but used to drive
LEDs and other low-side switched resistive loads.

Signed-off-by: Andrew F. Davis 


This patch will have to be rebased to apply and compile after the release
of kernel v4.5-rc1, as we have too much lined up right now, I see no
big problems
with it but here are some more minor comments.



Works for me.


  +static inline struct tpic2810 *to_tpic2810(struct gpio_chip *chip)

+{
+   return container_of(chip, struct tpic2810, chip);
+}


We are getting rid of this design pattern, check the gpiochip_get_data()
function that will be introduced in v4.5-rc1 and patches I merge to all
other drivers.



ACK


+static const struct i2c_device_id tpic2810_id_table[] = {
+   { "tpic2810", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, tpic2810_id_table);
+
+static struct i2c_driver tpic2810_driver = {
+   .driver = {
+   .name = "tpic2810",
+   },
+   .probe = tpic2810_probe,
+   .remove = tpic2810_remove,
+   .id_table = tpic2810_id_table,
+};
+module_i2c_driver(tpic2810_driver);


No device tree probing? Which platform uses this?
I was expecting an .of_match_table()  in .driver.



As far as I know .of_match_table and MODULE_ALIAS for
DT have no real effect on I2C devices as they match
on "anything,i2c_name". And only throw an I2C
MODALIAS to userspace for loading. So we can use
this device in a DTS without any driver modifications.

At least it worked like this on my test platform
(am57xx-evm).

I think it might be best to keep drivers DT agnostic
when possible, in case DT is superseded by something,
so we don't end up with mountains of dead code.

Thanks,
Andrew


Yours,
Linus Walleij


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

Re: [PATCH 4/4] soc: mediatek: Add MT2701/MT7623 scpsys driver




On 30/12/15 11:18, James Liao wrote:

Hi Daniel,

On Wed, 2015-12-30 at 17:01 +0800, Daniel Kurtz wrote:

On Wed, Dec 30, 2015 at 2:41 PM, James Liao  wrote:


From: Shunli Wang 

Add scpsys driver for MT2701 and MT7623.

Signed-off-by: Shunli Wang 
Signed-off-by: James Liao 
---
  drivers/soc/mediatek/Kconfig |  11 +++
  drivers/soc/mediatek/Makefile|   1 +
  drivers/soc/mediatek/mtk-scpsys-mt2701.c | 161 +++
  3 files changed, 173 insertions(+)
  create mode 100644 drivers/soc/mediatek/mtk-scpsys-mt2701.c

diff --git a/drivers/soc/mediatek/Kconfig b/drivers/soc/mediatek/Kconfig
index eca6fb7..92cf838 100644
--- a/drivers/soc/mediatek/Kconfig
+++ b/drivers/soc/mediatek/Kconfig
@@ -39,3 +39,14 @@ config MTK_SCPSYS_MT8173
   driver.
   The System Control Processor System (SCPSYS) has several power
   management related tasks in the system.
+
+config MTK_SCPSYS_MT2701
+   bool "SCPSYS Support MediaTek MT2701 and MT7623"
+   depends on ARCH_MEDIATEK || COMPILE_TEST
+   select MTK_SCPSYS
+   default ARCH_MEDIATEK
+   help
+ Say yes here to add support for the MT2701/MT7623 SCPSYS power
+ domain driver.
+ The System Control Processor System (SCPSYS) has several power
+ management related tasks in the system.


I don't think we really want different drivers and Kconfig options.

Can we just use different compatibles to select the appropriate scp_domain_data?


Yes, we can. All scpsys drivers are built-in by default, and they will
be activate by specific compatible string.

But some projects don't want to build unused drivers into kernel to save
code size. Use different Kconfig options for each SoC so that these
projects can disable unused drivers.



Scpsys is a bool right now, you can disable it if you don't need it for 
your project.


I don't think the impact of adding scp_domain_data justifies adding SoC 
specific scpsys drivers and bloat the drivers/soc/mediatek folder.


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

Re: [PATCH 07/34] sparc: reuse asm-generic/barrier.h

2015-12-30 Thread David Miller


I find it a little bit irritating when I receive a patch directly
addressed to me to review, but I don't see the "00/34" cover letter.

I want to see what this series is about, and what the motiviation
for this change is.

I'm also highly frustrated, in general, with mix-and-match CC: lists
for patch series.  Just put everyone relevant in the CC: for the
entire series.  That way I can easily inspect other parts of the
series to see infrastructure buildup, and examples of other
conversions or versions of the change.

Thanks.

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

Re: Re: [PATCH] regmap: flat: introduce register striding to save somememories

On Fri, Dec 18, 2015 at 04:59:38PM +0800, lixi...@cmss.chinamobile.com wrote:

> > I think we'll need to continue supporting non power of two strides so
> > an unconditional conversion to shifts might be an issue - some weird DSP
> > probably does that.

> Yes, agreed. 

> IMO this won't happen to MMIO, and for the device using MMIO the
> register strides should equal to power of two. 

> Are there some cases I have met? 

DSPs exposed via I2C and SPI are the main things I'm worried about.
It's fairly common for DSPs to have unusual word sizes including things
like three bytes.


signature.asc
Description: PGP signature

Re: [PULL] Re: bcache stability patches

2015-12-30 Thread Jens Axboe


On 12/29/2015 08:00 PM, Eric Wheeler wrote:

Hi Jens and Kent,

This affects many users, so please take a look when you have a moment:

There is a growing bcache user community with a well-tested patchset that
is necessary for production bcache use.  The diffstat is small and we all
want someone to pull it in and get it into mainline.  This would serve
many people if this can get pulled in upstream.

More below:

On Tue, 22 Dec 2015, Denis Bychkov wrote:

There is a set of bcache stability patches elevating bcache stability to
production level. As far as I know, there is no single reported and peer
confirmed bug that is not solved by this set. Unfortunately, for some
reason, Kent does not have enough time and/or energy to review them and
send them upstream. Let's come up with a solution that would allow to
review all these patches (some of them written by Ken himself, some of
them produced by the community), review them and hand them to the
maintainer who is willing to apply them upstream. Without that, bcache
is just another half-assed unstable and buggy cache layer. These patches
will allow people to start use bcache in production systems. Please find
the patch set attached. (The patches apply cleanly to 4.3 and 4.4 kernel
series).


Hi Dennis,

I'm maintaining a branch here that is ready to merge.  We have been
testing this for about a year in production and works great.  All Cc's and
authors are correct and it (should) have every stability patch below,
possibly others too.  Please tell me if there are any patches missing:

git pull https://github.com/ewheelerinc/linux.git bcache-patches-for-3.17
(Yes, github for hosting only, I don't edit with their web interfaces.)

Note that this branch still merges cleanly through v4.4-rc7 and as far
back as 3.17-rc1 (maybe earlier).  Each patch provides Cc: 
sta...@vger.kernel.org.

It is ready to merge!  We just need Jens or Kent or someone to pull it in.
Here is the diffstat and shortlog against v4.4-rc7:

  drivers/md/bcache/btree.c |  5 -
  drivers/md/bcache/super.c | 16 
  drivers/md/bcache/writeback.c | 37 ++---
  drivers/md/bcache/writeback.h |  3 ++-
  4 files changed, 48 insertions(+), 13 deletions(-)

Al Viro (1):
   bcache: fix a leak in bch_cached_dev_run()

Gabriel de Perthuis (1):
   bcache: allows use of register in udev to avoid "device_busy" error.

Kent Overstreet (2):
   bcache: Add a cond_resched() call to gc
   bcache: Change refill_dirty() to always scan entire disk if
necessary

Stefan Bader (1):
   bcache: prevent crash on changing writeback_running

Zheng Liu (3):
   bcache: fix a livelock when we cause a huge number of cache misses
   bcache: clear BCACHE_DEV_UNLINK_DONE flag when attaching a backing device
   bcache: unregister reboot notifier if bcache fails to unregister device


Looking over these, most are really simple one-liners, and nothing 
sticks out as being overly complicated. Kent, do you have any plans to 
maintain the in-kernel bcache?


If I don't hear otherwise, I'll pull these in for 4.5.

--
Jens Axboe

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

Re: [PATCH] soc: mediatek: PMIC wrap: Clear the vldclr if state machine is stay on FSM_VLDCLR state.




On 22/12/15 08:51, Henry Chen wrote:

Sometimes PMIC is too busy to send data in time to cause pmic wrap timeout,
because pmic wrap is waiting for FSM_VLDCLR after finishing WACS2_CMD. It
just return error when issue happened, so the state machine will stay on
FSM_VLDCLR state when data send back later by PMIC and timeout again in next
time because pmic wrap waiting for FSM_IDLE state at the begining of the
read/write function.

Clear the vldclr when timeout if state machine is stay on FSM_VLDCLR.

Signed-off-by: Henry Chen 
---
  drivers/soc/mediatek/mtk-pmic-wrap.c | 16 ++--
  1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
b/drivers/soc/mediatek/mtk-pmic-wrap.c
index 105597a..ccd5337 100644
--- a/drivers/soc/mediatek/mtk-pmic-wrap.c
+++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
@@ -443,10 +443,16 @@ static int pwrap_wait_for_state(struct pmic_wrapper *wrp,
  static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, u32 wdata)
  {
int ret;
+   u32 val;

ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
-   if (ret)
+   if (ret) {
+   /* Clear vldclr bit if state is on the WACS_FSM_WFVLDCLR */
+   val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+   if (PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR)
+   pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
return ret;
+   }


I would prefer to have this encapsulated in a (inline) function. Maybe 
with better description then just the one line comment.


Thanks,
Matthias



pwrap_writel(wrp, (1 << 31) | ((adr >> 1) << 16) | wdata,
PWRAP_WACS2_CMD);
@@ -457,10 +463,16 @@ static int pwrap_write(struct pmic_wrapper *wrp, u32 adr, 
u32 wdata)
  static int pwrap_read(struct pmic_wrapper *wrp, u32 adr, u32 *rdata)
  {
int ret;
+   u32 val;

ret = pwrap_wait_for_state(wrp, pwrap_is_fsm_idle);
-   if (ret)
+   if (ret) {
+   /* Clear vldclr bit if state is on the WACS_FSM_WFVLDCLR */
+   val = pwrap_readl(wrp, PWRAP_WACS2_RDATA);
+   if (PWRAP_GET_WACS_FSM(val) == PWRAP_WACS_FSM_WFVLDCLR)
+   pwrap_writel(wrp, 1, PWRAP_WACS2_VLDCLR);
return ret;
+   }

pwrap_writel(wrp, (adr >> 1) << 16, PWRAP_WACS2_CMD);



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

Re: [PATCH] f2fs: introduce F2FS_MAX_BLOCKS

2015-12-30 Thread Jaegeuk Kim

Hi Chao,

On Wed, Dec 30, 2015 at 02:47:29PM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Wednesday, December 30, 2015 9:14 AM
> > To: Chao Yu
> > Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH] f2fs: introduce F2FS_MAX_BLOCKS
> > 
> > Hi Chao,
> > 
> > On Tue, Dec 29, 2015 at 05:48:04PM +0800, Chao Yu wrote:
> > > Introduce a macro named F2FS_MAX_BLOCKS to indicate maximum block index
> > > in f2fs, it could be used to avoid unneeded calculation in runtime.
> > 
> > It's not so different from previous one.
> 
> Yes, just save some time of calculation in max_file_size if it is
> used in bmap frequently.
> 
> > 
> > How about adding something like:
> > 
> > static loff_t max_file_size(unsigned bits)
> 
> @bits will no longer be used, how about remove this parameter?
> 
> > {
> > }
> > 
> > ...
> > 
> > sbi->max_file_blocks = max_file_size(0);
> 
> If max_file_size return max block index of file, how about rename it to
> max_file_blocks() for readability?

Fairly agreed.

Thanks,

> 
> Thanks,
> 
> > sb->max_file_size =
> > sbi->max_file_blocks << le32_to_cpu(raw_super->log_blocksize);
> > 
> > ...
> > 
> > Thanks,
> > 
> > >
> > > Signed-off-by: Chao Yu 
> > > ---
> > >  fs/f2fs/data.c  |  2 +-
> > >  fs/f2fs/f2fs.h  |  1 -
> > >  fs/f2fs/super.c | 19 ++-
> > >  include/linux/f2fs_fs.h |  5 +
> > >  4 files changed, 8 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > > index 7175d33..a366a4c 100644
> > > --- a/fs/f2fs/data.c
> > > +++ b/fs/f2fs/data.c
> > > @@ -762,7 +762,7 @@ static int get_data_block_bmap(struct inode *inode, 
> > > sector_t iblock,
> > >   struct buffer_head *bh_result, int create)
> > >  {
> > >   /* Block number less than F2FS MAX BLOCKS */
> > > - if (unlikely(iblock > max_file_size(0)))
> > > + if (unlikely(iblock > F2FS_MAX_BLOCKS))
> > >   return -EFBIG;
> > >
> > >   return __get_data_block(inode, iblock, bh_result, create,
> > > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > > index 9ba6a09..95c6f38 100644
> > > --- a/fs/f2fs/f2fs.h
> > > +++ b/fs/f2fs/f2fs.h
> > > @@ -1731,7 +1731,6 @@ static inline int f2fs_add_link(struct dentry 
> > > *dentry, struct inode
> > *inode)
> > >   * super.c
> > >   */
> > >  int f2fs_commit_super(struct f2fs_sb_info *, bool);
> > > -loff_t max_file_size(unsigned bits);
> > >  int f2fs_sync_fs(struct super_block *, int);
> > >  extern __printf(3, 4)
> > >  void f2fs_msg(struct super_block *, const char *, const char *, ...);
> > > diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> > > index f474355..5f7e632 100644
> > > --- a/fs/f2fs/super.c
> > > +++ b/fs/f2fs/super.c
> > > @@ -909,24 +909,9 @@ static const struct export_operations 
> > > f2fs_export_ops = {
> > >   .get_parent = f2fs_get_parent,
> > >  };
> > >
> > > -loff_t max_file_size(unsigned bits)
> > > +static loff_t max_file_size(unsigned bits)
> > >  {
> > > - loff_t result = (DEF_ADDRS_PER_INODE - F2FS_INLINE_XATTR_ADDRS);
> > > - loff_t leaf_count = ADDRS_PER_BLOCK;
> > > -
> > > - /* two direct node blocks */
> > > - result += (leaf_count * 2);
> > > -
> > > - /* two indirect node blocks */
> > > - leaf_count *= NIDS_PER_BLOCK;
> > > - result += (leaf_count * 2);
> > > -
> > > - /* one double indirect node block */
> > > - leaf_count *= NIDS_PER_BLOCK;
> > > - result += leaf_count;
> > > -
> > > - result <<= bits;
> > > - return result;
> > > + return ((loff_t)F2FS_MAX_BLOCKS << bits);
> > >  }
> > >
> > >  static inline bool sanity_check_area_boundary(struct super_block *sb,
> > > diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
> > > index e59c3be..814c471 100644
> > > --- a/include/linux/f2fs_fs.h
> > > +++ b/include/linux/f2fs_fs.h
> > > @@ -189,6 +189,11 @@ struct f2fs_extent {
> > >  #define F2FS_DATA_EXIST  0x08/* file inline data exist flag 
> > > */
> > >  #define F2FS_INLINE_DOTS 0x10/* file having implicit dot dentries */
> > >
> > > +#define F2FS_MAX_BLOCKS  ((DEF_ADDRS_PER_INODE - 
> > > F2FS_INLINE_XATTR_ADDRS) + \
> > > + ADDRS_PER_BLOCK * 2 + ADDRS_PER_BLOCK * \
> > > + NIDS_PER_BLOCK * 2 + ADDRS_PER_BLOCK * \
> > > + NIDS_PER_BLOCK * NIDS_PER_BLOCK)
> > > +
> > >  #define MAX_INLINE_DATA  (sizeof(__le32) * (DEF_ADDRS_PER_INODE 
> > > - \
> > >   F2FS_INLINE_XATTR_ADDRS - 1))
> > >
> > > --
> > > 2.6.3
> > >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/69] clocksource/drivers/mtk_timer: Fix pr_warn() messages in mtk_timer_init




On 18/12/15 15:17, Daniel Lezcano wrote:

From: Alexey Klimov 

1) Change pr_warn()s to pr_err()s. These messages are actually errors and not
warnings.
2) Add missing \n.
3) Error message for kzalloc() failure is removed per suggestion by Joe Perches.
There is generic stack_dump() for allocation issues.

Signed-off-by: Alexey Klimov 
Signed-off-by: Daniel Lezcano 
---


Acked-by: Matthias Brugger 


  drivers/clocksource/mtk_timer.c | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/clocksource/mtk_timer.c b/drivers/clocksource/mtk_timer.c
index 8f99cd7..e1e0642 100644
--- a/drivers/clocksource/mtk_timer.c
+++ b/drivers/clocksource/mtk_timer.c
@@ -189,10 +189,8 @@ static void __init mtk_timer_init(struct device_node *node)
struct clk *clk;

evt = kzalloc(sizeof(*evt), GFP_KERNEL);
-   if (!evt) {
-   pr_warn("Can't allocate mtk clock event driver struct");
+   if (!evt)
return;
-   }

evt->dev.name = "mtk_tick";
evt->dev.rating = 300;
@@ -206,31 +204,31 @@ static void __init mtk_timer_init(struct device_node 
*node)

evt->gpt_base = of_io_request_and_map(node, 0, "mtk-timer");
if (IS_ERR(evt->gpt_base)) {
-   pr_warn("Can't get resource\n");
+   pr_err("Can't get resource\n");
return;
}

evt->dev.irq = irq_of_parse_and_map(node, 0);
if (evt->dev.irq <= 0) {
-   pr_warn("Can't parse IRQ");
+   pr_err("Can't parse IRQ\n");
goto err_mem;
}

clk = of_clk_get(node, 0);
if (IS_ERR(clk)) {
-   pr_warn("Can't get timer clock");
+   pr_err("Can't get timer clock\n");
goto err_irq;
}

if (clk_prepare_enable(clk)) {
-   pr_warn("Can't prepare clock");
+   pr_err("Can't prepare clock\n");
goto err_clk_put;
}
rate = clk_get_rate(clk);

if (request_irq(evt->dev.irq, mtk_timer_interrupt,
IRQF_TIMER | IRQF_IRQPOLL, "mtk_timer", evt)) {
-   pr_warn("failed to setup irq %d\n", evt->dev.irq);
+   pr_err("failed to setup irq %d\n", evt->dev.irq);
goto err_clk_disable;
}



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

Re: [PATCH 15/69] clocksource/drivers/mediatek: Add the COMPILE_TEST option




On 18/12/15 15:17, Daniel Lezcano wrote:

Increase the compilation test coverage by adding the COMPILE_TEST option.

Signed-off-by: Daniel Lezcano 
---


Acked-by: Matthias Brugger 


  drivers/clocksource/Kconfig | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 96a34dc..3ba43f6 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -228,9 +228,11 @@ config SYS_SUPPORTS_SH_CMT
  bool

  config MTK_TIMER
+   bool "Mediatek timer driver" if COMPILE_TEST
select CLKSRC_OF
select CLKSRC_MMIO
-   bool
+   help
+ Support for Mediatek timer driver.

  config SYS_SUPPORTS_SH_MTU2
  bool


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

[GIT PULL] Make the block layer great again

2015-12-30 Thread Jens Axboe

Hi Linus,

Basically three amazing fixes in this pull request, split into 4
patches. Believe me, they should go into 4.4. Two of them fix a
regression, the third and last fixes an easy-to-trigger bug.

- Fix a bad irq enable through null_blk, for queue_mode=1 and using
  timer completions. Add a block helper to restart a queue
  asynchronously, and use that from null_blk. From me.

- Fix a performance issue in NVMe. Some devices (Intel P) expose a
  stripe boundary, and performance suffers if we cross it. We took that
  into account for merging, but not for the newer splitting code. Fix
  from Keith.

- Fix a kernel oops in lightnvm with multiple channels. From Matias.

Please pull!


  git://git.kernel.dk/linux-block.git for-linus



Jens Axboe (2):
  block: add blk_start_queue_async()
  null_blk: use async queue restart helper

Keith Busch (1):
  block: Split bios on chunk boundaries

Matias Bjørling (1):
  lightnvm: wrong offset in bad blk lun calculation

 block/blk-core.c  | 16 
 block/blk-merge.c |  2 +-
 drivers/block/null_blk.c  | 11 +--
 drivers/lightnvm/gennvm.c |  2 +-
 include/linux/blkdev.h|  1 +
 5 files changed, 24 insertions(+), 8 deletions(-)

-- 
Jens Axboe

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

Re: Routable IRQs

Felipe,

On Tue, 29 Dec 2015, Felipe Balbi wrote:
> Anyway, the interesting part is that PRUSS has 64 events (on current
> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
> land. Each of these 64 events can be routed to any of these 10 IRQ
> lines. This might not be very useful on UP (AM335x & AM437x) other than
> the fact that soft-IP drivers running on Linux would need to guarantee
> they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
> could have real tangible benefits by means of IRQ affinity, etc.
> 
> So, the question is, what is there in IRQ subsystem today for routable
> IRQ support ?
> 
> If a Diagram helps here's a simple one. Note that I'm not showing
> details on the PRUSS side, but that side can also map events pretty much
> any way it wants.
> 
>  .. ..
>  |  HOST CPU  | |   PRUSS|
>  || ||
>  || ||
>  |   irq0 |<-.--|evt0|
>  ||  |  ||
>  |   irq1 |  |  .---|evt1|
>  ||  |  |   ||
>  |   irq2 |  '--|evt2|
>  || |   ||
>  |   irq3 | |   ||
>  || |   ||
>  |   irq4 | |   | .  |
>  || |   ||
>  |   irq5 | |   | .  |
>  || |   ||
>  |   irq6 | |   | .  |
>  || |   ||
>  |   irq7 |<'   ||
>  || ||
>  |   irq8 | ||
>  || ||
>  |   irq9 |<|evtN|
>  '' ''
> 
> Given this setup, what I want to do, is let soft-IP drivers running on
> linux rely on standard *request_*irq() calls and DTS descrition. But I'm
> still considering how/if we should describe the routing itself or just
> go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
> irq0 -> evt10, ...).
> 
> Thoughts ?

I have a few questions:

 - Is there a "mapping" block between PRUSS and the host interrupt controller
   or is this "mapping" block part of PRUSS?

 - We all know how well shared interrupts work. Is there a point of supporting
   64 interrupts when you only have 10 irq lines available?

 - I assume that the PRUSS interrupt mapping is more or less a question of the
   firmware implementation. So you either have a fixed association in the
   firmware which is reflected in the DT description of the IP block or you
   need an interface to tell the PRUSS firmware which event it should map to
   which irq line. Is there actually a value in doing the latter?

Thanks,

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

[tip:x86/urgent] x86/numachip: Fix NumaConnect2 MMCFG PCI access

2015-12-30 Thread tip-bot for Daniel J Blueman

Commit-ID:  dd7a5ab495019d424c2b0747892eb2e38a052ba5
Gitweb: http://git.kernel.org/tip/dd7a5ab495019d424c2b0747892eb2e38a052ba5
Author: Daniel J Blueman 
AuthorDate: Thu, 31 Dec 2015 02:06:47 +0800
Committer:  Thomas Gleixner 
CommitDate: Wed, 30 Dec 2015 19:19:03 +0100

x86/numachip: Fix NumaConnect2 MMCFG PCI access

The MMCFG PCI accessors weren't being setup for NumacConnect2
correctly due to over-early assignment; this would create the
potential for the wrong PCI domain to be accessed.

Fix this by using the correct arch-specific PCI init function.

Signed-off-by: Daniel J Blueman 
Acked-by: Steffen Persvold 
Cc: Daniel Lezcano 
Cc: Linus Torvalds 
Link: 
http://lkml.kernel.org/r/1451498807-15920-1-git-send-email-dan...@numascale.com
Signed-off-by: Thomas Gleixner 
---
 arch/x86/kernel/apic/apic_numachip.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index 38dd5ef..2bd2292 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -193,20 +193,17 @@ static int __init numachip_system_init(void)
case 1:
init_extra_mapping_uc(NUMACHIP_LCSR_BASE, NUMACHIP_LCSR_SIZE);
numachip_apic_icr_write = numachip1_apic_icr_write;
-   x86_init.pci.arch_init = pci_numachip_init;
break;
case 2:
init_extra_mapping_uc(NUMACHIP2_LCSR_BASE, NUMACHIP2_LCSR_SIZE);
numachip_apic_icr_write = numachip2_apic_icr_write;
-
-   /* Use MCFG config cycles rather than locked CF8 cycles */
-   raw_pci_ops = &pci_mmcfg;
break;
default:
return 0;
}
 
x86_cpuinit.fixup_cpu_id = fixup_cpu_id;
+   x86_init.pci.arch_init = pci_numachip_init;
 
return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: nf_unregister_net_hook: hook not found!

2015-12-30 Thread Sander Eikelenboom


On 2015-12-30 03:39, ebied...@xmission.com wrote:

Pablo Neira Ayuso  writes:


On Mon, Dec 28, 2015 at 09:05:03PM +0100, Sander Eikelenboom wrote:

Hi,

Running a 4.4.0-rc6 kernel i encountered the warning below.


Cc'ing Eric Biederman.

@Sander, could you provide a way to reproduce this?


I am on vacation until the new year, but if this is reproducible we
should be able to print out reg, reg->pf, reg->hooknum, reg->hook
to figure out which hook is having something very weird happen to it.

This is happening in some network namespace exit.

Eric



Unfortunately i have found no way to reproduce,
13 seconds implies it was at boot, but i only have seen this once.

--
Sander


Thanks.


[   13.740472] ip_tables: (C) 2000-2006 Netfilter Core Team
[   13.936237] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
[   13.945391] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
[   13.947434] iwlwifi :03:00.0: Radio type=0x2-0x1-0x0
[   14.223990] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
[   14.232065] iwlwifi :03:00.0: L1 Enabled - LTR Disabled
[   14.233570] iwlwifi :03:00.0: Radio type=0x2-0x1-0x0
[   14.328141] systemd-logind[2485]: Failed to start user service: 
Unknown

unit: user@117.service
[   14.356634] systemd-logind[2485]: New session c1 of user lightdm.
[   14.357320] [ cut here ]
[   14.357327] WARNING: CPU: 2 PID: 102 at net/netfilter/core.c:143
netfilter_net_exit+0x25/0x50()
[   14.357328] nf_unregister_net_hook: hook not found!
[   14.357371] Modules linked in: iptable_security(+) iptable_raw
iptable_filter ip_tables x_tables input_polldev bnep binfmt_misc nfsd
auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc 
uvcvideo

videobuf2_vmalloc iTCO_wdt arc4 videobuf2_memops iTCO_vendor_support
intel_rapl iosf_mbi videobuf2_v4l2 x86_pkg_temp_thermal 
intel_powerclamp
btusb coretemp snd_hda_codec_hdmi iwldvm videobuf2_core btrtl 
kvm_intel
v4l2_common mac80211 videodev btbcm snd_hda_codec_conexant btintel 
media kvm
snd_hda_codec_generic bluetooth psmouse thinkpad_acpi iwlwifi 
snd_hda_intel
pcspkr serio_raw snd_hda_codec nvram cfg80211 snd_hwdep snd_hda_core 
rfkill
i2c_i801 lpc_ich snd_pcm mfd_core snd_timer evdev snd soundcore 
shpchp
tpm_tis tpm algif_skcipher af_alg crct10dif_pclmul crc32_pclmul 
crc32c_intel

aesni_intel
[   14.357380]  ehci_pci sdhci_pci aes_x86_64 glue_helper ehci_hcd 
e1000e
lrw ablk_helper sg sdhci cryptd sd_mod ptp mmc_core usbcore 
usb_common

pps_core
[   14.357383] CPU: 2 PID: 102 Comm: kworker/u16:3 Tainted: G U
4.4.0-rc6-x220-20151224+ #1
[   14.357384] Hardware name: LENOVO 42912ZU/42912ZU, BIOS 8DET69WW 
(1.39 )

07/18/2013
[   14.357390] Workqueue: netns cleanup_net
[   14.357393]  81a27dfd 81359c69 88030e7cbd40
81060297
[   14.357395]  88030e820d80 88030e7cbd90 81c962d8
81c962e0
[   14.357397]  88030e7cbdf8 81060317 81a2c010
88030018
[   14.357398] Call Trace:
[   14.357405]  [] ? dump_stack+0x40/0x57
[   14.357408]  [] ? warn_slowpath_common+0x77/0xb0
[   14.357410]  [] ? warn_slowpath_fmt+0x47/0x50
[   14.357416]  [] ? mutex_lock+0x9/0x30
[   14.357418]  [] ? netfilter_net_exit+0x25/0x50
[   14.357421]  [] ? ops_exit_list.isra.6+0x2e/0x60
[   14.357424]  [] ? cleanup_net+0x1ab/0x280
[   14.357427]  [] ? process_one_work+0x133/0x330
[   14.357429]  [] ? worker_thread+0x60/0x470
[   14.357430]  [] ? process_one_work+0x330/0x330
[   14.357434]  [] ? kthread+0xca/0xe0
[   14.357436]  [] ? 
kthread_create_on_node+0x170/0x170

[   14.357439]  [] ? ret_from_fork+0x3f/0x70
[   14.357441]  [] ? 
kthread_create_on_node+0x170/0x170

[   14.357443] ---[ end trace 9984cc4b0e89f818 ]---
[   14.357443] [ cut here ]
[   14.357446] WARNING: CPU: 2 PID: 102 at net/netfilter/core.c:143
netfilter_net_exit+0x25/0x50()
[   14.357446] nf_unregister_net_hook: hook not found!
[   14.357472] Modules linked in: iptable_security(+) iptable_raw
iptable_filter ip_tables x_tables input_polldev bnep binfmt_misc nfsd
auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache sunrpc 
uvcvideo

videobuf2_vmalloc iTCO_wdt arc4 videobuf2_memops iTCO_vendor_support
intel_rapl iosf_mbi videobuf2_v4l2 x86_pkg_temp_thermal 
intel_powerclamp
btusb coretemp snd_hda_codec_hdmi iwldvm videobuf2_core btrtl 
kvm_intel
v4l2_common mac80211 videodev btbcm snd_hda_codec_conexant btintel 
media kvm
snd_hda_codec_generic bluetooth psmouse thinkpad_acpi iwlwifi 
snd_hda_intel
pcspkr serio_raw snd_hda_codec nvram cfg80211 snd_hwdep snd_hda_core 
rfkill
i2c_i801 lpc_ich snd_pcm mfd_core snd_timer evdev snd soundcore 
shpchp
tpm_tis tpm algif_skcipher af_alg crct10dif_pclmul crc32_pclmul 
crc32c_intel

aesni_intel
[   14.357478]  ehci_pci sdhci_pci aes_x86_64 glue_helper ehci_hcd 
e1000e
lrw ablk_helper sg sdhci cryptd sd_mod ptp mmc_core usbcore 
usb_common

pps_core
[   14.357480] CPU: 2 PID: 102 Comm: kworker/u16:3 Tainted: G U  
W

4.4.0-rc6-x220-201512

Re: [PATCH] mac80211: Make addr const in SET_IEEE80211_PERM_ADDR()

2015-12-30 Thread Souptick Joarder

On Wed, Dec 30, 2015 at 10:35 PM, Bjorn Andersson  wrote:
> On Wed, Dec 30, 2015 at 8:47 AM, Souptick Joarder  
> wrote:
>>
>> HI Bjorn,
>>
>> On Thu, Dec 24, 2015 at 2:03 PM, Bjorn Andersson  wrote:
>> > Make the addr parameter const in SET_IEEE80211_PERM_ADDR() to save
>> > clients from having to cast away a const qualifier.
>> >
>> > Signed-off-by: Bjorn Andersson 
>> > ---
>> >  include/net/mac80211.h | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>> > index 7c30faff245f..a6f3c9c4b7c2 100644
>> > --- a/include/net/mac80211.h
>> > +++ b/include/net/mac80211.h
>> > @@ -2167,7 +2167,7 @@ static inline void SET_IEEE80211_DEV(struct 
>> > ieee80211_hw *hw, struct device *dev
>> >   * @hw: the &struct ieee80211_hw to set the MAC address for
>> >   * @addr: the address to set
>> >   */
>> > -static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, u8 
>> > *addr)
>> > +static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, const 
>> > u8 *addr)
>>
>> I guess without const or with const doesn't make much difference here.
>> Correct me if I am wrong.
>
> For most cases it doesn't make any difference, but in my driver I
> acquire the mac address as a const u8 *. Therefor I need to cast away
> the const part when calling this API.
>
> There's an existing example of this in
> drivers/net/wireless/st/cw1200/main.c line 601.

Is the path correct ? I think path is
drivers/net/wireless/cw1200/main.c line 334

> I think it's safe to assume that this API won't ever modify the passed
> addr buffer, so there would be no future issues of marking the
> parameter const either.

I agree with you.

>
>>
>> >  {
>> > memcpy(hw->wiphy->perm_addr, addr, ETH_ALEN);
>> >  }
>>
>
> Regards,
> Bjorn

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

[PATCH] MAINTAINERS: Add myself as a reviewer for the bq27xxx driver.

Signed-off-by: Andrew F. Davis 
---
 MAINTAINERS | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 44666b1..046d001 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7605,10 +7605,8 @@ NOKIA N900 POWER SUPPLY DRIVERS
 M: Pali Rohár 
 S: Maintained
 F: include/linux/power/bq2415x_charger.h
-F: include/linux/power/bq27xxx_battery.h
 F: include/linux/power/isp1704_charger.h
 F: drivers/power/bq2415x_charger.c
-F: drivers/power/bq27xxx_battery.c
 F: drivers/power/isp1704_charger.c
 F: drivers/power/rx51_battery.c
 
@@ -10710,6 +10708,14 @@ L: linux-o...@vger.kernel.org
 S: Maintained
 F: drivers/thermal/ti-soc-thermal/
 
+TI BQ27XXX POWER SUPPLY DRIVER
+M: Pali Rohár 
+R: Andrew F. Davis 
+S: Maintained
+F: include/linux/power/bq27xxx_battery.h
+F: drivers/power/bq27xxx_battery.c
+F: drivers/power/bq27xxx_battery_i2c.c
+
 TI CDCE706 CLOCK DRIVER
 M: Max Filippov 
 S: Maintained
-- 
2.6.4

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

Re: [PATCH 4/6] regulator: lp872x: Add enable GPIO pin support

2015-12-30 Thread Paul Kocialkowski

Le mercredi 30 décembre 2015 à 16:33 +, Mark Brown a écrit :
> On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote:
> 
> > In my opinion, it would be more elegant to adapt the core regulator
> > framework to first enable the GPIO and then call the regulator enable
> > ops callback instead of handling the GPIO in the driver.
> 
> Why would we want to actively manage both things at runtime?  It's more
> work, what do we gain from it?

Well, I figured that it would be best to disable the EN pin when we're
not using any of the regulators, since that allows the chip to enter
standby mode (and thus consume less power).

Implementing that logic in the driver seems very redundant when we're
one step away from doing it with the core regulator framework.
It is also likely that in the future, other chips will use and need to
handle a global enable pin for the same purpose, while allowing
regulator configuration and enable via registers.

It also doesn't hurt regulators that only use a GPIO for enable.

The diff to do this is very minimal, I already have a patch ready, that
I could send if there is a chance for it to get through.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/

signature.asc
Description: This is a digitally signed message part

[PATCH] x86/urgent: Fix NumaConnect2 MMCFG PCI access

2015-12-30 Thread Daniel J Blueman

The MMCFG PCI accessors weren't being setup for NumacConnect2
correctly due to over-early assignment; this would create the
potential for the wrong PCI domain to be accessed.

Fix this by using the correct arch-specific PCI init function.

Signed-off-by: Daniel J Blueman 
Acked-by: Steffen Persvold 
---
 arch/x86/kernel/apic/apic_numachip.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/arch/x86/kernel/apic/apic_numachip.c 
b/arch/x86/kernel/apic/apic_numachip.c
index 38dd5ef..2bd2292 100644
--- a/arch/x86/kernel/apic/apic_numachip.c
+++ b/arch/x86/kernel/apic/apic_numachip.c
@@ -193,20 +193,17 @@ static int __init numachip_system_init(void)
case 1:
init_extra_mapping_uc(NUMACHIP_LCSR_BASE, NUMACHIP_LCSR_SIZE);
numachip_apic_icr_write = numachip1_apic_icr_write;
-   x86_init.pci.arch_init = pci_numachip_init;
break;
case 2:
init_extra_mapping_uc(NUMACHIP2_LCSR_BASE, NUMACHIP2_LCSR_SIZE);
numachip_apic_icr_write = numachip2_apic_icr_write;
-
-   /* Use MCFG config cycles rather than locked CF8 cycles */
-   raw_pci_ops = &pci_mmcfg;
break;
default:
return 0;
}

x86_cpuinit.fixup_cpu_id = fixup_cpu_id;
+   x86_init.pci.arch_init = pci_numachip_init;

return 0;
 }
--
2.5.0

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

Re: Routable IRQs

2015-12-30 Thread Felipe Balbi


Hi Thomas,

Thomas Gleixner  writes:
> On Tue, 29 Dec 2015, Felipe Balbi wrote:
>> Anyway, the interesting part is that PRUSS has 64 events (on current
>> incarnations at least) and PRUSS has 10 physical IRQ lines to the ARM
>> land. Each of these 64 events can be routed to any of these 10 IRQ
>> lines. This might not be very useful on UP (AM335x & AM437x) other than
>> the fact that soft-IP drivers running on Linux would need to guarantee
>> they are the ones who should handle the IRQ. However, on SMP (AM57xx) we
>> could have real tangible benefits by means of IRQ affinity, etc.
>> 
>> So, the question is, what is there in IRQ subsystem today for routable
>> IRQ support ?
>> 
>> If a Diagram helps here's a simple one. Note that I'm not showing
>> details on the PRUSS side, but that side can also map events pretty much
>> any way it wants.
>> 
>>  .. ..
>>  |  HOST CPU  | |   PRUSS|
>>  || ||
>>  || ||
>>  |   irq0 |<-.--|evt0|
>>  ||  |  ||
>>  |   irq1 |  |  .---|evt1|
>>  ||  |  |   ||
>>  |   irq2 |  '--|evt2|
>>  || |   ||
>>  |   irq3 | |   ||
>>  || |   ||
>>  |   irq4 | |   | .  |
>>  || |   ||
>>  |   irq5 | |   | .  |
>>  || |   ||
>>  |   irq6 | |   | .  |
>>  || |   ||
>>  |   irq7 |<'   ||
>>  || ||
>>  |   irq8 | ||
>>  || ||
>>  |   irq9 |<|evtN|
>>  '' ''
>> 
>> Given this setup, what I want to do, is let soft-IP drivers running on
>> linux rely on standard *request_*irq() calls and DTS descrition. But I'm
>> still considering how/if we should describe the routing itself or just
>> go round-robin (i.o.w. irq0 -> evt0, irq1 -> evt1, ..., irq9 -> evt9,
>> irq0 -> evt10, ...).
>> 
>> Thoughts ?
>
> I have a few questions:
>
>  - Is there a "mapping" block between PRUSS and the host interrupt controller
>or is this "mapping" block part of PRUSS?

The description in TRM is a bit "poor", but from what I can gather, the
mapping is done on an interrupt controller inside the PRUSS. However,
Linux is the one who's got the driver for that INTC (well, Linux will be
the one with the soft ethernet/uart/whatever IP to talk to). All of its
(INTC's) registers are memory mapped to the ARM side.

>  - We all know how well shared interrupts work. Is there a point of supporting
>64 interrupts when you only have 10 irq lines available?

I'm looking at these 64 events more like MSI kind of events. It's just
that the events themselves can be routed to any of the 10 available HW
IRQ lines.

>  - I assume that the PRUSS interrupt mapping is more or less a question of the
>firmware implementation. So you either have a fixed association in the
>firmware which is reflected in the DT description of the IP block or you
>need an interface to tell the PRUSS firmware which event it should map to
>which irq line. Is there actually a value in doing the latter?

right, I'd say the mapping is pretty static. Unless Suman has some extra
information which I don't. I guess the question was really to see if
there was an easy way for doing this so we don't have to mess with DTS
for every other FW and their neighbor.

Chances are (or at least I'm speculating) in most cases we won't use
more than 10 events anyway (Suman ?) so we might not run into any
troubles.

-- 
balbi


signature.asc
Description: PGP signature

Re: [Bugfix v2 2/5] x86/irq: Enhance __assign_irq_vector() to rollback in case of failure

On Wed, 23 Dec 2015, Jiang Liu wrote:
> @@ -167,11 +170,13 @@ next:
>  
>   if (test_bit(vector, used_vectors))
>   goto next;
> -
>   for_each_cpu_and(new_cpu, vector_cpumask, cpu_online_mask) {
>   if (!IS_ERR_OR_NULL(per_cpu(vector_irq, 
> new_cpu)[vector]))
>   goto next;
>   }
> + if (apic->cpu_mask_to_apicid_and(mask, vector_cpumask, &dest))
> + goto next;

This is silly. If the checks in cpu_mask_to_apicid_and() fail, then there is
no point to try the next vector number simply because the checks will fail
with the next vector again. You need a new vector_cpumask() in order to make
progress.

> +
>   /* Found one! */
>   current_vector = vector;
>   current_offset = offset;
> @@ -190,8 +195,7 @@ next:
>  
>   if (!err) {
>   /* cache destination APIC IDs into cfg->dest_apicid */
> - err = apic->cpu_mask_to_apicid_and(mask, d->domain,
> -&d->cfg.dest_apicid);

I have serious doubts that this is the proper solution.

d->domain is @vector_cpumask. @vector_cpumask gets assigned by the call to
apic->vector_allocation_domain()

So the only way this can fail is when:

   vector_cpumask & mask & cpu_online_mask == 0

So we can do that check way earlier, i.e. right after the call to
apic->vector_allocation_domain(). Once we have established that this check
does not fail, we know that the call to apic->cpu_mask_to_apicid_and() wont
fail either once we have a vector number to use.

Thanks,

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

[PATCH 0/4] More improvements on MIDI gadget function

Patch 1:
  The main improvement is the refactor of the state machine MIDI parser.
  It is better to read and handles states properly, even weird ones.

Patch 3:
  Fix a race condition.

Patches 3-4:
  Miscelaneous fixes.

Felipe F. Tonello (4):
  usb: gadget: f_midi: refactor state machine
  usb: gadget: f_midi: added spinlock on transmit function
  usb: gadget: f_midi: remove useless midi reference from port struct
  usb: gadget: f_midi: add mutex_unlock under setup_fail label

 drivers/usb/gadget/function/f_midi.c | 223 ++-
 1 file changed, 143 insertions(+), 80 deletions(-)

-- 
2.6.4

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

[PATCH 1/4] usb: gadget: f_midi: refactor state machine

This refactor results in a cleaner state machine code and as a result fixed a
bug when packaging a MIDI-USB packet right after a non-conformant MIDI byte 
stream.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 204 ++-
 1 file changed, 129 insertions(+), 75 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index fb1fe96d3215..c4b47f68e553 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -50,6 +50,19 @@ static const char f_midi_longname[] = "MIDI Gadget";
  */
 #define MAX_PORTS 16
 
+/* MIDI message states */
+enum {
+   STATE_INITIAL = 0,  /* pseudo state */
+   STATE_1PARAM,
+   STATE_2PARAM_1,
+   STATE_2PARAM_2,
+   STATE_SYSEX_0,
+   STATE_SYSEX_1,
+   STATE_SYSEX_2,
+   STATE_REAL_TIME,
+   STATE_FINISHED, /* pseudo state */
+};
+
 /*
  * This is a gadget, and the IN/OUT naming is from the host's perspective.
  * USB -> OUT endpoint -> rawmidi
@@ -60,13 +73,6 @@ struct gmidi_in_port {
int active;
uint8_t cable;
uint8_t state;
-#define STATE_UNKNOWN  0
-#define STATE_1PARAM   1
-#define STATE_2PARAM_1 2
-#define STATE_2PARAM_2 3
-#define STATE_SYSEX_0  4
-#define STATE_SYSEX_1  5
-#define STATE_SYSEX_2  6
uint8_t data[2];
 };
 
@@ -400,118 +406,166 @@ static int f_midi_snd_free(struct snd_device *device)
return 0;
 }
 
-static void f_midi_transmit_packet(struct usb_request *req, uint8_t p0,
-   uint8_t p1, uint8_t p2, uint8_t p3)
-{
-   unsigned length = req->length;
-   u8 *buf = (u8 *)req->buf + length;
-
-   buf[0] = p0;
-   buf[1] = p1;
-   buf[2] = p2;
-   buf[3] = p3;
-   req->length = length + 4;
-}
-
 /*
  * Converts MIDI commands to USB MIDI packets.
  */
 static void f_midi_transmit_byte(struct usb_request *req,
 struct gmidi_in_port *port, uint8_t b)
 {
-   uint8_t p0 = port->cable << 4;
+   uint8_t p[4] = { port->cable << 4, 0, 0, 0 };
+   uint8_t next_state = STATE_INITIAL;
+
+   switch (b) {
+   case 0xf8 ... 0xff:
+   /* System Real-Time Messages */
+   p[0] |= 0x0f;
+   p[1] = b;
+   next_state = port->state;
+   port->state = STATE_REAL_TIME;
+   break;
 
-   if (b >= 0xf8) {
-   f_midi_transmit_packet(req, p0 | 0x0f, b, 0, 0);
-   } else if (b >= 0xf0) {
+   case 0xf7:
+   /* End of SysEx */
+   switch (port->state) {
+   case STATE_SYSEX_0:
+   p[0] |= 0x05;
+   p[1] = 0xf7;
+   next_state = STATE_FINISHED;
+   break;
+   case STATE_SYSEX_1:
+   p[0] |= 0x06;
+   p[1] = port->data[0];
+   p[2] = 0xf7;
+   next_state = STATE_FINISHED;
+   break;
+   case STATE_SYSEX_2:
+   p[0] |= 0x07;
+   p[1] = port->data[0];
+   p[2] = port->data[1];
+   p[3] = 0xf7;
+   next_state = STATE_FINISHED;
+   break;
+   default:
+   /* Ignore byte */
+   next_state = port->state;
+   port->state = STATE_INITIAL;
+   }
+   break;
+
+   case 0xf0 ... 0xf6:
+   /* System Common Messages */
+   port->data[0] = port->data[1] = 0;
+   port->state = STATE_INITIAL;
switch (b) {
case 0xf0:
port->data[0] = b;
-   port->state = STATE_SYSEX_1;
+   port->data[1] = 0;
+   next_state = STATE_SYSEX_1;
break;
case 0xf1:
case 0xf3:
port->data[0] = b;
-   port->state = STATE_1PARAM;
+   next_state = STATE_1PARAM;
break;
case 0xf2:
port->data[0] = b;
-   port->state = STATE_2PARAM_1;
+   next_state = STATE_2PARAM_1;
break;
case 0xf4:
case 0xf5:
-   port->state = STATE_UNKNOWN;
+   next_state = STATE_INITIAL;
break;
case 0xf6:
-   f_midi_transmit_packet(req, p0 | 0x05, 0xf6, 0, 0);
-   port->state = STATE_UNKNOWN;
-   break;
-   case 0xf7:
-   switch (port->state) {
-   case STATE_SYSEX_0:
-

[PATCH 2/4] usb: gadget: f_midi: added spinlock on transmit function

Since f_midi_transmit is called by both ALSA and USB frameworks, it can
potentially cause a race condition between both calls. This is bad because the
way f_midi_transmit is implemented can't handle concurrent calls. This is due
to the fact that the usb request fifo looks for the next element and only if
it has data to process it enqueues the request, otherwise re-uses it. If both
(ALSA and USB) frameworks calls this function at the same time, the
kfifo_seek() will return the same usb_request, which will cause a race
condition.

To solve this problem a syncronization mechanism is necessary. In this case it
is used a spinlock since f_midi_transmit is also called by usb_request->complete
callback in interrupt context.

On benchmarks realized by me, spinlocks were more efficient then scheduling
the f_midi_transmit tasklet in process context and using a mutex to
synchronize. Also it performs better then previous implementation that
allocated a usb_request for every new transmit made.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index c4b47f68e553..bbff20697f76 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -98,6 +99,7 @@ struct f_midi {
/* This fifo is used as a buffer ring for pre-allocated IN usb_requests 
*/
DECLARE_KFIFO_PTR(in_req_fifo, struct usb_request *);
unsigned int in_last_port;
+   spinlock_t transmit_lock;
 };
 
 static inline struct f_midi *func_to_midi(struct usb_function *f)
@@ -589,12 +591,15 @@ static void f_midi_drop_out_substreams(struct f_midi 
*midi)
 static void f_midi_transmit(struct f_midi *midi)
 {
struct usb_ep *ep = midi->in_ep;
+   unsigned long flags;
bool active;
 
/* We only care about USB requests if IN endpoint is enabled */
if (!ep || !ep->enabled)
goto drop_out;
 
+   spin_lock_irqsave(&midi->transmit_lock, flags);
+
do {
struct usb_request *req = NULL;
unsigned int len, i;
@@ -606,14 +611,17 @@ static void f_midi_transmit(struct f_midi *midi)
len = kfifo_peek(&midi->in_req_fifo, &req);
if (len != 1) {
ERROR(midi, "%s: Couldn't get usb request\n", __func__);
+   spin_unlock_irqrestore(&midi->transmit_lock, flags);
goto drop_out;
}
 
/* If buffer overrun, then we ignore this transmission.
 * IMPORTANT: This will cause the user-space rawmidi device to 
block until a) usb
 * requests have been completed or b) snd_rawmidi_write() times 
out. */
-   if (req->length > 0)
+   if (req->length > 0) {
+   spin_unlock_irqrestore(&midi->transmit_lock, flags);
return;
+   }
 
for (i = midi->in_last_port; i < MAX_PORTS; i++) {
struct gmidi_in_port *port = midi->in_port[i];
@@ -665,6 +673,8 @@ static void f_midi_transmit(struct f_midi *midi)
}
} while (active);
 
+   spin_unlock_irqrestore(&midi->transmit_lock, flags);
+
return;
 
 drop_out:
@@ -1270,6 +1280,8 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
if (status)
goto setup_fail;
 
+   spin_lock_init(&midi->transmit_lock);
+
++opts->refcnt;
mutex_unlock(&opts->lock);
 
-- 
2.6.4

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

[PATCH 3/4] usb: gadget: f_midi: remove useless midi reference from port struct

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index bbff20697f76..b7d3f5a10bf0 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -70,7 +70,6 @@ enum {
  * USB <- IN endpoint  <- rawmidi
  */
 struct gmidi_in_port {
-   struct f_midi *midi;
int active;
uint8_t cable;
uint8_t state;
@@ -1256,7 +1255,6 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
goto setup_fail;
}
 
-   port->midi = midi;
port->active = 0;
port->cable = i;
midi->in_port[i] = port;
-- 
2.6.4

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

[PATCH 4/4] usb: gadget: f_midi: add mutex_unlock under setup_fail label

This ensures that at any point on the function if a goto to setup_fail is
made, it will unlock the mutex.

Signed-off-by: Felipe F. Tonello 
---
 drivers/usb/gadget/function/f_midi.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/usb/gadget/function/f_midi.c 
b/drivers/usb/gadget/function/f_midi.c
index b7d3f5a10bf0..1255f8a898d0 100644
--- a/drivers/usb/gadget/function/f_midi.c
+++ b/drivers/usb/gadget/function/f_midi.c
@@ -1251,7 +1251,6 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
 
if (!port) {
status = -ENOMEM;
-   mutex_unlock(&opts->lock);
goto setup_fail;
}
 
@@ -1264,7 +1263,6 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
midi->id = kstrdup(opts->id, GFP_KERNEL);
if (opts->id && !midi->id) {
status = -ENOMEM;
-   mutex_unlock(&opts->lock);
goto setup_fail;
}
midi->in_ports = opts->in_ports;
@@ -1293,6 +1291,7 @@ static struct usb_function *f_midi_alloc(struct 
usb_function_instance *fi)
return &midi->func;
 
 setup_fail:
+   mutex_unlock(&opts->lock);
for (--i; i >= 0; i--)
kfree(midi->in_port[i]);
kfree(midi);
-- 
2.6.4

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

Re: [PATCH V9 1/2] ACPI, PCI, irq: remove interrupt count restriction

2015-12-30 Thread Sinan Kaya

On 12/30/2015 8:28 AM, Andy Shevchenko wrote:
> Yep, I meant not to use an additional variable.
> 
>> > BTW, I suggest you spend some time around checkpatch for contributions. I 
>> > could
>> > have caught most of the issues you are generally concerned before 
>> > submitting a patch.
> Is it a question?

It is a request not a question. I hate wasting your time and my time with 
things that I could
have fixed before submitting a patch.

I ran the checkpatch and it said I'm good to go. But, obviously I'm not. 

-- 
Sinan Kaya
Qualcomm Technologies, Inc. on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v4 0/5] mtd: nand: properly handle bitflips in erased pages

Hi,

This patch series aims at providing a common logic to check for bitflips
in erased pages.

Currently each driver is implementing its own logic to check for bitflips
in erased pages. Not only this create code duplication, but most of these
implementations are incorrect.
Here are a few aspects that are often left aside in those implementations:
1/ they do not check OOB bytes when checking for the ff pattern, which
   means they can consider a page as empty while the MTD user actually
   wanted to write almost ff with a few bits to zero
2/ they check for the ff pattern on the whole page, while ECC actually
   works on smaller chunks (usually 512 or 1024 bytes chunks)
3/ they use random bitflip thresholds to decide whether a page/chunk is
   erased or not. IMO this threshold should be set to ECC strength (or
   at least something correlated to this parameter)

The approach taken in this series is to provide two helper functions to
check for bitflips in erased pages. Each driver that needs to check for
such cases can then call the nand_check_erased_ecc_chunk() function, and
rely on the common logic to decide whether a page is erased or not.

While Brian suggested a few times to make this detection automatic for
all drivers that set a specific flag (NAND_CHECK_ERASED_BITFLIPS?), here
is a few reasons I think this is not such a good idea:
1/ some (a lot of) drivers do not properly implement the raw access
   functions, and since we need to check for raw data and OOB bytes this
   makes the automatic detection unusable for most drivers unless they
   decide to correctly implement those methods (which would be a good
   thing BTW).
2/ as a I said earlier, this check should be made at the ECC chunk level
   and not at the page level. This spots two problems: some (a lot of)
   drivers do not properly specify the ecc layout information, and even
   if the ecc layout is correctly defined, there is no way to attach ECC
   bytes to a specific ECC chunk.
3/ the last aspect is the perf penalty incured by this test. Automatically
   doing that at the NAND core level implies reading the whole page again
   in raw mode, while with the helper function approach, drivers supporting
   access at the ECC chunk level can read only the faulty chunk in raw
   mode.

Regarding the bitflips threshold at which an erased pages is considered as
faulty, I have assigned it to ECC strength. As mentioned by Andrea, using
ECC strength might cause some trouble, because if you already have some
bitflips in an erased page, programming it might generate even more of
them.
In the other hand, shouldn't that be checked after (or before) programming
a page. I mean, UBI is already capable of detecting pages which are over
the configured bitflips_threshold and move data around when it detects
such pages.
If we check data after writing a page we wouldn't have to bother about
setting a weaker value for the "bitflips in erased page" case.
Another thing in favor of the ECC strength value for this "bitflips in
erased page" threshold value: if the ECC engine is generating 0xff ECC
bytes when the page is empty, then it will be able to fix ECC strength
bitflips without complaining, so why should we use different value when
we detect bitflips using the pattern match approach?

Best Regards,

Boris

Changes since v3:
- drop already applied patches
- make the generic "bitflips in erased pages" check as an opt-in flag
- split driver changes to ease review
- addressed Brian's comments

Changes since v2:
- improve nand_check_erased_buf() implementation
- keep nand_check_erased_buf() private to nand_base.c
- patch existing ecc.correct() implementations to return consistent error
  codes
- make the 'erased check' optional
- remove some custom implementations of the 'erased check'

Changes since v1:
- fix the nand_check_erased_buf() function
- mark the bitflips > bitflips_threshold condition as unlikely
- add missing memsets in nand_check_erased_ecc_chunk()


Boris Brezillon (5):
  mtd: nand: return consistent error codes in ecc.correct()
implementations
  mtd: nand: use nand_check_erased_ecc_chunk in default ECC read
functions
  mtd: nand: davinci: remove custom 'erased check' implementation
  mtd: nand: diskonchip: remove custom 'erased check' implementation
  mtd: nand: jz4740: remove custom 'erased check' implementation

 drivers/mtd/nand/atmel_nand.c   |  2 +-
 drivers/mtd/nand/bf5xx_nand.c   | 20 +++-
 drivers/mtd/nand/davinci_nand.c | 15 
 drivers/mtd/nand/diskonchip.c   | 37 ++--
 drivers/mtd/nand/jz4740_nand.c  | 22 ++---
 drivers/mtd/nand/mxc_nand.c |  4 ++--
 drivers/mtd/nand/nand_base.c| 53 +++--
 drivers/mtd/nand/nand_bch.c |  2 +-
 drivers/mtd/nand/nand_ecc.c |  2 +-
 drivers/mtd/nand/omap2.c|  6 ++---
 drivers/mtd/nand/r852.c |  4 ++--
 include/linux/mtd/nand.h| 18 +-
 include/linux/mtd/nand_bch.

[PATCH v4 1/5] mtd: nand: return consistent error codes in ecc.correct() implementations

The error code returned by the ecc.correct() are not consistent over the
all implementations.

Document the expected behavior in include/linux/mtd/nand.h and fix
offending implementations.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/atmel_nand.c   |  2 +-
 drivers/mtd/nand/bf5xx_nand.c   | 20 ++--
 drivers/mtd/nand/davinci_nand.c |  6 +++---
 drivers/mtd/nand/jz4740_nand.c  |  4 ++--
 drivers/mtd/nand/mxc_nand.c |  4 ++--
 drivers/mtd/nand/nand_bch.c |  2 +-
 drivers/mtd/nand/nand_ecc.c |  2 +-
 drivers/mtd/nand/omap2.c|  6 +++---
 drivers/mtd/nand/r852.c |  4 ++--
 include/linux/mtd/nand.h|  8 +++-
 include/linux/mtd/nand_bch.h|  2 +-
 11 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 18c4e14..b216bf5 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -1445,7 +1445,7 @@ static int atmel_nand_correct(struct mtd_info *mtd, 
u_char *dat,
 * We can't correct so many errors */
dev_dbg(host->dev, "atmel_nand : multiple errors detected."
" Unable to correct.\n");
-   return -EIO;
+   return -EBADMSG;
}
 
/* if there's a single bit error : we can correct it */
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 9514e13..89d9414 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -252,7 +252,7 @@ static int bf5xx_nand_correct_data_256(struct mtd_info 
*mtd, u_char *dat,
 */
if (hweight32(syndrome[0]) == 1) {
dev_err(info->device, "ECC data was incorrect!\n");
-   return 1;
+   return -EBADMSG;
}
 
syndrome[1] = (calced & 0x7FF) ^ (stored & 0x7FF);
@@ -285,7 +285,7 @@ static int bf5xx_nand_correct_data_256(struct mtd_info 
*mtd, u_char *dat,
data = data ^ (0x1 << failing_bit);
*(dat + failing_byte) = data;
 
-   return 0;
+   return 1;
}
 
/*
@@ -298,26 +298,34 @@ static int bf5xx_nand_correct_data_256(struct mtd_info 
*mtd, u_char *dat,
dev_err(info->device,
"Please discard data, mark bad block\n");
 
-   return 1;
+   return -EBADMSG;
 }
 
 static int bf5xx_nand_correct_data(struct mtd_info *mtd, u_char *dat,
u_char *read_ecc, u_char *calc_ecc)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
-   int ret;
+   int ret, bitflips = 0;
 
ret = bf5xx_nand_correct_data_256(mtd, dat, read_ecc, calc_ecc);
+   if (ret < 0)
+   return ret;
+
+   bitflips = ret;
 
/* If ecc size is 512, correct second 256 bytes */
if (chip->ecc.size == 512) {
dat += 256;
read_ecc += 3;
calc_ecc += 3;
-   ret |= bf5xx_nand_correct_data_256(mtd, dat, read_ecc, 
calc_ecc);
+   ret = bf5xx_nand_correct_data_256(mtd, dat, read_ecc, calc_ecc);
+   if (ret < 0)
+   return ret;
+
+   bitflips += ret;
}
 
-   return ret;
+   return bitflips;
 }
 
 static void bf5xx_nand_enable_hwecc(struct mtd_info *mtd, int mode)
diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 3b49fe8..ddb73c3 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -207,7 +207,7 @@ static int nand_davinci_correct_1bit(struct mtd_info *mtd, 
u_char *dat,
dat[diff >> (12 + 3)] ^= BIT((diff >> 12) & 7);
return 1;
} else {
-   return -1;
+   return -EBADMSG;
}
} else if (!(diff & (diff - 1))) {
/* Single bit ECC error in the ECC itself,
@@ -215,7 +215,7 @@ static int nand_davinci_correct_1bit(struct mtd_info *mtd, 
u_char *dat,
return 1;
} else {
/* Uncorrectable error */
-   return -1;
+   return -EBADMSG;
}
 
}
@@ -391,7 +391,7 @@ compare:
return 0;
case 1: /* five or more errors detected */
davinci_nand_readl(info, NAND_ERR_ERRVAL1_OFFSET);
-   return -EIO;
+   return -EBADMSG;
case 2: /* error addresses computed */
case 3:
num_errors = 1 + ((fsr >> 16) & 0x03);
diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index a2363d3..adccae3 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -254,7 +254,7 @@ static int jz_na

[PATCH v4 2/5] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions

The default NAND read functions are relying on the underlying controller
driver to correct bitflips, but some of those controllers cannot properly
fix bitflips in erased pages.
Check for bitflips in erased pages in default core functions if the driver
delegated the this check by setting the NAND_ECC_GENERIC_ERASED_CHECK flag.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 53 ++--
 include/linux/mtd/nand.h | 10 +
 2 files changed, 56 insertions(+), 7 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 928081b..909a1d4 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -1426,6 +1426,16 @@ static int nand_read_subpage(struct mtd_info *mtd, 
struct nand_chip *chip,
 
stat = chip->ecc.correct(mtd, p,
&chip->buffers->ecccode[i], &chip->buffers->ecccalc[i]);
+   if (stat == -EBADMSG &&
+   (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
+   /* check for empty pages with bitflips */
+   stat = nand_check_erased_ecc_chunk(p, chip->ecc.size,
+   &chip->buffers->ecccode[i],
+   chip->ecc.bytes,
+   NULL, 0,
+   chip->ecc.strength);
+   }
+
if (stat < 0) {
mtd->ecc_stats.failed++;
} else {
@@ -1475,6 +1485,15 @@ static int nand_read_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
int stat;
 
stat = chip->ecc.correct(mtd, p, &ecc_code[i], &ecc_calc[i]);
+   if (stat == -EBADMSG &&
+   (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
+   /* check for empty pages with bitflips */
+   stat = nand_check_erased_ecc_chunk(p, eccsize,
+   &ecc_code[i], eccbytes,
+   NULL, 0,
+   chip->ecc.strength);
+   }
+
if (stat < 0) {
mtd->ecc_stats.failed++;
} else {
@@ -1527,6 +1546,15 @@ static int nand_read_page_hwecc_oob_first(struct 
mtd_info *mtd,
chip->ecc.calculate(mtd, p, &ecc_calc[i]);
 
stat = chip->ecc.correct(mtd, p, &ecc_code[i], NULL);
+   if (stat == -EBADMSG &&
+   (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
+   /* check for empty pages with bitflips */
+   stat = nand_check_erased_ecc_chunk(p, eccsize,
+   &ecc_code[i], eccbytes,
+   NULL, 0,
+   chip->ecc.strength);
+   }
+
if (stat < 0) {
mtd->ecc_stats.failed++;
} else {
@@ -1554,6 +1582,7 @@ static int nand_read_page_syndrome(struct mtd_info *mtd, 
struct nand_chip *chip,
int i, eccsize = chip->ecc.size;
int eccbytes = chip->ecc.bytes;
int eccsteps = chip->ecc.steps;
+   int eccpadbytes = eccbytes + chip->ecc.prepad + chip->ecc.postpad;
uint8_t *p = buf;
uint8_t *oob = chip->oob_poi;
unsigned int max_bitflips = 0;
@@ -1573,19 +1602,29 @@ static int nand_read_page_syndrome(struct mtd_info 
*mtd, struct nand_chip *chip,
chip->read_buf(mtd, oob, eccbytes);
stat = chip->ecc.correct(mtd, p, oob, NULL);
 
-   if (stat < 0) {
-   mtd->ecc_stats.failed++;
-   } else {
-   mtd->ecc_stats.corrected += stat;
-   max_bitflips = max_t(unsigned int, max_bitflips, stat);
-   }
-
oob += eccbytes;
 
if (chip->ecc.postpad) {
chip->read_buf(mtd, oob, chip->ecc.postpad);
oob += chip->ecc.postpad;
}
+
+   if (stat == -EBADMSG &&
+   (chip->ecc.options & NAND_ECC_GENERIC_ERASED_CHECK)) {
+   /* check for empty pages with bitflips */
+   stat = nand_check_erased_ecc_chunk(p, chip->ecc.size,
+  oob - eccpadbytes,
+  eccpadbytes,
+  NULL, 0,
+  chip->ecc.strength);
+   }
+
+   if (stat < 0) {
+   mtd->ecc_stats.failed++;
+   } else {
+   mtd->ecc_sta

[PATCH v4 4/5] mtd: nand: diskonchip: remove custom 'erased check' implementation

The diskonchip drivers is manually checking for 'erased pages' while
correcting ECC bytes.
This logic can now done by the core infrastructure, and can thus be removed
from this drivers.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/diskonchip.c | 37 ++---
 1 file changed, 2 insertions(+), 35 deletions(-)

diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index a5c0466..a6927bf 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -74,10 +74,6 @@ struct doc_priv {
int (*late_init)(struct mtd_info *mtd);
 };
 
-/* This is the syndrome computed by the HW ecc generator upon reading an empty
-   page, one with all 0xff for data and stored ecc code. */
-static u_char empty_read_syndrome[6] = { 0x26, 0xff, 0x6d, 0x47, 0x73, 0x7a };
-
 /* This is the ecc value computed by the HW ecc generator upon writing an empty
page, one with all 0xff for data. */
 static u_char empty_write_ecc[6] = { 0x4b, 0x00, 0xe2, 0x0e, 0x93, 0xf7 };
@@ -912,7 +908,6 @@ static int doc200x_correct_data(struct mtd_info *mtd, 
u_char *dat,
void __iomem *docptr = doc->virtadr;
uint8_t calc_ecc[6];
volatile u_char dummy;
-   int emptymatch = 1;
 
/* flush the pipeline */
if (DoC_is_2000(doc)) {
@@ -936,37 +931,9 @@ static int doc200x_correct_data(struct mtd_info *mtd, 
u_char *dat,
calc_ecc[i] = ReadDOC_(docptr, 
DoC_Mplus_ECCSyndrome0 + i);
else
calc_ecc[i] = ReadDOC_(docptr, DoC_ECCSyndrome0 
+ i);
-   if (calc_ecc[i] != empty_read_syndrome[i])
-   emptymatch = 0;
-   }
-   /* If emptymatch=1, the read syndrome is consistent with an
-  all-0xff data and stored ecc block.  Check the stored ecc. */
-   if (emptymatch) {
-   for (i = 0; i < 6; i++) {
-   if (read_ecc[i] == 0xff)
-   continue;
-   emptymatch = 0;
-   break;
-   }
}
-   /* If emptymatch still =1, check the data block. */
-   if (emptymatch) {
-   /* Note: this somewhat expensive test should not be 
triggered
-  often.  It could be optimized away by examining the 
data in
-  the readbuf routine, and remembering the result. */
-   for (i = 0; i < 512; i++) {
-   if (dat[i] == 0xff)
-   continue;
-   emptymatch = 0;
-   break;
-   }
-   }
-   /* If emptymatch still =1, this is almost certainly a freshly-
-  erased block, in which case the ECC will not come out right.
-  We'll suppress the error and tell the caller everything's
-  OK.  Because it is. */
-   if (!emptymatch)
-   ret = doc_ecc_decode(rs_decoder, dat, calc_ecc);
+
+   ret = doc_ecc_decode(rs_decoder, dat, calc_ecc);
if (ret > 0)
printk(KERN_ERR "doc200x_correct_data corrected %d 
errors\n", ret);
}
-- 
2.1.4

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

[PATCH v4 5/5] mtd: nand: jz4740: remove custom 'erased check' implementation

The jz4740 drivers is manually checking for 'erased pages' while
correcting ECC bytes.
This logic can now done by the core infrastructure, and can thus be removed
from this drivers.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/jz4740_nand.c | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index adccae3..f934060 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -224,24 +224,6 @@ static int jz_nand_correct_ecc_rs(struct mtd_info *mtd, 
uint8_t *dat,
uint32_t t;
unsigned int timeout = 1000;
 
-   t = read_ecc[0];
-
-   if (t == 0xff) {
-   for (i = 1; i < 9; ++i)
-   t &= read_ecc[i];
-
-   t &= dat[0];
-   t &= dat[nand->chip.ecc.size / 2];
-   t &= dat[nand->chip.ecc.size - 1];
-
-   if (t == 0xff) {
-   for (i = 1; i < nand->chip.ecc.size - 1; ++i)
-   t &= dat[i];
-   if (t == 0xff)
-   return 0;
-   }
-   }
-
for (i = 0; i < 9; ++i)
writeb(read_ecc[i], nand->base + JZ_REG_NAND_PAR0 + i);
 
-- 
2.1.4

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

[PATCH 00/34] arch: barrier cleanup + __smp_xxx barriers for virt

Reposting without XXX in subject: vger does not like them :(

This is really trying to cleanup some virt code, as suggested by Peter, who
said
> You could of course go fix that instead of mutilating things into
> sort-of functional state.

This work is needed for virtio, so it's probably easiest to
merge it through my tree - is this fine by everyone?
Arnd, if you agree, could you ack this please?

Note to arch maintainers: please don't cherry-pick patches out of this patchset
as it's been structured in this order to avoid breaking bisect.
Please send acks instead!

Sometimes, virtualization is weird. For example, virtio does this 
(conceptually):

#ifdef CONFIG_SMP
smp_mb();
#else
mb();
#endif

Similarly, Xen calls mb() when it's not doing any MMIO at all.

Of course it's wrong in the sense that it's suboptimal. What we would really
like is to have, on UP, exactly the same barrier as on SMP.  This is because a
UP guest can run on an SMP host.

But Linux doesn't provide this ability: if CONFIG_SMP is not defined is
optimizes most barriers out to a compiler barrier.

Consider for example x86: what we want is xchg (NOT mfence - there's no real IO
going on here - just switching out of the VM - more like a function call
really) but if built without CONFIG_SMP smp_store_mb does not include this.

Virt in general is probably the only use-case, because this really is an
artifact of interfacing with an SMP host while running an UP kernel,
but since we have (at least) two users, it seems to make sense to
put these APIs in a central place.

In fact, smp_ barriers are stubs on !SMP, so they can be defined as follows:

arch/XXX/include/asm/barrier.h:

#define __smp_mb() DOSOMETHING

include/asm-generic/barrier.h:

#ifdef CONFIG_SMP
#define smp_mb() __smp_mb()
#else
#define smp_mb() barrier()
#endif

This has the benefit of cleaning out a bunch of duplicated
ifdefs on a bunch of architectures - this patchset brings
about a net reduction in LOC, compensated for by extra documentation :)

Then virt can use __smp_XXX when talking to an SMP host.

Touching all archs is a tad tedious, but its fairly straight forward.

The rest of the patchset is structured as follows:

-. Patch 1 documents the __smp APIs, and explains why they are
   useful for virt

-. Patches 2-7 makes sure barrier.h on ia64, powerpc, s390 and sparc
   includes asm-generic/barrier.h: this is safe because code there matches
   asm-generic/barrier.h almost verbatim.
   Minor code tweaks were required in a couple of places.
   Macros duplicated from asm-generic/barrier.h are dropped
   in the process.

   I compiled these arches before and after the changes,
   dumped the .text section (using objdump -O binary) and
   made sure that the object code is exactly identical
   before and after the change.


-. Patch 8 fixes up smp_store_mb in asm-generic/barrier.h:
   it should call smp_mb and not mb. Luckily only used
   in core kernel so we know no one misused it for an
   MMIO barrier (so far).
   This is the only patch that affects code behaviour
   outside virt, and that for !SMP only.
   Compile-tested on a bunch of architectures (x86
   hardware which I have is unaffected by this).
   It's very straightforward so I hope it's enough.
   Hoping for some acks on this architecture.

-. Patches 9-14 make sure barrier.h on all remaining
   architectures includes asm-generic/barrier.h:
   after the change in Patch 8, code there matches
   asm-generic/barrier.h almost verbatim.
   Macros duplicated from asm-generic/barrier.h are dropped
   in the process.

After all that preparatory work, we are getting to the actual change.

-. Patches 15 adds generic smp_XXX wrappers in asm-generic
   these select __smp_XXX or barrier() depending on CONFIG_SMP

-. Patches 16-28 change all architectures to
   define __smp_XXX macros; the generic code in asm-generic/barrier.h
   then defines smp_XXX macros

   I compiled the affected arches before and after the changes,
   dumped the .text section (using objdump -O binary) and
   made sure that the object code is exactly identical
   before and after the change.
   I couldn't fully build sh,tile,xtensa but I did this test
   kernel/rcu/tree.o kernel/sched/wait.o and
   kernel/futex.o and tested these instead.

Unfortunately, I don't have a metag cross-build toolset ready.
Hoping for some acks on this architecture.

Finally, the following patches put the __smp_XXX APIs to work for virt:

-. Patches 29-31 convert virtio and xen drivers to use the __smp_XXX APIs

   xen patches are untested
   virtio ones have been tested on x86

-. Patches 33-34 teach virtio to use
   __smp_load_acquire/__smp_store_release/__smp_store_mb
   This is what started all this work.

   tested on x86

The patchset has been in linux-next for a bit, so far without issues.

Michael S. Tsirkin (34):
  Documentation/memory-barriers.txt: document __smb_mb()
  asm-generic: guard smp_store_release/load_acquire
  ia64: rename nop->ios

[PATCH v4 3/5] mtd: nand: davinci: remove custom 'erased check' implementation

The davinci drivers is manually checking for 'erased pages' while
correcting ECC bytes.
This logic can now done by the core infrastructure, and can thus be removed
from this drivers.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/davinci_nand.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index ddb73c3..8cb821b 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -317,14 +317,6 @@ static int nand_davinci_correct_4bit(struct mtd_info *mtd,
unsigned num_errors, corrected;
unsigned long timeo;
 
-   /* All bytes 0xff?  It's an erased page; ignore its ECC. */
-   for (i = 0; i < 10; i++) {
-   if (ecc_code[i] != 0xff)
-   goto compare;
-   }
-   return 0;
-
-compare:
/* Unpack ten bytes into eight 10 bit values.  We know we're
 * little-endian, and use type punning for less shifting/masking.
 */
@@ -749,6 +741,7 @@ static int nand_davinci_probe(struct platform_device *pdev)
info->chip.ecc.correct = nand_davinci_correct_4bit;
info->chip.ecc.hwctl = nand_davinci_hwctl_4bit;
info->chip.ecc.bytes = 10;
+   info->chip.ecc.options = NAND_ECC_GENERIC_ERASED_CHECK;
} else {
info->chip.ecc.calculate = nand_davinci_calculate_1bit;
info->chip.ecc.correct = nand_davinci_correct_1bit;
-- 
2.1.4

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

[PATCH 15/34] asm-generic: add __smp_xxx wrappers

On !SMP, most architectures define their
barriers as compiler barriers.
On SMP, most need an actual barrier.

Make it possible to remove the code duplication for
!SMP by defining a low-level __smp_XXX barriers
which do not depend on the value of SMP, then
use them from asm-generic conditionally.

Besides reducing code duplication, these low level APIs will also be
useful for virtualization, where a barrier is sometimes needed even if
!SMP since we might be talking to another kernel on the same SMP system.

Both virtio and Xen drivers will benefit.

The smp_XXX variants should use __smp_XXX ones or barrier() depending on
SMP, identically for all architectures.

We keep ifndef guards around them for now - once all
architectures have been converted to use the generic
code, we'll be able to remove these.

Suggested-by: Peter Zijlstra 
Signed-off-by: Michael S. Tsirkin 
---
 include/asm-generic/barrier.h | 91 ++-
 1 file changed, 82 insertions(+), 9 deletions(-)

diff --git a/include/asm-generic/barrier.h b/include/asm-generic/barrier.h
index 987b2e0..8752964 100644
--- a/include/asm-generic/barrier.h
+++ b/include/asm-generic/barrier.h
@@ -54,22 +54,38 @@
 #define read_barrier_depends() do { } while (0)
 #endif
 
+#ifndef __smp_mb
+#define __smp_mb() mb()
+#endif
+
+#ifndef __smp_rmb
+#define __smp_rmb()rmb()
+#endif
+
+#ifndef __smp_wmb
+#define __smp_wmb()wmb()
+#endif
+
+#ifndef __smp_read_barrier_depends
+#define __smp_read_barrier_depends()   read_barrier_depends()
+#endif
+
 #ifdef CONFIG_SMP
 
 #ifndef smp_mb
-#define smp_mb()   mb()
+#define smp_mb()   __smp_mb()
 #endif
 
 #ifndef smp_rmb
-#define smp_rmb()  rmb()
+#define smp_rmb()  __smp_rmb()
 #endif
 
 #ifndef smp_wmb
-#define smp_wmb()  wmb()
+#define smp_wmb()  __smp_wmb()
 #endif
 
 #ifndef smp_read_barrier_depends
-#define smp_read_barrier_depends() read_barrier_depends()
+#define smp_read_barrier_depends() __smp_read_barrier_depends()
 #endif
 
 #else  /* !CONFIG_SMP */
@@ -92,23 +108,78 @@
 
 #endif /* CONFIG_SMP */
 
+#ifndef __smp_store_mb
+#define __smp_store_mb(var, value)  do { WRITE_ONCE(var, value); __smp_mb(); } 
while (0)
+#endif
+
+#ifndef __smp_mb__before_atomic
+#define __smp_mb__before_atomic()  __smp_mb()
+#endif
+
+#ifndef __smp_mb__after_atomic
+#define __smp_mb__after_atomic()   __smp_mb()
+#endif
+
+#ifndef __smp_store_release
+#define __smp_store_release(p, v)  \
+do {   \
+   compiletime_assert_atomic_type(*p); \
+   __smp_mb(); \
+   WRITE_ONCE(*p, v);  \
+} while (0)
+#endif
+
+#ifndef __smp_load_acquire
+#define __smp_load_acquire(p)  \
+({ \
+   typeof(*p) ___p1 = READ_ONCE(*p);   \
+   compiletime_assert_atomic_type(*p); \
+   __smp_mb(); \
+   ___p1;  \
+})
+#endif
+
+#ifdef CONFIG_SMP
+
+#ifndef smp_store_mb
+#define smp_store_mb(var, value)  __smp_store_mb(var, value)
+#endif
+
+#ifndef smp_mb__before_atomic
+#define smp_mb__before_atomic()__smp_mb__before_atomic()
+#endif
+
+#ifndef smp_mb__after_atomic
+#define smp_mb__after_atomic() __smp_mb__after_atomic()
+#endif
+
+#ifndef smp_store_release
+#define smp_store_release(p, v) __smp_store_release(p, v)
+#endif
+
+#ifndef smp_load_acquire
+#define smp_load_acquire(p) __smp_load_acquire(p)
+#endif
+
+#else  /* !CONFIG_SMP */
+
 #ifndef smp_store_mb
-#define smp_store_mb(var, value)  do { WRITE_ONCE(var, value); smp_mb(); } 
while (0)
+#define smp_store_mb(var, value)  do { WRITE_ONCE(var, value); barrier(); } 
while (0)
 #endif
 
 #ifndef smp_mb__before_atomic
-#define smp_mb__before_atomic()smp_mb()
+#define smp_mb__before_atomic()barrier()
 #endif
 
 #ifndef smp_mb__after_atomic
-#define smp_mb__after_atomic() smp_mb()
+#define smp_mb__after_atomic() barrier()
 #endif
 
 #ifndef smp_store_release
 #define smp_store_release(p, v)
\
 do {   \
compiletime_assert_atomic_type(*p); \
-   smp_mb();   \
+   barrier();  \
WRITE_ONCE(*p, v);  \
 } while (0)
 #endif
@@ -118,10 +189,12 @@ do {  
\
 ({

[PATCH] arm64: defconfig: Enable PL031

2015-12-30 Thread Christopher Covington

Since Real Time Clock (RTC) configuration options were first enabled in the
arm64 defconfig (commit 2d39ad6 "arm64: defconfig: update defconfig for
3.18"), QEMU's device tree based virt machine has grown to include a PL031
RTC. Update the defconfig accordingly.

Signed-off-by: Christopher Covington 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index bdd7aa3..9bd25e0 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -168,6 +168,7 @@ CONFIG_LEDS_TRIGGER_HEARTBEAT=y
 CONFIG_LEDS_TRIGGER_CPU=y
 CONFIG_RTC_CLASS=y
 CONFIG_RTC_DRV_EFI=y
+CONFIG_RTC_DRV_PL031=y
 CONFIG_RTC_DRV_XGENE=y
 CONFIG_DMADEVICES=y
 CONFIG_QCOM_BAM_DMA=y
-- 
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCH 16/34] powerpc: define __smp_xxx

This defines __smp_XXX barriers for powerpc
for use by virtualization.

smp_XXX barriers are removed as they are
defined correctly by asm-generic/barriers.h

This reduces the amount of arch-specific boiler-plate code.

Signed-off-by: Michael S. Tsirkin 
---
 arch/powerpc/include/asm/barrier.h | 24 
 1 file changed, 8 insertions(+), 16 deletions(-)

diff --git a/arch/powerpc/include/asm/barrier.h 
b/arch/powerpc/include/asm/barrier.h
index 980ad0c..c0deafc 100644
--- a/arch/powerpc/include/asm/barrier.h
+++ b/arch/powerpc/include/asm/barrier.h
@@ -44,19 +44,11 @@
 #define dma_rmb()  __lwsync()
 #define dma_wmb()  __asm__ __volatile__ (stringify_in_c(SMPWMB) : : 
:"memory")
 
-#ifdef CONFIG_SMP
-#define smp_lwsync()   __lwsync()
+#define __smp_lwsync() __lwsync()
 
-#define smp_mb()   mb()
-#define smp_rmb()  __lwsync()
-#define smp_wmb()  __asm__ __volatile__ (stringify_in_c(SMPWMB) : : 
:"memory")
-#else
-#define smp_lwsync()   barrier()
-
-#define smp_mb()   barrier()
-#define smp_rmb()  barrier()
-#define smp_wmb()  barrier()
-#endif /* CONFIG_SMP */
+#define __smp_mb() mb()
+#define __smp_rmb()__lwsync()
+#define __smp_wmb()__asm__ __volatile__ (stringify_in_c(SMPWMB) : : 
:"memory")
 
 /*
  * This is a barrier which prevents following instructions from being
@@ -67,18 +59,18 @@
 #define data_barrier(x)\
asm volatile("twi 0,%0,0; isync" : : "r" (x) : "memory");
 
-#define smp_store_release(p, v)
\
+#define __smp_store_release(p, v)  
\
 do {   \
compiletime_assert_atomic_type(*p); \
-   smp_lwsync();   \
+   __smp_lwsync(); \
WRITE_ONCE(*p, v);  \
 } while (0)
 
-#define smp_load_acquire(p)\
+#define __smp_load_acquire(p)  \
 ({ \
typeof(*p) ___p1 = READ_ONCE(*p);   \
compiletime_assert_atomic_type(*p); \
-   smp_lwsync();   \
+   __smp_lwsync(); \
___p1;  \
 })
 
-- 
MST

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

[PATCH v5 4/5] mtd: nand: diskonchip: remove custom 'erased check' implementation

The diskonchip drivers is manually checking for 'erased pages' while
correcting ECC bytes.
This logic can now done by the core infrastructure, and can thus be removed
from this drivers.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- add missing NAND_ECC_GENERIC_ERASED_CHECK flag

 drivers/mtd/nand/diskonchip.c | 38 +++---
 1 file changed, 3 insertions(+), 35 deletions(-)

diff --git a/drivers/mtd/nand/diskonchip.c b/drivers/mtd/nand/diskonchip.c
index a5c0466..4f4aa35 100644
--- a/drivers/mtd/nand/diskonchip.c
+++ b/drivers/mtd/nand/diskonchip.c
@@ -74,10 +74,6 @@ struct doc_priv {
int (*late_init)(struct mtd_info *mtd);
 };
 
-/* This is the syndrome computed by the HW ecc generator upon reading an empty
-   page, one with all 0xff for data and stored ecc code. */
-static u_char empty_read_syndrome[6] = { 0x26, 0xff, 0x6d, 0x47, 0x73, 0x7a };
-
 /* This is the ecc value computed by the HW ecc generator upon writing an empty
page, one with all 0xff for data. */
 static u_char empty_write_ecc[6] = { 0x4b, 0x00, 0xe2, 0x0e, 0x93, 0xf7 };
@@ -912,7 +908,6 @@ static int doc200x_correct_data(struct mtd_info *mtd, 
u_char *dat,
void __iomem *docptr = doc->virtadr;
uint8_t calc_ecc[6];
volatile u_char dummy;
-   int emptymatch = 1;
 
/* flush the pipeline */
if (DoC_is_2000(doc)) {
@@ -936,37 +931,9 @@ static int doc200x_correct_data(struct mtd_info *mtd, 
u_char *dat,
calc_ecc[i] = ReadDOC_(docptr, 
DoC_Mplus_ECCSyndrome0 + i);
else
calc_ecc[i] = ReadDOC_(docptr, DoC_ECCSyndrome0 
+ i);
-   if (calc_ecc[i] != empty_read_syndrome[i])
-   emptymatch = 0;
-   }
-   /* If emptymatch=1, the read syndrome is consistent with an
-  all-0xff data and stored ecc block.  Check the stored ecc. */
-   if (emptymatch) {
-   for (i = 0; i < 6; i++) {
-   if (read_ecc[i] == 0xff)
-   continue;
-   emptymatch = 0;
-   break;
-   }
}
-   /* If emptymatch still =1, check the data block. */
-   if (emptymatch) {
-   /* Note: this somewhat expensive test should not be 
triggered
-  often.  It could be optimized away by examining the 
data in
-  the readbuf routine, and remembering the result. */
-   for (i = 0; i < 512; i++) {
-   if (dat[i] == 0xff)
-   continue;
-   emptymatch = 0;
-   break;
-   }
-   }
-   /* If emptymatch still =1, this is almost certainly a freshly-
-  erased block, in which case the ECC will not come out right.
-  We'll suppress the error and tell the caller everything's
-  OK.  Because it is. */
-   if (!emptymatch)
-   ret = doc_ecc_decode(rs_decoder, dat, calc_ecc);
+
+   ret = doc_ecc_decode(rs_decoder, dat, calc_ecc);
if (ret > 0)
printk(KERN_ERR "doc200x_correct_data corrected %d 
errors\n", ret);
}
@@ -1586,6 +1553,7 @@ static int __init doc_probe(unsigned long physadr)
nand->ecc.size  = 512;
nand->ecc.bytes = 6;
nand->ecc.strength  = 2;
+   nand->ecc.options   = NAND_ECC_GENERIC_ERASED_CHECK;
nand->bbt_options   = NAND_BBT_USE_FLASH;
/* Skip the automatic BBT scan so we can run it manually */
nand->options   |= NAND_SKIP_BBTSCAN;
-- 
2.1.4

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

Re: [PATCH 2/2] f2fs: support revoking atomic written pages

2015-12-30 Thread Jaegeuk Kim

Hello,

On Wed, Dec 30, 2015 at 09:34:40AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
> 
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Wednesday, December 30, 2015 8:05 AM
> > To: Chao Yu
> > Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 2/2] f2fs: support revoking atomic written pages
> > 
> > Hi Chao,
> > 
> > On Tue, Dec 29, 2015 at 11:12:36AM +0800, Chao Yu wrote:
> > > f2fs support atomic write with following semantics:
> > > 1. open db file
> > > 2. ioctl start atomic write
> > > 3. (write db file) * n
> > > 4. ioctl commit atomic write
> > > 5. close db file
> > >
> > > With this flow we can avoid file becoming corrupted when abnormal power
> > > cut, because we hold data of transaction in referenced pages linked in
> > > inmem_pages list of inode, but without setting them dirty, so these data
> > > won't be persisted unless we commit them in step 4.
> > >
> > > But we should still hold journal db file in memory by using volatile 
> > > write,
> > > because our semantics of 'atomic write support' is not full, in step 4, we
> > > could be fail to submit all dirty data of transaction, once partial dirty
> > > data was committed in storage, db file should be corrupted, in this case,
> > > we should use journal db to recover the original data in db file.
> > 
> > Originally, IOC_ABORT_VOLATILE_WRITE was supposed to handle commit failures,
> > since database should get its error literally.
> > 
> > So, the only thing that we need to do is keeping journal data for further db
> > recovery.
> 
> IMO, if we really support *atomic* interface, we don't need any journal data
> kept by user, because f2fs already have it in its storage since we always
> trigger OPU for pages written in atomic-write opened file, f2fs can easily try
> to revoke (replace old to new in metadata) when any failure exist in atomic
> write process.

Yeah, so current design does not fully support atomic writes. IOWs, volatile
writes for journal files should be used together to minimize sqlite change as
much as possible.

> But in current design, we still hold journal data in memory for recovering for
> *rare* failure case. I think there are several issues:
> a) most of time, we are in concurrent scenario, so if large number of journal
> db files were opened simultaneously, we are under big memory pressure.

In current android, I've seen that this is not a big concern. Even there is
memory pressure, f2fs flushes volatile pages.

> b) If we are out of memory, reclaimer tries to write page of journal db into
> disk, it will destroy db file.

I don't understand. Could you elaborate why journal writes can corrupt db?

> c) Though, we have journal db file, we will face failure of recovering db file
> from journal db due to ENOMEM or EIO, then db file will be corrupted.

Do you mean the failure of recovering db with a complete journal?
Why do we have to handle that? That's a database stuff, IMO.

> d) Recovery flow will make data page dirty, triggering both data stream and
> metadata stream, there should be more IOs than in inner revoking in
> atomic-interface.

Well, do you mean there is no need to recover db after revoking?

> e) Moreover, there should be a hole between 1) commit fail and 2) abort write 
> &
> recover, checkpoint will persist the corrupt data in db file, following 
> abnormal
> power-cut will leave that data in disk.

Yes, in that case, database should recover corrupted db with its journal file.

> With revoking supported design, we can not solve all above issues, we will 
> still
> face the same issue like c), but it will be a big improve if we can apply this
> in our interface, since it provide a way to fix the issue a) b) d). And also 
> for
> e) case, we try to rescue data in first time that our revoking operation 
> would be
> protected by f2fs_lock_op to avoid checkpoint + power-cut.
> 
> If you don't want to have a big change in this interface or recovery flow, how
> about keep them both, and add a mount option to control inner recovery flow?

Hmm, okay. I believe the current design is fine for sqlite in android.
For other databases, I can understand that they can use atomic_write without
journal control, which is a sort of stand-alone atomic_write.

It'd better to add a new ioctl for that, but before adding it, can we find
any usecase for this feature? (e.g., postgresql, mysql, mariadb, couchdb?)
Then, I expect that we can define a more appropriate and powerful ioctl.

Thanks,

> 
> How do you think? :)
> 
> Thanks,
> 
> > But, unfortunately, it seems that something is missing in the
> > current implementation.
> > 
> > So simply how about this?
> > 
> > A possible flow would be:
> > 1. write journal data to volatile space
> > 2. write db data to atomic space
> > 3. in the error case, call ioc_abort_volatile_writes for both journal and db
> >  - flush/fsync journal data to disk
> >  - drop atomic data, and will be recovered by data

[PATCH v5 5/5] mtd: nand: jz4740: remove custom 'erased check' implementation

The jz4740 drivers is manually checking for 'erased pages' while
correcting ECC bytes.
This logic can now done by the core infrastructure, and can thus be removed
from this drivers.

Signed-off-by: Boris Brezillon 
---
Changes since v4:
- add missing NAND_ECC_GENERIC_ERASED_CHECK flag

 drivers/mtd/nand/jz4740_nand.c | 19 +--
 1 file changed, 1 insertion(+), 18 deletions(-)

diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
index adccae3..b19d2a9 100644
--- a/drivers/mtd/nand/jz4740_nand.c
+++ b/drivers/mtd/nand/jz4740_nand.c
@@ -224,24 +224,6 @@ static int jz_nand_correct_ecc_rs(struct mtd_info *mtd, 
uint8_t *dat,
uint32_t t;
unsigned int timeout = 1000;
 
-   t = read_ecc[0];
-
-   if (t == 0xff) {
-   for (i = 1; i < 9; ++i)
-   t &= read_ecc[i];
-
-   t &= dat[0];
-   t &= dat[nand->chip.ecc.size / 2];
-   t &= dat[nand->chip.ecc.size - 1];
-
-   if (t == 0xff) {
-   for (i = 1; i < nand->chip.ecc.size - 1; ++i)
-   t &= dat[i];
-   if (t == 0xff)
-   return 0;
-   }
-   }
-
for (i = 0; i < 9; ++i)
writeb(read_ecc[i], nand->base + JZ_REG_NAND_PAR0 + i);
 
@@ -443,6 +425,7 @@ static int jz_nand_probe(struct platform_device *pdev)
chip->ecc.size  = 512;
chip->ecc.bytes = 9;
chip->ecc.strength  = 4;
+   chip->ecc.options   = NAND_ECC_GENERIC_ERASED_CHECK;
 
if (pdata)
chip->ecc.layout = pdata->ecc_layout;
-- 
2.1.4

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

Re: [f2fs-dev] [PATCH 2/2] f2fs: support revoking atomic written pages

2015-12-30 Thread Jaegeuk Kim

On Wed, Dec 30, 2015 at 11:35:20PM +0800, Chao Yu wrote:
> On 12/30/15 9:34 AM, Chao Yu wrote:
> > Hi Jaegeuk,
> > 
> >> -Original Message-
> >> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> >> Sent: Wednesday, December 30, 2015 8:05 AM
> >> To: Chao Yu
> >> Cc: linux-f2fs-de...@lists.sourceforge.net; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH 2/2] f2fs: support revoking atomic written pages
> >>
> >> Hi Chao,
> >>
> >> On Tue, Dec 29, 2015 at 11:12:36AM +0800, Chao Yu wrote:
> >>> f2fs support atomic write with following semantics:
> >>> 1. open db file
> >>> 2. ioctl start atomic write
> >>> 3. (write db file) * n
> >>> 4. ioctl commit atomic write
> >>> 5. close db file
> >>>
> >>> With this flow we can avoid file becoming corrupted when abnormal power
> >>> cut, because we hold data of transaction in referenced pages linked in
> >>> inmem_pages list of inode, but without setting them dirty, so these data
> >>> won't be persisted unless we commit them in step 4.
> >>>
> >>> But we should still hold journal db file in memory by using volatile 
> >>> write,
> >>> because our semantics of 'atomic write support' is not full, in step 4, we
> >>> could be fail to submit all dirty data of transaction, once partial dirty
> >>> data was committed in storage, db file should be corrupted, in this case,
> >>> we should use journal db to recover the original data in db file.
> >>
> >> Originally, IOC_ABORT_VOLATILE_WRITE was supposed to handle commit 
> >> failures,
> >> since database should get its error literally.
> >>
> >> So, the only thing that we need to do is keeping journal data for further 
> >> db
> >> recovery.
> > 
> > IMO, if we really support *atomic* interface, we don't need any journal data
> > kept by user, because f2fs already have it in its storage since we always
> > trigger OPU for pages written in atomic-write opened file, f2fs can easily 
> > try
> > to revoke (replace old to new in metadata) when any failure exist in atomic
> > write process.
> > 
> > But in current design, we still hold journal data in memory for recovering 
> > for
> > *rare* failure case. I think there are several issues:
> > a) most of time, we are in concurrent scenario, so if large number of 
> > journal
> > db files were opened simultaneously, we are under big memory pressure.
> > b) If we are out of memory, reclaimer tries to write page of journal db into
> > disk, it will destroy db file.
> > c) Though, we have journal db file, we will face failure of recovering db 
> > file
> > from journal db due to ENOMEM or EIO, then db file will be corrupted.
> > d) Recovery flow will make data page dirty, triggering both data stream and
> > metadata stream, there should be more IOs than in inner revoking in
> > atomic-interface.
> > e) Moreover, there should be a hole between 1) commit fail and 2) abort 
> > write &
> > recover, checkpoint will persist the corrupt data in db file, following 
> > abnormal
> > power-cut will leave that data in disk.
> > 
> > With revoking supported design, we can not solve all above issues, we will 
> > still
> > face the same issue like c), but it will be a big improve if we can apply 
> > this
> > in our interface, since it provide a way to fix the issue a) b) d). And 
> > also for
> > e) case, we try to rescue data in first time that our revoking operation 
> > would be
> > protected by f2fs_lock_op to avoid checkpoint + power-cut.
> > 
> > If you don't want to have a big change in this interface or recovery flow, 
> > how
> > about keep them both, and add a mount option to control inner recovery flow?
> 
> Or introduce F2FS_IOC_COMMIT_ATOMIC_WRITE_V2 for revoking supported interface?
> 
> > 
> > How do you think? :)
> > 
> > Thanks,
> > 
> >> But, unfortunately, it seems that something is missing in the
> >> current implementation.
> >>
> >> So simply how about this?
> >>
> >> A possible flow would be:
> >> 1. write journal data to volatile space
> >> 2. write db data to atomic space
> >> 3. in the error case, call ioc_abort_volatile_writes for both journal and 
> >> db
> >>  - flush/fsync journal data to disk
> >>  - drop atomic data, and will be recovered by database with journal
> >>
> >> From cb33fc8bc30981c370ec70fe68871130109793ec Mon Sep 17 00:00:00 2001
> >> From: Jaegeuk Kim 
> >> Date: Tue, 29 Dec 2015 15:46:33 -0800
> >> Subject: [PATCH] f2fs: fix f2fs_ioc_abort_volatile_write
> >>
> >> There are two rules to handle aborting volatile or atomic writes.
> >>
> >> 1. drop atomic writes
> >>  - we don't need to keep any stale db data.
> >>
> >> 2. write journal data
> >>  - we should keep the journal data with fsync for db recovery.
> >>
> >> Signed-off-by: Jaegeuk Kim 
> >> ---
> >>  fs/f2fs/file.c | 13 ++---
> >>  1 file changed, 10 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> >> index 91f576a..d16438a 100644
> >> --- a/fs/f2fs/file.c
> >> +++ b/fs/f2fs/file.c
> >> @@ -1433,9 +1433,16 @@ static int f2fs_ioc_abort

Re: Routable IRQs

Felipe,

On Wed, 30 Dec 2015, Felipe Balbi wrote:
> Thomas Gleixner  writes:
> >  - Is there a "mapping" block between PRUSS and the host interrupt 
> > controller
> >or is this "mapping" block part of PRUSS?
> 
> The description in TRM is a bit "poor", but from what I can gather, the
> mapping is done on an interrupt controller inside the PRUSS. However,
> Linux is the one who's got the driver for that INTC (well, Linux will be
> the one with the soft ethernet/uart/whatever IP to talk to). All of its
> (INTC's) registers are memory mapped to the ARM side.

Ok. And the INTC registers include the "mapping" configuration, right?

> >  - We all know how well shared interrupts work. Is there a point of 
> > supporting
> >64 interrupts when you only have 10 irq lines available?
> 
> I'm looking at these 64 events more like MSI kind of events. It's just

Well, that's fine to look at them this way, but they will end up shared no
matter what.

> that the events themselves can be routed to any of the 10 available HW
> IRQ lines.
> 
> >  - I assume that the PRUSS interrupt mapping is more or less a question of 
> > the
> >firmware implementation. So you either have a fixed association in the
> >firmware which is reflected in the DT description of the IP block or you
> >need an interface to tell the PRUSS firmware which event it should map to
> >which irq line. Is there actually a value in doing the latter?
> 
> right, I'd say the mapping is pretty static. Unless Suman has some extra
> information which I don't. I guess the question was really to see if
> there was an easy way for doing this so we don't have to mess with DTS
> for every other FW and their neighbor.

Well, you will need information about every other firmware simply because you
need to know which events the firmware is actually using and what the purpose
of the particular event is.

Assume you have a simple uart with 3 events (RX, TX, status). So how will the
firmware tell you which event is which? You have a few options:

 1) DT + fixed mapping scheme: 

Describe the PRUSS event number in DT and have a fixed mapping scheme like
the one you mentioned evt0 -> irq0 .

 2) DT + DT mapping scheme

Describe the PRUSS event number in DT and describe the mapping scheme in
DT as well

 3) DT + dynamic mapping scheme

Describe the PRUSS event number in DT and let your interrupt controller
associate the irq number dynamically. That's kind of similar to MSI with
the exception that it needs to support shared interrupts.

 4) Fully dynamic association

Have a query interface to the firmware which tells you which event it uses
for which particular purpose (RX, TX ...) and then establish a dynamic
mapping to one of the interrupts.

Not sure which level of complexity you want :)

Thanks,

tglx

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

Re: [PATCH V9 1/2] ACPI, PCI, irq: remove interrupt count restriction

2015-12-30 Thread Andy Shevchenko

On Wed, Dec 30, 2015 at 9:17 PM, Sinan Kaya  wrote:
> On 12/30/2015 8:28 AM, Andy Shevchenko wrote:
>> Yep, I meant not to use an additional variable.
>>
>>> > BTW, I suggest you spend some time around checkpatch for contributions. I 
>>> > could
>>> > have caught most of the issues you are generally concerned before 
>>> > submitting a patch.
>> Is it a question?
>
> It is a request not a question. I hate wasting your time and my time with 
> things that I could
> have fixed before submitting a patch.
>
> I ran the checkpatch and it said I'm good to go. But, obviously I'm not.

Hmm… checkpatch.pl is just a small helper to fix style issues. Here is
just a common sense rule, or kind of Occam's razor: no need to have
more variables then needed if it doesn't improve something really
significantly.

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

Re: [PATCH 07/34] sparc: reuse asm-generic/barrier.h

On Wed, Dec 30, 2015 at 12:56:03PM -0500, David Miller wrote:
> 
> I find it a little bit irritating when I receive a patch directly
> addressed to me to review, but I don't see the "00/34" cover letter.
> 
> I want to see what this series is about, and what the motiviation
> for this change is.
> 
> I'm also highly frustrated, in general, with mix-and-match CC: lists
> for patch series.  Just put everyone relevant in the CC: for the
> entire series.  That way I can easily inspect other parts of the
> series to see infrastructure buildup, and examples of other
> conversions or versions of the change.
> 
> Thanks.

Hi Dave.
Sorry about that.

The problem I had in the past is that vger rejects email with
too many CC addresses.

(It also rejected email with __smp_XXX in the subject
suspecting it's spam :( )

I'll look for better solutions next time - for now, would it help if I
bounced the whole patchset to you?

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

Re: [PATCH] mac80211: Make addr const in SET_IEEE80211_PERM_ADDR()

2015-12-30 Thread Bjorn Andersson

On Wed, Dec 30, 2015 at 10:30 AM, Souptick Joarder  wrote:
> On Wed, Dec 30, 2015 at 10:35 PM, Bjorn Andersson  wrote:
>> On Wed, Dec 30, 2015 at 8:47 AM, Souptick Joarder  
>> wrote:
>>>
>>> HI Bjorn,
>>>
>>> On Thu, Dec 24, 2015 at 2:03 PM, Bjorn Andersson  wrote:
>>> > Make the addr parameter const in SET_IEEE80211_PERM_ADDR() to save
>>> > clients from having to cast away a const qualifier.
>>> >
>>> > Signed-off-by: Bjorn Andersson 
>>> > ---
>>> >  include/net/mac80211.h | 2 +-
>>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>> >
>>> > diff --git a/include/net/mac80211.h b/include/net/mac80211.h
>>> > index 7c30faff245f..a6f3c9c4b7c2 100644
>>> > --- a/include/net/mac80211.h
>>> > +++ b/include/net/mac80211.h
>>> > @@ -2167,7 +2167,7 @@ static inline void SET_IEEE80211_DEV(struct 
>>> > ieee80211_hw *hw, struct device *dev
>>> >   * @hw: the &struct ieee80211_hw to set the MAC address for
>>> >   * @addr: the address to set
>>> >   */
>>> > -static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, u8 
>>> > *addr)
>>> > +static inline void SET_IEEE80211_PERM_ADDR(struct ieee80211_hw *hw, 
>>> > const u8 *addr)
>>>
>>> I guess without const or with const doesn't make much difference here.
>>> Correct me if I am wrong.
>>
>> For most cases it doesn't make any difference, but in my driver I
>> acquire the mac address as a const u8 *. Therefor I need to cast away
>> the const part when calling this API.
>>
>> There's an existing example of this in
>> drivers/net/wireless/st/cw1200/main.c line 601.
>
> Is the path correct ? I think path is
> drivers/net/wireless/cw1200/main.c line 334
>

It's apparently being relocated in linux-next, and I'm not sure where
I got that line number from. But that's the example I tried to refer
to ;)

Sorry about that.

Regards,
Bjorn

>> I think it's safe to assume that this API won't ever modify the passed
>> addr buffer, so there would be no future issues of marking the
>> parameter const either.
>
> I agree with you.
>
>>
>>>
>>> >  {
>>> > memcpy(hw->wiphy->perm_addr, addr, ETH_ALEN);
>>> >  }
>>>
>>
>> Regards,
>> Bjorn
>
> -Souptick
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Routable IRQs

2015-12-30 Thread Felipe Balbi


Hi,

Thomas Gleixner  writes:
> Felipe,
>
> On Wed, 30 Dec 2015, Felipe Balbi wrote:
>> Thomas Gleixner  writes:
>> >  - Is there a "mapping" block between PRUSS and the host interrupt 
>> > controller
>> >or is this "mapping" block part of PRUSS?
>> 
>> The description in TRM is a bit "poor", but from what I can gather, the
>> mapping is done on an interrupt controller inside the PRUSS. However,
>> Linux is the one who's got the driver for that INTC (well, Linux will be
>> the one with the soft ethernet/uart/whatever IP to talk to). All of its
>> (INTC's) registers are memory mapped to the ARM side.
>
> Ok. And the INTC registers include the "mapping" configuration, right?

right. A bunch of 32 bit registers each with several 4 bit fields (one
for each of the 64 events) where we write the physical IRQ number.

>> >  - We all know how well shared interrupts work. Is there a point of 
>> > supporting
>> >64 interrupts when you only have 10 irq lines available?
>> 
>> I'm looking at these 64 events more like MSI kind of events. It's just
>
> Well, that's fine to look at them this way, but they will end up
> shared no matter what.

sure :-)

>> that the events themselves can be routed to any of the 10 available HW
>> IRQ lines.
>> 
>> >  - I assume that the PRUSS interrupt mapping is more or less a question of 
>> > the
>> >firmware implementation. So you either have a fixed association in the
>> >firmware which is reflected in the DT description of the IP block or you
>> >need an interface to tell the PRUSS firmware which event it should map 
>> > to
>> >which irq line. Is there actually a value in doing the latter?
>> 
>> right, I'd say the mapping is pretty static. Unless Suman has some extra
>> information which I don't. I guess the question was really to see if
>> there was an easy way for doing this so we don't have to mess with DTS
>> for every other FW and their neighbor.
>
> Well, you will need information about every other firmware simply because you
> need to know which events the firmware is actually using and what the purpose
> of the particular event is.
>
> Assume you have a simple uart with 3 events (RX, TX, status). So how will the
> firmware tell you which event is which? You have a few options:
>
>  1) DT + fixed mapping scheme: 
>
> Describe the PRUSS event number in DT and have a fixed mapping scheme like
> the one you mentioned evt0 -> irq0 .
>
>  2) DT + DT mapping scheme
>
> Describe the PRUSS event number in DT and describe the mapping scheme in
> DT as well
>
>  3) DT + dynamic mapping scheme
>
> Describe the PRUSS event number in DT and let your interrupt controller
> associate the irq number dynamically. That's kind of similar to MSI with
> the exception that it needs to support shared interrupts.
>
>  4) Fully dynamic association
>
> Have a query interface to the firmware which tells you which event it uses
> for which particular purpose (RX, TX ...) and then establish a dynamic
> mapping to one of the interrupts.
>
> Not sure which level of complexity you want :)

I guess only 1, 2 are anything worth considering, most likely. 4 would
just be too much headache :-p

3 might be doable too, though a bit more complex. Suman (who has been
working on this for much longer than I have) might have some extra info
to add, but he's on vacations for now. Hopefully, he'll add to this
thread once he's back.

cheers

-- 
balbi


signature.asc
Description: PGP signature

[PATCH] sh: support a 2-byte smp_store_mb

At the moment, xchg on sh only supports 4 and 1 byte values, so using it
from smp_store_mb means attempts to store a 2 byte value using this
macro fail.

And happens to be exactly what virtio drivers want to do.

Check size and fall back to a slower, but safe, WRITE_ONCE+smp_mb.

Signed-off-by: Michael S. Tsirkin 
---

Note: this is on top of my __smp_XXX barrier rework.
Please don't cherry-pick, please ack so I can
queue this in virtio tree together with driver change
that depends on it.

 arch/sh/include/asm/barrier.h | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/sh/include/asm/barrier.h b/arch/sh/include/asm/barrier.h
index f887c64..0cc5735 100644
--- a/arch/sh/include/asm/barrier.h
+++ b/arch/sh/include/asm/barrier.h
@@ -32,7 +32,15 @@
 #define ctrl_barrier() __asm__ __volatile__ ("nop;nop;nop;nop;nop;nop;nop;nop")
 #endif
 
-#define __smp_store_mb(var, value) do { (void)xchg(&var, value); } while (0)
+#define __smp_store_mb(var, value) do { \
+   if (sizeof(var) != 4 && sizeof(var) != 1) { \
+WRITE_ONCE(var, value); \
+   __smp_mb(); \
+   } else { \
+   (void)xchg(&var, value);  \
+   } \
+} while (0)
+
 #define smp_store_mb(var, value) __smp_store_mb(var, value)
 
 #include 
-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/34] asm-generic: smp_store_mb should use smp_mb