1. 20 Feb, 2005 10 commits
  2. 19 Feb, 2005 6 commits
  3. 18 Feb, 2005 1 commit
  4. 19 Feb, 2005 1 commit
  5. 18 Feb, 2005 6 commits
    • Linus Torvalds's avatar
      Merge bk://bk.arm.linux.org.uk/linux-2.6-rmk · 41740fe8
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      41740fe8
    • Russell King's avatar
      [ARM] Take account of vm_pgoff for DMA mmap · 04320dad
      Russell King authored
      The DMA mmap code was ignoring vm_pgoff which prevented a partial
      mmap() of a DMA buffer.
      Signed-off-by: default avatarRussell King <rmk@arm.linux.org.uk>
      04320dad
    • Lennert Buytenhek's avatar
      [ARM PATCH] 2494/1: fix 'CONFGI_' -> 'CONFIG_' in mach-ixp2000/ixdp2x00.c · 7478a481
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      Fix a misspelled config symbol name in the ixp2000 code.
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Russell King
      7478a481
    • Lennert Buytenhek's avatar
      [ARM PATCH] 2493/1: put IXP2000 slowport in 8-bit mode after boot · bb12ca40
      Lennert Buytenhek authored
      Patch from Lennert Buytenhek
      
      This is an old patch from 2.6.9-rc3-ds2 that never made it upstream.
      The IXP2000 slowport has two modes of operation, 8-bit and 32-bit.
      The slowport itself is a byte-wide bus, and in 8-bit mode, it does the
      more-or-less obvious thing: every word read causes four byte reads,
      and those bytes are then combined into a word according to the xscale
      core's current endian setting.  So, what value you get depends on what
      endianity your IXP2000 is running in.
      In 32-bit mode, however, it is the slowport itself which combines
      bytes into words, and for this it unconditionally uses little endian
      mode.  In this mode, word reads from the slowport will return the
      same value no matter whether the xscale core is running in big or
      little endian mode.  This can be a plus in some cases.  Byte (and
      halfword) accesses in 32-bit mode have rather useless semantics
      due to this, though.
      The usefulness of 32-bit mode is limited to the initial boot.  When
      the IXP2000 resets, the slowport is always in 32-bit mode, so if you
      flash the bootloader into flash (which is connected to the slowport)
      using little-endian byte ordering, the xscale will always read the
      instruction stream correctly, no matter whether it's running in big
      or little endian mode.
      After booting it makes no sense to use 32-bit mode anymore.  Especially
      since the slowport's word ordering in 32-bit mode is little endian,
      and the IXP2000 is conventionally run in big endian, which gives all
      kinds of fun issues when trying to access peripherals connected to
      the slowport.
      In fact, the current MTD map driver for IXP2000 already sets the
      slowport to 8-bit mode because it cannot access the flash otherwise.
      However, this means that if the MTD map driver is not compiled in for
      some reason, the slowport will stay in 32-bit mode after the initial
      boot, which will cause peripheral accesses to unexpectedly break!
      
      Signed-off-by: Lennert Buytenhek
      Signed-off-by: Russell King
      bb12ca40
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/sparc-2.6 · ed343ca9
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.6/linux
      ed343ca9
    • David S. Miller's avatar
      [SPARC64]: BUG on rediculious memcpy lengths. · 2b424f63
      David S. Miller authored
      Anything larger than MAX_INT is suspect.  Do this
      for user copies too.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2b424f63
  6. 17 Feb, 2005 14 commits
  7. 16 Feb, 2005 2 commits
    • Nick Piggin's avatar
      [PATCH] optimise copy page range · 97a4e84b
      Nick Piggin authored
      Suggested by Linus: optimise a condition in the clear_p?d_range functions.
      Results in one less conditional branch on i386 with gcc-3.4.4
      Signed-off-by: default avatarNick Piggin <nickpiggin@yahoo.com.au>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      97a4e84b
    • Benjamin Herrenschmidt's avatar
      [PATCH] Fix buf in zeromap_pud_range() losing virtual address · 02567099
      Benjamin Herrenschmidt authored
      This patch fixes a nasty bug that took us almost a week to track down on
      ppc64, introduced by the 4L page table changes, and resulting in random
      memory corruption. All archs that rely on a PTE page's struct page to
      contain the mm & address (in mapping/index) will be affected.
      
      zeromap_pud_range() is one of these page tables walking functions that
      split the address into a base and an offset. It forgets to add back the
      "base" when calling the lower level zeromap_pmd_range(), thus passing a
      bogus virtual address. Most archs won't care, unless they do the above,
      since the lower level can allocate a PTE page.
      
      Kudo's to Michael Ellerman too who spent that week running tests after
      tests to track it down, since the only way we managed to get it to show
      up was after about 1 to 2h of LTP runs ...
      
      (Note: We are in _urgent_ need to consolidate all those page table
      walking functions, they all do things in a subtely different way, with
      different checks (sometimes redudant) and inconsitent with each other,
      even within a given set of them. Hopefully, Nick has some work in
      progress there).
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      02567099