1. 11 9月, 2018 2 次提交
  2. 23 8月, 2018 1 次提交
  3. 17 8月, 2018 1 次提交
    • R
      PCI / ACPI / PM: Resume all bridges on suspend-to-RAM · 9d64b539
      Rafael J. Wysocki 提交于
      Commit 26112ddc (PCI / ACPI / PM: Resume bridges w/o drivers on
      suspend-to-RAM) attempted to fix a functional regression resulting
      from commit c62ec461 (PM / core: Fix direct_complete handling
      for devices with no callbacks) by resuming PCI bridges without
      drivers (that is, "parallel PCI" ones) during system-wide suspend if
      the target system state is not ACPI S0 (working state).
      
      That turns out insufficient, however, as it is reported that, at
      least in one case, the platform firmware gets confused if a PCIe
      root port is suspended before entering the ACPI S3 sleep state.
      That issue was exposed by commit 77b3729ca03 (PCI / PM: Use
      SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) that allowed
      PCIe ports to stay in runtime suspend during system-wide suspend
      (which is OK for suspend-to-idle, but turns out to be problematic
      otherwise).
      
      For this reason, drop the driver check from acpi_pci_need_resume()
      and resume all bridges (including PCIe ports with drivers) during
      system-wide suspend if the target system state is not ACPI S0.
      
      [If the target system state is ACPI S0, it means suspend-to-idle
       and the platform firmware is not going to be invoked to actually
       suspend the system, so there is no need to resume the bridges in
       that case.]
      
      Fixes: 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports)
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200675Reported-by: Nteika kazura <teika@gmx.com>
      Tested-by: Nteika kazura <teika@gmx.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: 4.16+ <stable@vger.kernel.org> # 4.16+: 26112ddc (PCI / ACPI / PM: Resume bridges ...)
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d64b539
  4. 16 8月, 2018 1 次提交
  5. 15 8月, 2018 3 次提交
    • J
      PCI: Limit config space size for Netronome NFP5000 · 2538fb89
      Jakub Kicinski 提交于
      Like the NFP4000 and NFP6000, the NFP5000 as an erratum where reading/
      writing to PCI config space addresses above 0x600 can cause the NFP to
      generate PCIe completion timeouts.
      
      Limit the NFP5000's PF's config space size to 0x600 bytes as is already
      done for the NFP4000 and NFP6000.
      
      The NFP5000's VF is 0x6003 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same
      device ID as the NFP6000's VF.  Thus, its config space is already limited
      by the existing use of quirk_nfp6000().
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NTony Egan <tony.egan@netronome.com>
      2538fb89
    • H
      PCI/MSI: Set IRQCHIP_ONESHOT_SAFE for PCI-MSI irqchips · 923aa4c3
      Heiner Kallweit 提交于
      If flag IRQCHIP_ONESHOT_SAFE isn't set for an irqchip and we have a
      threaded interrupt with no primary handler, flag IRQF_ONESHOT needs to be
      set for the interrupt, causing some overhead in the threaded interrupt
      handler.  For more detailed explanation also check following comment in
      __setup_irq():
      
        The interrupt was requested with handler = NULL, so we use the default
        primary handler for it. But it does not have the oneshot flag set.  In
        combination with level interrupts this is deadly, because the default
        primary handler just wakes the thread, then the irq lines is reenabled,
        but the device still has the level irq asserted.  Rinse and repeat....
      
        While this works for edge type interrupts, we play it safe and reject
        unconditionally because we can't say for sure which type this interrupt
        really has.  The type flags are unreliable as the underlying chip
        implementation can override them.
      
      Another comment in __setup_irq() gives a hint already that this
      overhead can be avoided for PCI-MSI:
      
        Some irq chips like MSI based interrupts are per se one shot safe.  Check
        the chip flags, so we can avoid the unmask dance at the end of the
        threaded handler for those.
      
      Following this let's mark all PCI-MSI irqchips as oneshot-safe.
      
      See also discussion here:
      https://lkml.kernel.org/r/alpine.DEB.2.21.1808032136490.1658@nanos.tec.linutronix.deSigned-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      923aa4c3
    • B
      PCI/VPD: Check for VPD access completion before checking for timeout · 6eaf2781
      Bert Kenward 提交于
      Previously we checked the timeout before checking the VPD access completion
      bit.  On a very heavily loaded system this can cause VPD access to timeout.
      Check the completion bit before checking the timeout.
      Signed-off-by: NBert Kenward <bkenward@solarflare.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6eaf2781
  6. 14 8月, 2018 3 次提交
    • M
      PCI: Match Root Port's MPS to endpoint's MPSS as necessary · 9f0e8935
      Myron Stowe 提交于
      In commit 27d868b5 ("PCI: Set MPS to match upstream bridge"), we made
      sure every device's MPS setting matches its upstream bridge, making it more
      likely that a hot-added device will work in a system with an optimized MPS
      configuration.
      
      Recently I've started encountering systems where the endpoint device's MPSS
      capability is less than its Root Port's current MPS value, thus the
      endpoint is not capable of matching its upstream bridge's MPS setting (see:
      bugzilla via "Link:" below).  This leaves the system vulnerable - the
      upstream Root Port could respond with larger TLPs than the device can
      handle, and the device will consider them to be 'Malformed'.
      
      One could use the "pci=pcie_bus_safe" kernel parameter to work around the
      issue, but that forces a user to supply a kernel parameter to get the
      system to function reliably and may end up limiting MPS settings of other
      unrelated, sub-topologies which could benefit from maintaining their larger
      values.
      
      Augment Keith's approach to include tuning down a Root Port's MPS setting
      when its hot-added endpoint device is not capable of matching it.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Acked-by: NJon Mason <jdmason@kudzu.us>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Sinan Kaya <okaya@kernel.org>
      Cc: Dongdong Liu <liudongdong3@huawei.com>
      9f0e8935
    • M
      PCI: Skip MPS logic for Virtual Functions (VFs) · 3dbe97ef
      Myron Stowe 提交于
      PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
      Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
      VFs.  Just prior to the table it states:
      
        "PF and VF functionality is defined in Section 7.5.3.4 except where
         noted in Table 9-16.  For VF fields marked 'RsvdP', the PF setting
         applies to the VF."
      
      All of which implies that with respect to Max_Payload_Size Supported
      (MPSS), MPS, and MRRS values, we should not be paying any attention to the
      VF's fields, but rather only to the PF's.  Only looking at the PF's fields
      also logically makes sense as it's the sole physical interface to the PCIe
      bus.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
      Fixes: 27d868b5 ("PCI: Set MPS to match upstream bridge")
      Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # 4.3+
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Sinan Kaya <okaya@kernel.org>
      Cc: Dongdong Liu <liudongdong3@huawei.com>
      Cc: Jon Mason <jdmason@kudzu.us>
      3dbe97ef
    • B
      PCI: Add function 1 DMA alias quirk for Marvell 88SS9183 · 7695e73f
      Bjorn Helgaas 提交于
      Add function 1 DMA alias quirk for Marvell 88SS9183 PCIe SSD Controller.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679#c134Reported-and-tested-by: NFelix Blüthner <f.bluethner@mailbox.org>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      7695e73f
  7. 11 8月, 2018 1 次提交
    • A
      PCI: Check for PCIe Link downtraining · 2d1ce5ec
      Alexandru Gagniuc 提交于
      When both ends of a PCIe Link are capable of a higher bandwidth than is
      currently in use, the Link is said to be "downtrained".  A downtrained Link
      may indicate hardware or configuration problems in the system, but it's
      hard to identify such Links from userspace.
      
      Refactor pcie_print_link_status() so it continues to always print PCIe
      bandwidth information, as several NIC drivers desire.
      
      Add a new internal __pcie_print_link_status() to emit a message only when a
      device's bandwidth is constrained by the fabric and call it from the PCI
      core for all devices, which identifies all downtrained Links.  It also
      emits messages for a few cases that are technically not downtrained, such
      as a x4 device in an open-ended x1 slot.
      Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [bhelgaas: changelog, move __pcie_print_link_status() declaration to
      drivers/pci/, rename pcie_check_upstream_link() to
      pcie_report_downtraining()]
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      2d1ce5ec
  8. 10 8月, 2018 10 次提交
  9. 08 8月, 2018 6 次提交
  10. 07 8月, 2018 2 次提交
  11. 06 8月, 2018 1 次提交
  12. 05 8月, 2018 1 次提交
    • N
      x86: Don't include linux/irq.h from asm/hardirq.h · 447ae316
      Nicolai Stange 提交于
      The next patch in this series will have to make the definition of
      irq_cpustat_t available to entering_irq().
      
      Inclusion of asm/hardirq.h into asm/apic.h would cause circular header
      dependencies like
      
        asm/smp.h
          asm/apic.h
            asm/hardirq.h
              linux/irq.h
                linux/topology.h
                  linux/smp.h
                    asm/smp.h
      
      or
      
        linux/gfp.h
          linux/mmzone.h
            asm/mmzone.h
              asm/mmzone_64.h
                asm/smp.h
                  asm/apic.h
                    asm/hardirq.h
                      linux/irq.h
                        linux/irqdesc.h
                          linux/kobject.h
                            linux/sysfs.h
                              linux/kernfs.h
                                linux/idr.h
                                  linux/gfp.h
      
      and others.
      
      This causes compilation errors because of the header guards becoming
      effective in the second inclusion: symbols/macros that had been defined
      before wouldn't be available to intermediate headers in the #include chain
      anymore.
      
      A possible workaround would be to move the definition of irq_cpustat_t
      into its own header and include that from both, asm/hardirq.h and
      asm/apic.h.
      
      However, this wouldn't solve the real problem, namely asm/harirq.h
      unnecessarily pulling in all the linux/irq.h cruft: nothing in
      asm/hardirq.h itself requires it. Also, note that there are some other
      archs, like e.g. arm64, which don't have that #include in their
      asm/hardirq.h.
      
      Remove the linux/irq.h #include from x86' asm/hardirq.h.
      
      Fix resulting compilation errors by adding appropriate #includes to *.c
      files as needed.
      
      Note that some of these *.c files could be cleaned up a bit wrt. to their
      set of #includes, but that should better be done from separate patches, if
      at all.
      Signed-off-by: NNicolai Stange <nstange@suse.de>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      447ae316
  13. 01 8月, 2018 8 次提交
    • B
      PCI/AER: Remove duplicate PCI_EXP_AER_FLAGS definition · 944d5859
      Bjorn Helgaas 提交于
      PCI_EXP_AER_FLAGS was defined twice (with identical definitions), once
      under #ifdef CONFIG_ACPI_APEI, and again at the top level.  This looks like
      my merge error from these commits:
      
        fd3362cb ("PCI/AER: Squash aerdrv_core.c into aerdrv.c")
        41cbc9eb ("PCI/AER: Squash ecrc.c into aerdrv.c")
      
      Remove the duplicate PCI_EXP_AER_FLAGS definition.
      
      Fixes: 41cbc9eb ("PCI/AER: Squash ecrc.c into aerdrv.c")
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NOza Pawandeep <poza@codeaurora.org>
      944d5859
    • L
      PCI: pciehp: Deduplicate presence check on probe & resume · 4e6a1335
      Lukas Wunner 提交于
      On driver probe and on resume from system sleep, pciehp checks the
      Presence Detect State bit in the Slot Status register to bring up an
      occupied slot or bring down an unoccupied slot.  Both code paths are
      identical, so deduplicate them per Mika's request.
      
      On probe, an additional check is performed to disable power of an
      unoccupied slot.  This can e.g. happen if power was enabled by BIOS.
      It cannot happen once pciehp has taken control, hence is not necessary
      on resume:  The Slot Control register is set to the same value that it
      had on suspend by pci_restore_state(), so if the slot was occupied,
      power is enabled and if it wasn't, power is disabled.  Should occupancy
      have changed during the system sleep transition, power is adjusted by
      bringing up or down the slot per the paragraph above.
      
      To allow for deduplication of the presence check, move the power check
      to pcie_init().  This seems safer anyway, because right now it is
      performed while interrupts are already enabled, and although I can't
      think of a scenario where pciehp_power_off_slot() and the IRQ thread
      collide, it does feel brittle.
      
      However this means that pcie_init() may now write to the Slot Control
      register before the IRQ is requested.  If both the CCIE and HPIE bits
      happen to be set, pcie_wait_cmd() will wait for an interrupt (instead
      of polling the Command Completed bit) and eventually emit a timeout
      message.  Additionally, if a level-triggered INTx interrupt is used,
      the user may see a spurious interrupt splat.  Avoid by disabling
      interrupts before disabling power.  (Normally the HPIE and CCIE bits
      should be clear on probe, but conceivably they may already have been
      set e.g. by BIOS.)
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      4e6a1335
    • L
      PCI: pciehp: Avoid implicit fallthroughs in switch statements · 8bb46b07
      Lukas Wunner 提交于
      Per Mika's request, add an explicit break to the last case of switch
      statements everywhere in pciehp to be more defensive towards future
      amendments.
      
      Per Gustavo's request, mark all non-empty implicit fallthroughs with a
      comment to silence warnings triggered by -Wimplicit-fallthrough=2.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      8bb46b07
    • H
      PCI: Fix is_added/is_busmaster race condition · 44bda4b7
      Hari Vyas 提交于
      When a PCI device is detected, pdev->is_added is set to 1 and proc and
      sysfs entries are created.
      
      When the device is removed, pdev->is_added is checked for one and then
      device is detached with clearing of proc and sys entries and at end,
      pdev->is_added is set to 0.
      
      is_added and is_busmaster are bit fields in pci_dev structure sharing same
      memory location.
      
      A strange issue was observed with multiple removal and rescan of a PCIe
      NVMe device using sysfs commands where is_added flag was observed as zero
      instead of one while removing device and proc,sys entries are not cleared.
      This causes issue in later device addition with warning message
      "proc_dir_entry" already registered.
      
      Debugging revealed a race condition between the PCI core setting the
      is_added bit in pci_bus_add_device() and the NVMe driver reset work-queue
      setting the is_busmaster bit in pci_set_master().  As these fields are not
      handled atomically, that clears the is_added bit.
      
      Move the is_added bit to a separate private flag variable and use atomic
      functions to set and retrieve the device addition state.  This avoids the
      race because is_added no longer shares a memory location with is_busmaster.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=200283Signed-off-by: NHari Vyas <hari.vyas@broadcom.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NLukas Wunner <lukas@wunner.de>
      Acked-by: NMichael Ellerman <mpe@ellerman.id.au>
      44bda4b7
    • L
      PCI: Whitelist Thunderbolt ports for runtime D3 · 47a8e237
      Lukas Wunner 提交于
      Thunderbolt controllers can be runtime suspended to D3cold to save ~1.5W.
      This requires that runtime D3 is allowed on its PCIe ports, so whitelist
      them.
      
      The 2015 BIOS cutoff that we've instituted for runtime D3 on PCIe ports
      is unnecessary on Thunderbolt because we know that even the oldest
      controller, Light Ridge (2010), is able to suspend its ports to D3 just
      fine -- specifically including its hotplug ports.  And the power saving
      should be afforded to machines even if their BIOS predates 2015.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andreas Noever <andreas.noever@gmail.com>
      47a8e237
    • L
      PCI: Whitelist native hotplug ports for runtime D3 · eb3b5bf1
      Lukas Wunner 提交于
      Previously we blacklisted PCIe hotplug ports for runtime D3 because:
      
      (a) Ports handled by the firmware must not be transitioned to D3 by the
          OS behind the firmware's back:
          https://bugzilla.kernel.org/show_bug.cgi?id=53811
      
      (b) Ports handled natively by the OS lacked runtime D3 support in the
          pciehp driver.
      
      We've just rectified the latter, so allow users to manually enable and
      test it by passing pcie_port_pm=force on the command line.  Vendors are
      thus put in a position to validate hotplug ports for runtime D3 and
      perhaps we can someday enable it by default, but with a BIOS cutoff date.
      
      Ashok Raj tested runtime D3 on hotplug ports of a SkyLake Xeon-SP in
      2017 and encountered Hardware Error NMIs, so this feature clearly cannot
      be enabled for everyone yet:
      https://lkml.kernel.org/r/20170503180426.GA4058@otc-nc-03
      
      While at it, remove an erroneous code comment I added with 97a90aee
      ("PCI: Consolidate conditions to allow runtime PM on PCIe ports") which
      claims that parents of a hotplug port must stay awake lest interrupts
      cannot be delivered.  That has turned out to be wrong at least for
      Thunderbolt hotplug ports.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      eb3b5bf1
    • L
      PCI: sysfs: Resume to D0 on function reset · 82c3fbff
      Lukas Wunner 提交于
      When performing a function reset via sysfs, the device's config space is
      accessed in places such as pcie_flr() and its MMIO space is accessed e.g.
      in reset_ivb_igd(), so ensure accessibility by resuming the device to D0.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      82c3fbff
    • L
      PCI: pciehp: Resume parent to D0 on config space access · 4417aa45
      Lukas Wunner 提交于
      Ensure accessibility of a hotplug port's config space when accessed via
      sysfs by resuming its parent to D0.
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Ashok Raj <ashok.raj@intel.com>
      Cc: Keith Busch <keith.busch@intel.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      4417aa45