linux-stable.git/drivers/pci, branch v4.9.115

PCI: pciehp: Clear Presence Detect and Data Link Layer Status Changed on resume

2018-07-03T09:23:10+00:00

commit 13c65840feab8109194f9490c9870587173cb29d upstream.

After a suspend/resume cycle the Presence Detect or Data Link Layer Status
Changed bits might be set.  If we don't clear them those events will not
fire anymore and nothing happens for instance when a device is now
hot-unplugged.

Fix this by clearing those bits in a newly introduced function
pcie_reenable_notification().  This should be fine because immediately
after, we check if the adapter is still present by reading directly from
the status register.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Rafael J. Wysocki 
Reviewed-by: Andy Shevchenko 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: Add ACS quirk for Intel 300 series

2018-07-03T09:23:10+00:00

commit f154a718e6cc0d834f5ac4dc4c3b174e65f3659e upstream.

Intel 300 series chipset still has the same ACS issue as the previous
generations so extend the ACS quirk to cover it as well.

Signed-off-by: Mika Westerberg 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: Add ACS quirk for Intel 7th & 8th Gen mobile

2018-07-03T09:23:10+00:00

commit e8440f4bfedc623bee40c84797ac78d9303d0db6 upstream.

The specification update indicates these have the same errata for
implementing non-standard ACS capabilities.

Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

PCI: Add function 1 DMA alias quirk for Marvell 88SE9220

2018-05-30T05:50:49+00:00

[ Upstream commit 832e4e1f76b8a84991e9db56fdcef1ebce839b8b ]

Add Marvell 88SE9220 DMA quirk as found and tested on bug 42679.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Signed-off-by: Thomas Vincent-Cross 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Restore config space on runtime resume despite being unbound

2018-05-30T05:50:46+00:00

[ Upstream commit 5775b843a619b3c93f946e2b55a208d9f0f48b59 ]

We leave PCI devices not bound to a driver in D0 during runtime suspend.
But they may have a parent which is bound and can be transitioned to
D3cold at runtime. Once the parent goes to D3cold, the unbound child
may go to D3cold as well. When the child goes to D3cold, its internal
state, including configuration of BARs, MSI, ASPM, MPS, etc., is lost.

One example are recent hybrid graphics laptops which cut power to the
discrete GPU when the root port above it goes to ACPI power state D3.
Users may provoke this by unbinding the GPU driver and allowing runtime
PM on the GPU via sysfs: The PM core will then treat the GPU as
"suspended", which in turn allows the root port to runtime suspend,
causing the power resources listed in its _PR3 object to be powered off.
The GPU's BARs will be uninitialized when a driver later probes it.

Another example are hybrid graphics laptops where the GPU itself (rather
than the root port) is capable of runtime suspending to D3cold. If the
GPU's integrated HDA controller is not bound and the GPU's driver
decides to runtime suspend to D3cold, the HDA controller's BARs will be
uninitialized when a driver later probes it.

Fix by saving and restoring config space over a runtime suspend cycle
even if the device is not bound.

Acked-by: Bjorn Helgaas
Tested-by: Peter Wu # Nvidia Optimus
Tested-by: Lukas Wunner # MacBook Pro
Signed-off-by: Rafael J. Wysocki
[lukas: add commit message, bikeshed code comments for clarity]
Signed-off-by: Lukas Wunner
Link: https://patchwork.freedesktop.org/patch/msgid/92fb6e6ae2730915eb733c08e2f76c6a313e3860.1520068884.git.lukas@wunner.de
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman

PCI: Add function 1 DMA alias quirk for Marvell 9128

2018-05-30T05:50:19+00:00

[ Upstream commit aa008206634363ef800fbd5f0262016c9ff81dea ]

The Marvell 9128 is the original device generating bug 42679, from which
many other Marvell DMA alias quirks have been sourced, but we didn't have
positive confirmation of the fix on 9128 until now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=42679
Link: https://www.spinics.net/lists/kvm/msg161459.html
Reported-by: Binarus 
Tested-by: Binarus 
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Fix PCIe Max Read Request Size setting

2018-05-01T22:13:08+00:00

commit fc31c4e347c9dad50544d01d5ee98b22c7df88bb upstream.

There is an obvious typo issue in the definition of the PCIe maximum
read request size: a bit shift is directly used as a value, while it
should be used to shift the correct value.

Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Cc: 
Signed-off-by: Evan Wang 
Reviewed-by: Victor Gu 
Reviewed-by: Nadav Haklai 
[Thomas: tweak commit log.]
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Set PIO_ADDR_LS correctly in advk_pcie_rd_conf()

2018-05-01T22:13:08+00:00

commit 4fa3999ee672c54a5498ce98e20fe3fdf9c1cbb4 upstream.

When setting the PIO_ADDR_LS register during a configuration read, we
were properly passing the device number, function number and register
number, but not the bus number, causing issues when reading the
configuration of PCIe devices.

Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Cc: 
Signed-off-by: Victor Gu 
Reviewed-by: Wilson Ding 
Reviewed-by: Nadav Haklai 
[Thomas: tweak commit log.]
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Fix logic in advk_pcie_{rd,wr}_conf()

2018-05-01T22:13:08+00:00

commit 660661afcd40ed7f515ef3369721ed58e80c0fc5 upstream.

The PCI configuration space read/write functions were special casing
the situation where PCI_SLOT(devfn) != 0, and returned
PCIBIOS_DEVICE_NOT_FOUND in this case.

However, while this is what is intended for the root bus, it is not
intended for the child busses, as it prevents discovering devices with
PCI_SLOT(x) != 0. Therefore, we return PCIBIOS_DEVICE_NOT_FOUND only
if we're on the root bus.

Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Cc: 
Signed-off-by: Victor Gu 
Reviewed-by: Wilson Ding 
Reviewed-by: Nadav Haklai 
[Thomas: tweak commit log.]
Signed-off-by: Thomas Petazzoni 
Signed-off-by: Lorenzo Pieralisi 
Signed-off-by: Greg Kroah-Hartman

PCI: Wait up to 60 seconds for device to become ready after FLR

2018-04-29T09:31:58+00:00

commit 821cdad5c46cae94ce65b9a98614c70a6ff021f8 upstream.

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: Sinan Kaya 
[bhelgaas: include the mandatory 100ms in the delays we print]
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman