1. 04 Oct, 2006 3 commits
    • Eric W. Biederman's avatar
      [PATCH] msi: move the ia64 code into arch/ia64 · 03571e11
      Eric W. Biederman authored
      
      
      This is just a few makefile tweaks and some file renames.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg KH <greg@kroah.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      03571e11
    • Eric W. Biederman's avatar
      [PATCH] Initial generic hypertransport interrupt support · 8b955b0d
      Eric W. Biederman authored
      
      
      This patch implements two functions ht_create_irq and ht_destroy_irq for
      use by drivers.  Several other functions are implemented as helpers for
      arch specific irq_chip handlers.
      
      The driver for the card I tested this on isn't yet ready to be merged.
      However this code is and hypertransport irqs are in use in a few other
      places in the kernel.  Not that any of this will get merged before 2.6.19
      
      Because the ipath-ht400 is slightly out of spec this code will need to be
      generalized to work there.
      
      I think all of the powerpc uses are for a plain interrupt controller in a
      chipset so support for native hypertransport devices is a little less
      interesting.
      
      However I think this is a half way decent model on how to separate arch
      specific and generic helper code, and I think this is a functional model of
      how to get the architecture dependencies out of the msi code.
      
      [akpm@osdl.org: Kconfig fix]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      8b955b0d
    • Eric W. Biederman's avatar
      [PATCH] genirq: msi: only build msi-apic.c on ia64 · 4b2fabb9
      Eric W. Biederman authored
      
      
      After the previous changes ia64 is the only architecture useing msi-apic.c
      
      [akpm@osdl.org: unbreak MSI on ia64]
      Signed-off-by: default avatarEric W. Biederman <ebiederm@xmission.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rajesh Shah <rajesh.shah@intel.com>
      Cc: Andi Kleen <ak@muc.de>
      Cc: "Protasevich, Natalie" <Natalie.Protasevich@UNISYS.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4b2fabb9
  2. 21 Jun, 2006 1 commit
  3. 16 Dec, 2005 1 commit
  4. 08 Sep, 2005 2 commits
    • David S. Miller's avatar
      [PATCH] Make sparc64 use setup-res.c · 085ae41f
      David S. Miller authored
      
      
      There were three changes necessary in order to allow
      sparc64 to use setup-res.c:
      
      1) Sparc64 roots the PCI I/O and MEM address space using
         parent resources contained in the PCI controller structure.
         I'm actually surprised no other platforms do this, especially
         ones like Alpha and PPC{,64}.  These resources get linked into the
         iomem/ioport tree when PCI controllers are probed.
      
         So the hierarchy looks like this:
      
         iomem --|
      	   PCI controller 1 MEM space --|
      				        device 1
      					device 2
      					etc.
      	   PCI controller 2 MEM space --|
      				        ...
         ioport --|
                  PCI controller 1 IO space --|
      					...
                  PCI controller 2 IO space --|
      					...
      
         You get the idea.  The drivers/pci/setup-res.c code allocates
         using plain iomem_space and ioport_space as the root, so that
         wouldn't work with the above setup.
      
         So I added a pcibios_select_root() that is used to handle this.
         It uses the PCI controller struct's io_space and mem_space on
         sparc64, and io{port,mem}_resource on every other platform to
         keep current behavior.
      
      2) quirk_io_region() is buggy.  It takes in raw BUS view addresses
         and tries to use them as a PCI resource.
      
         pci_claim_resource() expects the resource to be fully formed when
         it gets called.  The sparc64 implementation would do the translation
         but that's absolutely wrong, because if the same resource gets
         released then re-claimed we'll adjust things twice.
      
         So I fixed up quirk_io_region() to do the proper pcibios_bus_to_resource()
         conversion before passing it on to pci_claim_resource().
      
      3) I was mistakedly __init'ing the function methods the PCI controller
         drivers provide on sparc64 to implement some parts of these
         routines.  This was, of course, easy to fix.
      
      So we end up with the following, and that nasty SPARC64 makefile
      ifdef in drivers/pci/Makefile is finally zapped.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      085ae41f
    • Adrian Bunk's avatar
      [PATCH] PCI: remove CONFIG_PCI_NAMES · 982245f0
      Adrian Bunk authored
      
      
      This patch removes CONFIG_PCI_NAMES.
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      982245f0
  5. 01 Jul, 2005 1 commit
  6. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      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