1. 10 9月, 2009 1 次提交
  2. 19 6月, 2009 1 次提交
  3. 21 5月, 2009 1 次提交
  4. 21 3月, 2009 1 次提交
  5. 08 1月, 2009 1 次提交
    • C
      PCI: pci-stub module to reserve pci device · c70e0d9d
      Chris Wright 提交于
      When doing device assignment with KVM there's currently nothing to
      protect the device from having a driver in the host as well as the guest.
      This trivial module just binds the pci device on the host to a stub
      driver so that a real host driver can't bind to the device.  It has no
      pci id table, it supports only dynamic ids.
      
       # echo "8086 10f5" > /sys/bus/pci/drivers/pci-stub/new_id
       # echo -n 0000:00:19.0 > /sys/bus/pci/drivers/e1000e/unbind
       # echo -n 0000:00:19.0 > /sys/bus/pci/drivers/pci-stub/bind
       # ls -l /sys/bus/pci/devices/0000:00:19.0/driver
       lrwxrwxrwx 1 root root 0 2008-11-25 19:10 /sys/bus/pci/devices/0000:00:19.0/driver -> ../../../bus/pci/drivers/pci-stub
      
      Cc: "Kay, Allen M" <allen.m.kay@intel.com>
      Cc: "Nakajima, Jun" <jun.nakajima@intel.com>
      Signed-off-by: NChris Wright <chrisw@sous-sol.org>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      c70e0d9d
  6. 24 10月, 2008 1 次提交
  7. 12 7月, 2008 1 次提交
  8. 11 7月, 2008 2 次提交
  9. 11 6月, 2008 1 次提交
    • A
      PCI: introduce pci_slot · f46753c5
      Alex Chiang 提交于
      Currently, /sys/bus/pci/slots/ only exposes hotplug attributes when a
      hotplug driver is loaded, but PCI slots have attributes such as address,
      speed, width, etc.  that are not related to hotplug at all.
      
      Introduce pci_slot as the primary data structure and kobject model.
      Hotplug attributes described in hotplug_slot become a secondary
      structure associated with the pci_slot.
      
      This patch only creates the infrastructure that allows the separation of
      PCI slot attributes and hotplug attributes.  In this patch, the PCI
      hotplug core remains the only user of this infrastructure, and thus,
      /sys/bus/pci/slots/ will still only become populated when a hotplug
      driver is loaded.
      
      A later patch in this series will add a second user of this new
      infrastructure and demonstrate splitting the task of exposing pci_slot
      attributes from hotplug_slot attributes.
      
        - Make pci_slot the primary sysfs entity. hotplug_slot becomes a
          subsidiary structure.
          o pci_create_slot() creates and registers a slot with the PCI core
          o pci_slot_add_hotplug() gives it hotplug capability
      
        - Change the prototype of pci_hp_register() to take the bus and
          slot number (on parent bus) as parameters.
      
        - Remove all the ->get_address methods since this functionality is
          now handled by pci_slot directly.
      
      [achiang@hp.com: rpaphp-correctly-pci_hp_register-for-empty-pci-slots]
      Tested-by: NBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      [akpm@linux-foundation.org: build fix]
      [akpm@linux-foundation.org: make headers_check happy]
      [akpm@linux-foundation.org: nuther build fix]
      [akpm@linux-foundation.org: fix typo in #include]
      Signed-off-by: NAlex Chiang <achiang@hp.com>
      Signed-off-by: NMatthew Wilcox <matthew@wil.cx>
      Cc: Greg KH <greg@kroah.com>
      Cc: Kristen Carlson Accardi <kristen.c.accardi@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Acked-by: NKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
      f46753c5
  10. 09 2月, 2008 1 次提交
  11. 03 2月, 2008 1 次提交
    • S
      PCI: fix section mismatch warnings referring to pci_do_scan_bus · 4105717b
      Sam Ravnborg 提交于
      Fix following warnings:
      WARNING: o-x86_64/drivers/pci/built-in.o(.text+0xb054): Section mismatch in reference from the function cpci_configure_slot() to the function .devinit.text:pci_do_scan_bus()
      WARNING: o-x86_64/drivers/pci/built-in.o(.text+0x153ab): Section mismatch in reference from the function shpchp_configure_device() to the function .devinit.text:pci_do_scan_bus()
      WARNING: o-x86_64/drivers/pci/built-in.o(__ksymtab+0xc0): Section mismatch in reference from the variable __ksymtab_pci_do_scan_bus to the function .devinit.text:pci_do_scan_bus()
      
      PCI hotplug were the only user of pci_do_scan_bus()
      so moving this function to a separate file that is build
      only when we enable CONFIG_HOTPLUG_PCI.
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      Cc: Adrian Bunk <bunk@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4105717b
  12. 28 1月, 2008 1 次提交
  13. 22 10月, 2007 2 次提交
    • K
      Intel IOMMU: Intel IOMMU driver · ba395927
      Keshavamurthy, Anil S 提交于
      Actual intel IOMMU driver.  Hardware spec can be found at:
      http://www.intel.com/technology/virtualization
      
      This driver sets X86_64 'dma_ops', so hook into standard DMA APIs.  In this
      way, PCI driver will get virtual DMA address.  This change is transparent to
      PCI drivers.
      
      [akpm@linux-foundation.org: remove unneeded cast]
      [akpm@linux-foundation.org: build fix]
      [bunk@stusta.de: fix duplicate CONFIG_DMAR Makefile line]
      Signed-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ba395927
    • K
      Intel IOMMU: DMAR detection and parsing logic · 10e5247f
      Keshavamurthy, Anil S 提交于
      This patch supports the upcomming Intel IOMMU hardware a.k.a.  Intel(R)
      Virtualization Technology for Directed I/O Architecture and the hardware spec
      for the same can be found here
      http://www.intel.com/technology/virtualization/index.htm
      
      FAQ! (questions from akpm, answers from ak)
      
      > So...  what's all this code for?
      >
      > I assume that the intent here is to speed things up under Xen, etc?
      
      Yes in some cases, but not this code.  That would be the Xen version of this
      code that could potentially assign whole devices to guests.  I expect this to
      be only useful in some special cases though because most hardware is not
      virtualizable and you typically want an own instance for each guest.
      
      Ok at some point KVM might implement this too; i likely would use this code
      for this.
      
      > Do we
      > have any benchmark results to help us to decide whether a merge would be
      > justified?
      
      The main advantage for doing it in the normal kernel is not performance, but
      more safety.  Broken devices won't be able to corrupt memory by doing random
      DMA.
      
      Unfortunately that doesn't work for graphics yet, for that need user space
      interfaces for the X server are needed.
      
      There are some potential performance benefits too:
      
      - When you have a device that cannot address the complete address range an
        IOMMU can remap its memory instead of bounce buffering.  Remapping is likely
        cheaper than copying.
      
      - The IOMMU can merge sg lists into a single virtual block.  This could
        potentially speed up SG IO when the device is slow walking SG lists.  [I
        long ago benchmarked 5% on some block benchmark with an old MPT Fusion; but
        it probably depends a lot on the HBA]
      
      And you get better driver debugging because unexpected memory accesses from
      the devices will cause a trappable event.
      
      >
      > Does it slow anything down?
      
      It adds more overhead to each IO so yes.
      
      This patch:
      
      Add support for early detection and parsing of DMAR's (DMA Remapping) reported
      to OS via ACPI tables.
      
      DMA remapping(DMAR) devices support enables independent address translations
      for Direct Memory Access(DMA) from Devices.  These DMA remapping devices are
      reported via ACPI tables and includes pci device scope covered by these DMA
      remapping device.
      
      For detailed info on the specification of "Intel(R) Virtualization Technology
      for Directed I/O Architecture" please see
      http://www.intel.com/technology/virtualization/index.htmSigned-off-by: NAnil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Muli Ben-Yehuda <muli@il.ibm.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Cc: Arjan van de Ven <arjan@infradead.org>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Christoph Lameter <clameter@sgi.com>
      Cc: Greg KH <greg@kroah.com>
      Cc: Len Brown <lenb@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      10e5247f
  14. 12 7月, 2007 1 次提交
  15. 04 10月, 2006 4 次提交
    • E
      [PATCH] htirq: tidy up the htirq code · 95d77884
      Eric W. Biederman 提交于
      This moves the declarations for the architecture helpers into
      include/linux/htirq.h from the generic include/linux/pci.h.  Hopefully this
      will make this distinction clearer.
      
      htirq.h is included where it is needed.
      
      The dependency on the msi code is fixed and removed.
      
      The Makefile is tidied up.
      Signed-off-by: NEric 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      95d77884
    • E
      [PATCH] msi: move the ia64 code into arch/ia64 · 03571e11
      Eric W. Biederman 提交于
      This is just a few makefile tweaks and some file renames.
      Signed-off-by: NEric 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      03571e11
    • E
      [PATCH] Initial generic hypertransport interrupt support · 8b955b0d
      Eric W. Biederman 提交于
      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: NEric 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8b955b0d
    • E
      [PATCH] genirq: msi: only build msi-apic.c on ia64 · 4b2fabb9
      Eric W. Biederman 提交于
      After the previous changes ia64 is the only architecture useing msi-apic.c
      
      [akpm@osdl.org: unbreak MSI on ia64]
      Signed-off-by: NEric 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4b2fabb9
  16. 22 6月, 2006 1 次提交
  17. 17 12月, 2005 1 次提交
  18. 09 9月, 2005 2 次提交
    • D
      [PATCH] Make sparc64 use setup-res.c · 085ae41f
      David S. Miller 提交于
      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: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      085ae41f
    • A
      [PATCH] PCI: remove CONFIG_PCI_NAMES · 982245f0
      Adrian Bunk 提交于
      This patch removes CONFIG_PCI_NAMES.
      Signed-off-by: NAdrian Bunk <bunk@stusta.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      982245f0
  19. 02 7月, 2005 1 次提交
  20. 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