1. 01 Nov, 2018 2 commits
  2. 20 Oct, 2018 1 commit
  3. 18 Oct, 2018 1 commit
  4. 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
      as:
      
        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:
      https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23
      
      Based on that, rewrite the prefetch register values even when that appears
      unnecessary.
      
      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
      RTL8168g").
      
      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
      suspend/resume.
      
      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>
      8ebd6558
  5. 29 Sep, 2018 2 commits
  6. 19 Sep, 2018 1 commit
  7. 15 Sep, 2018 1 commit
  8. 24 Aug, 2018 9 commits
    • Lukas Wunner's avatar
      PCI: pciehp: Fix unprotected list iteration in IRQ handler · b5b7417e
      Lukas Wunner authored
      commit 1204e35b upstream.
      
      Commit b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug
      events for a device") iterates over the devices on a hotplug port's
      subordinate bus in pciehp's IRQ handler without acquiring pci_bus_sem.
      It is thus possible for a user to cause a crash by concurrently
      manipulating the device list, e.g. by disabling slot power via sysfs
      on a different CPU or by initiating a remove/rescan via sysfs.
      
      This can't be fixed by acquiring pci_bus_sem because it may sleep.
      The simplest fix is to avoid the list iteration altogether and just
      check the ignore_hotplug flag on the port itself.  This works because
      pci_ignore_hotplug() sets the flag both on the device as well as on its
      parent bridge.
      
      We do lose the ability to print the name of the device blocking hotplug
      in the debug message, but that's probably bearable.
      
      Fixes: b440bde7 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b5b7417e
    • Lukas Wunner's avatar
      PCI: pciehp: Fix use-after-free on unplug · 2f27dfad
      Lukas Wunner authored
      commit 281e878e upstream.
      
      When pciehp is unbound (e.g. on unplug of a Thunderbolt device), the
      hotplug_slot struct is deregistered and thus freed before freeing the
      IRQ.  The IRQ handler and the work items it schedules print the slot
      name referenced from the freed structure in various informational and
      debug log messages, each time resulting in a quadruple dereference of
      freed pointers (hotplug_slot -> pci_slot -> kobject -> name).
      
      At best the slot name is logged as "(null)", at worst kernel memory is
      exposed in logs or the driver crashes:
      
        pciehp 0000:10:00.0:pcie204: Slot((null)): Card not present
      
      An attacker may provoke the bug by unplugging multiple devices on a
      Thunderbolt daisy chain at once.  Unplugging can also be simulated by
      powering down slots via sysfs.  The bug is particularly easy to trigger
      in poll mode.
      
      It has been present since the driver's introduction in 2004:
      https://git.kernel.org/tglx/history/c/c16b4b14d980
      
      Fix by rearranging teardown such that the IRQ is freed first.  Run the
      work items queued by the IRQ handler to completion before freeing the
      hotplug_slot struct by draining the work queue from the ->release_slot
      callback which is invoked by pci_hp_deregister().
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.6.4
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2f27dfad
    • Myron Stowe's avatar
      PCI: Skip MPS logic for Virtual Functions (VFs) · 8af37982
      Myron Stowe authored
      commit 3dbe97ef upstream.
      
      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: default avatarMyron Stowe <myron.stowe@redhat.com>
      Signed-off-by: default avatarBjorn 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>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8af37982
    • Lukas Wunner's avatar
      PCI: hotplug: Don't leak pci_slot on registration failure · cf9c2bc5
      Lukas Wunner authored
      commit 4ce64358 upstream.
      
      If addition of sysfs files fails on registration of a hotplug slot, the
      struct pci_slot as well as the entry in the slot_list is leaked.  The
      issue has been present since the hotplug core was introduced in 2002:
      https://git.kernel.org/tglx/history/c/a8a2069f432c
      
      Perhaps the idea was that even though sysfs addition fails, the slot
      should still be usable.  But that's not how drivers use the interface,
      they abort probe if a non-zero value is returned.
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Cc: stable@vger.kernel.org # v2.4.15+
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf9c2bc5
    • Sergei Shtylyov's avatar
      PCI: versatile: Fix I/O space page leak · 96dfb765
      Sergei Shtylyov authored
      [ Upstream commit 0018b265 ]
      
      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:
         ioremap_page_range+0x370/0x3c8
         pci_remap_iospace+0x7c/0xac
         pci_parse_request_of_pci_ranges+0x13c/0x190
         rcar_pcie_probe+0x4c/0xb04
         platform_drv_probe+0x50/0xbc
         driver_probe_device+0x21c/0x308
         __device_attach_driver+0x98/0xc8
         bus_for_each_drv+0x54/0x94
         __device_attach+0xc4/0x12c
         device_initial_probe+0x10/0x18
         bus_probe_device+0x90/0x98
         deferred_probe_work_func+0xb0/0x150
         process_one_work+0x12c/0x29c
         worker_thread+0x200/0x3fc
         kthread+0x108/0x134
         ret_from_fork+0x10/0x18
        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.
      
      The Versatile PCI controller driver has the same issue.
      Replace pci_remap_iospace() with the devm_ managed version to fix the bug.
      
      Fixes: b7e78170 ("PCI: versatile: Add DT-based ARM Versatile PB PCIe host driver")
      Signed-off-by: default avatarSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      [lorenzo.pieralisi@arm.com: 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 avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      96dfb765
    • 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:
         ioremap_page_range+0x370/0x3c8
         pci_remap_iospace+0x7c/0xac
         pci_parse_request_of_pci_ranges+0x13c/0x190
         rcar_pcie_probe+0x4c/0xb04
         platform_drv_probe+0x50/0xbc
         driver_probe_device+0x21c/0x308
         __device_attach_driver+0x98/0xc8
         bus_for_each_drv+0x54/0x94
         __device_attach+0xc4/0x12c
         device_initial_probe+0x10/0x18
         bus_probe_device+0x90/0x98
         deferred_probe_work_func+0xb0/0x150
         process_one_work+0x12c/0x29c
         worker_thread+0x200/0x3fc
         kthread+0x108/0x134
         ret_from_fork+0x10/0x18
        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>
      0e66392d
    • Nicholas Mc Guire's avatar
      PCI: faraday: Add missing of_node_put() · 441712f2
      Nicholas Mc Guire authored
      [ Upstream commit 3dc6ddfe ]
      
      The call to of_get_next_child() returns a node pointer with refcount
      incremented thus it must be explicitly decremented here in the error
      path and after the last usage.
      
      Fixes: d3c68e0a ("PCI: faraday: Add Faraday Technology FTPCI100 PCI Host Bridge driver")
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      [lorenzo.pieralisi@arm.com: updated 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 avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      441712f2
    • Nicholas Mc Guire's avatar
      PCI: xilinx-nwl: Add missing of_node_put() · 7851cea4
      Nicholas Mc Guire authored
      [ Upstream commit 342639d9 ]
      
      The call to of_get_next_child() returns a node pointer with
      refcount incremented thus it must be explicitly decremented
      here after the last usage.
      
      Fixes: ab597d35 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller")
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      [lorenzo.pieralisi@arm.com: updated commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7851cea4
    • Nicholas Mc Guire's avatar
      PCI: xilinx: Add missing of_node_put() · dfcee0c7
      Nicholas Mc Guire authored
      [ Upstream commit 8c3f9bd8 ]
      
      The call to of_get_next_child() returns a node pointer with refcount
      incremented thus it must be explicitly decremented here after the last
      usage.
      
      Fixes: 8961def5 ("PCI: xilinx: Add Xilinx AXI PCIe Host Bridge IP driver")
      Signed-off-by: default avatarNicholas Mc Guire <hofrat@osadl.org>
      [lorenzo.pieralisi@arm.com: reworked commit log]
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfcee0c7
  9. 15 Aug, 2018 1 commit
    • Nicolai Stange's avatar
      x86: Don't include linux/irq.h from asm/hardirq.h · 18f891ef
      Nicolai Stange authored
      commit 447ae316 upstream
      
      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: default avatarNicolai Stange <nstange@suse.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      18f891ef
  10. 09 Aug, 2018 1 commit
  11. 03 Aug, 2018 4 commits
  12. 22 Jul, 2018 2 commits
  13. 03 Jul, 2018 4 commits
  14. 20 Jun, 2018 1 commit
  15. 11 Jun, 2018 1 commit
  16. 05 Jun, 2018 1 commit
    • Dexuan Cui's avatar
      PCI: hv: Fix 2 hang issues in hv_compose_msi_msg() · 54978daa
      Dexuan Cui authored
      commit de0aa7b2 upstream.
      
      1. With the patch "x86/vector/msi: Switch to global reservation mode",
      the recent v4.15 and newer kernels always hang for 1-vCPU Hyper-V VM
      with SR-IOV. This is because when we reach hv_compose_msi_msg() by
      request_irq() -> request_threaded_irq() ->__setup_irq()->irq_startup()
      -> __irq_startup() -> irq_domain_activate_irq() -> ... ->
      msi_domain_activate() -> ... -> hv_compose_msi_msg(), local irq is
      disabled in __setup_irq().
      
      Note: when we reach hv_compose_msi_msg() by another code path:
      pci_enable_msix_range() -> ... -> irq_domain_activate_irq() -> ... ->
      hv_compose_msi_msg(), local irq is not disabled.
      
      hv_compose_msi_msg() depends on an interrupt from the host.
      With interrupts disabled, a UP VM always hangs in the busy loop in
      the function, because the interrupt callback hv_pci_onchannelcallback()
      can not be called.
      
      We can do nothing but work it around by polling the channel. This
      is ugly, but we don't have any other choice.
      
      2. If the host is ejecting the VF device before we reach
      hv_compose_msi_msg(), in a UP VM, we can hang in hv_compose_msi_msg()
      forever, because at this time the host doesn't respond to the
      CREATE_INTERRUPT request. This issue exists the first day the
      pci-hyperv driver appears in the kernel.
      
      Luckily, this can also by worked around by polling the channel
      for the PCI_EJECT message and hpdev->state, and by checking the
      PCI vendor ID.
      
      Note: actually the above 2 issues also happen to a SMP VM, if
      "hbus->hdev->channel->target_cpu == smp_processor_id()" is true.
      
      Fixes: 4900be83 ("x86/vector/msi: Switch to global reservation mode")
      Tested-by: default avatarAdrian Suhov <v-adsuho@microsoft.com>
      Tested-by: default avatarChris Valean <v-chvale@microsoft.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Reviewed-by: default avatarMichael Kelley <mikelley@microsoft.com>
      Acked-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Cc: <stable@vger.kernel.org>
      Cc: Stephen Hemminger <sthemmin@microsoft.com>
      Cc: K. Y. Srinivasan <kys@microsoft.com>
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Jack Morgenstein <jackm@mellanox.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54978daa
  17. 30 May, 2018 2 commits
  18. 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>
      64a03d3b
    • 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
      condition.
      
      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>
      89d5c4eb
  19. 01 May, 2018 3 commits