1. 07 9月, 2005 1 次提交
  2. 06 9月, 2005 1 次提交
  3. 05 9月, 2005 5 次提交
  4. 01 9月, 2005 2 次提交
    • 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
    • D
      [ARM] 2869/1: ixp4xx: correct ioread*/iowrite* · 147056fb
      David Vrabel 提交于
      Patch from David Vrabel
      
      Correct the ioread* and iowrite* functions.  In particular, add an offset to the cookie in ioport_map so we can map I/O port ranges starting from 0 (0 is for reporting errors).
      Signed-off-by: NDavid Vrabel <dvrabel@arcom.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      147056fb
  5. 30 8月, 2005 5 次提交
  6. 24 8月, 2005 2 次提交
  7. 19 8月, 2005 1 次提交
  8. 18 8月, 2005 1 次提交
  9. 15 8月, 2005 1 次提交
  10. 10 8月, 2005 3 次提交
  11. 05 8月, 2005 1 次提交
  12. 29 7月, 2005 1 次提交
  13. 27 7月, 2005 4 次提交
  14. 24 7月, 2005 1 次提交
  15. 18 7月, 2005 1 次提交
  16. 17 7月, 2005 1 次提交
  17. 12 7月, 2005 2 次提交
  18. 11 7月, 2005 4 次提交
  19. 07 7月, 2005 2 次提交
    • T
      [MTD] XIP cleanup · 97f927a4
      Thomas Gleixner 提交于
      Move the architecture dependend code into include/asm/mtd-xip.h
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      97f927a4
    • D
      [PATCH] ARM: 2792/1: IXP4xx iomap API implementation · 450008b5
      Deepak Saxena 提交于
      Patch from Deepak Saxena
      
      This patch implements the iomap API for Intel IXP4xx NPU systems.
      We need to implement our own version of the API functions b/c of the
      PCI hostbridge does not provide the capability to map PCI I/O space
      into the CPU's physical memory space. In addition, if a system has
      more than 64M of PCI memory mapped BARs, PCI memory must also be
      accessed indirectly.  This patch changes the assignment of PCI I/O
      resources to fall into to 0x0000:0xffff range so that we can trap
      I/O areas in our ioread/iowrite macros.
      
      Signed-off-by: Deepak Saxena
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      450008b5
  20. 04 7月, 2005 1 次提交