26 Feb, 2013

1 commit

  • Pull PCI changes from Bjorn Helgaas:
    "Host bridge hotplug
    - Major overhaul of ACPI host bridge add/start (Rafael Wysocki, Yinghai Lu)
    - Major overhaul of PCI/ACPI binding (Rafael Wysocki, Yinghai Lu)
    - Split out ACPI host bridge and ACPI PCI device hotplug (Yinghai Lu)
    - Stop caching _PRT and make independent of bus numbers (Yinghai Lu)

    PCI device hotplug
    - Clean up cpqphp dead code (Sasha Levin)
    - Disable ARI unless device and upstream bridge support it (Yijing Wang)
    - Initialize all hot-added devices (not functions 0-7) (Yijing Wang)

    Power management
    - Don't touch ASPM if disabled (Joe Lawrence)
    - Fix ASPM link state management (Myron Stowe)

    Miscellaneous
    - Fix PCI_EXP_FLAGS accessor (Alex Williamson)
    - Disable Bus Master in pci_device_shutdown (Konstantin Khlebnikov)
    - Document hotplug resource and MPS parameters (Yijing Wang)
    - Add accessor for PCIe capabilities (Myron Stowe)
    - Drop pciehp suspend/resume messages (Paul Bolle)
    - Make pci_slot built-in only (not a module) (Jiang Liu)
    - Remove unused PCI/ACPI bind ops (Jiang Liu)
    - Removed used pci_root_bus (Bjorn Helgaas)"

    * tag 'pci-v3.9-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (51 commits)
    PCI/ACPI: Don't cache _PRT, and don't associate them with bus numbers
    PCI: Fix PCI Express Capability accessors for PCI_EXP_FLAGS
    ACPI / PCI: Make pci_slot built-in only, not a module
    PCI/PM: Clear state_saved during suspend
    PCI: Use atomic_inc_return() rather than atomic_add_return()
    PCI: Catch attempts to disable already-disabled devices
    PCI: Disable Bus Master unconditionally in pci_device_shutdown()
    PCI: acpiphp: Remove dead code for PCI host bridge hotplug
    PCI: acpiphp: Create companion ACPI devices before creating PCI devices
    PCI: Remove unused "rc" in virtfn_add_bus()
    PCI: pciehp: Drop suspend/resume ENTRY messages
    PCI/ASPM: Don't touch ASPM if forcibly disabled
    PCI/ASPM: Deallocate upstream link state even if device is not PCIe
    PCI: Document MPS parameters pci=pcie_bus_safe, pci=pcie_bus_perf, etc
    PCI: Document hpiosize= and hpmemsize= resource reservation parameters
    PCI: Use PCI Express Capability accessor
    PCI: Introduce accessor to retrieve PCIe Capabilities Register
    PCI: Put pci_dev in device tree as early as possible
    PCI: Skip attaching driver in device_add()
    PCI: acpiphp: Keep driver loaded even if no slots found
    ...

    Linus Torvalds
     

02 Feb, 2013

1 commit


26 Jan, 2013

1 commit

  • We want to put pci_dev structs in the device tree as soon as possible so
    for_each_pci_dev() iteration will not miss them, but driver attachment
    needs to be delayed until after pci_assign_unassigned_resources() to make
    sure all devices have resources assigned first.

    This patch moves device registering from pci_bus_add_devices() to
    pci_device_add(), which happens earlier, leaving driver attachment in
    pci_bus_add_devices().

    It also removes unattached child bus handling in pci_bus_add_devices().
    That's not needed because child bus via pci_add_new_bus() is already
    in parent bus children list.

    [bhelgaas: changelog]
    Signed-off-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas
    Acked-by: Rafael J. Wysocki

    Yinghai Lu
     

11 Jan, 2013

1 commit


10 Nov, 2012

3 commits


21 Sep, 2012

