1. 25 9月, 2014 2 次提交
    • C
      arm64: Fix typos in KGDB macros · 7acf71d1
      Catalin Marinas 提交于
      Some of the KGDB macros used for generating the BRK instructions had the
      wrong spelling for DBG and KGDB abbreviations.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      7acf71d1
    • M
      arm64: insn: Add return statements after BUG_ON() · a9ae04c9
      Mark Brown 提交于
      Following a recent series of enhancements to the insn code the ARMv8
      allnoconfig build has been generating a large number of warnings in the
      form of:
      
      arch/arm64/kernel/insn.c:689:8: warning: 'insn' may be used uninitialized in this function [-Wmaybe-uninitialized]
      
      This is because BUG() and related macros can be compiled out so we get
      execution paths which normally result in a panic compiling out to noops
      instead.
      
      I wasn't able to immediately identify a sensible return value to use in
      these cases so just return AARCH64_BREAK_FAULT - this is all "should
      never happen" code so hopefully it never has a practical impact.
      Signed-off-by: NMark Brown <broonie@kernel.org>
      [catalin.marinas@arm.com: AARCH64_BREAK_FAULT definition contributed by Daniel Borkmann]
      [catalin.marinas@arm.com: replace return 0 with AARCH64_BREAK_FAULT]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      a9ae04c9
  2. 23 9月, 2014 1 次提交
    • C
      Revert "arm64: dmi: Add SMBIOS/DMI support" · 6f325eaa
      Catalin Marinas 提交于
      This reverts commit 668ebd10.
      
      ... because of lots of warnings during boot if Linux isn't started as an EFI
      application:
      
      WARNING: CPU: 4 PID: 1 at
      /work/Linux/linux-2.6-aarch64/drivers/firmware/dmi_scan.c:591 dmi_matches+0x10c/0x110()
      dmi check: not initialized yet.
      Modules linked in:
      CPU: 4 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc4+ #606
      Call trace:
      [<ffffffc000087fb0>] dump_backtrace+0x0/0x124
      [<ffffffc0000880e4>] show_stack+0x10/0x1c
      [<ffffffc0004d58f8>] dump_stack+0x74/0xb8
      [<ffffffc0000ab640>] warn_slowpath_common+0x8c/0xb4
      [<ffffffc0000ab6b4>] warn_slowpath_fmt+0x4c/0x58
      [<ffffffc0003f2d7c>] dmi_matches+0x108/0x110
      [<ffffffc0003f2da8>] dmi_check_system+0x24/0x68
      [<ffffffc0006974c4>] atkbd_init+0x10/0x34
      [<ffffffc0000814ac>] do_one_initcall+0x88/0x1a0
      [<ffffffc00067aab4>] kernel_init_freeable+0x148/0x1e8
      [<ffffffc0004d2c64>] kernel_init+0x10/0xd4
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      6f325eaa
  3. 22 9月, 2014 2 次提交
  4. 12 9月, 2014 2 次提交
    • L
      arm64: kernel: introduce cpu_init_idle CPU operation · d64f84f6
      Lorenzo Pieralisi 提交于
      The CPUidle subsystem on ARM64 machines requires the idle states
      implementation back-end to initialize idle states parameter upon
      boot. This patch adds a hook in the CPU operations structure that
      should be initialized by the CPU operations back-end in order to
      provide a function that initializes cpu idle states.
      
      This patch also adds the infrastructure to arm64 kernel required
      to export the CPU operations based initialization interface, so
      that drivers (ie CPUidle) can use it when they are initialized
      at probe time.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      d64f84f6
    • L
      arm64: kernel: refactor the CPU suspend API for retention states · 714f5992
      Lorenzo Pieralisi 提交于
      CPU suspend is the standard kernel interface to be used to enter
      low-power states on ARM64 systems. Current cpu_suspend implementation
      by default assumes that all low power states are losing the CPU context,
      so the CPU registers must be saved and cleaned to DRAM upon state
      entry. Furthermore, the current cpu_suspend() implementation assumes
      that if the CPU suspend back-end method returns when called, this has
      to be considered an error regardless of the return code (which can be
      successful) since the CPU was not expected to return from a code path that
      is different from cpu_resume code path - eg returning from the reset vector.
      
      All in all this means that the current API does not cope well with low-power
      states that preserve the CPU context when entered (ie retention states),
      since first of all the context is saved for nothing on state entry for
      those states and a successful state entry can return as a normal function
      return, which is considered an error by the current CPU suspend
      implementation.
      
      This patch refactors the cpu_suspend() API so that it can be split in
      two separate functionalities. The arm64 cpu_suspend API just provides
      a wrapper around CPU suspend operation hook. A new function is
      introduced (for architecture code use only) for states that require
      context saving upon entry:
      
      __cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
      
      __cpu_suspend() saves the context on function entry and calls the
      so called suspend finisher (ie fn) to complete the suspend operation.
      The finisher is not expected to return, unless it fails in which case
      the error is propagated back to the __cpu_suspend caller.
      
      The API refactoring results in the following pseudo code call sequence for a
      suspending CPU, when triggered from a kernel subsystem:
      
      /*
       * int cpu_suspend(unsigned long idx)
       * @idx: idle state index
       */
      {
      -> cpu_suspend(idx)
      	|---> CPU operations suspend hook called, if present
      		|--> if (retention_state)
      			|--> direct suspend back-end call (eg PSCI suspend)
      		     else
      			|--> __cpu_suspend(idx, &back_end_finisher);
      }
      
      By refactoring the cpu_suspend API this way, the CPU operations back-end
      has a chance to detect whether idle states require state saving or not
      and can call the required suspend operations accordingly either through
      simple function call or indirectly through __cpu_suspend() which carries out
      state saving and suspend finisher dispatching to complete idle state entry.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reviewed-by: NHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      714f5992
  5. 08 9月, 2014 20 次提交
  6. 29 8月, 2014 3 次提交
  7. 20 8月, 2014 1 次提交
  8. 19 8月, 2014 1 次提交
  9. 09 8月, 2014 1 次提交
    • A
      arm64,ia64,ppc,s390,sh,tile,um,x86,mm: remove default gate area · a6c19dfe
      Andy Lutomirski 提交于
      The core mm code will provide a default gate area based on
      FIXADDR_USER_START and FIXADDR_USER_END if
      !defined(__HAVE_ARCH_GATE_AREA) && defined(AT_SYSINFO_EHDR).
      
      This default is only useful for ia64.  arm64, ppc, s390, sh, tile, 64-bit
      UML, and x86_32 have their own code just to disable it.  arm, 32-bit UML,
      and x86_64 have gate areas, but they have their own implementations.
      
      This gets rid of the default and moves the code into ia64.
      
      This should save some code on architectures without a gate area: it's now
      possible to inline the gate_area functions in the default case.
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Acked-by: NNathan Lynch <nathan_lynch@mentor.com>
      Acked-by: NH. Peter Anvin <hpa@linux.intel.com>
      Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> [in principle]
      Acked-by: Richard Weinberger <richard@nod.at> [for um]
      Acked-by: Will Deacon <will.deacon@arm.com> [for arm64]
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Nathan Lynch <Nathan_Lynch@mentor.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6c19dfe
  10. 06 8月, 2014 1 次提交
  11. 01 8月, 2014 1 次提交
  12. 31 7月, 2014 1 次提交
  13. 25 7月, 2014 2 次提交
    • C
      arm64: gicv3: Allow GICv3 compilation with older binutils · 72c58395
      Catalin Marinas 提交于
      GICv3 introduces new system registers accessible with the full msr/mrs
      syntax (e.g. mrs x0, Sop0_op1_CRm_CRn_op2). However, only recent
      binutils understand the new syntax. This patch introduces msr_s/mrs_s
      assembly macros which generate the equivalent instructions above and
      converts the existing GICv3 code (both drivers/irqchip/ and
      arch/arm64/kernel/).
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NOlof Johansson <olof@lixom.net>
      Tested-by: NOlof Johansson <olof@lixom.net>
      Suggested-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NMark Rutland <mark.rutland@arm.com>
      Acked-by: NJason Cooper <jason@lakedaemon.net>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      72c58395
    • M
      arm64: fix soft lockup due to large tlb flush range · 05ac6530
      Mark Salter 提交于
      Under certain loads, this soft lockup has been observed:
      
         BUG: soft lockup - CPU#2 stuck for 22s! [ip6tables:1016]
         Modules linked in: ip6t_rpfilter ip6t_REJECT cfg80211 rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw vfat fat efivarfs xfs libcrc32c
      
         CPU: 2 PID: 1016 Comm: ip6tables Not tainted 3.13.0-0.rc7.30.sa2.aarch64 #1
         task: fffffe03e81d1400 ti: fffffe03f01f8000 task.ti: fffffe03f01f8000
         PC is at __cpu_flush_kern_tlb_range+0xc/0x40
         LR is at __purge_vmap_area_lazy+0x28c/0x3ac
         pc : [<fffffe000009c5cc>] lr : [<fffffe0000182710>] pstate: 80000145
         sp : fffffe03f01fbb70
         x29: fffffe03f01fbb70 x28: fffffe03f01f8000
         x27: fffffe0000b19000 x26: 00000000000000d0
         x25: 000000000000001c x24: fffffe03f01fbc50
         x23: fffffe03f01fbc58 x22: fffffe03f01fbc10
         x21: fffffe0000b2a3f8 x20: 0000000000000802
         x19: fffffe0000b2a3c8 x18: 000003fffdf52710
         x17: 000003ff9d8bb910 x16: fffffe000050fbfc
         x15: 0000000000005735 x14: 000003ff9d7e1a5c
         x13: 0000000000000000 x12: 000003ff9d7e1a5c
         x11: 0000000000000007 x10: fffffe0000c09af0
         x9 : fffffe0000ad1000 x8 : 000000000000005c
         x7 : fffffe03e8624000 x6 : 0000000000000000
         x5 : 0000000000000000 x4 : 0000000000000000
         x3 : fffffe0000c09cc8 x2 : 0000000000000000
         x1 : 000fffffdfffca80 x0 : 000fffffcd742150
      
      The __cpu_flush_kern_tlb_range() function looks like:
      
        ENTRY(__cpu_flush_kern_tlb_range)
      	dsb	sy
      	lsr	x0, x0, #12
      	lsr	x1, x1, #12
        1:	tlbi	vaae1is, x0
      	add	x0, x0, #1
      	cmp	x0, x1
      	b.lo	1b
      	dsb	sy
      	isb
      	ret
        ENDPROC(__cpu_flush_kern_tlb_range)
      
      The above soft lockup shows the PC at tlbi insn with:
      
        x0 = 0x000fffffcd742150
        x1 = 0x000fffffdfffca80
      
      So __cpu_flush_kern_tlb_range has 0x128ba930 tlbi flushes left
      after it has already been looping for 23 seconds!.
      
      Looking up one frame at __purge_vmap_area_lazy(), there is:
      
      	...
      	list_for_each_entry_rcu(va, &vmap_area_list, list) {
      		if (va->flags & VM_LAZY_FREE) {
      			if (va->va_start < *start)
      				*start = va->va_start;
      			if (va->va_end > *end)
      				*end = va->va_end;
      			nr += (va->va_end - va->va_start) >> PAGE_SHIFT;
      			list_add_tail(&va->purge_list, &valist);
      			va->flags |= VM_LAZY_FREEING;
      			va->flags &= ~VM_LAZY_FREE;
      		}
      	}
      	...
      	if (nr || force_flush)
      		flush_tlb_kernel_range(*start, *end);
      
      So if two areas are being freed, the range passed to
      flush_tlb_kernel_range() may be as large as the vmalloc
      space. For arm64, this is ~240GB for 4k pagesize and ~2TB
      for 64kpage size.
      
      This patch works around this problem by adding a loop limit.
      If the range is larger than the limit, use flush_tlb_all()
      rather than flushing based on individual pages. The limit
      chosen is arbitrary as the TLB size is implementation
      specific and not accessible in an architected way. The aim
      of the arbitrary limit is to avoid soft lockup.
      Signed-off-by: NMark Salter <msalter@redhat.com>
      [catalin.marinas@arm.com: commit log update]
      [catalin.marinas@arm.com: marginal optimisation]
      [catalin.marinas@arm.com: changed to MAX_TLB_RANGE and added comment]
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      05ac6530
  14. 24 7月, 2014 1 次提交
    • C
      arm64: Fix barriers used for page table modifications · 7f0b1bf0
      Catalin Marinas 提交于
      The architecture specification states that both DSB and ISB are required
      between page table modifications and subsequent memory accesses using the
      corresponding virtual address. When TLB invalidation takes place, the
      tlb_flush_* functions already have the necessary barriers. However, there are
      other functions like create_mapping() for which this is not the case.
      
      The patch adds the DSB+ISB instructions in the set_pte() function for
      valid kernel mappings. The invalid pte case is handled by tlb_flush_*
      and the user mappings in general have a corresponding update_mmu_cache()
      call containing a DSB. Even when update_mmu_cache() isn't called, the
      kernel can still cope with an unlikely spurious page fault by
      re-executing the instruction.
      
      In addition, the set_pmd, set_pud() functions gain an ISB for
      architecture compliance when block mappings are created.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      Reported-by: NLeif Lindholm <leif.lindholm@linaro.org>
      Acked-by: NSteve Capper <steve.capper@linaro.org>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: <stable@vger.kernel.org>
      7f0b1bf0
  15. 23 7月, 2014 1 次提交