linux.git/drivers/pci, branch v4.14.49

PCI: hv: Do not wait forever on a device that has disappeared

2018-06-11T20:49:22+00:00

commit c3635da2a336441253c33298b87b3042db100725 upstream.

Before the guest finishes the device initialization, the device can be
removed anytime by the host, and after that the host won't respond to
the guest's request, so the guest should be prepared to handle this
case.

Add a polling mechanism to detect device presence.

Signed-off-by: Dexuan Cui 
[lorenzo.pieralisi@arm.com: edited commit log]
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Haiyang Zhang 
Cc: Stephen Hemminger 
Cc: K. Y. Srinivasan 
Signed-off-by: Greg Kroah-Hartman

PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()

2018-06-05T09:41:55+00:00

commit de0aa7b2f97d348ba7d1e17a00744c989baa0cb6 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: 4900be83602b ("x86/vector/msi: Switch to global reservation mode")
Tested-by: Adrian Suhov 
Tested-by: Chris Valean 
Signed-off-by: Dexuan Cui 
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Michael Kelley 
Acked-by: Haiyang Zhang 
Cc: 
Cc: Stephen Hemminger 
Cc: K. Y. Srinivasan 
Cc: Vitaly Kuznetsov 
Cc: Jack Morgenstein 
Signed-off-by: Greg Kroah-Hartman

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

2018-05-30T05:52:38+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:52:32+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 / PM: Check device_may_wakeup() in pci_enable_wake()

2018-05-16T08:10:29+00:00

commit cfcadfaad7251d8b640713724b388164d75465b2 upstream.

Commit 0847684cfc5f0 (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: 0847684cfc5f0 (PCI / PM: Simplify device wakeup settings code)
Reported-by: Joseph Salisbury 
Cc: 4.13+  # 4.13+
Signed-off-by: Rafael J. Wysocki 
Acked-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI / PM: Always check PME wakeup capability for runtime wakeup support

2018-05-16T08:10:29+00:00

commit 8feaec33b9868582654cd3d5355225dcb79aeca6 upstream.

USB controller ASM1042 stops working after commit de3ef1eb1cd0 (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 de3ef1eb1cd0, 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: de3ef1eb1cd0 (PM / core: Drop run_wake flag from struct dev_pm_info)
Signed-off-by: Kai-Heng Feng 
Cc: 4.13+  # 4.13+
Acked-by: Bjorn Helgaas 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Fix PCIe Max Read Request Size setting

2018-05-01T19:58:21+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: Use ISR1 instead of ISR0 interrupt in legacy irq mode

2018-05-01T19:58:20+00:00

commit 3430f924a62905891c8fa9a3b97ea52007795bc3 upstream.

The Aardvark has two interrupts sets:

 - first set is bit[23:16] of PCIe ISR 0 register(RD0074840h)

 - second set is bit[11:8] of PCIe ISR 1 register(RD0074848h)

Only one set should be used, while another set should be masked.

The second set, ISR1, is more advanced, the Legacy INT_X status bit is
asserted once Assert_INTX message is received, and de-asserted after
Deassert_INTX message is received which matches what the driver is
currently doing in the ->irq_mask() and ->irq_unmask() functions.

The ISR0 requires additional work to deassert the interrupt, which the
driver does not currently implement, therefore it needs fixing.

Update the driver to use ISR1 register set, fixing current
implementation.

Fixes: 8c39d710363c1 ("PCI: aardvark: Add Aardvark PCI host controller driver")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196339
Signed-off-by: Victor Gu 
[Thomas: tweak commit log.]
Signed-off-by: Thomas Petazzoni 
[lorenzo.pieralisi@arm.com: updated the commit log]
Signed-off-by: Lorenzo Pieralisi 
Reviewed-by: Evan Wang 
Reviewed-by: Nadav Haklai 
Cc: 
Signed-off-by: Greg Kroah-Hartman

PCI: aardvark: Set PIO_ADDR_LS correctly in advk_pcie_rd_conf()

2018-05-01T19:58:20+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-01T19:58:20+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