1. 19 4月, 2006 1 次提交
  2. 28 3月, 2006 1 次提交
    • D
      [PATCH] unify PFN_* macros · 22a9835c
      Dave Hansen 提交于
      Just about every architecture defines some macros to do operations on pfns.
       They're all virtually identical.  This patch consolidates all of them.
      
      One minor glitch is that at least i386 uses them in a very skeletal header
      file.  To keep away from #include dependency hell, I stuck the new
      definitions in a new, isolated header.
      
      Of all of the implementations, sh64 is the only one that varied by a bit.
      It used some masks to ensure that any sign-extension got ripped away before
      the arithmetic is done.  This has been posted to that sh64 maintainers and
      the development list.
      
      Compiles on x86, x86_64, ia64 and ppc64.
      Signed-off-by: NDave Hansen <haveblue@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      22a9835c
  3. 21 3月, 2006 1 次提交
  4. 28 2月, 2006 1 次提交
    • R
      [MIPS] SMP: Fix initialization order bug. · 9b6695a8
      Ralf Baechle 提交于
          
      A recent change requires cpu_possible_map to be initialized before
      smp_sched_init() but most MIPS platforms were initializing their
      processors in the prom_prepare_cpus callback of smp_prepare_cpus.  The
      simple fix of calling prom_prepare_cpus from one of the earlier SMP
      initialization hooks doesn't work well either since IPIs may require
      init_IRQ() to have completed, so bit the bullet and split
      prom_prepare_cpus into two initialization functions, plat_smp_setup
      which is called early from setup_arch and plat_prepare_cpus called where
      prom_prepare_cpus used to be called.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      9b6695a8
  5. 30 10月, 2005 3 次提交
  6. 05 9月, 2005 1 次提交
  7. 26 6月, 2005 1 次提交
  8. 17 4月, 2005 1 次提交
    • 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