1. 13 Oct, 2018 1 commit
    • Daniel Drake's avatar
      PCI: Reprogram bridge prefetch registers on resume · 8ebd6558
      Daniel Drake authored
      commit 08387454 upstream.
      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=201069Signed-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
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 24 Aug, 2018 1 commit
    • Sergei Shtylyov's avatar
      PCI: OF: Fix I/O space page leak · 0e66392d
      Sergei Shtylyov authored
      commit a5fb9fb0 upstream.
      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: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 16 May, 2018 2 commits
    • Rafael J. Wysocki's avatar
      PCI / PM: Check device_may_wakeup() in pci_enable_wake() · 64a03d3b
      Rafael J. Wysocki authored
      commit cfcadfaa upstream.
      Commit 0847684c (PCI / PM: Simplify device wakeup settings code)
      went too far and dropped the device_may_wakeup() check from
      pci_enable_wake() which causes wakeup to be enabled during system
      suspend, hibernation or shutdown for some PCI devices that are not
      allowed by user space to wake up the system from sleep (or power off).
      As a result of this, excessive power is drawn by some of the affected
      systems while in sleep states or off.
      Restore the device_may_wakeup() check in pci_enable_wake(), but make
      sure that the PCI bus type's runtime suspend callback will not call
      device_may_wakeup() which is about system wakeup from sleep and not
      about device wakeup from runtime suspend.
      Fixes: 0847684c (PCI / PM: Simplify device wakeup settings code)
      Reported-by: default avatarJoseph Salisbury <joseph.salisbury@canonical.com>
      Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
    • Kai Heng Feng's avatar
      PCI / PM: Always check PME wakeup capability for runtime wakeup support · 89d5c4eb
      Kai Heng Feng authored
      commit 8feaec33 upstream.
      USB controller ASM1042 stops working after commit de3ef1eb (PM /
      core: Drop run_wake flag from struct dev_pm_info).
      The device in question is not power managed by platform firmware,
      furthermore, it only supports PME# from D3cold:
      Capabilities: [78] Power Management version 3
             Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+)
             Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
      Before commit de3ef1eb, the device never gets runtime suspended.
      After that commit, the device gets runtime suspended to D3hot, which can
      not generate any PME#.
      usb_hcd_pci_probe() unconditionally calls device_wakeup_enable(), hence
      device_can_wakeup() in pci_dev_run_wake() always returns true.
      So pci_dev_run_wake() needs to check PME wakeup capability as its first
      In addition, change wakeup flag passed to pci_target_state() from false
      to true, because we want to find the deepest state different from D3cold
      that the device can still generate PME#. In this case, it's D0 for the
      device in question.
      Fixes: de3ef1eb (PM / core: Drop run_wake flag from struct dev_pm_info)
      Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Cc: 4.13+ <stable@vger.kernel.org> # 4.13+
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 25 Dec, 2017 1 commit
  5. 15 Sep, 2017 1 commit
    • Bjorn Helgaas's avatar
      Revert "PCI: Avoid race while enabling upstream bridges" · 0f50a49e
      Bjorn Helgaas authored
      This reverts commit 40f11adc.
      Jens found that iwlwifi firmware loading failed on a Lenovo X1 Carbon,
        iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-34.ucode failed with error -2
        iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-33.ucode failed with error -2
        iwlwifi 0000:04:00.0: Direct firmware load for iwlwifi-8000C-32.ucode failed with error -2
        iwlwifi 0000:04:00.0: loaded firmware version 31.532993.0 op_mode iwlmvm
        iwlwifi 0000:04:00.0: Detected Intel(R) Dual Band Wireless AC 8260, REV=0x208
        iwlwifi 0000:04:00.0: Failed to load firmware chunk!
        iwlwifi 0000:04:00.0: Could not load the [0] uCode section
        iwlwifi 0000:04:00.0: Failed to start INIT ucode: -110
        iwlwifi 0000:04:00.0: Failed to run INIT ucode: -110
      He bisected it to 40f11adc ("PCI: Avoid race while enabling upstream
      bridges").  Revert that commit to fix the regression.
      Link: http://lkml.kernel.org/r/4bcbcbc1-7c79-09f0-5071-bc2f53bf6574@kernel.dk
      Fixes: 40f11adc ("PCI: Avoid race while enabling upstream bridges")
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      CC: Srinath Mannam <srinath.mannam@broadcom.com>
      CC: Jens Axboe <axboe@kernel.dk>
      CC: Luca Coelho <luca@coelho.fi>
      CC: Johannes Berg <johannes@sipsolutions.net>
      CC: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
  6. 29 Aug, 2017 1 commit
    • Sinan Kaya's avatar
      PCI: Wait up to 60 seconds for device to become ready after FLR · 821cdad5
      Sinan Kaya authored
      Sporadic reset issues have been observed with an Intel 750 NVMe drive while
      assigning the physical function to the guest machine.  The sequence of
      events observed is as follows:
        - perform a Function Level Reset (FLR)
        - sleep up to 1000ms total
        - read ~0 from PCI_COMMAND (CRS completion for config read)
        - warn that the device didn't return from FLR
        - touch the device before it's ready
        - device drops config writes when we restore register settings (there's
          no mechanism for software to learn about CRS completions for writes)
        - incomplete register restore leaves device in inconsistent state
        - device probe fails because device is in inconsistent state
      After reset, an endpoint may respond to config requests with Configuration
      Request Retry Status (CRS) to indicate that it is not ready to accept new
      requests. See PCIe r3.1, sec 2.3.1 and 6.6.2.
      Increase the timeout value from 1 second to 60 seconds to cover the period
      where device responds with CRS and also report polling progress.
      Signed-off-by: default avatarSinan Kaya <okaya@codeaurora.org>
      [bhelgaas: include the mandatory 100ms in the delays we print]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  7. 24 Aug, 2017 1 commit
  8. 19 Aug, 2017 1 commit
    • Srinath Mannam's avatar
      PCI: Avoid race while enabling upstream bridges · 40f11adc
      Srinath Mannam authored
      When we enable a device, we first enable any upstream bridges.  If a bridge
      has multiple downstream devices and we enable them simultaneously, the race
      to enable the upstream bridge may cause problems.  Consider this hierarchy:
        bridge A --+-- device B
                   +-- device C
      If drivers for B and C call pci_enable_device() simultaneously, both will
      attempt to enable A, which involves setting PCI_COMMAND_MASTER via
      pci_set_master() and PCI_COMMAND_MEMORY via pci_enable_resources().
      In the following sequence, B's update to set A's PCI_COMMAND_MEMORY is
      lost, and neither B nor C will work correctly:
            B                                C
          cmd = read(A, PCI_COMMAND)
          cmd |= PCI_COMMAND_MASTER
                                           cmd = read(A, PCI_COMMAND)
                                           cmd |= PCI_COMMAND_MASTER
          write(A, PCI_COMMAND, cmd)
            cmd = read(A, PCI_COMMAND)
            cmd |= PCI_COMMAND_MEMORY
            write(A, PCI_COMMAND, cmd)
                                           write(A, PCI_COMMAND, cmd)
      Avoid this race by holding a new pci_bridge_mutex while enabling a bridge.
      This ensures that both PCI_COMMAND_MASTER and PCI_COMMAND_MEMORY will be
      updated before another thread can start enabling the bridge.
      Note that although pci_enable_bridge() is recursive, it enables any
      upstream bridges *before* acquiring the mutex.  When it acquires the mutex
      and calls pci_set_master() and pci_enable_device(), any upstream bridges
      have already been enabled so pci_enable_device() will not deadlock by
      calling pci_enable_bridge() again.
      Signed-off-by: default avatarSrinath Mannam <srinath.mannam@broadcom.com>
      [bhelgaas: changelog, comment]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  9. 18 Aug, 2017 1 commit
  10. 16 Aug, 2017 1 commit
    • dingtianhong's avatar
      PCI: fix oops when try to find Root Port for a PCI device · 0e405232
      dingtianhong authored
      Eric report a oops when booting the system after applying
      the commit a99b646a ("PCI: Disable PCIe Relaxed..."):
      [    4.241029] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050
      [    4.247001] IP: pci_find_pcie_root_port+0x62/0x80
      [    4.253011] PGD 0
      [    4.253011] P4D 0
      [    4.253011]
      [    4.258013] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      [    4.262015] Modules linked in:
      [    4.265005] CPU: 31 PID: 1 Comm: swapper/0 Not tainted 4.13.0-dbx-DEV #316
      [    4.271002] Hardware name: Intel RML,PCH/Iota_QC_19, BIOS 2.40.0 06/22/2016
      [    4.279002] task: ffffa2ee38cfa040 task.stack: ffffa51ec0004000
      [    4.285001] RIP: 0010:pci_find_pcie_root_port+0x62/0x80
      [    4.290012] RSP: 0000:ffffa51ec0007ab8 EFLAGS: 00010246
      [    4.295003] RAX: 0000000000000000 RBX: ffffa2ee36bae000 RCX: 0000000000000006
      [    4.303002] RDX: 000000000000081c RSI: ffffa2ee38cfa8c8 RDI: ffffa2ee36bae000
      [    4.310013] RBP: ffffa51ec0007b58 R08: 0000000000000001 R09: 0000000000000000
      [    4.317001] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa51ec0007ad0
      [    4.324005] R13: ffffa2ee36bae098 R14: 0000000000000002 R15: ffffa2ee37204818
      [    4.331002] FS:  0000000000000000(0000) GS:ffffa2ee3fcc0000(0000) knlGS:0000000000000000
      [    4.339002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [    4.345001] CR2: 0000000000000050 CR3: 000000401000f000 CR4: 00000000001406e0
      [    4.351002] Call Trace:
      [    4.354012]  ? pci_configure_device+0x19f/0x570
      [    4.359002]  ? pci_conf1_read+0xb8/0xf0
      [    4.363002]  ? raw_pci_read+0x23/0x40
      [    4.366011]  ? pci_read+0x2c/0x30
      [    4.370014]  ? pci_read_config_word+0x67/0x70
      [    4.374012]  pci_device_add+0x28/0x230
      [    4.378012]  ? pci_vpd_f0_read+0x50/0x80
      [    4.382014]  pci_scan_single_device+0x96/0xc0
      [    4.386012]  pci_scan_slot+0x79/0xf0
      [    4.389001]  pci_scan_child_bus+0x31/0x180
      [    4.394014]  acpi_pci_root_create+0x1c6/0x240
      [    4.398013]  pci_acpi_scan_root+0x15f/0x1b0
      [    4.402012]  acpi_pci_root_add+0x2e6/0x400
      [    4.406012]  ? acpi_evaluate_integer+0x37/0x60
      [    4.411002]  acpi_bus_attach+0xdf/0x200
      [    4.415002]  acpi_bus_attach+0x6a/0x200
      [    4.418014]  acpi_bus_attach+0x6a/0x200
      [    4.422013]  acpi_bus_scan+0x38/0x70
      [    4.426011]  acpi_scan_init+0x10c/0x271
      [    4.429001]  acpi_init+0x2fa/0x348
      [    4.433004]  ? acpi_sleep_proc_init+0x2d/0x2d
      [    4.437001]  do_one_initcall+0x43/0x169
      [    4.441001]  kernel_init_freeable+0x1d0/0x258
      [    4.445003]  ? rest_init+0xe0/0xe0
      [    4.449001]  kernel_init+0xe/0x150
      ====================== cut here =============================
      It looks like the pci_find_pcie_root_port() was trying to
      find the Root Port for the PCI device which is the Root
      Port already, it will return NULL and trigger the problem,
      so check the highest_pcie_bridge to fix thie problem.
      Fixes: a99b646a ("PCI: Disable PCIe Relaxed Ordering if unsupported")
      Fixes: c56d4450 ("PCI: Turn off Request Attributes to avoid Chelsio T5 Completion erratum")
      Reported-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
  11. 03 Aug, 2017 1 commit
  12. 02 Aug, 2017 1 commit
    • Marc Zyngier's avatar
      PCI: Add pci_reset_function_locked() · a477b9cd
      Marc Zyngier authored
      The implementation of PCI workarounds may require that the device is reset
      from its probe function.  This implies that the PCI device lock is already
      held, and makes calling pci_reset_function() impossible (since it will
      itself try to take that lock).
      Add pci_reset_function_locked(), which is the equivalent of
      pci_reset_function(), except that it requires the PCI device lock to be
      already held by the caller.
      Tested-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      [bhelgaas: folded in fix for conflict with 52354b9d ("PCI: Remove
      __pci_dev_reset() and pci_dev_reset()")]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org	# 4.11: 52354b9d: PCI: Remove __pci_dev_reset() and pci_dev_reset()
      Cc: stable@vger.kernel.org	# 4.11
  13. 01 Aug, 2017 1 commit
  14. 12 Jul, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Restore PME Enable after config space restoration · 0ce3fcaf
      Rafael J. Wysocki authored
      Commit dc15e71e (PCI / PM: Restore PME Enable if skipping wakeup
      setup) introduced a mechanism by which the PME Enable bit can be
      restored by pci_enable_wake() if dev->wakeup_prepared is set in
      case it has been overwritten by PCI config space restoration.
      However, that commit overlooked the fact that on some systems (Dell
      XPS13 9360 in particular) the AML handling wakeup events checks PME
      Status and PME Enable and it won't trigger a Notify() for devices
      where those bits are not set while it is running.
      That happens during resume from suspend-to-idle when pci_restore_state()
      invoked by pci_pm_default_resume_early() clears PME Enable before the
      wakeup events are processed by AML, effectively causing those wakeup
      events to be ignored.
      Fix this issue by restoring the PME Enable configuration right after
      pci_restore_state() has been called instead of doing that in
      Fixes: dc15e71e (PCI / PM: Restore PME Enable if skipping wakeup setup)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  15. 03 Jul, 2017 2 commits
  16. 30 Jun, 2017 1 commit
  17. 27 Jun, 2017 2 commits
  18. 16 Jun, 2017 1 commit
  19. 15 Jun, 2017 1 commit
  20. 14 Jun, 2017 1 commit
    • Rafael J. Wysocki's avatar
      PCI / PM: Restore PME Enable if skipping wakeup setup · dc15e71e
      Rafael J. Wysocki authored
      The wakeup_prepared PCI device flag is used for preventing subsequent
      changes of PCI device wakeup settings in the same way (e.g. enabling
      device wakeup twice in a row).
      However, in some cases PME Enable may be updated by things like PCI
      configuration space restoration in the meantime and it may need to be
      set again even though the rest of the settings need not change, so
      modify __pci_enable_wake() to do that when it is about to return
      Also, it is reasonable to expect that __pci_enable_wake() will always
      clear PME Status when invoked to disable device wakeup, so make it do
      so even if it is going to return early then.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  21. 30 May, 2017 1 commit
  22. 23 May, 2017 1 commit
  23. 17 May, 2017 1 commit
    • Ard Biesheuvel's avatar
      PCI: Do not disregard parent resources starting at 0x0 · 31342330
      Ard Biesheuvel authored
      Commit f44116ae ("PCI: Remove pci_find_parent_resource() use for
      allocation") updated the logic that iterates over all bus resources and
      compares them to a given resource, in order to decide whether one is the
      parent of the latter.
      This change inadvertently causes pci_find_parent_resource() to disregard
      resources starting at address 0x0, resulting in an error such as the one
      below on ARM systems whose I/O window starts at 0x0.
        pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff window]
        pci_bus 0000:00: root bus resource [io  0x0000-0xffff window]
        pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff window]
        pci_bus 0000:00: root bus resource [bus 00-0f]
        pci 0000:00:01.0: PCI bridge to [bus 01]
        pci 0000:00:02.0: PCI bridge to [bus 02]
        pci 0000:00:03.0: PCI bridge to [bus 03]
        pci 0000:00:03.0: can't claim BAR 13 [io  0x0000-0x0fff]: no compatible bridge window
        pci 0000:03:01.0: can't claim BAR 0 [io  0x0000-0x001f]: no compatible bridge window
      While this never happens on x86, it is perfectly legal in general for a PCI
      MMIO or IO window to start at address 0x0, and it was supported in the code
      before commit f44116ae.
      Drop the test for res->start != 0; resource_contains() already checks
      whether [start, end) completely covers the resource, and so it should be
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  24. 24 Apr, 2017 1 commit
    • Lorenzo Pieralisi's avatar
      PCI: Implement devm_pci_remap_cfgspace() · 490cb6dd
      Lorenzo Pieralisi authored
      The introduction of the pci_remap_cfgspace() interface allows PCI host
      controller drivers to map PCI config space through a dedicated kernel
      interface. Current PCI host controller drivers use the devm_ioremap_*()
      devres interfaces to map PCI configuration space regions so in order to
      update them to the new pci_remap_cfgspace() mapping interface a new set of
      devres interfaces should be implemented so that PCI host controller drivers
      can make use of them.
      Introduce two new functions in the PCI kernel layer and Devres
      - devm_pci_remap_cfgspace()
      - devm_pci_remap_cfg_resource()
      so that PCI host controller drivers can make use of them to map PCI
      configuration space regions.
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
  25. 21 Apr, 2017 1 commit
  26. 20 Apr, 2017 1 commit
    • Christoph Hellwig's avatar
      PCI: Export pcie_flr() · a60a2b73
      Christoph Hellwig authored
      Currently we opencode the FLR sequence in lots of place; export a core
      helper instead.  We split out the probing for FLR support as all the
      non-core callers already know their hardware.
      Note that in the new pci_has_flr() function the quirk check has been moved
      before the capability check as there is no point in reading the capability
      in this case.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  27. 19 Apr, 2017 5 commits
    • Lorenzo Pieralisi's avatar
      PCI: Remove __weak tag from pci_remap_iospace() · 7b309aef
      Lorenzo Pieralisi authored
      pci_remap_iospace() is marked as a weak symbol even though no architecture
      is currently overriding it; given that its implementation internals have
      already code paths that are arch specific (ie PCI_IOBASE and
      ioremap_page_range() attributes) there is no need to leave the weak symbol
      in the kernel since the same functionality can be achieved by customizing
      per-arch the corresponding functionality.
      Remove the __weak symbol from pci_remap_iospace().
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
    • Yongji Xie's avatar
      PCI: Don't resize resources when realigning all devices in system · e3adec72
      Yongji Xie authored
      The "pci=resource_alignment" argument aligns BARs of designated devices by
      artificially increasing their size.  Increasing the size increases the
      alignment and prevents other resources from being assigned in the same
      alignment region, e.g., in the same page, but it can break drivers that use
      the BAR size to locate things, e.g., ilo_map_device() does this:
        off = pci_resource_len(pdev, bar) - 0x2000;
      The new pcibios_default_alignment() interface allows an arch to request
      that *all* BARs in the system be aligned to a larger size.  In this case,
      we don't need to artificially increase the resource size because we know
      every BAR of every device will be realigned, so nothing will share the same
      alignment region.
      Use IORESOURCE_STARTALIGN to request realignment of PCI BARs when we know
      we're realigning all BARs in the system.
      [bhelgaas: comment, changelog]
      Signed-off-by: default avatarYongji Xie <elohimes@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Bjorn Helgaas's avatar
      PCI: Don't reassign resources that are already aligned · 0dde1c08
      Bjorn Helgaas authored
      The "pci=resource_alignment=" kernel argument designates devices for which
      we want alignment greater than is required by the PCI specs.  Previously we
      set IORESOURCE_UNSET for every MEM resource of those devices, even if the
      resource was *already* sufficiently aligned.
      If a resource is already sufficiently aligned, leave it alone and don't try
      to reassign it.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Bjorn Helgaas's avatar
      PCI: Factor pci_reassigndev_resource_alignment() · 81a5e70e
      Bjorn Helgaas authored
      Pull the BAR size adjustment out into a new function,
      pci_request_resource_alignment(), and add a comment about how and why we
      increase the resource size and alignment.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
    • Yongji Xie's avatar
      PCI: Add pcibios_default_alignment() for arch-specific alignment control · 0a701aa6
      Yongji Xie authored
      When VFIO passes through a PCI device to a guest, it does not allow the
      guest to mmap BARs that are smaller than PAGE_SIZE unless it can reserve
      the rest of the page (see vfio_pci_probe_mmaps()). This is because a page
      might contain several small BARs for unrelated devices and a guest should
      not be able to access all of them.
      VFIO emulates guest accesses to non-mappable BARs, which is functional but
      slow. On systems with large page sizes, e.g., PowerNV with 64K pages, BARs
      are more likely to share a page and performance is more likely to be a
      Add a weak function to set default alignment for all PCI devices.  An arch
      can override it to force the PCI core to place memory BARs on their own
      Signed-off-by: default avatarYongji Xie <elohimes@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
  28. 18 Apr, 2017 2 commits
    • Lukas Wunner's avatar
      PCI: Freeze PME scan before suspending devices · ea00353f
      Lukas Wunner authored
      Laurent Pinchart reported that the Renesas R-Car H2 Lager board (r8a7790)
      crashes during suspend tests.  Geert Uytterhoeven managed to reproduce the
      issue on an M2-W Koelsch board (r8a7791):
        It occurs when the PME scan runs, once per second.  During PME scan, the
        PCI host bridge (rcar-pci) registers are accessed while its module clock
        has already been disabled, leading to the crash.
      One reproducer is to configure s2ram to use "s2idle" instead of "deep"
        # echo 0 > /sys/module/printk/parameters/console_suspend
        # echo s2idle > /sys/power/mem_sleep
        # echo mem > /sys/power/state
      Another reproducer is to write either "platform" or "processors" to
      /sys/power/pm_test.  It does not (or is less likely) to happen during full
      system suspend ("core" or "none") because system suspend also disables
      timers, and thus the workqueue handling PME scans no longer runs.  Geert
      believes the issue may still happen in the small window between disabling
      module clocks and disabling timers:
        # echo 0 > /sys/module/printk/parameters/console_suspend
        # echo platform > /sys/power/pm_test    # Or "processors"
        # echo mem > /sys/power/state
      (Make sure CONFIG_PCI_RCAR_GEN2 and CONFIG_USB_OHCI_HCD_PCI are enabled.)
      Rafael Wysocki agrees that PME scans should be suspended before the host
      bridge registers become inaccessible.  To that end, queue the task on a
      workqueue that gets frozen before devices suspend.
      Rafael notes however that as a result, some wakeup events may be missed if
      they are delivered via PME from a device without working IRQ (which hence
      must be polled) and occur after the workqueue has been frozen.  If that
      turns out to be an issue in practice, it may be possible to solve it by
      calling pci_pme_list_scan() once directly from one of the host bridge's
      pm_ops callbacks.
      Stacktrace for posterity:
        PM: Syncing filesystems ... [   38.566237] done.
        PM: Preparing system for sleep (mem)
        Freezing user space processes ... [   38.579813] (elapsed 0.001 seconds) done.
        Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
        PM: Suspending system (mem)
        PM: suspend of devices complete after 152.456 msecs
        PM: late suspend of devices complete after 2.809 msecs
        PM: noirq suspend of devices complete after 29.863 msecs
        suspend debug: Waiting for 5 second(s).
        Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
        pgd = c0003000
        [00000000] *pgd=80000040004003, *pmd=00000000
        Internal error: : 1211 [#1] SMP ARM
        Modules linked in:
        CPU: 1 PID: 20 Comm: kworker/1:1 Not tainted
        4.9.0-rc1-koelsch-00011-g68db9bc8 #3383
        Hardware name: Generic R8A7791 (Flattened Device Tree)
        Workqueue: events pci_pme_list_scan
        task: eb56e140 task.stack: eb58e000
        PC is at pci_generic_config_read+0x64/0x6c
        LR is at rcar_pci_cfg_base+0x64/0x84
        pc : [<c041d7b4>]    lr : [<c04309a0>]    psr: 600d0093
        sp : eb58fe98  ip : c041d750  fp : 00000008
        r10: c0e2283c  r9 : 00000000  r8 : 600d0013
        r7 : 00000008  r6 : eb58fed6  r5 : 00000002  r4 : eb58feb4
        r3 : 00000000  r2 : 00000044  r1 : 00000008  r0 : 00000000
        Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
        Control: 30c5387d  Table: 6a9f6c80  DAC: 55555555
        Process kworker/1:1 (pid: 20, stack limit = 0xeb58e210)
        Stack: (0xeb58fe98 to 0xeb590000)
        fe80:                                                       00000002 00000044
        fea0: eb6f5800 c041d9b0 eb58feb4 00000008 00000044 00000000 eb78a000 eb78a000
        fec0: 00000044 00000000 eb9aff00 c0424bf0 eb78a000 00000000 eb78a000 c0e22830
        fee0: ea8a6fc0 c0424c5c eaae79c0 c0424ce0 eb55f380 c0e22838 eb9a9800 c0235fbc
        ff00: eb55f380 c0e22838 eb55f380 eb9a9800 eb9a9800 eb58e000 eb9a9824 c0e02100
        ff20: eb55f398 c02366c4 eb56e140 eb5631c0 00000000 eb55f380 c023641c 00000000
        ff40: 00000000 00000000 00000000 c023a928 cd105598 00000000 40506a34 eb55f380
        ff60: 00000000 00000000 dead4ead ffffffff ffffffff eb58ff74 eb58ff74 00000000
        ff80: 00000000 dead4ead ffffffff ffffffff eb58ff90 eb58ff90 eb58ffac eb5631c0
        ffa0: c023a844 00000000 00000000 c0206d68 00000000 00000000 00000000 00000000
        ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 3a81336c 10ccd1dd
        [<c041d7b4>] (pci_generic_config_read) from [<c041d9b0>]
        [<c041d9b0>] (pci_bus_read_config_word) from [<c0424bf0>]
        [<c0424bf0>] (pci_check_pme_status) from [<c0424c5c>] (pci_pme_wakeup+0x28/0x54)
        [<c0424c5c>] (pci_pme_wakeup) from [<c0424ce0>] (pci_pme_list_scan+0x58/0xb4)
        [<c0424ce0>] (pci_pme_list_scan) from [<c0235fbc>]
        [<c0235fbc>] (process_one_work) from [<c02366c4>] (worker_thread+0x2a8/0x3e0)
        [<c02366c4>] (worker_thread) from [<c023a928>] (kthread+0xe4/0xfc)
        [<c023a928>] (kthread) from [<c0206d68>] (ret_from_fork+0x14/0x2c)
        Code: ea000000 e5903000 f57ff04f e3a00000 (e5843000)
        ---[ end trace 667d43ba3aa9e589 ]---
      Fixes: df17e62e ("PCI: Add support for polling PME state on suspended legacy PCI devices")
      Reported-and-tested-by: default avatarLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Reported-and-tested-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Acked-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Cc: stable@vger.kernel.org	# 2.6.37+
      Cc: Mika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Cc: Simon Horman <horms+renesas@verge.net.au>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
    • Yongji Xie's avatar
      PCI: Ignore requested alignment for IOV BARs · ea629d87
      Yongji Xie authored
      We would call pci_reassigndev_resource_alignment() before
      pci_init_capabilities().  So the requested alignment would never work for
      IOV BARs.
      Furthermore, it's meaningless to request additional alignment for IOV BARs,
      the IOV BAR alignment is only determined by the VF BAR size.
      Signed-off-by: default avatarYongji Xie <xyjxie@linux.vnet.ibm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarGavin Shan <gwshan@linux.vnet.ibm.com>
  29. 03 Apr, 2017 1 commit
  30. 30 Mar, 2017 1 commit
  31. 14 Mar, 2017 1 commit
  32. 03 Feb, 2017 1 commit