<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/pci, branch v3.16.45</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>powerpc/pci/rpadlpar: Fix device reference leaks</title>
<updated>2017-03-16T02:26:20+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan@kernel.org</email>
</author>
<published>2016-11-01T15:26:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4554c6aec03bb0135cafadb68e4531e2d13b07f4'/>
<id>4554c6aec03bb0135cafadb68e4531e2d13b07f4</id>
<content type='text'>
commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream.

Make sure to drop any device reference taken by vio_find_node() when
adding and removing virtual I/O slots.

Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 99e5cde5eae78bef95bfe7c16ccda87fb070149b upstream.

Make sure to drop any device reference taken by vio_find_node() when
adding and removing virtual I/O slots.

Fixes: 5eeb8c63a38f ("[PATCH] PCI Hotplug: rpaphp: Move VIO registration")
Signed-off-by: Johan Hovold &lt;johan@kernel.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Check for PME in targeted sleep state</title>
<updated>2017-03-16T02:26:19+00:00</updated>
<author>
<name>Alan Stern</name>
<email>stern@rowland.harvard.edu</email>
</author>
<published>2016-10-21T20:45:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=905b97f31d7cf0c45d42d0d21fb0b1bd25f14aa1'/>
<id>905b97f31d7cf0c45d42d0d21fb0b1bd25f14aa1</id>
<content type='text'>
commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil &lt;flyos@mailoo.org&gt;
Tested-by: Pierre de Villemereuil &lt;flyos@mailoo.org&gt;
Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
CC: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 6496ebd7edf446fccf8266a1a70ffcb64252593e upstream.

One some systems, the firmware does not allow certain PCI devices to be put
in deep D-states.  This can cause problems for wakeup signalling, if the
device does not support PME# in the deepest allowed suspend state.  For
example, Pierre reports that on his system, ACPI does not permit his xHCI
host controller to go into D3 during runtime suspend -- but D3 is the only
state in which the controller can generate PME# signals.  As a result, the
controller goes into runtime suspend but never wakes up, so it doesn't work
properly.  USB devices plugged into the controller are never detected.

If the device relies on PME# for wakeup signals but is not capable of
generating PME# in the target state, the PCI core should accurately report
that it cannot do wakeup from runtime suspend.  This patch modifies the
pci_dev_run_wake() routine to add this check.

Reported-by: Pierre de Villemereuil &lt;flyos@mailoo.org&gt;
Tested-by: Pierre de Villemereuil &lt;flyos@mailoo.org&gt;
Signed-off-by: Alan Stern &lt;stern@rowland.harvard.edu&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
CC: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Mark Atheros AR9580 to avoid bus reset</title>
<updated>2017-02-23T03:53:55+00:00</updated>
<author>
<name>Maik Broemme</name>
<email>mbroemme@libmpq.org</email>
</author>
<published>2016-08-09T14:41:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f262767a3aeac80a0e6440760716d290eabc44e'/>
<id>2f262767a3aeac80a0e6440760716d290eabc44e</id>
<content type='text'>
commit 8e2e03179923479ca0c0b6fdc7c93ecf89bce7a8 upstream.

Similar to the AR93xx and the AR94xx series, the AR95xx also have the same
quirk for the Bus Reset.  It will lead to instant system reset if the
device is assigned via VFIO to a KVM VM.  I've been able reproduce this
behavior with a MikroTik R11e-2HnD.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Maik Broemme &lt;mbroemme@libmpq.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 8e2e03179923479ca0c0b6fdc7c93ecf89bce7a8 upstream.

Similar to the AR93xx and the AR94xx series, the AR95xx also have the same
quirk for the Bus Reset.  It will lead to instant system reset if the
device is assigned via VFIO to a KVM VM.  I've been able reproduce this
behavior with a MikroTik R11e-2HnD.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Maik Broemme &lt;mbroemme@libmpq.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Mark Atheros AR9485 and QCA9882 to avoid bus reset</title>
<updated>2016-11-20T01:16:40+00:00</updated>
<author>
<name>Chris Blake</name>
<email>chrisrblake93@gmail.com</email>
</author>
<published>2016-05-30T12:26:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dce26aa0a86cdde59012bb05cdce69480c30c954'/>
<id>dce26aa0a86cdde59012bb05cdce69480c30c954</id>
<content type='text'>
commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 upstream.

Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake &lt;chrisrblake93@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 9ac0108c2bac3f1d0255f64fb89fc27e71131b24 upstream.

Similar to the AR93xx series, the AR94xx and the Qualcomm QCA988x also have
the same quirk for the Bus Reset.

