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

PCI / PM: Force devices to D0 in pci_pm_thaw_noirq()

2017-12-29T16:42:59+00:00

commit 5839ee7389e893a31e4e3c9cf17b50d14103c902 upstream.

It is incorrect to call pci_restore_state() for devices in low-power
states (D1-D3), as that involves the restoration of MSI setup which
requires MMIO to be operational and that is only the case in D0.

However, pci_pm_thaw_noirq() may do that if the driver's "freeze"
callbacks put the device into a low-power state, so fix it by making
it force devices into D0 via pci_set_power_state() instead of trying
to "update" their power state which is pointless.

Fixes: e60514bd4485 (PCI/PM: Restore the status of PCI devices across hibernation)
Reported-by: Thomas Gleixner 
Reported-by: Maarten Lankhorst 
Tested-by: Thomas Gleixner 
Tested-by: Maarten Lankhorst 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI/AER: Report non-fatal errors only to the affected endpoint

2017-12-25T13:23:44+00:00

[ Upstream commit 86acc790717fb60fb51ea3095084e331d8711c74 ]

Previously, if an non-fatal error was reported by an endpoint, we
called report_error_detected() for the endpoint, every sibling on the
bus, and their descendents.  If any of them did not implement the
.error_detected() method, do_recovery() failed, leaving all these
devices unrecovered.

For example, the system described in the bugzilla below has two devices:

  0000:74:02.0 [19e5:a230] SAS controller, driver has .error_detected()
  0000:74:03.0 [19e5:a235] SATA controller, driver lacks .error_detected()

When a device such as 74:02.0 reported a non-fatal error, do_recovery()
failed because 74:03.0 lacked an .error_detected() method.  But per PCIe
r3.1, sec 6.2.2.2.2, such an error does not compromise the Link and
does not affect 74:03.0:

  Non-fatal errors are uncorrectable errors which cause a particular
  transaction to be unreliable but the Link is otherwise fully functional.
  Isolating Non-fatal from Fatal errors provides Requester/Receiver logic
  in a device or system management software the opportunity to recover from
  the error without resetting the components on the Link and disturbing
  other transactions in progress.  Devices not associated with the
  transaction in error are not impacted by the error.

Report non-fatal errors only to the endpoint that reported them.  We really
want to check for AER_NONFATAL here, but the current code structure doesn't
allow that.  Looking for pci_channel_io_normal is the best we can do now.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=197055
Fixes: 6c2b374d7485 ("PCI-Express AER implemetation: AER core and aerdriver")
Signed-off-by: Gabriele Paoloni 
Signed-off-by: Dongdong Liu 
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Create SR-IOV virtfn/physfn links before attaching driver

2017-12-25T13:23:44+00:00

[ Upstream commit 27d6162944b9b34c32cd5841acd21786637ee743 ]

When creating virtual functions, create the "virtfn%u" and "physfn" links
in sysfs *before* attaching the driver instead of after.  When we attach
the driver to the new virtual network interface first, there is a race when
the driver attaches to the new sends out an "add" udev event, and the
network interface naming software (biosdevname or systemd, for example)
tries to look at these links.

Signed-off-by: Stuart Hayes 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Avoid bus reset if bridge itself is broken

2017-12-25T13:23:44+00:00

[ Upstream commit 357027786f3523d26f42391aa4c075b8495e5d28 ]

When checking to see if a PCI bus can safely be reset, we previously
checked to see if any of the children had their PCI_DEV_FLAGS_NO_BUS_RESET
flag set.  Children marked with that flag are known not to behave well
after a bus reset.

Some PCIe root port bridges also do not behave well after a bus reset,
sometimes causing the devices behind the bridge to become unusable.

Add a check for PCI_DEV_FLAGS_NO_BUS_RESET being set in the bridge device
to allow these bridges to be flagged, and prevent their secondary buses
from being reset.

Signed-off-by: David Daney 
[jglauber@cavium.com: fixed typo]
Signed-off-by: Jan Glauber 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Alex Williamson 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Detach driver before procfs & sysfs teardown on device remove

2017-12-20T09:07:31+00:00

[ Upstream commit 16b6c8bb687cc3bec914de09061fcb8411951fda ]

When removing a device, for example a VF being removed due to SR-IOV
teardown, a "soft" hot-unplug via 'echo 1 > remove' in sysfs, or an actual
hot-unplug, we first remove the procfs and sysfs attributes for the device
before attempting to release the device from any driver bound to it.
Unbinding the driver from the device can take time.  The device might need
to write out data or it might be actively in use.  If it's in use by
userspace through a vfio driver, the unbind might block until the user
releases the device.  This leads to a potentially non-trivial amount of
time where the device exists, but we've torn down the interfaces that
userspace uses to examine devices, for instance lspci might generate this
sort of error:

  pcilib: Cannot open /sys/bus/pci/devices/0000:01:0a.3/config
  lspci: Unable to read the standard configuration space header of device 0000:01:0a.3

We don't seem to have any dependence on this teardown ordering in the
kernel, so let's unbind the driver first, which is also more symmetric with
the instantiation of the device in pci_bus_add_device().

Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Do not allocate more buses than available in parent

2017-12-20T09:07:28+00:00

