linux-stable.git/drivers/pci, branch v3.18.26

PCI: Add VPD function 0 quirk for Intel Ethernet devices

2015-12-03T03:35:50+00:00

[ Upstream commit 7aa6ca4d39edf01f997b9e02cf6d2fdeb224f351 ]

Set the PCI_DEV_FLAGS_VPD_REF_F0 flag on all Intel Ethernet device
functions other than function 0, so that on multi-function devices, we will
always read VPD from function 0 instead of from the other functions.

[bhelgaas: changelog]
Signed-off-by: Mark Rustad 
Signed-off-by: Bjorn Helgaas 
Acked-by: Alexander Duyck 
CC: stable@vger.kernel.org

Signed-off-by: Sasha Levin

PCI: Add dev_flags bit to access VPD through function 0

2015-12-03T03:35:38+00:00

[ Upstream commit 91a37c794cf2cf7ec1f9afc4cbf4a118df7e085e ]

commit 932c435caba8a2ce473a91753bad0173269ef334 upstream.

Add a dev_flags bit, PCI_DEV_FLAGS_VPD_REF_F0, to access VPD through
function 0 to provide VPD access on other functions.  This is for hardware
devices that provide copies of the same VPD capability registers in
multiple functions.  Because the kernel expects that each function has its
own registers, both the locking and the state tracking are affected by VPD
accesses to different functions.

On such devices for example, if a VPD write is performed on function 0,
*any* later attempt to read VPD from any other function of that device will
hang.  This has to do with how the kernel tracks the expected value of the
F bit per function.

Concurrent accesses to different functions of the same device can not only
hang but also corrupt both read and write VPD data.

When hangs occur, typically the error message:

  vpd r/w failed.  This is likely a firmware bug on this device.

will be seen.

Never set this bit on function 0 or there will be an infinite recursion.

Signed-off-by: Mark Rustad 
Signed-off-by: Bjorn Helgaas 
Acked-by: Alexander Duyck 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

PCI: Add flag for devices that don't reset on D3hot->D0 transition

2015-12-03T03:35:32+00:00

[ Upstream commit 51e537387990dc1f00752103f314fd135cb94bc6 ]

Per the PCI Power Management spec r1.2, sec 3.2.4, a device that advertises
No_Soft_Reset == 0 in the PMCSR register (reported by lspci as "NoSoftRst-")
should perform an internal reset when transitioning from D3hot to D0 via
software control.  Configuration context is lost and the device requires a
full reinitialization sequence.

Unfortunately the definition of "internal reset", beyond the application of
the configuration context, is largely left to the interpretation of the
specific device.  Some devices don't seem to perform an "internal reset"
even if they report No_Soft_Reset == 0.

We still need to honor the PCI specification and restore PCI config context
in the event that we do a PM reset, so we don't cache and modify the
PCI_PM_CTRL_NO_SOFT_RESET bit for the device, but for interfaces where the
intention is to reset the device, like pci_reset_function(), we need a
mechanism to flag that PM reset (a D3hot->D0 transition) doesn't perform
any significant "internal reset" of the device.

Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Sasha Levin

PCI: Fix TI816X class code quirk

2015-10-28T02:14:39+00:00

[ Upstream commit d1541dc977d376406f4584d8eb055488655c98ec ]

In fixup_ti816x_class(), we assigned "class = PCI_CLASS_MULTIMEDIA_VIDEO".
But PCI_CLASS_MULTIMEDIA_VIDEO is only the two-byte base class/sub-class
and needs to be shifted to make space for the low-order interface byte.

Shift PCI_CLASS_MULTIMEDIA_VIDEO to set the correct class code.

Fixes: 63c4408074cb ("PCI: Add quirk for setting valid class for TI816X Endpoint")
Signed-off-by: Bjorn Helgaas 
CC: Hemant Pedanekar 
Signed-off-by: Sasha Levin

PCI: pciehp: Wait for hotplug command completion where necessary

2015-07-04T03:02:25+00:00

[ Upstream commit a5dd4b4b0570b3bf880d563969b245dfbd170c1e ]

The commit referenced below deferred waiting for command completion until
the start of the next command, allowing hardware to do the latching
asynchronously.  Unfortunately, being ready to accept a new command is the
only indication we have that the previous command is completed.  In cases
where we need that state change to be enabled, we must still wait for
completion.  For instance, pciehp_reset_slot() attempts to disable anything
that might generate a surprise hotplug on slots that support presence
detection.  If we don't wait for those settings to latch before the
secondary bus reset, we negate any value in attempting to prevent the
spurious hotplug.

Create a base function with optional wait and helper functions so that
pcie_write_cmd() turns back into the "safe" interface which waits before
and after issuing a command and add pcie_write_cmd_nowait(), which
eliminates the trailing wait for asynchronous completion.  The following
functions are returned to their previous behavior:

  pciehp_power_on_slot
  pciehp_power_off_slot
  pcie_disable_notification
  pciehp_reset_slot

The rationale is that pciehp_power_on_slot() enables the link and therefore
relies on completion of power-on.  pciehp_power_off_slot() and
pcie_disable_notification() need a wait because data structures may be
freed after these calls and continued signaling from the device would be
unexpected.  And, of course, pciehp_reset_slot() needs to wait for the
scenario outlined above.

Fixes: 3461a068661c ("PCI: pciehp: Wait for hotplug command completion lazily")
Signed-off-by: Alex Williamson 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v3.17+
Signed-off-by: Sasha Levin

PCI: Propagate the "ignore hotplug" setting to parent

2015-07-04T03:02:18+00:00

[ Upstream commit 0824965140fff1bf640a987dc790d1594a8e0699 ]

Refine the mechanism introduced by commit f244d8b623da ("ACPIPHP / radeon /
nouveau: Fix VGA switcheroo problem related to hotplug") to propagate the
ignore_hotplug setting of the device to its parent bridge in case hotplug
notifications related to the graphics adapter switching are given for the
bridge rather than for the device itself (they need to be ignored in both
cases).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=61891
Link: https://bugs.freedesktop.org/show_bug.cgi?id=88927
Fixes: b440bde74f04 ("PCI: Add pci_ignore_hotplug() to ignore hotplug events for a device")
Reported-and-tested-by: tiagdtd-lava 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v3.17+
Signed-off-by: Sasha Levin

PCI: spear: Drop __initdata from spear13xx_pcie_driver

2015-04-23T03:31:01+00:00

[ Upstream commit a43f32d647273023edddb0dc8f91c4c6378b252b ]

Struct spear13xx_pcie_driver was in initdata, but we passed a pointer to it
to platform_driver_register(), which can use the pointer at arbitrary times
in the future, even after the initdata is freed.  That leads to crashes.

Move spear13xx_pcie_driver and things referenced by it
(spear13xx_pcie_probe() and dw_pcie_host_init()) out of initdata.

[bhelgaas: changelog]
Fixes: 6675ef212dac ("PCI: spear: Fix Section mismatch compilation warning for probe()")
Signed-off-by: Matwey V. Kornilov 
Signed-off-by: Bjorn Helgaas 
Acked-by: Viresh Kumar 
CC: stable@vger.kernel.org	# v3.17+

Signed-off-by: Sasha Levin

PCI: Don't look for ACPI hotplug parameters if ACPI is disabled

2015-04-23T03:30:27+00:00

[ Upstream commit 8647ca9ad5a0065ad53a2ad7e39163592b6ed35e ]

Booting a v3.18 or newer Xen domU kernel with PCI devices passed through
results in an oops (this is a 32-bit 3.13.11 dom0 with a 64-bit 4.4.0
hypervisor and 32-bit domU):

  BUG: unable to handle kernel paging request at 0030303e
  IP: [] acpi_ns_validate_handle+0x12/0x1a
  Call Trace:
   [] ? acpi_evaluate_object+0x31/0x1fc
   [] ? pci_get_hp_params+0x111/0x4e0
   [] ? xen_force_evtchn_callback+0x17/0x30
   [] ? xen_restore_fl_direct_reloc+0x4/0x4
   [] ? pci_device_add+0x24/0x450

Don't look for ACPI configuration information if ACPI has been disabled.

I don't think this is the best fix, because we can boot plain Linux (no
Xen) with "acpi=off", and we don't need this check in pci_get_hp_params().
There should be a better fix that would make Xen domU work the same way.
The domU kernel has ACPI support but it has no AML.  There should be a way
to initialize the ACPI data structures so things fail gracefully rather
than oopsing.  This is an interim fix to address the regression.

Fixes: 6cd33649fa83 ("PCI: Add pci_configure_device() during enumeration")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96301
Reported-by: Michael D Labriola 
Tested-by: Michael D Labriola 
Signed-off-by: Bjorn Helgaas 
CC: stable@vger.kernel.org	# v3.18+
Signed-off-by: Sasha Levin

PCI: cpcihp: Add missing curly braces in cpci_configure_slot()

2015-04-23T03:28:34+00:00

[ Upstream commit bc3b5b47c80da8838758731d423179262c9c36ec ]

I don't have this hardware but it looks like we weren't adding bridge
devices as intended.  Maybe the bridge is always the last device?

Fixes: 05b125004815 ("PCI: cpcihp: Iterate over all devices in slot, not functions 0-7")
Signed-off-by: Dan Carpenter 
Signed-off-by: Bjorn Helgaas 
Acked-by: Yijing Wang 
CC: stable@vger.kernel.org	# v3.9+
Signed-off-by: Sasha Levin

PCI/AER: Avoid info leak in __print_tlp_header()

2015-04-23T03:28:22+00:00

[ Upstream commit a1b7f2f6367944d445c6853035830a35c6343939 ]

Commit fab4c256a58b ("PCI/AER: Add a TLP header print helper") introduced
the helper function __print_tlp_header(), but contrary to the intention,
the behaviour did change: Since we're taking the address of the parameter
t, the first 4 or 8 bytes printed will be the value of the pointer t
itself, and the remaining 12 or 8 bytes will be who-knows-what (something
from the stack).

We want to show the values of the four members of the struct
aer_header_log_regs; that can be done without ugly and error-prone casts.
On little-endian this should produce the same output as originally
intended, and since no-one has complained about getting garbage output so
far, I think big-endian should be ok too.

Fixes: fab4c256a58b ("PCI/AER: Add a TLP header print helper")
Signed-off-by: Rasmus Villemoes 
Signed-off-by: Bjorn Helgaas 
Acked-by: Borislav Petkov 
CC: stable@vger.kernel.org	# v3.14+
Signed-off-by: Sasha Levin