Skip to content

L
linux
Switch branch/tag
  1. 20 Feb, 2005 10 commits
  3. 19 Feb, 2005 6 commits
  5. 18 Feb, 2005 1 commit
  7. 19 Feb, 2005 1 commit
  9. 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
  11. 17 Feb, 2005 14 commits
  13. 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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7