1. 29 11月, 2011 1 次提交
  2. 01 11月, 2011 5 次提交
  3. 27 10月, 2011 1 次提交
  4. 25 10月, 2011 1 次提交
  5. 24 10月, 2011 1 次提交
  6. 08 9月, 2011 1 次提交
  7. 27 8月, 2011 1 次提交
  8. 20 8月, 2011 1 次提交
  9. 18 8月, 2011 1 次提交
  10. 27 7月, 2011 9 次提交
  11. 26 7月, 2011 2 次提交
  12. 23 7月, 2011 3 次提交
    • J
      iomap: make IOPORT/PCI mapping functions conditional · 82ed223c
      Jonas Bonn 提交于
      Use the CONFIG_HAS_IOPORT and CONFIG_PCI options to decide whether or
      not functions for mapping these areas are provided.
      Signed-off-by: NJonas Bonn <jonas@southpole.se>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      82ed223c
    • J
      asm-generic: add MMU variants of io.h functions · f1ecc698
      Jonas Bonn 提交于
      Some of the implementations, in particular the ioremap variants, in
      asm-generic/io.h are for systems without an MMU.  In order to be able to
      use the generic header file for systems with an MMU, this patch wraps
      these implementations in checks for CONFIG_MMU.
      
      Tested on OpenRISC.
      Signed-off-by: NJonas Bonn <jonas@southpole.se>
      Cc: liqin.chen@sunplusct.com
      Cc: gxt@mprc.pku.edu.cn
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      f1ecc698
    • A
      asm-generic: delay.h fix udelay and ndelay for 8 bit args · a87e553f
      Andrew Morton 提交于
      With a non-constant 8-bit argument, a call to udelay() generates a warning:
      
      drivers/gpu/drm/radeon/atom.c: In function 'atom_op_delay':
      drivers/gpu/drm/radeon/atom.c:654: warning: comparison is always false due to limited range of data type
      
      The code looks like it works OK with an 8-bit arg, and the calling code is
      doing nothing wrong, so udelay() needs fixing.
      
      Fixing it was rather tricky.  Simply typecasting `n' in the comparison with
      20000 didn't change anything.  Hence the divide-by-20000 trick.
      
      Using a do{}while loop didn't work because udelay() is used in ?: statements,
      hence the ({...}) construct.
      
      While I was there I replaced the brain-bending ?:?:?: mess with nice if/else
      code.
      
      Probably other architectures are generating the same warning and can use a
      similar change.
      
      [Taken from the x86 tree and moved to asm-generic by Jonas Bonn]
      
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJonas Bonn <jonas@southpole.se>
      a87e553f
  13. 22 7月, 2011 1 次提交
  14. 14 7月, 2011 1 次提交
  15. 13 7月, 2011 1 次提交
  16. 08 7月, 2011 1 次提交
    • J
      asm-generic: adapt delay.h to common implementation · 30ab2b03
      Jonas Bonn 提交于
      Several architectures are using a common delay.h implementation that
      appears to have originated with the x86 architecture.  This common
      implementation is a bit fuller than the current asm-generic version
      and has some compile-time checks that should be interesting for all
      architectures.
      
      This patch takes the common delay.h version and replaces the rather
      trivial asm-generic version with it.  As no architecture was actually
      using asm-generic/delay.h, this change is rather innocuous; it will,
      however, allow us to switch at least four architectures over to using
      the asm-generic version.
      Signed-off-by: NJonas Bonn <jonas@southpole.se>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      30ab2b03
  17. 16 6月, 2011 2 次提交
  18. 03 6月, 2011 1 次提交
  19. 29 5月, 2011 1 次提交
    • E
      ns: Wire up the setns system call · 7b21fddd
      Eric W. Biederman 提交于
      32bit and 64bit on x86 are tested and working.  The rest I have looked
      at closely and I can't find any problems.
      
      setns is an easy system call to wire up.  It just takes two ints so I
      don't expect any weird architecture porting problems.
      
      While doing this I have noticed that we have some architectures that are
      very slow to get new system calls.  cris seems to be the slowest where
      the last system calls wired up were preadv and pwritev.  avr32 is weird
      in that recvmmsg was wired up but never declared in unistd.h.  frv is
      behind with perf_event_open being the last syscall wired up.  On h8300
      the last system call wired up was epoll_wait.  On m32r the last system
      call wired up was fallocate.  mn10300 has recvmmsg as the last system
      call wired up.  The rest seem to at least have syncfs wired up which was
      new in the 2.6.39.
      
      v2: Most of the architecture support added by Daniel Lezcano <dlezcano@fr.ibm.com>
      v3: ported to v2.6.36-rc4 by: Eric W. Biederman <ebiederm@xmission.com>
      v4: Moved wiring up of the system call to another patch
      v5: ported to v2.6.39-rc6
      v6: rebased onto parisc-next and net-next to avoid syscall  conflicts.
      v7: ported to Linus's latest post 2.6.39 tree.
      
      >  arch/blackfin/include/asm/unistd.h     |    3 ++-
      >  arch/blackfin/mach-common/entry.S      |    1 +
      Acked-by: NMike Frysinger <vapier@gentoo.org>
      
      Oh - ia64 wiring looks good.
      Acked-by: NTony Luck <tony.luck@intel.com>
      Signed-off-by: NEric W. Biederman <ebiederm@xmission.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b21fddd
  20. 28 5月, 2011 1 次提交
  21. 27 5月, 2011 4 次提交