Fixes: c3e59ee4e766 ("PCI: Mark Atheros AR93xx to avoid bus reset")
Signed-off-by: Chris Blake &lt;chrisrblake93@gmail.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Disable all BAR sizing for devices with non-compliant BARs</title>
<updated>2016-08-22T21:38:00+00:00</updated>
<author>
<name>Prarit Bhargava</name>
<email>prarit@redhat.com</email>
</author>
<published>2016-05-11T16:27:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=36265cadf588c080a6bb0ce1d7d377430264569e'/>
<id>36265cadf588c080a6bb0ce1d7d377430264569e</id>
<content type='text'>
commit ad67b437f187ea818b2860524d10f878fadfdd99 upstream.

b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant
BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
the PCI spec.  But it didn't do anything for expansion ROM BARs, so we
still try to size them, resulting in warnings like this on Broadwell-EP:

  pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]

Move the non-compliant BAR check from __pci_read_base() up to
pci_read_bases() so it applies to the expansion ROM BAR as well as
to BARs 0-5.

Note that direct callers of __pci_read_base(), like sriov_init(), will now
bypass this check.  We haven't had reports of devices with broken SR-IOV
BARs yet.

[bhelgaas: changelog]
Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs")
Signed-off-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Thomas Gleixner &lt;tglx@linutronix.de&gt;
CC: Ingo Molnar &lt;mingo@redhat.com&gt;
CC: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
CC: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ad67b437f187ea818b2860524d10f878fadfdd99 upstream.

b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant
BARs") disabled BAR sizing for BARs 0-5 of devices that don't comply with
the PCI spec.  But it didn't do anything for expansion ROM BARs, so we
still try to size them, resulting in warnings like this on Broadwell-EP:

  pci 0000:ff:12.0: BAR 6: failed to assign [mem size 0x00000001 pref]

Move the non-compliant BAR check from __pci_read_base() up to
pci_read_bases() so it applies to the expansion ROM BAR as well as
to BARs 0-5.

Note that direct callers of __pci_read_base(), like sriov_init(), will now
bypass this check.  We haven't had reports of devices with broken SR-IOV
BARs yet.

[bhelgaas: changelog]
Fixes: b84106b4e229 ("PCI: Disable IO/MEM decoding for devices with non-compliant BARs")
Signed-off-by: Prarit Bhargava &lt;prarit@redhat.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Thomas Gleixner &lt;tglx@linutronix.de&gt;
CC: Ingo Molnar &lt;mingo@redhat.com&gt;
CC: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
CC: Andi Kleen &lt;ak@linux.intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Supply CPU physical address (not bus address) to iomem_is_exclusive()</title>
<updated>2016-08-22T21:37:51+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2016-04-08T00:15:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6eb6abdd75722a0b35fbb87fa3c716f3c3e4722f'/>
<id>6eb6abdd75722a0b35fbb87fa3c716f3c3e4722f</id>
<content type='text'>
commit ca620723d4ff9ea7ed484eab46264c3af871b9ae upstream.

iomem_is_exclusive() requires a CPU physical address, but on some arches we
supplied a PCI bus address instead.

On most arches, pci_resource_to_user(res) returns "res-&gt;start", which is a
CPU physical address.  But on microblaze, mips, powerpc, and sparc, it
returns the PCI bus address corresponding to "res-&gt;start".

The result is that pci_mmap_resource() may fail when it shouldn't (if the
bus address happens to match an existing resource), or it may succeed when
it should fail (if the resource is exclusive but the bus address doesn't
match it).

Call iomem_is_exclusive() with "res-&gt;start", which is always a CPU physical
address, not the result of pci_resource_to_user().

Fixes: e8de1481fd71 ("resource: allow MMIO exclusivity for device drivers")
Suggested-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ca620723d4ff9ea7ed484eab46264c3af871b9ae upstream.

iomem_is_exclusive() requires a CPU physical address, but on some arches we
supplied a PCI bus address instead.

On most arches, pci_resource_to_user(res) returns "res-&gt;start", which is a
CPU physical address.  But on microblaze, mips, powerpc, and sparc, it
returns the PCI bus address corresponding to "res-&gt;start".

The result is that pci_mmap_resource() may fail when it shouldn't (if the
bus address happens to match an existing resource), or it may succeed when
it should fail (if the resource is exclusive but the bus address doesn't
match it).

Call iomem_is_exclusive() with "res-&gt;start", which is always a CPU physical
address, not the result of pci_resource_to_user().

Fixes: e8de1481fd71 ("resource: allow MMIO exclusivity for device drivers")
Suggested-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: Arjan van de Ven &lt;arjan@linux.intel.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Disable IO/MEM decoding for devices with non-compliant BARs</title>
<updated>2016-04-30T22:05:50+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2016-02-25T20:35:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=fa02bc48bbd771393c75c5663f00225bf233b0bc'/>
<id>fa02bc48bbd771393c75c5663f00225bf233b0bc</id>
<content type='text'>
commit b84106b4e2290c081cdab521fa832596cdfea246 upstream.

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Andi Kleen &lt;ak@linux.intel.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b84106b4e2290c081cdab521fa832596cdfea246 upstream.