1 commit

  • This reverts commit 433efd2247b0cbf5e7e86275e1f21281d3b99047.

    When we remove an SR-IOV device, we have this call chain:

    driver .remove() method
    pci_disable_sriov()
    sriov_disable()
    virtfn_remove()
    pci_get_domain_bus_and_slot()

    sriov_disable() is only called for PFs, not for VFs. When it's called
    for a PF, it loops through all the VFs and calls virtfn_remove() for
    each. But we stop and remove VFs before PFs, so by the time we get
    to virtfn_remove(), the VFs have already been stopped and deleted
    from the device list. Now pci_get_domain_bus_and_slot(), which uses
    bus_find_device() and relies on that device list, doesn't find the
    VFs, so the VF references aren't released correctly.

    Reported-by: Yinghai Lu
    Signed-off-by: Bjorn Helgaas

    Bjorn Helgaas
     

18 Sep, 2012

1 commit

  • * pci/jiang-get-domain-bus-slot:
    xen-pcifront: Use hotplug-safe pci_get_domain_bus_and_slot()
    PCI: Use hotplug-safe pci_get_domain_bus_and_slot()
    PCI/cpcihp: Use hotplug-safe pci_get_domain_bus_and_slot()
    PCI/vga: Use hotplug-safe pci_get_domain_bus_and_slot()
    ia64/PCI: Use hotplug-safe pci_get_domain_bus_and_slot()

    Bjorn Helgaas
     

13 Sep, 2012

1 commit

  • Following code has a race window between pci_find_bus() and pci_get_slot()
    if PCI hotplug operation happens between them which removes the pci_bus.
    So use PCI hotplug safe interface pci_get_domain_bus_and_slot() instead,
    which also reduces code complexity.

    struct pci_bus *pci_bus = pci_find_bus(domain, busno);
    struct pci_dev *pci_dev = pci_get_slot(pci_bus, devfn);

    Signed-off-by: Jiang Liu
    Signed-off-by: Bjorn Helgaas

    Jiang Liu
     

23 Aug, 2012

1 commit


14 Jun, 2012

2 commits


28 Feb, 2012

1 commit


18 Feb, 2012

1 commit


11 Feb, 2012

1 commit

  • For an SRIOV device, PCI_SRIOV_SYS_PGSIZE should be set before
    the PCI_SRIOV_BAR are queried. The sys pagesize defaults to 4k,
    so this change is required on powerpc box with 64k base page size.

    This is a regression caused due to moving SRIOV init to sriov_enable().

    | commit afd24ece5c76af87f6fc477f2747b83a764f161c
    | Author: Ram Pai

    | PCI: delay configuration of SRIOV capability
    | The SRIOV capability, namely page size and total_vfs of a device are
    | configured during enumeration phase of the device. This can potentially
    | interfere with the PCI operations of the platform, if the IOV capability
    | of the device is not enabled.

    Signed-off-by: Vaidyanathan Srinivasan
    Acked-by: Ram Pai
    Signed-off-by: Jesse Barnes

    Vaidyanathan Srinivasan
     

07 Jan, 2012

2 commits

  • The SRIOV capability, namely page size and total_vfs of a device are
    configured during enumeration phase of the device. This can potentially
    interfere with the PCI operations of the platform, if the IOV capability
    of the device is not enabled.

    The following patch postpones the configuration of the IOV capability of
    the device to a later point, when the IOV capability is explicitly
    enabled by the device driver.

    The patch is tested on x86 and power platform.

    Tested-by: Donald Dutile
    Signed-off-by: Ram Pai
    Signed-off-by: Jesse Barnes

    Ram Pai
     
  • pci_block_user_cfg_access was designed for the use case that a single
    context, the IPR driver, temporarily delays user space accesses to the
    config space via sysfs. This assumption became invalid by the time
    pci_dev_reset was added as locking instance. Today, if you run two loops
    in parallel that reset the same device via sysfs, you end up with a
    kernel BUG as pci_block_user_cfg_access detect the broken assumption.

    This reworks the pci_block_user_cfg_access to a sleeping service
    pci_cfg_access_lock and an atomic-compatible variant called
    pci_cfg_access_trylock. The former not only blocks user space access as
    before but also waits if access was already locked. The latter service
    just returns false in this case, allowing the caller to resolve the
    conflict instead of raising a BUG.

    Adaptions of the ipr driver were originally written by Brian King.

    Acked-by: Brian King
    Acked-by: Michael S. Tsirkin
    Signed-off-by: Jan Kiszka
    Signed-off-by: Jesse Barnes

    Jan Kiszka
     

