1. 02 4月, 2011 1 次提交
  2. 23 2月, 2011 1 次提交
  3. 23 12月, 2010 1 次提交
  4. 20 12月, 2010 2 次提交
  5. 26 11月, 2010 1 次提交
  6. 20 11月, 2010 1 次提交
  7. 04 11月, 2010 1 次提交
  8. 08 9月, 2010 1 次提交
  9. 09 7月, 2010 1 次提交
  10. 07 7月, 2010 1 次提交
  11. 16 2月, 2010 1 次提交
  12. 13 2月, 2010 2 次提交
  13. 09 12月, 2009 1 次提交
  14. 02 12月, 2009 1 次提交
  15. 20 9月, 2009 1 次提交
    • S
      arm, cris, mips, sparc, powerpc, um, xtensa: fix build with bash 4.0 · 51b563fc
      Sam Ravnborg 提交于
      Albin Tonnerre <albin.tonnerre@free-electrons.com> reported:
      
          Bash 4 filters out variables which contain a dot in them.
          This happends to be the case of CPPFLAGS_vmlinux.lds.
          This is rather unfortunate, as it now causes
          build failures when using SHELL=/bin/bash to compile,
          or when bash happens to be used by make (eg when it's /bin/sh)
      
      Remove the common definition of CPPFLAGS_vmlinux.lds by
      pushing relevant stuff to either Makefile.build or the
      arch specific kernel/Makefile where we build the linker script.
      
      This is also nice cleanup as we move the information out where
      it is used.
      
      Notes for the different architectures touched:
      
      arm - we use an already exported symbol
      cris - we use a config symbol aleady available
             [Not build tested]
      mips - the jiffies complexity has moved to vmlinux.lds.S where we need it.
             Added a few variables to CPPFLAGS - they are only used by
             the linker script.
             [Not build tested]
      powerpc - removed assignment that is not needed
                [not build tested]
      sparc - simplified it using $(BITS)
      um - introduced a few new exported variables to deal with this
      xtensa - added options to CPP invocation
               [not build tested]
      
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      51b563fc
  16. 16 9月, 2009 1 次提交
  17. 22 7月, 2009 1 次提交
    • U
      [ARM] 5613/1: implement CALLER_ADDRESSx · 4bf1fa5a
      Uwe Kleine-König 提交于
      From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      
      As __builtin_return_address(n) doesn't work for ARM with n > 0, the
      kernel needs its own implementation.
      
      This fixes many warnings saying:
      
      	warning: unsupported argument to '__builtin_return_address'
      
      The new methods and walk_stackframe must not be instrumented because
      CALLER_ADDRESSx is used in the various tracers and tracing the tracer is
      a bad idea.
      
      What's currently missing is an implementation using unwind tables.  This
      is not fatal though, it's just that the tracers don't get enough
      information to be really useful.
      
      Note that if both ARM_UNWIND and FRAME_POINTER are enabled,
      walk_stackframe uses unwind information.  So in this case the same
      implementation is used as when FRAME_POINTER is disabled.
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4bf1fa5a
  18. 18 5月, 2009 2 次提交
  19. 23 3月, 2009 1 次提交
  20. 19 2月, 2009 1 次提交
  21. 01 10月, 2008 1 次提交
  22. 24 7月, 2008 1 次提交
    • J
      kgdb: support for ARCH=arm · 5cbad0eb
      Jason Wessel 提交于
      This patch adds the ARCH=arm specific a kgdb backend, originally
      written by Deepak Saxena <dsaxena@plexity.net> and George Davis
      <gdavis@mvista.com>.  Geoff Levand <geoffrey.levand@am.sony.com>,
      Nicolas Pitre, Manish Lachwani, and Jason Wessel have contributed
      various fixups here as well.
      
      The KGDB patch makes one change to the core ARM architecture such that
      the traps are initialized early for use with the debugger or other
      subsystems.
      
      [ mingo@elte.hu: small cleanups. ]
      [ ben-linux@fluff.org: fixed early_trap_init ]
      Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
      Acked-by: NDeepak Saxena <dsaxena@plexity.net>
      5cbad0eb
  23. 02 6月, 2008 1 次提交
  24. 19 4月, 2008 1 次提交
  25. 17 4月, 2008 1 次提交
  26. 04 2月, 2008 1 次提交
    • R
      [ARM] 4736/1: Export atags to userspace and allow kexec to use customised atags · 4cd9d6f7
      Richard Purdie 提交于
      Currently, the atags used by kexec are fixed to the ones originally used
      to boot the kernel. This is less than ideal as changing the commandline,
      initrd and other options would be a useful feature.
      
      This patch exports the atags used for the current kernel to userspace
      through an "atags" file in procfs. The presence of the file is
      controlled by its own Kconfig option and cleans up several ifdef blocks
      into a separate file. The tags for the new kernel are assumed to be at
      a fixed location before the kernel image itself. The location of the
      tags used to boot the original kernel is unimportant and no longer
      saved.
      
      Based on a patch from Uli Luckas <u.luckas@road.de>
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Acked-by: NUli Luckas <u.luckas@road.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4cd9d6f7
  27. 26 1月, 2008 2 次提交
    • A
      ARM kprobes: core code · 24ba613c
      Abhishek Sagar 提交于
      This is a full implementation of Kprobes including Jprobes and
      Kretprobes support.
      
      This ARM implementation does not follow the usual kprobes double-
      exception model. The traditional model is where the initial kprobes
      breakpoint calls kprobe_handler(), which returns from exception to
      execute the instruction in its original context, then immediately
      re-enters after a second breakpoint (or single-stepping exception)
      into post_kprobe_handler(), each time the probe is hit..  The ARM
      implementation only executes one kprobes exception per hit, so no
      post_kprobe_handler() phase. All side-effects from the kprobe'd
      instruction are resolved before returning from the initial exception.
      As a result, all instructions are _always_ effectively boosted
      regardless of the type of instruction, and even regardless of whether
      or not there is a post-handler for the probe.
      Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
      Signed-off-by: NQuentin Barnes <qbarnes@gmail.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      24ba613c
    • Q
      ARM kprobes: instruction single-stepping support · 35aa1df4
      Quentin Barnes 提交于
      This is the code implementing instruction single-stepping for kprobes
      on ARM.
      
      To get around the limitation of no Next-PC and no hardware single-
      stepping, all kprobe'd instructions are split into three camps:
      simulation, emulation, and rejected. "Simulated" instructions are
      those instructions which behavior is reproduced by straight C code.
      "Emulated" instructions are ones that are copied, slightly altered
      and executed directly in the instruction slot to reproduce their
      behavior.  "Rejected" instructions are ones that could be simulated,
      but work hasn't been put into simulating them. These instructions
      should be very rare, if not unencountered, in the kernel. If ever
      needed, code could be added to simulate them.
      
      One might wonder why this and the ptrace singlestep facility are not
      sharing some code.  Both approaches are fundamentally different because
      the ptrace code regains control after the stepped instruction by installing
      a breakpoint after the instruction itself, and possibly at the location
      where the instruction might be branching to, instead of simulating or
      emulating the target instruction.
      
      The ptrace approach isn't suitable for kprobes because the breakpoints
      would have to be moved back, and the icache flushed, everytime the
      probe is hit to let normal code execution resume, which would have a
      significant performance impact. It is also racy on SMP since another
      CPU could, with the right timing, sail through the probe point without
      being caught.  Because ptrace single-stepping always result in a
      different process to be scheduled, the concern for performance is much
      less significant.
      
      On the other hand, the kprobes approach isn't (currently) suitable for
      ptrace because it has no provision for proper user space memory
      protection and translation, and even if that was implemented, the gain
      wouldn't be worth the added complexity in the ptrace path compared to
      the current approach.
      
      So, until kprobes does support user space, both kprobes and ptrace are
      best kept independent and separate.
      Signed-off-by: NQuentin Barnes <qbarnes@gmail.com>
      Signed-off-by: NAbhishek Sagar <sagar.abhishek@gmail.com>
      Signed-off-by: NNicolas Pitre <nico@marvell.com>
      35aa1df4
  28. 28 4月, 2007 1 次提交
  29. 16 2月, 2007 1 次提交
    • R
      [ARM] 4137/1: Add kexec support · c587e4a6
      Richard Purdie 提交于
      Add kexec support to ARM.
      
      Improvements like commandline handling could be made but this patch gives
      basic functional support. It uses the next available syscall number, 347.
      
      Once the syscall number is known, userspace support will be
      finalised/submitted to kexec-tools, various patches already exist.
      
      Originally based on a patch by Maxim Syrchin but updated and forward
      ported by various people.
      Signed-off-by: NRichard Purdie <rpurdie@rpsys.net>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      c587e4a6
  30. 10 2月, 2007 1 次提交
  31. 04 12月, 2006 1 次提交
    • L
      [ARM] 3881/4: xscale: clean up cp0/cp1 handling · afe4b25e
      Lennert Buytenhek 提交于
      XScale cores either have a DSP coprocessor (which contains a single
      40 bit accumulator register), or an iWMMXt coprocessor (which contains
      eight 64 bit registers.)
      
      Because of the small amount of state in the DSP coprocessor, access to
      the DSP coprocessor (CP0) is always enabled, and DSP context switching
      is done unconditionally on every task switch.  Access to the iWMMXt
      coprocessor (CP0/CP1) is enabled only when an iWMMXt instruction is
      first issued, and iWMMXt context switching is done lazily.
      
      CONFIG_IWMMXT is supposed to mean 'the cpu we will be running on will
      have iWMMXt support', but boards are supposed to select this config
      symbol by hand, and at least one pxa27x board doesn't get this right,
      so on that board, proc-xscale.S will incorrectly assume that we have a
      DSP coprocessor, enable CP0 on boot, and we will then only save the
      first iWMMXt register (wR0) on context switches, which is Bad.
      
      This patch redefines CONFIG_IWMMXT as 'the cpu we will be running on
      might have iWMMXt support, and we will enable iWMMXt context switching
      if it does.'  This means that with this patch, running a CONFIG_IWMMXT=n
      kernel on an iWMMXt-capable CPU will no longer potentially corrupt iWMMXt
      state over context switches, and running a CONFIG_IWMMXT=y kernel on a
      non-iWMMXt capable CPU will still do DSP context save/restore.
      
      These changes should make iWMMXt work on PXA3xx, and as a side effect,
      enable proper acc0 save/restore on non-iWMMXt capable xsc3 cores such
      as IOP13xx and IXP23xx (which will not have CONFIG_CPU_XSCALE defined),
      as well as setting and using HWCAP_IWMMXT properly.
      Signed-off-by: NLennert Buytenhek <buytenh@wantstofly.org>
      Acked-by: NDan Williams <dan.j.williams@intel.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      afe4b25e
  32. 28 8月, 2006 1 次提交
  33. 02 7月, 2006 1 次提交
  34. 29 6月, 2006 1 次提交
  35. 24 4月, 2006 1 次提交
  36. 15 1月, 2006 1 次提交