1. 17 Jan, 2019 1 commit
    • Logan Gunthorpe's avatar
      PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter · d2fd6e81
      Logan Gunthorpe authored
      The disable_acs_redir parameter stores a pointer to the string passed to
      pci_setup().  However, the string passed to PCI setup is actually a
      temporary copy allocated in static __initdata memory.  After init, once the
      memory is freed, it is no longer valid to reference this pointer.
      This bug was noticed in v5.0-rc1 after a change in commit c5eb1190
      ("PCI / PM: Allow runtime PM without callback functions") caused
      pci_disable_acs_redir() to be called during shutdown which manifested
      as an unable to handle kernel paging request at:
        RIP: 0010:pci_enable_acs+0x3f/0x1e0
        Call Trace:
           ? pci_restore_standard_config+0x40/0x40
           ? pci_restore_standard_config+0x40/0x40
           ? pci_conf1_read+0xb6/0xf0
           ? pci_conf1_write+0xb2/0xe0
           ? __fput+0x144/0x1d0
           ? do_writev+0x5e/0xf0
      It was also likely possible to trigger this bug when hotplugging PCI
      To fix this, instead of storing a pointer, we use kstrdup() to copy the
      disable_acs_redir_param to its own buffer which will never be freed.
      Fixes: aaca43fd
       ("PCI: Add "pci=disable_acs_redir=" parameter for peer-to-peer support")
      Tested-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
      Signed-off-by: default avatarLogan Gunthorpe <logang@deltatee.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarJarkko Nikula <jarkko.nikula@linux.intel.com>
  2. 01 Dec, 2018 1 commit
  3. 02 Oct, 2018 3 commits
  4. 28 Sep, 2018 1 commit
    • Felipe Balbi's avatar
      PCI: Add support for Immediate Readiness · d6112f8d
      Felipe Balbi authored
      PCIe r4.0, sec defines a new bit in the Status Register:
        Immediate Readiness – This optional bit, when Set, indicates the Function
        is guaranteed to be ready to successfully complete valid configuration
        accesses at any time following any reset that the host is capable of
        issuing Configuration Requests to this Function.
        When this bit is Set, for accesses to this Function, software is exempt
        from all requirements to delay configuration accesses following any type
        of reset, including but not limited to the timing requirements defined in
        Section 6.6.
      This means that all delays after a Conventional or Function Reset can be
      This patch reads such bit and caches its value in a flag inside struct
      pci_dev to be checked later if we should delay or can skip delays after a
      reset.  While at that, also move the explicit msleep(100) call from
      pcie_flr() and pci_af_flr() to pci_dev_wait().
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  5. 27 Sep, 2018 1 commit
    • Daniel Drake's avatar
      PCI: Reprogram bridge prefetch registers on resume · 08387454
      Daniel Drake authored
      On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
      suspend/resume.  The affected products include multiple generations of
      NVIDIA GPUs and Intel SoCs.  After resume, nouveau logs many errors such
        fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
              [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
        DRM: failed to idle channel 0 [DRM]
      Similarly, the NVIDIA proprietary driver also fails after resume (black
      screen, 100% CPU usage in Xorg process).  We shipped a sample to NVIDIA for
      diagnosis, and their response indicated that it's a problem with the parent
      PCI bridge (on the Intel SoC), not the GPU.
      Runtime suspend/resume works fine, only S3 suspend is affected.
      We found a workaround: on resume, rewrite the Intel PCI bridge
      'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32).  In the
      cases that I checked, this register has value 0 and we just have to rewrite
      that value.
      Linux already saves and restores PCI config space during suspend/resume,
      but this register was being skipped because upon resume, it already has
      value 0 (the correct, pre-suspend value).
      Intel appear to have previously acknowledged this behaviour and the
      requirement to rewrite this register:
      Based on that, rewrite the prefetch register values even when that appears
      We have confirmed this solution on all the affected models we have in-hands
      (X542UQ, UX533FD, X530UN, V272UN).
      Additionally, this solves an issue where r8169 MSI-X interrupts were broken
      after S3 suspend/resume on ASUS X441UAR.  This issue was recently worked
      around in commit 7bb05b85 ("r8169: don't use MSI-X on RTL8106e").  It
      also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
      that we had not yet patched.  I suspect it will also fix the issue that was
      worked around in commit 7c53a722 ("r8169: don't use MSI-X on
      Thomas Martitz reports that this change also solves an issue where the AMD
      Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069
      Signed-off-by: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Reviewed-By: default avatarPeter Wu <peter@lekensteyn.nl>
      CC: stable@vger.kernel.org
  6. 21 Sep, 2018 1 commit
  7. 20 Sep, 2018 1 commit
  8. 18 Sep, 2018 1 commit
    • Lukas Wunner's avatar
      PCI: hotplug: Constify hotplug_slot_ops · 81c4b5bf
      Lukas Wunner authored
      Hotplug drivers cannot declare their hotplug_slot_ops const, making them
      attractive targets for attackers, because upon registration of a hotplug
      slot, __pci_hp_initialize() writes to the "owner" and "mod_name" members
      in that struct.
      Fix by moving these members to struct hotplug_slot and constify every
      driver's hotplug_slot_ops except for pciehp.
      pciehp constructs its hotplug_slot_ops at runtime based on the PCIe
      port's capabilities, hence cannot declare them const.  It can be
      converted to __write_rarely once that's mainlined:
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: Tyrel Datwyler <tyreld@linux.vnet.ibm.com>  # drivers/pci/hotplug/rpa*
      Acked-by: Andy Shevchenko <andy.shevchenko@gmail.com> # drivers/platform/x86
      Cc: Len Brown <lenb@kernel.org>
      Cc: Scott Murray <scott@spiteful.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Oliver OHalloran <oliveroh@au1.ibm.com>
      Cc: Gavin Shan <gwshan@linux.vnet.ibm.com>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
      Cc: Corentin Chary <corentin.chary@gmail.com>
      Cc: Darren Hart <dvhart@infradead.org>
  9. 17 Sep, 2018 2 commits
  10. 12 Sep, 2018 2 commits
  11. 10 Aug, 2018 1 commit
    • Alexandru Gagniuc's avatar
      PCI: Check for PCIe Link downtraining · 2d1ce5ec
      Alexandru Gagniuc authored
      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: default avatarAlexandru Gagniuc <mr.nuke.me@gmail.com>
      [bhelgaas: changelog, move __pcie_print_link_status() declaration to
      drivers/pci/, rename pcie_check_upstream_link() to
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  12. 09 Aug, 2018 5 commits
  13. 06 Aug, 2018 1 commit
  14. 31 Jul, 2018 2 commits
    • Lukas Wunner's avatar
      PCI: Whitelist Thunderbolt ports for runtime D3 · 47a8e237
      Lukas Wunner authored
      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
      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: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: Andreas Noever <andreas.noever@gmail.com>
    • Lukas Wunner's avatar
      PCI: Whitelist native hotplug ports for runtime D3 · eb3b5bf1
      Lukas Wunner authored
      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:
      (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:
      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: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn 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>
  15. 19 Jul, 2018 5 commits
  16. 18 Jul, 2018 1 commit
    • Sergei Shtylyov's avatar
      PCI: OF: Fix I/O space page leak · a5fb9fb0
      Sergei Shtylyov authored
      When testing the R-Car PCIe driver on the Condor board, if the PCIe PHY
      driver was left disabled, the kernel crashed with this BUG:
        kernel BUG at lib/ioremap.c:72!
        Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
        Modules linked in:
        CPU: 0 PID: 39 Comm: kworker/0:1 Not tainted 4.17.0-dirty #1092
        Hardware name: Renesas Condor board based on r8a77980 (DT)
        Workqueue: events deferred_probe_work_func
        pstate: 80000005 (Nzcv daif -PAN -UAO)
        pc : ioremap_page_range+0x370/0x3c8
        lr : ioremap_page_range+0x40/0x3c8
        sp : ffff000008da39e0
        x29: ffff000008da39e0 x28: 00e8000000000f07
        x27: ffff7dfffee00000 x26: 0140000000000000
        x25: ffff7dfffef00000 x24: 00000000000fe100
        x23: ffff80007b906000 x22: ffff000008ab8000
        x21: ffff000008bb1d58 x20: ffff7dfffef00000
        x19: ffff800009c30fb8 x18: 0000000000000001
        x17: 00000000000152d0 x16: 00000000014012d0
        x15: 0000000000000000 x14: 0720072007200720
        x13: 0720072007200720 x12: 0720072007200720
        x11: 0720072007300730 x10: 00000000000000ae
        x9 : 0000000000000000 x8 : ffff7dffff000000
        x7 : 0000000000000000 x6 : 0000000000000100
        x5 : 0000000000000000 x4 : 000000007b906000
        x3 : ffff80007c61a880 x2 : ffff7dfffeefffff
        x1 : 0000000040000000 x0 : 00e80000fe100f07
        Process kworker/0:1 (pid: 39, stack limit = 0x        (ptrval))
        Call trace:
        Code: f9004ba2 54000080 aa0003fb 17ffff48 (d4210000)
      It turned out that pci_remap_iospace() wasn't undone when the driver's
      probe failed, and since devm_phy_optional_get() returned -EPROBE_DEFER,
      the probe was retried, finally causing the BUG due to trying to remap
      already remapped pages.
      Introduce the devm_pci_remap_iospace() managed API and replace the
      pci_remap_iospace() call with it to fix the bug.
      Fixes: dbf9826d
       ("PCI: generic: Convert to DT resource parsing API")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      [lorenzo.pieralisi@arm.com: split commit/updated the commit log]
      Signed-off-by: Lorenzo Pieralisi's avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  17. 12 Jul, 2018 1 commit
  18. 05 Jul, 2018 1 commit
  19. 30 Jun, 2018 4 commits
  20. 25 May, 2018 1 commit
    • Bjorn Helgaas's avatar
      PCI: Remove unused pcie_get_minimum_link() · e5b1db01
      Bjorn Helgaas authored
      In some cases pcie_get_minimum_link() returned misleading information
      because it found the slowest link and the narrowest link without
      considering the total bandwidth of the link.
      For example, consider a path with these two links:
        - 16.0 GT/s  x1 link  (16.0 * 10^9 * 128 / 130) *  1 / 8 = 1969 MB/s
        -  2.5 GT/s x16 link  ( 2.5 * 10^9 *   8 /  10) * 16 / 8 = 4000 MB/s
      The available bandwidth of the path is limited by the 16 GT/s link to about
      1969 MB/s, but pcie_get_minimum_link() returned 2.5 GT/s x1, which
      corresponds to only 250 MB/s.
      Callers should use pcie_print_link_status() instead, or
      pcie_bandwidth_available() if they need more detailed information.
      Remove pcie_get_minimum_link() since there are no callers left.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  21. 24 May, 2018 1 commit
  22. 17 May, 2018 1 commit
  23. 15 May, 2018 1 commit
  24. 10 May, 2018 1 commit
    • Gil Kupfer's avatar
      PCI: Add "pci=noats" boot parameter · cef74409
      Gil Kupfer authored
      Adds a "pci=noats" boot parameter.  When supplied, all ATS related
      functions fail immediately and the IOMMU is configured to not use
      Any function that checks for ATS capabilities directly against the devices
      should also check this flag.  Currently, such functions exist only in IOMMU
      drivers, and they are covered by this patch.
      The motivation behind this patch is the existence of malicious devices.
      Lots of research has been done about how to use the IOMMU as protection
      from such devices.  When ATS is supported, any I/O device can access any
      physical address by faking device-IOTLB entries.  Adding the ability to
      ignore these entries lets sysadmins enhance system security.
      Signed-off-by: default avatarGil Kupfer <gilkup@cs.technion.ac.il>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarJoerg Roedel <jroedel@suse.de>