06 Dec, 2011

1 commit

  • All the PCI BARs of a device are enabled when the device is enabled
    using pci_enable_device(). This unnecessarily enables SRIOV BARs of the
    device.

    On some platforms, which do not support SRIOV as yet, the
    pci_enable_device() fails to enable the device if its SRIOV BARs are not
    allocated resources correctly.

    The following patch fixes the above problem. The SRIOV BARs are now
    enabled when IOV capability of the device is enabled in sriov_enable().

    NOTE: Note, there is subtle change in the pci_enable_device() API. Any
    driver that depends on SRIOV BARS to be enabled in pci_enable_device()
    can fail.

    The patch has been touch tested on power and x86 platform.

    Tested-by: Michael Wang
    Signed-off-by: Ram Pai
    Signed-off-by: Jesse Barnes

    Ram Pai
     

01 Nov, 2011

1 commit


15 Oct, 2011

1 commit

  • ATS does not depend on IOV support, so move the code into
    its own file. This file will also include support for the
    PRI and PASID capabilities later.
    Also give ATS its own Kconfig variable to allow selecting it
    without IOV support.

    Reviewed-by: Bjorn Helgaas
    Signed-off-by: Joerg Roedel
    Signed-off-by: Jesse Barnes

    Joerg Roedel
     

11 Apr, 2011

1 commit

  • This patch moves the relevant declarations from the local
    header file in drivers/pci to a more accessible locations so
    that it can be used by the AMD IOMMU driver too.
    The file is named pci-ats.h because support for the PCI PRI
    capability will also be added there in a later patch-set.

    Signed-off-by: Joerg Roedel
    Acked-by: Jesse Barnes

    Joerg Roedel
     

10 Sep, 2010

1 commit

  • This fixes the prototype for both pci_resource_alignment() and
    pci_sriov_resource_alignment().

    Patch started as debugging effort from Cam Macdonell.

    Cc: Cam Macdonell
    Cc: Avi Kivity
    [chrisw: add iov bits]
    Signed-off-by: Chris Wright
    Signed-off-by: Jesse Barnes

    Cam Macdonell
     

30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

13 Feb, 2010

1 commit

  • Add and export pci_num_vf to allow other subsystems to determine how many
    virtual function devices are associated with an SR-IOV physical function
    device.
    Add macros dev_is_pci, dev_is_ps, and dev_num_vf to make it easier for
    non-PCI specific code to determine SR-IOV capabilities.

    Signed-off-by: Mitch Williams
    Signed-off-by: Jeff Kirsher
    Signed-off-by: David S. Miller

    Williams, Mitch A
     

25 Nov, 2009

1 commit


30 Aug, 2009

