1. 01 11月, 2011 1 次提交
  2. 03 8月, 2011 1 次提交
  3. 22 7月, 2011 2 次提交
    • D
      net: Fix ppc64 BPF JIT dependencies. · 368940d0
      David S. Miller 提交于
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      368940d0
    • M
      net: filter: BPF 'JIT' compiler for PPC64 · 0ca87f05
      Matt Evans 提交于
      An implementation of a code generator for BPF programs to speed up packet
      filtering on PPC64, inspired by Eric Dumazet's x86-64 version.
      
      Filter code is generated as an ABI-compliant function in module_alloc()'d mem
      with stackframe & prologue/epilogue generated if required (simple filters don't
      need anything more than an li/blr).  The filter's local variables, M[], live in
      registers.  Supports all BPF opcodes, although "complicated" loads from negative
      packet offsets (e.g. SKF_LL_OFF) are not yet supported.
      
      There are a couple of further optimisations left for future work; many-pass
      assembly with branch-reach reduction and a register allocator to push M[]
      variables into volatile registers would improve the code quality further.
      
      This currently supports big-endian 64-bit PowerPC only (but is fairly simple
      to port to PPC32 or LE!).
      
      Enabled in the same way as x86-64:
      
      	echo 1 > /proc/sys/net/core/bpf_jit_enable
      
      Or, enabled with extra debug output:
      
      	echo 2 > /proc/sys/net/core/bpf_jit_enable
      Signed-off-by: NMatt Evans <matt@ozlabs.org>
      Acked-by: NEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0ca87f05
  4. 12 7月, 2011 1 次提交
  5. 01 7月, 2011 1 次提交
  6. 27 5月, 2011 1 次提交
  7. 26 5月, 2011 1 次提交
    • I
      powerpc/ftrace: Implement raw syscall tracepoints on PowerPC · 02424d89
      Ian Munsie 提交于
      This patch implements the raw syscall tracepoints on PowerPC and exports
      them for ftrace syscalls to use.
      
      To minimise reworking existing code, I slightly re-ordered the thread
      info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
      within the 16 bits of the andi. instruction's UI field. The instructions
      in question are in /arch/powerpc/kernel/entry_{32,64}.S to and the
      _TIF_SYSCALL_T_OR_A with the thread flags to see if system call tracing
      is enabled.
      
      In the case of 64bit PowerPC, arch_syscall_addr and
      arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
      work given the unusual system call table structure and symbol names that
      start with a period.
      Signed-off-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      02424d89
  8. 25 5月, 2011 1 次提交
  9. 20 4月, 2011 1 次提交
  10. 12 4月, 2011 1 次提交
  11. 30 3月, 2011 1 次提交
  12. 29 3月, 2011 1 次提交
  13. 24 3月, 2011 2 次提交
  14. 10 3月, 2011 1 次提交
  15. 21 1月, 2011 2 次提交
  16. 30 12月, 2010 1 次提交
    • S
      of/flattree: Add Kconfig for EARLY_FLATTREE · e6ce1324
      Stephen Neuendorffer 提交于
      The device tree code is now in two pieces: some which can be used generically
      on any platform which selects CONFIG_OF_FLATTREE, and some early which is used
      at boot time on only a few architectures.  This patch segregates the early
      code so that only those architectures which care about it need compile it.
      This also means that some of the requirements in the early code (such as
      a cmd_line variable) that most architectures (e.g. X86) don't provide
      can be ignored.
      Signed-off-by: NStephen Neuendorffer <stephen.neuendorffer@xilinx.com>
      [grant.likely@secretlab.ca: remove extra blank line addition]
      [grant.likely@secretlab.ca: fixed incorrect #ifdef CONFIG_EARLY_FLATTREE check]
      [grant.likely@secretlab.ca: Made OF_EARLY_FLATTREE select instead of depend
                                  on OF_FLATTREE]
      Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      e6ce1324
  17. 29 11月, 2010 2 次提交
  18. 18 11月, 2010 1 次提交
  19. 25 10月, 2010 1 次提交
  20. 19 10月, 2010 1 次提交
    • P
      irq_work: Add generic hardirq context callbacks · e360adbe
      Peter Zijlstra 提交于
      Provide a mechanism that allows running code in IRQ context. It is
      most useful for NMI code that needs to interact with the rest of the
      system -- like wakeup a task to drain buffers.
      
      Perf currently has such a mechanism, so extract that and provide it as
      a generic feature, independent of perf so that others may also
      benefit.
      
      The IRQ context callback is generated through self-IPIs where
      possible, or on architectures like powerpc the decrementer (the
      built-in timer facility) is set to generate an interrupt immediately.
      
      Architectures that don't have anything like this get to do with a
      callback from the timer tick. These architectures can call
      irq_work_run() at the tail of any IRQ handlers that might enqueue such
      work (like the perf IRQ handler) to avoid undue latencies in
      processing the work.
      Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Acked-by: NKyle McMartin <kyle@mcmartin.ca>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      [ various fixes ]
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      LKML-Reference: <1287036094.7768.291.camel@yhuang-dev>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      e360adbe
  21. 20 9月, 2010 1 次提交
  22. 03 8月, 2010 1 次提交
  23. 31 7月, 2010 1 次提交
  24. 27 7月, 2010 1 次提交
  25. 14 7月, 2010 1 次提交
  26. 09 7月, 2010 1 次提交
  27. 08 7月, 2010 1 次提交
  28. 06 7月, 2010 4 次提交
  29. 22 6月, 2010 1 次提交
    • K
      powerpc, hw_breakpoints: Implement hw_breakpoints for 64-bit server processors · 5aae8a53
      K.Prasad 提交于
      Implement perf-events based hw-breakpoint interfaces for PowerPC
      64-bit server (Book III S) processors.  This allows access to a
      given location to be used as an event that can be counted or
      profiled by the perf_events subsystem.
      
      This is done using the DABR (data breakpoint register), which can
      also be used for process debugging via ptrace.  When perf_event
      hw_breakpoint support is configured in, the perf_event subsystem
      manages the DABR and arbitrates access to it, and ptrace then
      creates a perf_event when it is requested to set a data breakpoint.
      
      [Adopted suggestions from Paul Mackerras <paulus@samba.org> to
      - emulate_step() all system-wide breakpoints and single-step only the
        per-task breakpoints
      - perform arch-specific cleanup before unregistration through
        arch_unregister_hw_breakpoint()
      ]
      Signed-off-by: NK.Prasad <prasad@linux.vnet.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      5aae8a53
  30. 28 5月, 2010 1 次提交
  31. 25 5月, 2010 1 次提交
    • S
      powerpc/kexec: Add support for FSL-BookE · b3df895a
      Sebastian Andrzej Siewior 提交于
      This adds support kexec on FSL-BookE where the MMU can not be simply
      switched off. The code borrows the initial MMU-setup code to create the
      identical mapping mapping. The only difference to the original boot code
      is the size of the mapping(s) and the executeable address.
      The kexec code maps the first 2 GiB of memory in 256 MiB steps. This
      should work also on e500v1 boxes.
      SMP support is still not available.
      
      (Kumar: Added minor change to build to ifdef CONFIG_PPC_STD_MMU_64 some
      code that was PPC64 specific)
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
      b3df895a
  32. 07 4月, 2010 1 次提交
  33. 19 3月, 2010 1 次提交
    • F
      powerpc: Remove IOMMU_VMERGE config option · 191aee58
      FUJITA Tomonori 提交于
      The description says:
      
       Cause IO segments sent to a device for DMA to be merged virtually
       by the IOMMU when they happen to have been allocated contiguously.
       This doesn't add pressure to the IOMMU allocator. However, some
       drivers don't support getting large merged segments coming back
       from *_map_sg().
      
       Most drivers don't have this problem; it is safe to say Y here.
      
      It's out of date. Long ago, drivers didn't have a way to tell IOMMUs
      about their segment length limit (that is, the maximum segment length
      that they can handle). So IOMMUs merged as many segments as possible
      and gave too large segments to drivers.
      
      dma_get_max_seg_size() was introduced to solve the above
      problem. Device drives can use the API to tell IOMMU about the maximum
      segment length that they can handle. In addition, the default limit
      (64K) should be safe for everyone.
      
      So this config option seems to be unnecessary.
      
      Note that this config option just enables users to disable the virtual
      merging by default. Users can still disable the virtual merging by the
      boot parameter.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      191aee58