1. 11 11月, 2014 1 次提交
  2. 01 10月, 2014 2 次提交
    • L
      PCI: Add pci_remap_iospace() to map bus I/O resources · 8b921acf
      Liviu Dudau 提交于
      Add pci_remap_iospace() to map bus I/O resources into the CPU virtual
      address space.  Architectures with special needs may provide their own
      version, but most should be able to use this one.
      
      This function is useful for PCI host bridge drivers that need to map the
      PCI I/O resources into virtual memory space.
      
      [bhelgaas: phys_addr description, drop temporary "err" variable]
      Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NRob Herring <robh@kernel.org>
      Reviewed-by: NCatalin Marinas <catalin.marinas@arm.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      8b921acf
    • L
      of/pci: Add pci_get_new_domain_nr() and of_get_pci_domain_nr() · 41e5c0f8
      Liviu Dudau 提交于
      Add pci_get_new_domain_nr() to allocate a new domain number and
      of_get_pci_domain_nr() to retrieve the PCI domain number of a given device
      from DT.  Host bridge drivers or architecture-specific code can choose to
      implement their PCI domain number policy using these two functions.
      
      Using of_get_pci_domain_nr() guarantees a stable PCI domain number on every
      boot provided that all host bridge controllers are assigned a number in the
      device tree using "linux,pci-domain" property.  Mixing use of
      pci_get_new_domain_nr() and of_get_pci_domain_nr() is not recommended as it
      can lead to potentially conflicting domain numbers being assigned to root
      buses behind different host bridges.
      Signed-off-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Arnd Bergmann <arnd@arndb.de>
      CC: Grant Likely <grant.likely@linaro.org>
      CC: Rob Herring <robh+dt@kernel.org>
      CC: Catalin Marinas <catalin.marinas@arm.com>
      41e5c0f8
  3. 24 9月, 2014 1 次提交
  4. 03 9月, 2014 1 次提交
  5. 17 7月, 2014 1 次提交
    • V
      PCI: Configure ASPM when enabling device · 1f6ae47e
      Vidya Sagar 提交于
      We can't do ASPM configuration at enumeration-time because enabling it
      makes some defective hardware unresponsive, even if ASPM is disabled later
      (see 41cd766b ("PCI: Don't enable aspm before drivers have had a chance
      to veto it").  Therefore, we have to do it after a driver claims the
      device.
      
      We previously configured ASPM in pci_set_power_state(), but that's not a
      very good place because it's not really related to setting the PCI device
      power state, and doing it there means:
      
        - We incorrectly skipped ASPM config when setting a device that's
          already in D0 to D0.
      
        - We unnecessarily configured ASPM when setting a device to a low-power
          state (the ASPM feature only applies when the device is in D0).
      
        - We unnecessarily configured ASPM when called from a .resume() method
          (ASPM configuration needs to be restored during resume, but
          pci_restore_pcie_state() should already do this).
      
      Move ASPM configuration from pci_set_power_state() to
      do_pci_enable_device() so we do it when a driver enables a device.
      
      [bhelgaas: changelog]
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=79621
      Fixes: db288c9c ("PCI / PM: restore the original behavior of pci_set_power_state()")
      Suggested-by: NBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: NVidya Sagar <sagar.tv@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.6+
      1f6ae47e
  6. 04 7月, 2014 1 次提交
  7. 18 6月, 2014 1 次提交
  8. 11 6月, 2014 3 次提交
  9. 28 5月, 2014 2 次提交
  10. 20 5月, 2014 1 次提交
  11. 05 5月, 2014 1 次提交
  12. 28 4月, 2014 1 次提交
  13. 26 4月, 2014 1 次提交
  14. 20 3月, 2014 1 次提交
  15. 13 3月, 2014 1 次提交
    • B
      PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled · 3cdeb713
      Bjorn Helgaas 提交于
      Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
      them disabled"), pciehp surprise removal stopped working.
      
      This happens because pci_reenable_device() on the hotplug bridge (used in
      the pciehp_configure_device() path) clears the Interrupt Disable bit, which
      apparently breaks the bridge's MSI hotplug event reporting.
      
      Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
      which is used by both pci_enable_device() and pci_reenable_device().  But
      we use pci_reenable_device() after the driver may have enabled MSI or
      MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
      
      This patch clears Interrupt Disable only when MSI/MSI-X has not been
      enabled.
      
      Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      3cdeb713
  16. 08 3月, 2014 1 次提交
    • B
      PCI: Enable INTx in pci_reenable_device() only when MSI/MSI-X not enabled · 866d5417
      Bjorn Helgaas 提交于
      Andreas reported that after 1f42db78 ("PCI: Enable INTx if BIOS left
      them disabled"), pciehp surprise removal stopped working.
      
      This happens because pci_reenable_device() on the hotplug bridge (used in
      the pciehp_configure_device() path) clears the Interrupt Disable bit, which
      apparently breaks the bridge's MSI hotplug event reporting.
      
      Previously we cleared the Interrupt Disable bit in do_pci_enable_device(),
      which is used by both pci_enable_device() and pci_reenable_device().  But
      we use pci_reenable_device() after the driver may have enabled MSI or
      MSI-X, and we *set* Interrupt Disable as part of enabling MSI/MSI-X.
      
      This patch clears Interrupt Disable only when MSI/MSI-X has not been
      enabled.
      
      Fixes: 1f42db78 PCI: Enable INTx if BIOS left them disabled
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=71691Reported-and-tested-by: NAndreas Noever <andreas.noever@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org
      CC: Sarah Sharp <sarah.a.sharp@linux.intel.com>
      866d5417
  17. 28 2月, 2014 2 次提交
    • B
      PCI: Mark resources as IORESOURCE_UNSET if we can't assign them · bd064f0a
      Bjorn Helgaas 提交于
      When assigning addresses to resources, mark them with IORESOURCE_UNSET
      before we start and clear IORESOURCE_UNSET if assignment is successful.
      That means that if we print the resource during assignment, we will show
      the size, not a meaningless address.
      
      Also, clear IORESOURCE_UNSET if we do assign an address, so we print the
      address when it is valid.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      bd064f0a
    • B
      PCI: Remove pci_find_parent_resource() use for allocation · f44116ae
      Bjorn Helgaas 提交于
      If the resource hasn't been allocated yet, pci_find_parent_resource() is
      documented as returning the region "where it should be allocated from."
      This is impossible in general because there may be several candidates: a
      prefetchable BAR can be put in either a prefetchable or non-prefetchable
      window, a transparent bridge may have overlapping positively- and
      subtractively-decoded windows, and a root bus may have several windows of
      the same type.
      
      Allocation should be done by pci_bus_alloc_resource(), which iterates
      through all bus resources and looks for the best match, e.g., one with the
      desired prefetchability attributes, and falls back to less-desired
      possibilities.
      
      The only valid use of pci_find_parent_resource() is to find the parent of
      an already-allocated resource so we can claim it via request_resource(),
      and all we need for that is a bus region of the correct type that contains
      the resource.
      
      Note that like 8c8def26 ("PCI: allow matching of prefetchable resources
      to non-prefetchable windows"), this depends on pci_bus_for_each_resource()
      iterating through positively-decoded regions before subtractively-decoded
      ones.  We prefer not to return a subtractively-decoded region because
      requesting from it will likely conflict with the overlapping positively-
      decoded window (see Launchpad report below).
      
      Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/424142Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: Linus Torvalds <torvalds@linux-foundation.org>
      f44116ae
  18. 19 2月, 2014 1 次提交
  19. 15 2月, 2014 2 次提交
  20. 12 2月, 2014 1 次提交
  21. 04 2月, 2014 1 次提交
  22. 15 1月, 2014 2 次提交
    • B
      PCI: Fix pci_check_and_unmask_intx() comment typos · ebd50b93
      Bjorn Helgaas 提交于
      Fix typos in pci_check_and_unmask_intx() function comment.
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      ebd50b93
    • A
      PCI: Add pci_try_reset_function(), pci_try_reset_slot(), pci_try_reset_bus() · 61cf16d8
      Alex Williamson 提交于
      When doing a function/slot/bus reset PCI grabs the device_lock for each
      device to block things like suspend and driver probes, but call paths exist
      where this lock may already be held.  This creates an opportunity for
      deadlock.  For instance, vfio allows userspace to issue resets so long as
      it owns the device(s).  If a driver unbind .remove callback races with
      userspace issuing a reset, we have a deadlock as userspace gets stuck
      waiting on device_lock while another thread has device_lock and waits for
      .remove to complete.  To resolve this, we can make a version of the reset
      interfaces which use trylock.  With this, we can safely attempt a reset and
      return error to userspace if there is contention.
      
      [bhelgaas: the deadlock happens when A (userspace) has a file descriptor for
      the device, and B waits in this path:
      
        driver_detach
          device_lock                     # take device_lock
          __device_release_driver
            pci_device_remove             # pci_bus_type.remove
              vfio_pci_remove             # pci_driver .remove
                vfio_del_group_dev
                  wait_event(vfio.release_q, !vfio_dev_present)   # wait (holding device_lock)
      
      Now B is stuck until A gives up the file descriptor.  If A tries to acquire
      device_lock for any reason, we deadlock because A is waiting for B to release
      the lock, and B is waiting for A to release the file descriptor.]
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      61cf16d8
  23. 14 1月, 2014 1 次提交
  24. 11 1月, 2014 3 次提交
  25. 18 12月, 2013 3 次提交
  26. 03 12月, 2013 1 次提交
  27. 15 11月, 2013 1 次提交
  28. 08 11月, 2013 1 次提交
  29. 06 11月, 2013 1 次提交