1 commit

  • An SR-IOV capable device includes an SR-IOV PCIe capability which
    describes the Virtual Function (VF) BAR requirements. A typical SR-IOV
    device can support multiple VFs whose BARs must be in a contiguous region,
    effectively an array of VF BARs. The BAR reports the size requirement
    for a single VF. We calculate the full range needed by simply multiplying
    the VF BAR size with the number of possible VFs and create a resource
    spanning the full range.

    This all seems sane enough except it artificially inflates the alignment
    requirement for the VF BAR. The VF BAR need only be aligned to the size
    of a single BAR not the contiguous range of VF BARs. This can cause us
    to fail to allocate resources for the BAR despite the fact that we
    actually have enough space.

    This patch adds a thin PCI specific layer over the generic
    resource_alignment() function which is aware of the special nature of
    VF BARs and does sorting and allocation based on the smaller alignment
    requirement.

    I recognize that while resource_alignment is generic, it's basically a
    PCI helper. An alternative to this patch is to add PCI VF BAR specific
    information to struct resource. I opted for the extra layer rather than
    adding such PCI specific information to struct resource. This does
    have the slight downside that we don't cache the BAR size and re-read
    for each alignment query (happens a small handful of times during boot
    for each VF BAR).

    Signed-off-by: Chris Wright
    Cc: Ivan Kokshaysky
    Cc: Linus Torvalds
    Cc: Matthew Wilcox
    Cc: Yu Zhao
    Cc: stable@kernel.org
    Signed-off-by: Jesse Barnes

    Chris Wright
     

23 Jun, 2009

1 commit

  • * git://git.infradead.org/~dwmw2/iommu-2.6.31:
    intel-iommu: Fix one last ia64 build problem in Pass Through Support
    VT-d: support the device IOTLB
    VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps
    VT-d: add device IOTLB invalidation support
    VT-d: parse ATSR in DMA Remapping Reporting Structure
    PCI: handle Virtual Function ATS enabling
    PCI: support the ATS capability
    intel-iommu: dmar_set_interrupt return error value
    intel-iommu: Tidy up iommu->gcmd handling
    intel-iommu: Fix tiny theoretical race in write-buffer flush.
    intel-iommu: Clean up handling of "caching mode" vs. IOTLB flushing.
    intel-iommu: Clean up handling of "caching mode" vs. context flushing.
    VT-d: fix invalid domain id for KVM context flush
    Fix !CONFIG_DMAR build failure introduced by Intel IOMMU Pass Through Support
    Intel IOMMU Pass Through Support

    Fix up trivial conflicts in drivers/pci/{intel-iommu.c,intr_remapping.c}

    Linus Torvalds
     

17 Jun, 2009

1 commit

  • This patch enhances the FLR functions:
    1) remove disable_irq() so the shared IRQ won't be disabled.
    2) replace the 1s wait with 100, 200 and 400ms wait intervals
    for the Pending Transaction.
    3) replace mdelay() with msleep().
    4) add might_sleep().
    5) lock the device to prevent PM suspend from accessing the CSRs
    during the reset.
    6) coding style fixes.

    Reviewed-by: Kenji Kaneshige
    Signed-off-by: Yu Zhao
    Signed-off-by: Jesse Barnes

    Yu Zhao
     

12 Jun, 2009

1 commit

  • PCIe root complex integrated endpoint does not implement ARI, so this
    kind of endpoint uses 3-bit function number. The function dependency
    link of the integrated endpoint should be calculated using the device
    number plus the value from function dependency link register.

    Normal endpoint always implements ARI and the function dependency link
    register contains 8-bit function number (i.e. `devfn' from software's
    perspective).

    Signed-off-by: Yu Zhao
    Signed-off-by: Jesse Barnes

    Yu Zhao
     

18 May, 2009

2 commits

  • The SR-IOV spec requires that the Smallest Translation Unit and
    the Invalidate Queue Depth fields in the Virtual Function ATS
    capability are hardwired to 0. If a function is a Virtual Function,
    then and set its Physical Function's STU before enabling the ATS.

    Signed-off-by: Yu Zhao
    Acked-by: Jesse Barnes
    Signed-off-by: David Woodhouse

    Yu Zhao
     
  • The PCIe ATS capability makes the Endpoint be able to request the
    DMA address translation from the IOMMU and cache the translation
    in the device side, thus alleviate IOMMU pressure and improve the
    hardware performance in the I/O virtualization environment.

    Signed-off-by: Yu Zhao
    Acked-by: Jesse Barnes
    Signed-off-by: David Woodhouse

    Yu Zhao
     

07 Apr, 2009

1 commit


21 Mar, 2009

5 commits