1. 17 5月, 2016 1 次提交
  2. 12 5月, 2016 1 次提交
  3. 20 4月, 2016 1 次提交
  4. 12 4月, 2016 3 次提交
  5. 06 4月, 2016 1 次提交
  6. 11 3月, 2016 1 次提交
  7. 08 3月, 2016 2 次提交
    • K
      PCI: Allow a NULL "parent" pointer in pci_bus_assign_domain_nr() · 54c6e2dd
      Krzysztof =?utf-8?Q?Ha=C5=82asa?= 提交于
      pci_create_root_bus() passes a "parent" pointer to
      pci_bus_assign_domain_nr().  When CONFIG_PCI_DOMAINS_GENERIC is defined,
      pci_bus_assign_domain_nr() dereferences that pointer.  Many callers of
      pci_create_root_bus() supply a NULL "parent" pointer, which leads to a NULL
      pointer dereference error.
      
      7c674700 ("PCI: Move domain assignment from arm64 to generic code")
      moved the "parent" dereference from arm64 to generic code.  Only arm64 used
      that code (because only arm64 defined CONFIG_PCI_DOMAINS_GENERIC), and it
      always supplied a valid "parent" pointer.  Other arches supplied NULL
      "parent" pointers but didn't defined CONFIG_PCI_DOMAINS_GENERIC, so they
      used a no-op version of pci_bus_assign_domain_nr().
      
      8c7d1474 ("ARM/PCI: Move to generic PCI domains") defined
      CONFIG_PCI_DOMAINS_GENERIC on ARM, and many ARM platforms use
      pci_common_init(), which supplies a NULL "parent" pointer.
      These platforms (cns3xxx, dove, footbridge, iop13xx, etc.) crash
      with a NULL pointer dereference like this while probing PCI:
      
        Unable to handle kernel NULL pointer dereference at virtual address 000000a4
        PC is at pci_bus_assign_domain_nr+0x10/0x84
        LR is at pci_create_root_bus+0x48/0x2e4
        Kernel panic - not syncing: Attempted to kill init!
      
      [bhelgaas: changelog, add "Reported:" and "Fixes:" tags]
      Reported: http://forum.doozan.com/read.php?2,17868,22070,quote=1
      Fixes: 8c7d1474 ("ARM/PCI: Move to generic PCI domains")
      Fixes: 7c674700 ("PCI: Move domain assignment from arm64 to generic code")
      Signed-off-by: NKrzysztof Hałasa <khalasa@piap.pl>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      CC: stable@vger.kernel.org	# v4.0+
      54c6e2dd
    • B
      PCI: Consolidate PCI DMA constants and interfaces in linux/pci-dma-compat.h · fe537670
      Bjorn Helgaas 提交于
      Christoph added a generic include/linux/pci-dma-compat.h, so now there's
      one place with most of the PCI DMA interfaces.  Move more PCI DMA-related
      things there:
      
        - The PCI_DMA_* direction constants from linux/pci.h
        - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary()
          CONFIG_PCI implementations from drivers/pci/pci.c
        - The pci_set_dma_max_seg_size() and pci_set_dma_seg_boundary()
          !CONFIG_PCI stubs from linux/pci.h
        - The pci_set_dma_mask() and pci_set_consistent_dma_mask()
          !CONFIG_PCI stubs from linux/pci.h
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      fe537670
  8. 06 2月, 2016 1 次提交
  9. 09 1月, 2016 2 次提交
  10. 09 12月, 2015 1 次提交
  11. 30 10月, 2015 4 次提交
  12. 23 10月, 2015 1 次提交
    • H
      PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum · c56d4450
      Hariprasad Shenai 提交于
      The Chelsio T5 has a PCIe compliance erratum that causes Malformed TLP or
      Unexpected Completion errors in some systems, which may cause device access
      timeouts.
      
      Per PCIe r3.0, sec 2.2.9, "Completion headers must supply the same values
      for the Attribute as were supplied in the header of the corresponding
      Request, except as explicitly allowed when IDO is used."
      
      Instead of copying the Attributes from the Request to the Completion, the
      T5 always generates Completions with zero Attributes.  The receiver of a
      Completion whose Attributes don't match the Request may accept it (which
      itself seems non-compliant based on sec 2.3.2), or it may handle it as a
      Malformed TLP or an Unexpected Completion, which will probably lead to a
      device access timeout.
      
      Work around this by disabling "Relaxed Ordering" and "No Snoop" in the Root
      Port so it always generate Requests with zero Attributes.
      
      This does affect all other devices which are downstream of that Root Port,
      but these are performance optimizations that should not make a functional
      difference.
      
      Note that Configuration Space accesses are never supposed to have TLP
      Attributes, so we're safe waiting till after any Configuration Space
      accesses to do the Root Port "fixup".
      
      Based on original work by Casey Leedom <leedom@chelsio.com>
      
      [bhelgaas: changelog, comments, rename to pci_find_pcie_root_port(), rework
      to use pci_upstream_bridge() and check for Root Port device type, edit
      diagnostics to clarify intent and devices affected]
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      c56d4450
  13. 13 10月, 2015 1 次提交
    • R
      PCI / PM: Avoid resuming more devices during system suspend · 2cef548a
      Rafael J. Wysocki 提交于
      Commit bac2a909 (PCI / PM: Avoid resuming PCI devices during
      system suspend) introduced a mechanism by which some PCI devices that
      were runtime-suspended at the system suspend time might be left in
      that state for the duration of the system suspend-resume cycle.
      However, it overlooked devices that were marked as capable of waking
      up the system just because PME support was detected in their PCI
      config space.
      
      Namely, in that case, device_can_wakeup(dev) returns 'true' for the
      device and if the device is not configured for system wakeup,
      device_may_wakeup(dev) returns 'false' and it will be resumed during
      system suspend even though configuring it for system wakeup may not
      really make sense at all.
      
      To avoid this problem, simply disable PME for PCI devices that have
      not been configured for system wakeup and are runtime-suspended at
      the system suspend time for the duration of the suspend-resume cycle.
      
      If the device is in D3cold, its config space is not available and it
      shouldn't be written to, but that's only possible if the device
      has platform PM support and the platform code is responsible for
      checking whether or not the device's configuration is suitable for
      system suspend in that case.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2cef548a
  14. 17 9月, 2015 1 次提交
  15. 14 9月, 2015 1 次提交
  16. 25 8月, 2015 1 次提交
    • L
      PCI: Add pci_ioremap_wc_bar() · c43996f4
      Luis R. Rodriguez 提交于
      This lets drivers take advantage of PAT when available. It
      should help with the transition of converting video drivers over
      to ioremap_wc() to help with the goal of eventually using
      _PAGE_CACHE_UC over _PAGE_CACHE_UC_MINUS on x86 on
      ioremap_nocache(), see:
      
        de33c442 ("x86 PAT: fix performance drop for glx, use UC minus for ioremap(), ioremap_nocache() and pci_mmap_page_range()")
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Cc: <syrjala@sci.fi>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Toshi Kani <toshi.kani@hp.com>
      Cc: Ville Syrjälä <syrjala@sci.fi>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: airlied@linux.ie
      Cc: benh@kernel.crashing.org
      Cc: dan.j.williams@intel.com
      Cc: konrad.wilk@oracle.com
      Cc: linux-fbdev@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: mst@redhat.com
      Cc: vinod.koul@intel.com
      Cc: xen-devel@lists.xensource.com
      Link: http://lkml.kernel.org/r/1440443613-13696-2-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      c43996f4
  17. 24 8月, 2015 1 次提交
    • K
      PCI: Set MPS to match upstream bridge · 27d868b5
      Keith Busch 提交于
      Firmware typically configures the PCIe fabric with a consistent Max Payload
      Size setting based on the devices present at boot.  A hot-added device
      typically has the power-on default MPS setting (128 bytes), which may not
      match the fabric.
      
      The previous Linux default, in the absence of any "pci=pcie_bus_*" options,
      was PCIE_BUS_TUNE_OFF, in which we never touch MPS, even for hot-added
      devices.
      
      Add a new default setting, PCIE_BUS_DEFAULT, in which we make sure every
      device's MPS setting matches the upstream bridge.  This makes it more
      likely that a hot-added device will work in a system with optimized MPS
      configuration.
      
      Note that if we hot-add a device that only supports 128-byte MPS, it still
      likely won't work because we don't reconfigure the rest of the fabric.
      Booting with "pci=pcie_bus_peer2peer" is a workaround for this because it
      sets MPS to 128 for everything.
      
      [bhelgaas: changelog, new default, rework for pci_configure_device() path]
      Tested-by: NKeith Busch <keith.busch@intel.com>
      Tested-by: NJordan Hargrave <jharg93@gmail.com>
      Signed-off-by: NKeith Busch <keith.busch@intel.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NYinghai Lu <yinghai@kernel.org>
      27d868b5
  18. 21 7月, 2015 1 次提交
  19. 15 7月, 2015 3 次提交
  20. 23 5月, 2015 1 次提交
  21. 07 5月, 2015 1 次提交
  22. 10 4月, 2015 1 次提交
  23. 09 4月, 2015 1 次提交
  24. 13 3月, 2015 2 次提交
  25. 24 1月, 2015 1 次提交
    • R
      PCI / PM: Avoid resuming PCI devices during system suspend · bac2a909
      Rafael J. Wysocki 提交于
      Commit f25c0ae2 (ACPI / PM: Avoid resuming devices in ACPI PM
      domain during system suspend) modified the ACPI PM domain's system
      suspend callbacks to allow devices attached to it to be left in the
      runtime-suspended state during system suspend so as to optimize
      the suspend process.
      
      This was based on the general mechanism introduced by commit
      aae4518b (PM / sleep: Mechanism to avoid resuming runtime-suspended
      devices unnecessarily).
      
      Extend that approach to PCI devices by modifying the PCI bus type's
      ->prepare callback to return 1 for devices that are runtime-suspended
      when it is being executed and that are in a suitable power state and
      need not be resumed going forward.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      bac2a909
  26. 17 1月, 2015 2 次提交
    • A
      PCI: Add flag for devices that don't reset on D3hot->D0 transition · 51e53738
      Alex Williamson 提交于
      Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises
      No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-")
      should perform an internal reset when transitioning from D3hot to D0 via
      software control.  Configuration context is lost and the device requires a
      full reinitialization sequence.
      
      Unfortunately the definition of "internal reset", beyond the application of
      the configuration context, is largely left to the interpretation of the
      specific device.  Some devices don't seem to perform an "internal reset"
      even if they report No_Soft_Reset == 0.
      
      We still need to honor the PCI specification and restore PCI config context
      in the event that we do a PM reset, so we don't cache and modify the
      PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the
      intention is to reset the device, like pci_reset_function(), we need a
      mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform
      any significant "internal reset" of the device.
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      51e53738
    • A
      PCI: Add flag for devices where we can't use bus reset · f331a859
      Alex Williamson 提交于
      Enable a mechanism for devices to quirk that they do not behave when
      doing a PCI bus reset.  We require a modest level of spec compliant
      behavior in order to do a reset, for instance the device should come
      out of reset without throwing errors and PCI config space should be
      accessible after reset.  This is too much to ask for some devices.
      
      Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.orgSigned-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      CC: stable@vger.kernel.org	# v3.14+
      f331a859
  27. 28 12月, 2014 1 次提交
  28. 04 12月, 2014 1 次提交
  29. 20 11月, 2014 1 次提交