- 14 5月, 2012 1 次提交
-
-
由 David S. Miller 提交于
This eliminated most of the remaining users of btfixup. There are some complications because of the special cases we have for sun4d, leon, and some flavors of viking. It was found that there are no cases where a flush_page_for_dma method was not hooked up to something, so the "noflush" iommu methods were removed. Add some documentation to the viking_sun4d_smp_ops to describe exactly the hardware bug which causes us to need special TLB flushing on sun4d. Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 12 5月, 2012 1 次提交
-
-
由 Sam Ravnborg 提交于
Signed-off-by: NSam Ravnborg <sam@ravnborg.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 29 3月, 2012 1 次提交
-
-
由 David Howells 提交于
Disintegrate asm/system.h for Sparc. Signed-off-by: NDavid Howells <dhowells@redhat.com> cc: sparclinux@vger.kernel.org
-
- 15 12月, 2011 1 次提交
-
-
由 David S. Miller 提交于
The "(insn & 0x01800000) != 0x01800000" test matches 'restore' but that is a legitimate place to see the %lo() part of a 32-bit symbol relocation, particularly in tail calls. Signed-off-by: NDavid S. Miller <davem@davemloft.net> Tested-by: NSergei Trofimovich <slyfox@gentoo.org>
-
- 01 9月, 2008 1 次提交
-
-
由 Adrian Bunk 提交于
While doing some easy cleanups on the sparc code I noticed that the CONFIG_SUN4 code seems to be worse than the rest - there were some "I don't know how it should work, but the current code definitely cannot work." places. And while I have seen people running Linux on machines like a SPARCstation 5 a few years ago I don't recall having seen sun4 machines, even less ones running Linux. Signed-off-by: NAdrian Bunk <bunk@kernel.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 27 10月, 2007 1 次提交
-
-
由 David S. Miller 提交于
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 01 7月, 2006 1 次提交
-
-
由 Jörn Engel 提交于
Signed-off-by: NJörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: NAdrian Bunk <bunk@stusta.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
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!
-