1. 13 4月, 2007 1 次提交
  2. 28 3月, 2006 1 次提交
    • P
      ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc · 0a26b136
      Paul Mackerras 提交于
      32-bit CHRP machines are now supported only in arch/powerpc, as are
      all 64-bit PowerPC processors.  This means that we don't use
      Open Firmware on any platform in arch/ppc any more.
      
      This makes PReP support a single-platform option like every other
      platform support option in arch/ppc now, thus CONFIG_PPC_MULTIPLATFORM
      is gone from arch/ppc.  CONFIG_PPC_PREP is the option that selects
      PReP support and is generally what has replaced
      CONFIG_PPC_MULTIPLATFORM within arch/ppc.
      
      _machine is all but dead now, being #defined to 0.
      
      Updated Makefiles, comments and Kconfig options generally to reflect
      these changes.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a26b136
  3. 15 1月, 2006 1 次提交
    • P
      [PATCH] ppc: Remove powermac support from ARCH=ppc · a7fdd90b
      Paul Mackerras 提交于
      This makes it possible to build kernels for PReP and/or CHRP
      with ARCH=ppc by removing the (non-building) powermac support.
      It's now also possible to select PReP and CHRP independently.
      Powermac users should now build with ARCH=powerpc instead of
      ARCH=ppc.  (This does mean that it is no longer possible to
      build a 32-bit kernel for a G5.)
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      a7fdd90b
  4. 09 1月, 2006 2 次提交
    • B
      [PATCH] powerpc: Update OF address parsers · d2dd482b
      Benjamin Herrenschmidt 提交于
      This updates the OF address parsers to return the IO flags
      indicating the type of address obtained. It also adds a PCI
      call for converting physical addresses that hit IO space into
      into IO tokens, and add routines that return the translated
      addresses into struct resource
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d2dd482b
    • B
      [PATCH] powerpc: Add OF address parsing code (#2) · d1405b86
      Benjamin Herrenschmidt 提交于
      Parsing addresses extracted from Open Firmware isn't a simple matter. We
      have various bits of code that try to do it in various place, including
      some heuristics in prom.c that pre-parse addresses at boot and fill
      device-nodes "addrs", but those are dodgy at best and I want to
      deprecate them. So this patch introduces a new set of routines that
      should be capable of parsing most types of addresses and translating
      them into CPU physical addresses. It currently works for things on PCI
      busses and ISA busses and should work on "standard" busses like the root
      bus or the MacIO bus that don't put funky flags in addresses. If you
      have other bus types that do use funky flags, you'll have to add new bus
      type translators, which is fairly easy.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      d1405b86
  5. 08 11月, 2005 1 次提交
  6. 17 4月, 2005 2 次提交
    • B
      [PATCH] ppc32: fix compilation error in include/asm/prom.h · cd2c169e
      Benoit Boissinot 提交于
      make defconfig give the following error on ppc (gcc-4):
      
      arch/ppc/syslib/prom_init.c:120: error: static declaration of ‘prom_display_paths’ follows non-static declaration
      include/asm/prom.h:17: error: previous declaration of ‘prom_display_paths’ was here
      arch/ppc/syslib/prom_init.c:122: error: static declaration of ‘prom_num_displays’ follows non-static declaration
      include/asm/prom.h:18: error: previous declaration of ‘prom_num_displays’ was here
      Signed-Off-By: NBenoit Boissinot <benoit.boissinot@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      cd2c169e
    • 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