- 07 8月, 2008 1 次提交
-
-
由 Greg Ungerer 提交于
With the current kbuild infrastructure in place no other changes are required for this to work. Signed-off-by: NGreg Ungerer <gerg@uclinux.org>
-
- 24 8月, 2007 1 次提交
-
-
由 Greg Ungerer 提交于
Include asm-generic/pgtable.h to pick up the lazy_mmu_mode and lazy_cpu_mode macros. Won't build without them. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 20 7月, 2007 1 次提交
-
-
由 Greg Ungerer 提交于
Remove is_in_rom() function. It doesn't actually serve the purpose it was intended to. If you look at the use of it _access_ok() (which is the only use of it) then it is obvious that most of memory is marked as access_ok. No point having is_in_rom() then, so remove it. Signed-off-by: NGreg Ungerer <gerg@uclinux.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 09 5月, 2007 1 次提交
-
-
由 David Gibson 提交于
Most architectures defined three macros, MK_IOSPACE_PFN(), GET_IOSPACE() and GET_PFN() in pgtable.h. However, the only callers of any of these macros are in Sparc specific code, either in arch/sparc, arch/sparc64 or drivers/sbus. This patch removes the redundant macros from all architectures except sparc and sparc64. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Cc: <linux-arch@vger.kernel.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 26 4月, 2006 1 次提交
-
-
由 David Woodhouse 提交于
Signed-off-by: NDavid Woodhouse <dwmw2@infradead.org>
-
- 13 9月, 2005 1 次提交
-
-
由 Randy Dunlap 提交于
As written in Documentation/feature-removal-schedule.txt, remove the io_remap_page_range() kernel API. Signed-off-by: NRandy Dunlap <rdunlap@xenotime.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 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!
-