1. 03 4月, 2013 1 次提交
  2. 12 3月, 2013 1 次提交
    • I
      xen: arm: mandate EABI and use generic atomic operations. · 85323a99
      Ian Campbell 提交于
      Rob Herring has observed that c81611c4 "xen: event channel arrays are
      xen_ulong_t and not unsigned long" introduced a compile failure when building
      without CONFIG_AEABI:
      
      /tmp/ccJaIZOW.s: Assembler messages:
      /tmp/ccJaIZOW.s:831: Error: even register required -- `ldrexd r5,r6,[r4]'
      
      Will Deacon pointed out that this is because OABI does not require even base
      registers for 64-bit values. We can avoid this by simply using the existing
      atomic64_xchg operation and the same containerof trick as used by the cmpxchg
      macros. However since this code is used on memory which is shared with the
      hypervisor we require proper atomic instructions and cannot use the generic
      atomic64 callbacks (which are based on spinlocks), therefore add a dependency
      on !GENERIC_ATOMIC64. Since we already depend on !CPU_V6 there isn't much
      downside to this.
      
      While thinking about this we also observed that OABI has different struct
      alignment requirements to EABI, which is a problem for hypercall argument
      structs which are shared with the hypervisor and which must be in EABI layout.
      Since I don't expect people to want to run OABI kernels on Xen depend on
      CONFIG_AEABI explicitly too (although it also happens to be enforced by the
      !GENERIC_ATOMIC64 requirement too).
      Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Rob Herring <robherring2@gmail.com>
      Acked-by: NStefano Stabellini <Stefano.Stabellini@eu.citrix.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      85323a99
  3. 04 3月, 2013 2 次提交
    • W
      ARM: 7660/1: tlb: add branch predictor maintenance operations · 862c588f
      Will Deacon 提交于
      The ARM architecture requires explicit branch predictor maintenance
      when updating an instruction stream for a given virtual address. In
      reality, this isn't so much of a burden because the branch predictor
      is flushed during the cache maintenance required to make the new
      instructions visible to the I-side of the processor.
      
      However, there are still some cases where explicit flushing is required,
      so add a local_bp_flush_all operation to deal with this.
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      862c588f
    • W
      ARM: 7659/1: mm: make mm->context.id an atomic64_t variable · 8a4e3a9e
      Will Deacon 提交于
      mm->context.id is updated under asid_lock when a new ASID is allocated
      to an mm_struct. However, it is also read without the lock when a task
      is being scheduled and checking whether or not the current ASID
      generation is up-to-date.
      
      If two threads of the same process are being scheduled in parallel and
      the bottom bits of the generation in their mm->context.id match the
      current generation (that is, the mm_struct has not been used for ~2^24
      rollovers) then the non-atomic, lockless access to mm->context.id may
      yield the incorrect ASID.
      
      This patch fixes this issue by making mm->context.id and atomic64_t,
      ensuring that the generation is always read consistently. For code that
      only requires access to the ASID bits (e.g. TLB flushing by mm), then
      the value is accessed directly, which GCC converts to an ldrb.
      
      Cc: <stable@vger.kernel.org> # 3.8
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      8a4e3a9e
  4. 25 2月, 2013 4 次提交
  5. 21 2月, 2013 2 次提交
  6. 20 2月, 2013 2 次提交
  7. 17 2月, 2013 2 次提交
  8. 14 2月, 2013 2 次提交
    • A
      burying unused conditionals · d64008a8
      Al Viro 提交于
      __ARCH_WANT_SYS_RT_SIGACTION,
      __ARCH_WANT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_RT_SIGSUSPEND,
      __ARCH_WANT_COMPAT_SYS_SCHED_RR_GET_INTERVAL - not used anymore
      CONFIG_GENERIC_{SIGALTSTACK,COMPAT_RT_SIG{ACTION,QUEUEINFO,PENDING,PROCMASK}} -
      can be assumed always set.
      d64008a8
    • A
      ARM: disable virt_to_bus/virt_to_bus almost everywhere · a5d533ee
      Arnd Bergmann 提交于
      We are getting a number of warnings about the use of the deprecated
      bus_to_virt function in drivers using the ARM ISA DMA API:
      
      drivers/parport/parport_pc.c: In function 'parport_pc_fifo_write_block_dma':
      drivers/parport/parport_pc.c:622:3: warning: 'bus_to_virt' is deprecated
      (declared at arch/arm/include/asm/memory.h:253) [-Wdeprecated-declarations]
      
      This is only because that function gets used by the inline
      set_dma_addr() helper. We know that any driver for the ISA DMA API
      is correctly using the DMA addresses, so we can change this
      to use the __bus_to_virt() function instead, which does not warn.
      
      After this, there are no remaining drivers that are used on
      any defconfigs on ARM using virt_to_bus or bus_to_virt, with
      the exception of the OSS sound driver. That driver is only used
      on RiscPC, NetWinder and Shark, so we can set ARCH_NO_VIRT_TO_BUS
      on all other platforms and hide the deprecated functions, which
      is far more effective than marking them as deprecated, in order
      to avoid any new users of that code.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Russell King <linux@arm.linux.org.uk>
      a5d533ee
  9. 12 2月, 2013 9 次提交
  10. 08 2月, 2013 1 次提交
  11. 06 2月, 2013 1 次提交
  12. 04 2月, 2013 3 次提交
  13. 01 2月, 2013 1 次提交
  14. 31 1月, 2013 4 次提交
  15. 30 1月, 2013 1 次提交
  16. 29 1月, 2013 1 次提交
  17. 28 1月, 2013 1 次提交
  18. 24 1月, 2013 2 次提交