1. 26 Jan, 2018 1 commit
  2. 08 Nov, 2017 1 commit
  3. 06 Nov, 2017 1 commit
  4. 25 Oct, 2017 1 commit
    • Bjorn Helgaas's avatar
      PCI: Document reset method return values · 832c418a
      Bjorn Helgaas authored
      
      
      The pci_reset_function() path may try several different reset methods:
      device-specific resets, PCIe Function Level Resets, PCI Advanced Features
      Function Level Reset, etc.
      
      Add a comment about what the return values from these methods mean.  If one
      of the methods fails, in some cases we want to continue and try the next
      one in the list, but sometimes we want to stop trying.
      
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      832c418a
  5. 24 Oct, 2017 1 commit
  6. 11 Oct, 2017 2 commits
  7. 05 Oct, 2017 1 commit
  8. 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,
      gen4:
      
        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>
      0f50a49e
  9. 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>
      821cdad5
  10. 24 Aug, 2017 1 commit
  11. 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
        pci_set_master(A)
          cmd = read(A, PCI_COMMAND)
          cmd |= PCI_COMMAND_MASTER
                                         pci_set_master(A)
                                           cmd = read(A, PCI_COMMAND)
                                           cmd |= PCI_COMMAND_MASTER
          write(A, PCI_COMMAND, cmd)
        pci_enable_device(A)
          pci_enable_resources(A)
            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>
      40f11adc
  12. 18 Aug, 2017 1 commit
  13. 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>
      0e405232
  14. 03 Aug, 2017 1 commit
  15. 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
      a477b9cd
  16. 01 Aug, 2017 1 commit
  17. 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
      pci_enable_wake().
      
      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>
      0ce3fcaf
  18. 03 Jul, 2017 2 commits
  19. 30 Jun, 2017 1 commit
  20. 27 Jun, 2017 2 commits
  21. 16 Jun, 2017 1 commit
  22. 15 Jun, 2017 1 commit
  23. 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
      early.
      
      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>
      dc15e71e
  24. 30 May, 2017 1 commit
  25. 23 May, 2017 1 commit
  26. 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
      redundant.
      
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      31342330
  27. 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
      documentation:
      
      - 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: Lorenzo Pieralisi's avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      490cb6dd
  28. 21 Apr, 2017 1 commit
  29. 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>
      a60a2b73
  30. 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: Lorenzo Pieralisi's avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      7b309aef
    • 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>
      e3adec72
    • 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>
      0dde1c08
    • 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>
      81a5e70e
    • 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
      problem.
      
      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
      pages.
      
      Signed-off-by: default avatarYongji Xie <elohimes@gmail.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      0a701aa6
  31. 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"
      suspend:
      
        # 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>]
        (pci_bus_read_config_word+0x58/0x80)
        [<c041d9b0>] (pci_bus_read_config_word) from [<c0424bf0>]
        (pci_check_pme_status+0x34/0x78)
        [<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>]
        (process_one_work+0x1bc/0x308)
        [<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>
      ea00353f
    • 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>
      ea629d87
  32. 03 Apr, 2017 1 commit