1. 11 Feb, 2007 1 commit
    • Al Viro's avatar
      [PATCH] Switch s390 to NO_IOMEM · 23db764d
      Al Viro authored
      Martin Schwidefsky wrote:
        "s390 does not even need (in|out)b(_p|).  I wondered what else from
         io.h do we not need.  The answer is: almost nothing.  With the devres
         patch from Al and the dma-mapping patch from Heiko we can get rid of
         iomem and all associated definitions."
      
      So we'll just need to replace NO_IOPORT with NO_IOMEM in Kconfig and
      kill arch/s390/mm/ioremap.c.
      
      BTW, there's an annoying bit of junk in there - IO_SPACE_LIMIT.  We
      only need it for /proc/ioports, which AFAICS shouldn't even be there
      on s390 (or uml).  OTOH, removing that thing would mean a user-visible
      change - we go from "empty file in /proc" to "no such file in /proc"...
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      23db764d
  2. 05 Feb, 2007 1 commit
  3. 04 Oct, 2006 1 commit
  4. 28 Sep, 2006 1 commit
    • Martin Schwidefsky's avatar
      [S390] Inline assembly cleanup. · 94c12cc7
      Martin Schwidefsky authored
      Major cleanup of all s390 inline assemblies. They now have a common
      coding style. Quite a few have been shortened, mainly by using register
      asm variables. Use of the EX_TABLE macro helps  as well. The atomic ops,
      bit ops and locking inlines new use the Q-constraint if a newer gcc
      is used.  That results in slightly better code.
      
      Thanks to Christian Borntraeger for proof reading the changes.
      Signed-off-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      94c12cc7
  5. 20 Sep, 2006 1 commit
  6. 20 Jun, 2006 1 commit
  7. 03 Feb, 2006 1 commit
  8. 09 Nov, 2005 1 commit
  9. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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