1. 24 Apr, 2018 1 commit
    • Alexander Duyck's avatar
      PCI/IOV: Add pci-pf-stub driver for PFs that only enable VFs · a8ccf8a6
      Alexander Duyck authored
      Some SR-IOV PF devices provide no functionality other than acting as a
      means of enabling VFs.  For these devices, we want to enable the VFs and
      assign them to guest virtual machines, but there's no need to have a driver
      for the PF itself.
      Add a new pci-pf-stub driver to claim those PF devices and provide the
      generic VF enable functionality.  An administrator can use the sysfs
      "sriov_numvfs" file to enable VFs, then assign them to guests.
      For now I only have one example ID provided by Amazon in terms of devices
      that require this functionality.  The general idea is that in the future we
      will see other devices added as vendors come up with devices where the PF
      is more or less just a lightweight shim used to allocate VFs.
      Signed-off-by: default avatarAlexander Duyck <alexander.h.duyck@intel.com>
      [bhelgaas: changelog]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarGreg Rose <gvrose8192@gmail.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
  2. 19 Mar, 2018 1 commit
  3. 31 Jan, 2018 2 commits
  4. 23 Nov, 2017 1 commit
  5. 07 Nov, 2017 1 commit
  6. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard...
  7. 02 Jul, 2017 1 commit
  8. 20 Apr, 2017 1 commit
  9. 07 Mar, 2017 1 commit
  10. 21 Feb, 2017 2 commits
  11. 15 Jun, 2016 1 commit
  12. 11 May, 2016 1 commit
    • Jayachandran C's avatar
      PCI: Provide common functions for ECAM mapping · 35ff9477
      Jayachandran C authored
      Add config option PCI_ECAM and file drivers/pci/ecam.c to provide generic
      functions for accessing memory-mapped PCI config space.
      The API is defined in drivers/pci/ecam.h and is written to replace the API
      in drivers/pci/host/pci-host-common.h.  The file defines a new 'struct
      pci_config_window' to hold the information related to a PCI config area and
      its mapping.  This structure is expected to be used as sysdata for
      controllers that have ECAM based mapping.
      Helper functions are provided to setup the mapping, free the mapping and to
      implement the map_bus method in 'struct pci_ops'
      Signed-off-by: default avatarJayachandran C <jchandra@broadcom.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  13. 10 Mar, 2016 1 commit
  14. 20 Aug, 2015 1 commit
  15. 16 Dec, 2014 1 commit
    • Jiang Liu's avatar
      PCI: Remove PCI ioapic driver · 5db66334
      Jiang Liu authored
      To support IOAPIC hotplug on x86 and IA64 platforms, OS needs to figure
      out global interrupt source number(GSI) and IOAPIC enumeration ID
      through ACPI interfaces. So BIOS must implement an ACPI IOAPIC device
      with _GSB/_UID or _MAT method to support IOAPIC hotplug. OS also needs
      to figure out base physical address to access IOAPIC registers. OS may
      get the base physical address through PCI BARs if IOAPIC device is
      visible in PCI domain, otherwise OS may get the address by ACPI _CRS
      method if IOAPIC device is hidden from PCI domain by BIOS.
      When adding a PCI subtree, we need to add IOAPIC devices before enabling
      all other PCI devices because other PCI devices may use the IOAPIC to
      allocate PCI interrupts.
      So we plan to reimplement IOAPIC driver as an ACPI instead of PCI driver
      due to:
      1) hot-pluggable IOAPIC devices are always visible in ACPI domain,
         but may or may not be visible in PCI domain.
      2) we could explicitly control the order between IOAPIC and other PCI
      We also have another choice to use a PCI driver to manage IOAPIC device
      if it's visible in PCI domain and use an ACPI driver if it's only
      visible in ACPI domain. But this solution is a little complex.
      It shouldn't cause serious backward compatibility issues because:
      1) IOAPIC hotplug is never supported on x86 yet because it hasn't
         implemented the required acpi_register_ioapic() and
      2) Currently only ACPI based IOAPIC hotplug is possible on x86 and
         IA64, we don't know other specifications and interfaces to support
         IOAPIC hotplug yet.
      3) We will reimplement an ACPI IOAPIC driver to support IOAPIC hotplug.
      This change also helps to get rid of the false alarm on all current
      Linux distributions:
      [    6.952497] ioapic: probe of 0000:00:05.4 failed with error -22
      [    6.959542] ioapic: probe of 0000:80:05.4 failed with error -22
      Signed-off-by: default avatarJiang Liu <jiang.liu@linux.intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Link: http://lkml.kernel.org/r/1414387308-27148-9-git-send-email-jiang.liu@linux.intel.com
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  16. 27 Feb, 2014 1 commit
  17. 13 Feb, 2014 1 commit
  18. 18 Dec, 2013 1 commit
    • Alex Williamson's avatar
      PCI: Add Virtual Channel to save/restore support · 425c1b22
      Alex Williamson authored
      While we don't really have any infrastructure for making use of VC
      support, the system BIOS can configure the topology to non-default
      VC values prior to boot.  This may be due to silicon bugs, desire to
      reserve traffic classes, or perhaps just BIOS bugs.  When we reset
      devices, the VC configuration may return to default values, which can
      be incompatible with devices upstream.  For instance, Nvidia GRID
      cards provide a PCIe switch and some number of GPUs, all supporting
      VC.  The power-on default for VC is to support TC0-7 across VC0,
      however some platforms will only enable TC0/VC0 mapping across the
      topology.  When we do a secondary bus reset on the downstream switch
      port, the GPU is reset to a TC0-7/VC0 mapping while the opposite end
      of the link only enables TC0/VC0.  If the GPU attempts to use TC1-7,
      it fails.
      This patch attempts to provide complete support for VC save/restore,
      even beyond the minimally required use case above.  This includes
      save/restore and reload of the arbitration table, save/restore and
      reload of the port arbitration tables, and re-enabling of the
      channels for VC, VC9, and MFVC capabilities.
      Signed-off-by: default avatarAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  19. 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>
  20. 28 Nov, 2012 2 commits
  21. 13 Jul, 2012 1 commit
  22. 30 Apr, 2012 1 commit
  23. 26 Apr, 2012 1 commit
  24. 14 Oct, 2011 1 commit
  25. 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>
  26. 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>
  27. 02 Jun, 2011 1 commit
  28. 12 Apr, 2011 1 commit
  29. 17 Mar, 2011 1 commit
  30. 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>
  31. 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>
  32. 18 Oct, 2010 2 commits
  33. 30 Jul, 2010 1 commit
  34. 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>
  35. 28 Feb, 2010 1 commit
  36. 23 Feb, 2010 1 commit