1. 20 May, 2013 1 commit
    • Thomas Petazzoni's avatar
      pci: PCIe driver for Marvell Armada 370/XP systems · 45361a4f
      Thomas Petazzoni authored
      This driver implements the support for the PCIe interfaces on the
      Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
      cover earlier families of Marvell SoCs, such as Dove, Orion and
      The driver implements the hw_pci operations needed by the core ARM PCI
      code to setup PCI devices and get their corresponding IRQs, and the
      pci_ops operations that are used by the PCI core to read/write the
      configuration space of PCI devices.
      Since the PCIe interfaces of Marvell SoCs are completely separate and
      not linked together in a bus, this driver sets up an emulated PCI host
      bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
      In addition, this driver enumerates the different PCIe slots, and for
      those having a device plugged in, it sets up the necessary address
      decoding windows, using the mvebu-mbus driver.
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
  2. 28 Nov, 2012 2 commits
  3. 13 Jul, 2012 1 commit
  4. 30 Apr, 2012 1 commit
  5. 26 Apr, 2012 1 commit
  6. 14 Oct, 2011 1 commit
  7. 21 Jun, 2011 1 commit
    • Ohad Ben-Cohen's avatar
      x86/ia64: intel-iommu: move to drivers/iommu/ · 166e9278
      Ohad Ben-Cohen authored
      This should ease finding similarities with different platforms,
      with the intention of solving problems once in a generic framework
      which everyone can use.
      Note: to move intel-iommu.c, the declaration of pci_find_upstream_pcie_bridge()
      has to move from drivers/pci/pci.h to include/linux/pci.h. This is handled
      in this patch, too.
      As suggested, also drop DMAR's EXPERIMENTAL tag while we're at it.
      Compile-tested on x86_64.
      Signed-off-by: default avatarOhad Ben-Cohen <ohad@wizery.com>
      Signed-off-by: default avatarJoerg Roedel <joerg.roedel@amd.com>
  8. 07 Jun, 2011 1 commit
    • Benjamin Herrenschmidt's avatar
      pci/of: Match PCI devices to OF nodes dynamically · 98d9f30c
      Benjamin Herrenschmidt authored
      powerpc has two different ways of matching PCI devices to their
      corresponding OF node (if any) for historical reasons. The ppc64 one
      does a scan looking for matching bus/dev/fn, while the ppc32 one does a
      scan looking only for matching dev/fn on each level in order to be
      agnostic to busses being renumbered (which Linux does on some
      This removes both and instead moves the matching code to the PCI core
      itself. It's the most logical place to do it: when a pci_dev is created,
      we know the parent and thus can do a single level scan for the matching
      device_node (if any).
      The benefit is that all archs now get the matching for free. There's one
      hook the arch might want to provide to match a PHB bus to its device
      node. A default weak implementation is provided that looks for the
      parent device device node, but it's not entirely reliable on powerpc for
      various reasons so powerpc provides its own.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Acked-by: default avatarMichal Simek <monstr@monstr.eu>
      Acked-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  9. 02 Jun, 2011 1 commit
  10. 12 Apr, 2011 1 commit
  11. 17 Mar, 2011 1 commit
  12. 04 Mar, 2011 1 commit
    • Narendra_K@Dell.com's avatar
      PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs · 6058989b
      Narendra_K@Dell.com authored
      This patch exports ACPI _DSM (Device Specific Method) provided firmware
      instance number and string name of PCI devices as defined by 'PCI
      Firmware Specification Revision 3.1' section 4.6.7.( DSM for Naming a
      PCI or PCI Express Device Under Operating Systems) to sysfs.
      New files created are:
        /sys/bus/pci/devices/.../label which contains the firmware name for
      the device in question, and
        /sys/bus/pci/devices/.../acpi_index which contains the firmware device type
      instance for the given device.
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/acpi_index
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/label
      Embedded Broadcom 5709C NIC 1
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/acpi_index
      cat /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/label
      Embedded Broadcom 5709C NIC 2
      The ACPI _DSM provided firmware 'instance number' and 'string name' will
      be given priority if the firmware also provides 'SMBIOS type 41 device
      type instance and string'.
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Signed-off-by: default avatarJordan Hargrave <jordan_hargrave@dell.com>
      Signed-off-by: default avatarNarendra K <narendra_k@dell.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  13. 24 Nov, 2010 1 commit
    • Chris Metcalf's avatar
      pci root complex: support for tile architecture · f02cbbe6
      Chris Metcalf authored
      This change enables PCI root complex support for TILEPro.  Unlike
      TILE-Gx, TILEPro has no support for memory-mapped I/O, so the PCI
      support consists of hypervisor upcalls for PIO, DMA, etc.  However,
      the performance is fine for the devices we have tested with so far
      (1Gb Ethernet, SATA, etc.).
      The <asm/io.h> header was tweaked to be a little bit more aggressive
      about disabling attempts to map/unmap IO port space.  The hacky
      <asm/pci-bridge.h> header was rolled into the <asm/pci.h> header
      and the result was simplified.  Both of the latter two headers were
      preliminary versions not meant for release before now - oh well.
      There is one quirk for our TILEmpower platform, which accidentally
      negotiates up to 5GT and needs to be kicked down to 2.5GT.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
  14. 18 Oct, 2010 2 commits
  15. 30 Jul, 2010 1 commit
  16. 11 Mar, 2010 1 commit
    • Michal Simek's avatar
      microblaze: Enable PCI, missing files · a6475c13
      Michal Simek authored
      There are two parts of changes. The first is just enable
      PCI in Makefiles and in Kconfig. The second is the rest of
      missing files. I didn't want to add it with previous patch
      because that patch is too big.
      Current Microblaze toolchain has problem with weak symbols
      that's why is necessary to apply this changes to be possible
      to compile pci support.
      Xilinx knows about this problem.
      Signed-off-by: default avatarMichal Simek <monstr@monstr.eu>
  17. 28 Feb, 2010 1 commit
  18. 23 Feb, 2010 2 commits
    • Tilman Schmidt's avatar
      PCI: push deprecated pci_find_device() function to last user · 41a68a74
      Tilman Schmidt authored
      The ISDN4Linux HiSax driver family contains the last remaining users
      of the deprecated pci_find_device() function. This patch creates a
      private copy of that function in HiSax, and removes the now unused
      global function together with its controlling configuration option,
      Signed-off-by: default avatarTilman Schmidt <tilman@imap.cc>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
    • Rafael J. Wysocki's avatar
      PCI: Clean up build for CONFIG_PCI_QUIRKS unset · 93177a74
      Rafael J. Wysocki authored
      Currently, drivers/pci/quirks.c is built unconditionally, but if
      CONFIG_PCI_QUIRKS is unset, the only things actually built in this
      file are definitions of global variables and empty functions (due to
      the #ifdef CONFIG_PCI_QUIRKS embracing all of the code inside the
      file).  This is not particularly nice and if someone overlooks
      the #ifdef CONFIG_PCI_QUIRKS, build errors are introduced.
      To clean that up, move the definitions of the global variables in
      quirks.c that are always built to pci.c, move the definitions of
      the empty functions (compiled when CONFIG_PCI_QUIRKS is unset) to
      headers (additionally make these functions static inline) and modify
      drivers/pci/Makefile so that quirks.c is only built if
      CONFIG_PCI_QUIRKS is set.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  19. 04 Nov, 2009 1 commit
    • Bjorn Helgaas's avatar
      PCI hotplug: move IOAPIC support from acpiphp to ioapic driver · 204d49a5
      Bjorn Helgaas authored
      This patch moves PCI I/O APIC support from acpiphp to a separate driver.
      Like pciehp and shpchp, acpiphp handles PCI hotplug, i.e., addition and
      removal of PCI adapters.  But in addition, acpiphp handles some ACPI
      hotplug, such as the addition of new host bridges, and the I/O APIC
      support was tangled up with that.
      I don't think the I/O APIC support needs to be in acpiphp; PCI I/O APICs
      usually appear as a function on a PCI host bridge, and we'll enumerate the
      APIC before any of the devices behind the bridge that use it.
      As far as I know, nobody actually uses I/O APIC hotplug.  It depends on
      acpi_register_ioapic(), which is only implemented for ia64, and I don't
      think any vendors have supported I/O chassis hotplug yet.
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Reviewed-by: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      CC: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
      CC: MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  20. 09 Sep, 2009 1 commit
  21. 18 Jun, 2009 1 commit
  22. 21 May, 2009 1 commit
  23. 20 Mar, 2009 1 commit
  24. 07 Jan, 2009 1 commit
    • Chris Wright's avatar
      PCI: pci-stub module to reserve pci device · c70e0d9d
      Chris Wright authored
      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: default avatarChris Wright <chrisw@sous-sol.org>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  25. 23 Oct, 2008 1 commit
  26. 12 Jul, 2008 1 commit
  27. 10 Jul, 2008 2 commits
  28. 10 Jun, 2008 1 commit
    • Alex Chiang's avatar
      PCI: introduce pci_slot · f46753c5
      Alex Chiang authored
      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: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Acked-by: default avatarBenjamin 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: default avatarAlex Chiang <achiang@hp.com>
      Signed-off-by: default avatarMatthew 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: default avatarKenji Kaneshige <kaneshige.kenji@jp.fujitsu.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
  29. 08 Feb, 2008 1 commit
  30. 02 Feb, 2008 1 commit
    • Sam Ravnborg's avatar
      PCI: fix section mismatch warnings referring to pci_do_scan_bus · 4105717b
      Sam Ravnborg authored
      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: default avatarSam Ravnborg <sam@ravnborg.org>
      Cc: Adrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  31. 27 Jan, 2008 1 commit
  32. 22 Oct, 2007 2 commits
    • Keshavamurthy, Anil S's avatar
      Intel IOMMU: Intel IOMMU driver · ba395927
      Keshavamurthy, Anil S authored
      Actual intel IOMMU driver.  Hardware spec can be found at:
      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: default avatarAnil 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: default avatarAdrian Bunk <bunk@stusta.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Keshavamurthy, Anil S's avatar
      Intel IOMMU: DMAR detection and parsing logic · 10e5247f
      Keshavamurthy, Anil S authored
      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
      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
      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
      Signed-off-by: default avatarAnil 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  33. 11 Jul, 2007 1 commit
  34. 04 Oct, 2006 2 commits