1. 16 3月, 2009 1 次提交
  2. 13 3月, 2009 1 次提交
    • R
      [ARM] Fix virtual to physical translation macro corner cases · 1522ac3e
      Russell King 提交于
      The current use of these macros works well when the conversion is
      entirely linear.  In this case, we can be assured that the following
      holds true:
      
      	__va(p + s) - s = __va(p)
      
      However, this is not always the case, especially when there is a
      non-linear conversion (eg, when there is a 3.5GB hole in memory.)
      In this case, if 's' is the size of the region (eg, PAGE_SIZE) and
      'p' is the final page, the above is most definitely not true.
      
      So, we must ensure that __va() and __pa() are only used with valid
      kernel direct mapped RAM addresses.  This patch tweaks the code
      to achieve this.
      Tested-by: NCharles Moschel <fred99@carolina.rr.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      1522ac3e
  3. 01 12月, 2008 1 次提交
  4. 28 11月, 2008 2 次提交
  5. 02 10月, 2008 2 次提交
  6. 01 10月, 2008 1 次提交
  7. 06 9月, 2008 2 次提交
  8. 31 7月, 2008 1 次提交
  9. 25 7月, 2008 1 次提交
  10. 19 4月, 2008 1 次提交
  11. 08 2月, 2008 1 次提交
    • B
      Introduce flags for reserve_bootmem() · 72a7fe39
      Bernhard Walle 提交于
      This patchset adds a flags variable to reserve_bootmem() and uses the
      BOOTMEM_EXCLUSIVE flag in crashkernel reservation code to detect collisions
      between crashkernel area and already used memory.
      
      This patch:
      
      Change the reserve_bootmem() function to accept a new flag BOOTMEM_EXCLUSIVE.
      If that flag is set, the function returns with -EBUSY if the memory already
      has been reserved in the past.  This is to avoid conflicts.
      
      Because that code runs before SMP initialisation, there's no race condition
      inside reserve_bootmem_core().
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: fix powerpc build]
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Cc: <linux-arch@vger.kernel.org>
      Cc: "Eric W. Biederman" <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@in.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      72a7fe39
  12. 22 4月, 2007 1 次提交
  13. 24 1月, 2007 1 次提交
  14. 08 11月, 2006 1 次提交
  15. 27 9月, 2006 3 次提交
  16. 20 9月, 2006 1 次提交
  17. 01 7月, 2006 1 次提交
  18. 29 6月, 2006 1 次提交
  19. 07 4月, 2006 1 次提交
  20. 22 3月, 2006 2 次提交
  21. 18 11月, 2005 1 次提交
    • R
      [ARM] Fix some corner cases in new mm initialisation · 02b30839
      Russell King 提交于
      Document that the VMALLOC_END address must be aligned to 2MB since
      it must align with a PGD boundary.
      
      Allocate the vectors page early so that the flush_cache_all() later
      will cause any dirty cache lines in the direct mapping will be safely
      written back.
      
      Move the flush_cache_all() to the second local_flush_cache_tlb() and
      remove the now redundant first local_flush_cache_tlb().
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      02b30839
  22. 02 11月, 2005 1 次提交
  23. 29 10月, 2005 1 次提交
  24. 28 10月, 2005 2 次提交
  25. 28 6月, 2005 1 次提交
  26. 27 6月, 2005 1 次提交
  27. 23 6月, 2005 1 次提交
  28. 17 4月, 2005 2 次提交
    • A
      [PATCH] arm: add comment about max_low_pfn/max_pfn · d42ce812
      akpm@osdl.org 提交于
      )
      
      
      From: Russell King <rmk+lkml@arm.linux.org.uk>
      
      Oddly, max_low_pfn/max_pfn end up being the number of pages in the system,
      rather than the maximum PFN on ARM.  This doesn't seem to cause any problems,
      so just add a note about it.
      Signed-off-by: NRussell King <rmk@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d42ce812
    • L
      Linux-2.6.12-rc2 · 1da177e4
      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!
      1da177e4