1. 14 8月, 2009 1 次提交
  2. 30 5月, 2009 1 次提交
    • C
      Add core support for ARMv6/v7 big-endian · 26584853
      Catalin Marinas 提交于
      Starting with ARMv6, the CPUs support the BE-8 variant of big-endian
      (byte-invariant). This patch adds the core support:
      
      - setting of the BE-8 mode via the CPSR.E register for both kernel and
        user threads
      - big-endian page table walking
      - REV used to rotate instructions read from memory during fault
        processing as they are still little-endian format
      - Kconfig and Makefile support for BE-8. The --be8 option must be passed
        to the final linking stage to convert the instructions to
        little-endian
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      26584853
  3. 05 3月, 2009 1 次提交
    • U
      [ARM] 5418/1: restore lr before leaving mcount · d4cc510c
      Uwe Kleine-König 提交于
      gcc seems to expect that lr isn't clobbered by mcount, because for a
      function starting with:
      
      	static int func(void)
      	{
      		void *ra = __builtin_return_address(0);
      
      		printk(KERN_EMERG "__builtin_return_address(0) = %pS\n", ra)
      
      		...
      
      the following assembler is generated by gcc 4.3.2:
      
      	   0:   e1a0c00d        mov     ip, sp
      	   4:   e92dd810        push    {r4, fp, ip, lr, pc}
      	   8:   e24cb004        sub     fp, ip, #4      ; 0x4
      	   c:   ebfffffe        bl      0 <mcount>
      	  10:   e59f0034        ldr     r0, [pc, #52]
      	  14:   e1a0100e        mov     r1, lr
      	  18:   ebfffffe        bl      0 <printk>
      
      Without this patch obviously __builtin_return_address(0) yields
      func+0x10 instead of the return address of the caller.
      
      Note this patch fixes a similar issue for the routines used with dynamic
      ftrace even though this isn't currently selectable for ARM.
      
      Cc: Abhishek Sagar <sagar.abhishek@gmail.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      d4cc510c
  4. 19 2月, 2009 1 次提交
  5. 31 1月, 2009 1 次提交
  6. 21 10月, 2008 1 次提交
  7. 01 9月, 2008 1 次提交
  8. 07 8月, 2008 1 次提交
  9. 24 6月, 2008 1 次提交
  10. 02 6月, 2008 1 次提交
  11. 19 4月, 2008 1 次提交
  12. 26 1月, 2008 1 次提交
  13. 01 8月, 2007 1 次提交
  14. 17 2月, 2007 1 次提交
  15. 01 7月, 2006 1 次提交
  16. 25 6月, 2006 1 次提交
  17. 18 6月, 2006 1 次提交
    • P
      [ARM] 3335/1: Old-abi Thumb sys_syscall broken · 5247593c
      Paul Brook 提交于
      Patch from Paul Brook
      
      The old-abi sys_syscall syscall is broken when called from Thumb mode. It
      assumes the syscall number is an Arm syscall number (ie. starts from
      __NR_OABI_SYSCALL_BASE).  In thumb mode syscall numbers start from zero.
      
      The patch below fixes this by clearing the nigh bits of the syscall number
      instead of inverting them. Technically this means we accept some invalid
      syscall numbers, but I can't see how that could be a problem. The two sets of
      numbers far apart that unimplemented syscalls should still be rejected.
      Signed-off-by: NPaul Brook <paul@codesourcery.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      5247593c
  18. 19 1月, 2006 1 次提交
    • A
      [ARM] safer handling of syscall table padding · fa1b4f91
      Al Viro 提交于
      ARM entry-common.S needs to know syscall table size; in itself that would
      not be a problem, but there's an additional constraint - some of the
      instructions using it want a constant that would be a multiple of 4.
      So we have to pad syscall table with sys_ni_syscall and that's where
      the trouble begins.  .rept pseudo-op wants a constant expression for
      number of repetitions and subtraction of two labels (before and after
      syscall table) doesn't always get simplified to constant early enough
      for .rept.  If labels end up in different frags, we lose.  And while
      the frag size is large enough (slightly below 4Kb), the syscall table
      is about 1/3 of that.  We used to get away with that, but the recent
      changes had been enough to trigger the breakage.
      
      Proper fix is simple: have a macro (CALL(x)) to populate the table
      instead of using explicit .long x and the first time we include calls.S
      have it defined to .equ NR_syscalls,NR_syscalls+1.  Then we can find
      the proper amount of padding on the first inclusion simply by looking
      at NR_syscalls at that time.  And that will be constant, no matter what.
      
      Moreover, the same trick kills the need of having an estimate of padded
      NR_syscalls - it will be calculated for free at the same time.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      fa1b4f91
  19. 15 1月, 2006 5 次提交
  20. 17 12月, 2005 1 次提交
  21. 19 11月, 2005 1 次提交
    • D
      [ARM] 3168/1: Update ARM signal delivery and masking · a6c61e9d
      Daniel Jacobowitz 提交于
      Patch from Daniel Jacobowitz
      
      After delivering a signal (creating its stack frame) we must check for
      additional pending unblocked signals before returning to userspace.
      Otherwise signals may be delayed past the next syscall or reschedule.
      
      Once that was fixed it became obvious that the ARM signal mask manipulation
      was broken.  It was a little bit broken before the recent SA_NODEFER
      changes, and then very broken after them.  We must block the requested
      signals before starting the handler or the same signal can be delivered
      again before the handler even gets a chance to run.
      Signed-off-by: NDaniel Jacobowitz <dan@codesourcery.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      a6c61e9d
  22. 13 10月, 2005 1 次提交
  23. 14 9月, 2005 1 次提交
  24. 10 9月, 2005 1 次提交
  25. 01 9月, 2005 1 次提交
    • N
      [ARM] 2865/2: fix fadvise64_64 syscall argument passing · 68d9102f
      Nicolas Pitre 提交于
      Patch from Nicolas Pitre
      
      The prototype for sys_fadvise64_64() is:
          long sys_fadvise64_64(int fd, loff_t offset, loff_t len, int advice)
      The argument list is therefore as follows on legacy ABI:
      	fd: type int (r0)
      	offset: type long long (r1-r2)
      	len: type long long (r3-sp[0])
      	advice: type int (sp[4])
      With EABI this becomes:
      	fd: type int (r0)
      	offset: type long long (r2-r3)
      	len: type long long (sp[0]-sp[4])
      	advice: type int (sp[8])
      Not only do we have ABI differences here, but the EABI version requires
      one additional word on the syscall stack.
      To avoid the ABI mismatch and the extra stack space required with EABI
      this syscall is now defined with a different argument ordering
      on ARM as follows:
          long sys_arm_fadvise64_64(int fd, int advice, loff_t offset, loff_t len)
      This gives us the following ABI independent argument distribution:
      	fd: type int (r0)
      	advice: type int (r1)
      	offset: type long long (r2-r3)
      	len: type long long (sp[0]-sp[4])
      Now, since the syscall entry code takes care of 5 registers only by
      default including the store of r4 to the stack, we need a wrapper to
      store r5 to the stack as well.  Because that wrapper was missing and was
      always required this means that sys_fadvise64_64 never worked on ARM and
      therefore we can safely reuse its syscall number for our new
      sys_arm_fadvise64_64 interface.
      Signed-off-by: NNicolas Pitre <nico@cam.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      68d9102f
  26. 26 4月, 2005 5 次提交
  27. 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