1. 12 5月, 2007 1 次提交
    • A
      [ARM] stacktrace fix · fac07790
      Andrew Morton 提交于
      ab1b6f03 said
      
       - remove the unused task argument to save_stack_trace, it's always current
      
      then broke arm:
      
      arch/arm/kernel/stacktrace.c:56: error: conflicting types for 'save_stack_trace'
      include/linux/stacktrace.h:11: error: previous declaration of 'save_stack_trace' was here
      arch/arm/kernel/stacktrace.c:56: error: conflicting types for 'save_stack_trace'
      include/linux/stacktrace.h:11: error: previous declaration of 'save_stack_trace' was here
      
      Cc: Christoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fac07790
  2. 09 5月, 2007 3 次提交
  3. 08 5月, 2007 3 次提交
  4. 06 5月, 2007 1 次提交
  5. 04 5月, 2007 1 次提交
    • N
      [ARM] 4227/1: minor head.S fixups · 40435792
      Nicolas Pitre 提交于
      Let's surround constructs like:
      
      	orr	r3, r3, #(KERNEL_RAM_PADDR & 0x00f00000)
      
      between .if .endif since (KERNEL_RAM_PADDR & 0x00f00000) is 0 in 99% of
      all cases.
      
      Also let's mask PHYS_OFFSET with 0x00f00000 instead of 0x00e00000.
      Section mappings are really 1MB not 2MB and the 2MB groupping is
      a higher level issue already much better enforced with
      
      #if (PHYS_OFFSET & 0x001fffff)
      #error "PHYS_OFFSET must be at an even 2MiB boundary!"
      #endif
      
      at the top of the file.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      40435792
  6. 03 5月, 2007 7 次提交
  7. 28 4月, 2007 1 次提交
  8. 22 4月, 2007 4 次提交
  9. 01 4月, 2007 1 次提交
  10. 13 3月, 2007 1 次提交
  11. 26 2月, 2007 2 次提交
  12. 17 2月, 2007 3 次提交
  13. 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
  14. 15 2月, 2007 1 次提交
    • E
      [PATCH] sysctl: remove insert_at_head from register_sysctl · 0b4d4147
      Eric W. Biederman 提交于
      The semantic effect of insert_at_head is that it would allow new registered
      sysctl entries to override existing sysctl entries of the same name.  Which is
      pain for caching and the proc interface never implemented.
      
      I have done an audit and discovered that none of the current users of
      register_sysctl care as (excpet for directories) they do not register
      duplicate sysctl entries.
      
      So this patch simply removes the support for overriding existing entries in
      the sys_sysctl interface since no one uses it or cares and it makes future
      enhancments harder.
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Acked-by: NRalf Baechle <ralf@linux-mips.org>
      Acked-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: David Howells <dhowells@redhat.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Corey Minyard <minyard@acm.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: James Bottomley <James.Bottomley@steeleye.com>
      Cc: Jan Kara <jack@ucw.cz>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: Mark Fasheh <mark.fasheh@oracle.com>
      Cc: David Chinner <dgc@sgi.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Patrick McHardy <kaber@trash.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0b4d4147
  15. 14 2月, 2007 1 次提交
  16. 13 2月, 2007 1 次提交
  17. 12 2月, 2007 3 次提交
  18. 10 2月, 2007 1 次提交
  19. 08 2月, 2007 2 次提交
  20. 07 2月, 2007 1 次提交
    • R
      [ARM] Move processor_modes[] to .../process.c · ae0a846e
      Russell King 提交于
      bad_mode() currently prints the mode which caused the exception, and
      then causes an oops dump to be printed which again displays this
      information (since the CPSR in the struct pt_regs is correct.)  This
      leads to processor_modes[] being shared between traps.c and process.c
      with a local declaration of it.
      
      We can clean this up by moving processor_modes[] to process.c and
      removing the duplication, resulting in processor_modes[] becoming
      static.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ae0a846e
  21. 24 1月, 2007 1 次提交
    • L
      [ARM] 4102/1: Allow for PHYS_OFFSET on any valid 2MiB address · d4e1c889
      Linus Walleij 提交于
      This patchs allows the offset to the first page of
      physical memory to be on any 2MB boundary
      whereas the previous code could only handle psysical
      offset to any 16MB boundary (0xNN000000) or any 1MB
      boundary below 0x01000000 (e.g. 0x00N00000). The
      problem is a consequence of the orr one-byte syntax,
      so we fix this and we can place the first bank of
      memory at 0x28e00000. I have also included an explicit
      check that disallow compilation when PHYS_OFFSET is
      not on a 2MiB boundary. head.S would be the proper place
      to have this at since this is the first file that
      attempts to use PHYS_OFFSET during compile.
      Signed-off-by: NLinus Walleij <triad@df.lth.se>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d4e1c889