[ Upstream commit a20c7f36bd3d20d245616ae223bb9d05dfb6f050 ]

One can ask more buses to be reserved for hotplug bridges by passing
pci=hpbussize=N in the kernel command line.  If the parent bus does not
have enough bus space available we incorrectly create child bus with the
requested number of subordinate buses.

In the example below hpbussize is set to one more than we have available
buses in the root port:

  pci 0000:07:00.0: [8086:1578] type 01 class 0x060400
  pci 0000:07:00.0: scanning [bus 00-00] behind bridge, pass 0
  pci 0000:07:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
  pci 0000:07:00.0: scanning [bus 00-00] behind bridge, pass 1
  pci_bus 0000:08: busn_res: can not insert [bus 08-ff] under [bus 07-3f] (conflicts with (null) [bus 07-3f])
  pci_bus 0000:08: scanning bus
  ...
  pci_bus 0000:0a: bus scan returning with max=40
  pci_bus 0000:0a: busn_res: [bus 0a-ff] end is updated to 40
  pci_bus 0000:0a: [bus 0a-40] partially hidden behind bridge 0000:07 [bus 07-3f]
  pci_bus 0000:08: bus scan returning with max=40
  pci_bus 0000:08: busn_res: [bus 08-ff] end is updated to 40

Instead of allowing this, limit the subordinate number to be less than or
equal the maximum subordinate number allocated for the parent bus (if it
has any).

Signed-off-by: Mika Westerberg 
[bhelgaas: remove irrelevant dmesg messages]
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI/PME: Handle invalid data when reading Root Status

2017-12-20T09:07:27+00:00

[ Upstream commit 3ad3f8ce50914288731a3018b27ee44ab803e170 ]

PCIe PME and native hotplug share the same interrupt number, so hotplug
interrupts are also processed by PME.  In some cases, e.g., a Link Down
interrupt, a device may be present but unreachable, so when we try to
read its Root Status register, the read fails and we get all ones data
(0xffffffff).

Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e.,
"some device has asserted PME," so we scheduled pcie_pme_work_fn().  This
caused an infinite loop because pcie_pme_work_fn() tried to handle PME
requests until PCI_EXP_RTSTA_PME is cleared, but with the link down,
PCI_EXP_RTSTA_PME can't be cleared.

Check for the invalid 0xffffffff data everywhere we read the Root Status
register.

1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from
non-existent devices") added similar checks in the hotplug driver.

Signed-off-by: Qiang Zheng 
[bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow
other similar checks]
Signed-off-by: Bjorn Helgaas 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PCI: Apply _HPX settings only to relevant devices

2017-11-30T08:39:10+00:00

[ Upstream commit 977509f7c5c6fb992ffcdf4291051af343b91645 ]

Previously we didn't check the type of device before trying to apply Type 1
(PCI-X) or Type 2 (PCIe) Setting Records from _HPX.

We don't support PCI-X Setting Records, so this was harmless, but the
warning was useless.

We do support PCIe Setting Records, and we didn't check whether a device
was PCIe before applying settings.  I don't think anything bad happened on
non-PCIe devices because pcie_capability_clear_and_set_word(),
pcie_cap_has_lnkctl(), etc., would fail before doing any harm.  But it's
ugly to depend on those internals.

Check the device type before attempting to apply Type 1 and Type 2 Setting
Records (Type 0 records are applicable to PCI, PCI-X, and PCIe devices).

A side benefit is that this prevents useless "not supported" warnings when
a BIOS supplies a Type 1 (PCI-X) Setting Record and we try to apply it to
every single device:

  pci 0000:00:00.0: PCI-X settings not supported

After this patch, we'll get the warning only when a BIOS supplies a Type 1
record and we have a PCI-X device to which it should be applied.

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

PCI: Set Cavium ACS capability quirk flags to assert RR/CR/SV/UF

2017-11-30T08:39:02+00:00

commit 7f342678634f16795892677204366e835e450dda upstream.

The Cavium ThunderX (CN8XXX) family of PCIe Root Ports does not advertise
an ACS capability.  However, the RTL internally implements similar
protection as if ACS had Request Redirection, Completion Redirection,
Source Validation, and Upstream Forwarding features enabled.

Change Cavium ACS capabilities quirk flags accordingly.

Fixes: b404bcfbf035 ("PCI: Add ACS quirk for all Cavium devices")
Signed-off-by: Vadim Lomovtsev 
[bhelgaas: tidy changelog, comment, stable tag]
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman

PCI: mvebu: Handle changes to the bridge windows while enabled

2017-11-15T14:53:11+00:00

[ Upstream commit d9bf28e2650fe3eeefed7e34841aea07d10c6543 ]

The PCI core will write to the bridge window config multiple times while
they are enabled.  This can lead to mbus failures like this:

 mvebu_mbus: cannot add window '4:e8', conflicts with another window
 mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22

For me this is happening during a hotplug cycle.  The PCI core is not
changing the values, just writing them twice while active.

The patch addresses the general case of any change to an active window, but
not atomically.  The code is slightly refactored so io and mem can share
more of the window logic.

Signed-off-by: Jason Gunthorpe 
Signed-off-by: Bjorn Helgaas 
Acked-by: Jason Cooper 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman