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

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

PCI: Don't read past the end of sysfs "driver_override" buffer

2015-03-28T14:01:54+00:00

[ Upstream commit 4efe874aace57dba967624ce1c48322da2447b75 ]

When printing the driver_override parameter when it is 4095 and 4094 bytes
long, the printing code would access invalid memory because we need count+1
bytes for printing.

Fixes: 782a985d7af2 ("PCI: Introduce new device binding path using pci_dev.driver_override")
Signed-off-by: Sasha Levin 
Signed-off-by: Bjorn Helgaas 
Acked-by: Alex Williamson 
CC: stable@vger.kernel.org	# v3.16+
CC: Konrad Rzeszutek Wilk 
CC: Alexander Graf 
CC: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

PCI: Fix infinite loop with ROM image of size 0

2015-03-06T22:52:46+00:00

commit 16b036af31e1456cb69243a5a0c9ef801ecd1f17 upstream.

If the image size would ever read as 0, pci_get_rom_size() could keep
processing the same image over and over again.  Exit the loop if we ever
read a length of zero.

This fixes a soft lockup on boot when the radeon driver calls
pci_get_rom_size() on an AMD Radeon R7 250X PCIe discrete graphics card.

[bhelgaas: changelog, reference]
Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386973
Reported-by: Federico 
Signed-off-by: Michel Dänzer 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

PCI: Generate uppercase hex for modalias var in uevent

2015-03-06T22:52:46+00:00

commit 145b3fe579db66fbe999a2bc3fd5b63dffe9636d upstream.

Some implementations of modprobe fail to load the driver for a PCI device
automatically because the "interface" part of the modalias from the kernel
is lowercase, and the modalias from file2alias is uppercase.

The "interface" is the low-order byte of the Class Code, defined in PCI
r3.0, Appendix D.  Most interface types defined in the spec do not use
alpha characters, so they won't be affected.  For example, 00h, 01h, 10h,
20h, etc. are unaffected.

Print the "interface" byte of the Class Code in uppercase hex, as we
already do for the Vendor ID, Device ID, Class, etc.

Commit 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface
class") fixed only half of the problem.  Some udev implementations rely on
the uevent file and not the modalias file.

Fixes: d1ded203adf1 ("PCI: add MODALIAS to hotplug event for pci devices")
Fixes: 89ec3dcf17fd ("PCI: Generate uppercase hex for modalias interface class")
Signed-off-by: Ricardo Ribalda Delgado 
Signed-off-by: Bjorn Helgaas 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Greg Kroah-Hartman

PCI: Handle read-only BARs on AMD CS553x devices

2015-02-11T07:00:50+00:00

commit 06cf35f903aa6da0cc8d9f81e9bcd1f7e1b534bb upstream.

Some AMD CS553x devices have read-only BARs because of a firmware or
hardware defect.  There's a workaround in quirk_cs5536_vsa(), but it no
longer works after 36e8164882ca ("PCI: Restore detection of read-only
BARs").  Prior to 36e8164882ca, we filled in res->start; afterwards we
leave it zeroed out.  The quirk only updated the size, so the driver tried
to use a region starting at zero, which didn't work.

Expand quirk_cs5536_vsa() to read the base addresses from the BARs and
hard-code the sizes.

On Nix's system BAR 2's read-only value is 0x6200.  Prior to 36e8164882ca,
we interpret that as a 512-byte BAR based on the lowest-order bit set.  Per
datasheet sec 5.6.1, that BAR (MFGPT) requires only 64 bytes; use that to
avoid clearing any address bits if a platform uses only 64-byte alignment.

[bhelgaas: changelog, reduce BAR 2 size to 64]
Fixes: 36e8164882ca ("PCI: Restore detection of read-only BARs")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85991#c4
Link: http://support.amd.com/TechDocs/31506_cs5535_databook.pdf
Link: http://support.amd.com/TechDocs/33238G_cs5536_db.pdf
Reported-and-tested-by: Nix 
Signed-off-by: Myron Stowe 
Signed-off-by: Bjorn Helgaas 
Signed-off-by: Greg Kroah-Hartman