1. 30 11月, 2010 1 次提交
  2. 02 10月, 2010 1 次提交
    • N
      ARM: add a vma entry for the user accessible vector page · ec706dab
      Nicolas Pitre 提交于
      The kernel makes the high vector page visible to user space. This page
      contains (amongst others) small code segments that can be executed in
      user space.  Make this page visible through ptrace and /proc/<pid>/mem
      in order to let gdb perform code parsing needed for proper unwinding.
      
      For example, the ERESTART_RESTARTBLOCK handler actually has a stack
      frame -- it returns to a PC value stored on the user's stack.   To
      unwind after a "sleep" system call was interrupted twice, GDB would
      have to recognize this situation and understand that stack frame
      layout -- which it currently cannot do.
      
      We could fix this by hard-coding addresses in the vector page range into
      GDB, but that isn't really portable as not all of those addresses are
      guaranteed to remain stable across kernel releases.  And having the gdb
      process make an exception for this page and get  content from its own
      address space for it looks strange, and it is not future proof either.
      
      Being located above PAGE_OFFSET, this vma cannot be deleted by
      user space code.
      Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
      ec706dab
  3. 05 8月, 2010 1 次提交
  4. 26 7月, 2010 1 次提交
    • R
      ARM: fix build warning in asm/elf.h · 392c57a2
      Russell King 提交于
        CC      kernel/elfcore.o
      In file included from include/linux/elf.h:7,
                       from kernel/elfcore.c:1:
      arch/arm/include/asm/elf.h:124: warning: 'struct mm_struct' declared inside parameter list
      arch/arm/include/asm/elf.h:124: warning: its scope is only this definition or declaration, which is probably not what you want
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      392c57a2
  5. 15 6月, 2010 1 次提交
  6. 01 5月, 2010 1 次提交
  7. 13 3月, 2010 1 次提交
    • M
      ARM: 5987/1: fix warning in kernel/elfcore.c from ARM's elf.h · bb35579b
      Mikael Pettersson 提交于
      2.6.34-rc1 added kernel/elfcore.c which includes <asm/elf.h>.
      On ARM, this results in:
      
      In file included from include/linux/elf.h:7,
                       from kernel/elfcore.c:1:
      /tmp/linux-2.6.34-rc1/arch/arm/include/asm/elf.h:101: warning: 'struct task_struct' declared inside parameter list
      /tmp/linux-2.6.34-rc1/arch/arm/include/asm/elf.h:101: warning: its scope is only this definition or declaration, which is probably not what you want
      
      Including <linux/sched.h> seems a bit heavyweight, so this patch just
      adds a tentative declaration of struct task_struct in <asm/elf.h>.
      Signed-off-by: NMikael Pettersson <mikpe@it.uu.se>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      bb35579b
  8. 16 12月, 2009 1 次提交
  9. 14 10月, 2009 1 次提交
  10. 24 7月, 2009 1 次提交
    • C
      Thumb-2: Add support for loadable modules · adca6dc2
      Catalin Marinas 提交于
      Modules compiled to Thumb-2 have two additional relocations needing to
      be resolved at load time, R_ARM_THM_CALL and R_ARM_THM_JUMP24, for BL
      and B.W instructions. The maximum Thumb-2 addressing range is +/-2^24
      (+/-16MB) therefore the MODULES_VADDR macro in asm/memory.h is set to
      (MODULES_END - 8MB) for the Thumb-2 compiled kernel.
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      adca6dc2
  11. 08 5月, 2009 1 次提交
  12. 21 3月, 2009 1 次提交
  13. 19 2月, 2009 1 次提交
  14. 16 10月, 2008 1 次提交
  15. 01 10月, 2008 2 次提交
  16. 03 8月, 2008 1 次提交
  17. 08 2月, 2008 1 次提交
  18. 21 7月, 2007 1 次提交
  19. 12 7月, 2007 1 次提交
  20. 18 12月, 2006 1 次提交
  21. 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
  22. 30 11月, 2006 2 次提交
  23. 21 9月, 2006 1 次提交
  24. 18 9月, 2006 1 次提交
  25. 26 4月, 2006 1 次提交
  26. 15 12月, 2005 1 次提交
  27. 30 9月, 2005 1 次提交
  28. 04 6月, 2005 1 次提交
  29. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4