The PCI config header (first 64 bytes of each device's config space) is
defined by the PCI spec so generic software can identify the device and
manage its usage of I/O, memory, and IRQ resources.

Some non-spec-compliant devices put registers other than BARs where the
BARs should be.  When the PCI core sizes these "BARs", the reads and writes
it does may have unwanted side effects, and the "BAR" may appear to
describe non-sensical address space.

Add a flag bit to mark non-compliant devices so we don't touch their BARs.
Turn off IO/MEM decoding to prevent the devices from consuming address
space, since we can't read the BARs to find out what that address space
would be.

Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Tested-by: Andi Kleen &lt;ak@linux.intel.com&gt;
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Move link up check into imx6_pcie_wait_for_link()</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-25T22:50:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=92d27c4aaca0d15bb742de785dfd57f0f68aa586'/>
<id>92d27c4aaca0d15bb742de785dfd57f0f68aa586</id>
<content type='text'>
commit 4d107d3b5a686b5834e533a00b73bf7b1cf59df7 upstream.

imx6_pcie_link_up() previously used usleep_range() to wait for the link to
come up.  Since it may be called while holding the config spinlock, the
sleep causes a "BUG: scheduling while atomic" error.

Instead of waiting for the link to come up in imx6_pcie_link_up(), do the
waiting in imx6_pcie_wait_for_link(), where we're not holding a lock and
sleeping is allowed.

[bhelgaas: changelog, references to bugzilla and f95d3ae77191]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031
Fixes: f95d3ae77191 ("PCI: imx6: Wait for retraining")
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16: also update the retry loop in
 imx6_pcie_wait_for_link() as done upstream in commit 6cbb247e85eb
 ("PCI: designware: Wait for link to come up with consistent style")]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4d107d3b5a686b5834e533a00b73bf7b1cf59df7 upstream.

imx6_pcie_link_up() previously used usleep_range() to wait for the link to
come up.  Since it may be called while holding the config spinlock, the
sleep causes a "BUG: scheduling while atomic" error.

Instead of waiting for the link to come up in imx6_pcie_link_up(), do the
waiting in imx6_pcie_wait_for_link(), where we're not holding a lock and
sleeping is allowed.

[bhelgaas: changelog, references to bugzilla and f95d3ae77191]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=100031
Fixes: f95d3ae77191 ("PCI: imx6: Wait for retraining")
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16: also update the retry loop in
 imx6_pcie_wait_for_link() as done upstream in commit 6cbb247e85eb
 ("PCI: designware: Wait for link to come up with consistent style")]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Remove broken Gen2 workaround</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-25T22:49:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f5aa19a43aaba8be755936fa2dbe93404fcec169'/>
<id>f5aa19a43aaba8be755936fa2dbe93404fcec169</id>
<content type='text'>
commit a77c5422d7586003643377afdb9915e76d07d21c upstream.

Remove the remnants of the workaround for erratum ERR005184 which was never
completely implemented.  The checks alone don't carry any value as we don't
act properly on the result.

A workaround should be added to the lane speed change in establish_link
later.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a77c5422d7586003643377afdb9915e76d07d21c upstream.

Remove the remnants of the workaround for erratum ERR005184 which was never
completely implemented.  The checks alone don't carry any value as we don't
act properly on the result.

A workaround should be added to the lane speed change in establish_link
later.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Move PHY reset into imx6_pcie_establish_link()</title>
<updated>2016-04-30T22:05:44+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2016-01-25T22:49:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79a854239e3ad02b0a369f16767173ff546633a0'/>
<id>79a854239e3ad02b0a369f16767173ff546633a0</id>
<content type='text'>
commit 54a47a83421a3b7ee0e0fab7f65d04179bdf59b6 upstream.

This adds the PHY reset into a common error path of
imx6_pcie_establish_link(), deduplicating some of the debug prints.  Also
reduce the severity of the "no-link" message in the one place where it is
expected to be hit when no peripheral is attached.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16:
 - Error paths were different in imx6_pcie_start_link()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 54a47a83421a3b7ee0e0fab7f65d04179bdf59b6 upstream.

This adds the PHY reset into a common error path of
imx6_pcie_establish_link(), deduplicating some of the debug prints.  Also
reduce the severity of the "no-link" message in the one place where it is
expected to be hit when no peripheral is attached.

Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
[bwh: Backported to 3.16:
 - Error paths were different in imx6_pcie_start_link()
 - Adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</pre>
</div>
</content>
</entry>
</feed>
