<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/pci, branch v4.10.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>PCI: altera: Fix TLP_CFG_DW0 for TLP write</title>
<updated>2017-03-12T05:44:14+00:00</updated>
<author>
<name>Ley Foon Tan</name>
<email>ley.foon.tan@intel.com</email>
</author>
<published>2017-02-28T10:37:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2c849a5c6a83721b4c64dfc1e6851c2c8042c54b'/>
<id>2c849a5c6a83721b4c64dfc1e6851c2c8042c54b</id>
<content type='text'>
commit 2a7275a3d867b228216886aae35e1f64291180b1 upstream.

eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage") used
TLP_FMTTYPE_CFGRD* (instead of TLP_FMTTYPE_CFGWR*) for TLP writes, which
causes writing to configuration space to fail.  Fix it by using correct
FMTTYPE for write operation.

Fixes: eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage")
Signed-off-by: Ley Foon Tan &lt;ley.foon.tan@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2a7275a3d867b228216886aae35e1f64291180b1 upstream.

eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage") used
TLP_FMTTYPE_CFGRD* (instead of TLP_FMTTYPE_CFGWR*) for TLP writes, which
causes writing to configuration space to fail.  Fix it by using correct
FMTTYPE for write operation.

Fixes: eb5767122feb ("PCI: altera: Simplify TLB_CFG_DW0 usage")
Signed-off-by: Ley Foon Tan &lt;ley.foon.tan@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>pci/hotplug/pnv-php: Disable MSI and PCI device properly</title>
<updated>2017-03-12T05:44:14+00:00</updated>
<author>
<name>Gavin Shan</name>
<email>gwshan@linux.vnet.ibm.com</email>
</author>
<published>2017-02-15T23:22:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bc4c9766324a7e9fda48de58691796430c8511bf'/>
<id>bc4c9766324a7e9fda48de58691796430c8511bf</id>
<content type='text'>
commit 49f4b08e61547a5ccd2db551d994c4503efe5666 upstream.

pnv_php_disable_irq() can be called in two paths: Bailing path in
pnv_php_enable_irq() or releasing slot. The MSI (or MSIx) interrupts
is disabled unconditionally in pnv_php_disable_irq(). It's wrong
because that might be enabled by drivers other than pnv-php.

This disables MSI (or MSIx) interrupts and the PCI device only if
it was enabled by pnv-php. In the error path of pnv_php_enable_irq(),
we rely on the newly added parameter @disable_device. In the path
of releasing slot, @pnv_php-&gt;irq is checked.

Fixes: 360aebd85a4c ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
Signed-off-by: Gavin Shan &lt;gwshan@linux.vnet.ibm.com&gt;
Reviewed-by: Andrew Donnellan &lt;andrew.donnellan@au1.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 49f4b08e61547a5ccd2db551d994c4503efe5666 upstream.

pnv_php_disable_irq() can be called in two paths: Bailing path in
pnv_php_enable_irq() or releasing slot. The MSI (or MSIx) interrupts
is disabled unconditionally in pnv_php_disable_irq(). It's wrong
because that might be enabled by drivers other than pnv-php.

This disables MSI (or MSIx) interrupts and the PCI device only if
it was enabled by pnv-php. In the error path of pnv_php_enable_irq(),
we rely on the newly added parameter @disable_device. In the path
of releasing slot, @pnv_php-&gt;irq is checked.

Fixes: 360aebd85a4c ("drivers/pci/hotplug: Support surprise hotplug in powernv driver")
Signed-off-by: Gavin Shan &lt;gwshan@linux.vnet.ibm.com&gt;
Reviewed-by: Andrew Donnellan &lt;andrew.donnellan@au1.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: hv: Fix wslot_to_devfn() to fix warnings on device removal</title>
<updated>2017-03-12T05:44:14+00:00</updated>
<author>
<name>Dexuan Cui</name>
<email>decui@microsoft.com</email>
</author>
<published>2017-02-10T21:18:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=91f5bce789d9083f1e24bc09b00c8c781c015835'/>
<id>91f5bce789d9083f1e24bc09b00c8c781c015835</id>
<content type='text'>
commit 60e2e2fbafdd1285ae1b4ad39ded41603e0c74d0 upstream.

The devfn of 00:02.0 is 0x10.  devfn_to_wslot(0x10) == 0x2, and
wslot_to_devfn(0x2) should be 0x10, while it's 0x2 in the current code.

Due to this, hv_eject_device_work() -&gt; pci_get_domain_bus_and_slot()
returns NULL and pci_stop_and_remove_bus_device() is not called.

Later when the real device driver's .remove() is invoked by
hv_pci_remove() -&gt; pci_stop_root_bus(), some warnings can be noticed
because the VM has lost the access to the underlying device at that
time.

Signed-off-by: Jake Oshins &lt;jakeo@microsoft.com&gt;
Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
CC: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
CC: Stephen Hemminger &lt;sthemmin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 60e2e2fbafdd1285ae1b4ad39ded41603e0c74d0 upstream.

The devfn of 00:02.0 is 0x10.  devfn_to_wslot(0x10) == 0x2, and
wslot_to_devfn(0x2) should be 0x10, while it's 0x2 in the current code.

Due to this, hv_eject_device_work() -&gt; pci_get_domain_bus_and_slot()
returns NULL and pci_stop_and_remove_bus_device() is not called.

Later when the real device driver's .remove() is invoked by
hv_pci_remove() -&gt; pci_stop_root_bus(), some warnings can be noticed
because the VM has lost the access to the underlying device at that
time.

Signed-off-by: Jake Oshins &lt;jakeo@microsoft.com&gt;
Signed-off-by: Dexuan Cui &lt;decui@microsoft.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Haiyang Zhang &lt;haiyangz@microsoft.com&gt;
CC: K. Y. Srinivasan &lt;kys@microsoft.com&gt;
CC: Stephen Hemminger &lt;sthemmin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/PME: Restore pcie_pme_driver.remove</title>
<updated>2017-02-15T15:39:32+00:00</updated>
<author>
<name>Yinghai Lu</name>
<email>yinghai@kernel.org</email>
</author>
<published>2017-02-15T05:17:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=afe3e4d11bdf50a4c3965eb6465ba6bebbcf5dcf'/>
<id>afe3e4d11bdf50a4c3965eb6465ba6bebbcf5dcf</id>
<content type='text'>
In addition to making PME non-modular, d7def2040077 ("PCI/PME: Make
explicitly non-modular") removed the pcie_pme_driver .remove() method,
pcie_pme_remove().

pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe().
The fact that we don't free the IRQ after d7def2040077 causes the following
crash when removing a PCIe port device via /sys:

  ------------[ cut here ]------------
  kernel BUG at drivers/pci/msi.c:370!
  invalid opcode: 0000 [#1] SMP
  Modules linked in:
  CPU: 1 PID: 14509 Comm: sh Tainted: G    W  4.8.0-rc1-yh-00012-gd29438d
  RIP: 0010:[&lt;ffffffff9758bbf5&gt;]  free_msi_irqs+0x65/0x190
  ...
  Call Trace:
   [&lt;ffffffff9758cda4&gt;] pci_disable_msi+0x34/0x40
   [&lt;ffffffff97583817&gt;] cleanup_service_irqs+0x27/0x30
   [&lt;ffffffff97583e9a&gt;] pcie_port_device_remove+0x2a/0x40
   [&lt;ffffffff97584250&gt;] pcie_portdrv_remove+0x40/0x50
   [&lt;ffffffff97576d7b&gt;] pci_device_remove+0x4b/0xc0
   [&lt;ffffffff9785ebe6&gt;] __device_release_driver+0xb6/0x150
   [&lt;ffffffff9785eca5&gt;] device_release_driver+0x25/0x40
   [&lt;ffffffff975702e4&gt;] pci_stop_bus_device+0x74/0xa0
   [&lt;ffffffff975704ea&gt;] pci_stop_and_remove_bus_device_locked+0x1a/0x30
   [&lt;ffffffff97578810&gt;] remove_store+0x50/0x70
   [&lt;ffffffff9785a378&gt;] dev_attr_store+0x18/0x30
   [&lt;ffffffff97260b64&gt;] sysfs_kf_write+0x44/0x60
   [&lt;ffffffff9725feae&gt;] kernfs_fop_write+0x10e/0x190
   [&lt;ffffffff971e13f8&gt;] __vfs_write+0x28/0x110
   [&lt;ffffffff970b0fa4&gt;] ? percpu_down_read+0x44/0x80
   [&lt;ffffffff971e53a7&gt;] ? __sb_start_write+0xa7/0xe0
   [&lt;ffffffff971e53a7&gt;] ? __sb_start_write+0xa7/0xe0
   [&lt;ffffffff971e1f04&gt;] vfs_write+0xc4/0x180
   [&lt;ffffffff971e3089&gt;] SyS_write+0x49/0xa0
   [&lt;ffffffff97001a46&gt;] do_syscall_64+0xa6/0x1b0
   [&lt;ffffffff9819201e&gt;] entry_SYSCALL64_slow_path+0x25/0x25
  ...
   RIP  [&lt;ffffffff9758bbf5&gt;] free_msi_irqs+0x65/0x190
   RSP &lt;ffff89ad3085bc48&gt;
  ---[ end trace f4505e1dac5b95d3 ]---
  Segmentation fault

Restore pcie_pme_remove().

[bhelgaas: changelog]
Fixes: d7def2040077 ("PCI/PME: Make explicitly non-modular")
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
CC: stable@vger.kernel.org	# v4.9+</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In addition to making PME non-modular, d7def2040077 ("PCI/PME: Make
explicitly non-modular") removed the pcie_pme_driver .remove() method,
pcie_pme_remove().

pcie_pme_remove() freed the PME IRQ that was requested in pci_pme_probe().
The fact that we don't free the IRQ after d7def2040077 causes the following
crash when removing a PCIe port device via /sys:

  ------------[ cut here ]------------
  kernel BUG at drivers/pci/msi.c:370!
  invalid opcode: 0000 [#1] SMP
  Modules linked in:
  CPU: 1 PID: 14509 Comm: sh Tainted: G    W  4.8.0-rc1-yh-00012-gd29438d
  RIP: 0010:[&lt;ffffffff9758bbf5&gt;]  free_msi_irqs+0x65/0x190
  ...
  Call Trace:
   [&lt;ffffffff9758cda4&gt;] pci_disable_msi+0x34/0x40
   [&lt;ffffffff97583817&gt;] cleanup_service_irqs+0x27/0x30
   [&lt;ffffffff97583e9a&gt;] pcie_port_device_remove+0x2a/0x40
   [&lt;ffffffff97584250&gt;] pcie_portdrv_remove+0x40/0x50
   [&lt;ffffffff97576d7b&gt;] pci_device_remove+0x4b/0xc0
   [&lt;ffffffff9785ebe6&gt;] __device_release_driver+0xb6/0x150
   [&lt;ffffffff9785eca5&gt;] device_release_driver+0x25/0x40
   [&lt;ffffffff975702e4&gt;] pci_stop_bus_device+0x74/0xa0
   [&lt;ffffffff975704ea&gt;] pci_stop_and_remove_bus_device_locked+0x1a/0x30
   [&lt;ffffffff97578810&gt;] remove_store+0x50/0x70
   [&lt;ffffffff9785a378&gt;] dev_attr_store+0x18/0x30
   [&lt;ffffffff97260b64&gt;] sysfs_kf_write+0x44/0x60
   [&lt;ffffffff9725feae&gt;] kernfs_fop_write+0x10e/0x190
   [&lt;ffffffff971e13f8&gt;] __vfs_write+0x28/0x110
   [&lt;ffffffff970b0fa4&gt;] ? percpu_down_read+0x44/0x80
   [&lt;ffffffff971e53a7&gt;] ? __sb_start_write+0xa7/0xe0
   [&lt;ffffffff971e53a7&gt;] ? __sb_start_write+0xa7/0xe0
   [&lt;ffffffff971e1f04&gt;] vfs_write+0xc4/0x180
   [&lt;ffffffff971e3089&gt;] SyS_write+0x49/0xa0
   [&lt;ffffffff97001a46&gt;] do_syscall_64+0xa6/0x1b0
   [&lt;ffffffff9819201e&gt;] entry_SYSCALL64_slow_path+0x25/0x25
  ...
   RIP  [&lt;ffffffff9758bbf5&gt;] free_msi_irqs+0x65/0x190
   RSP &lt;ffff89ad3085bc48&gt;
  ---[ end trace f4505e1dac5b95d3 ]---
  Segmentation fault

Restore pcie_pme_remove().

[bhelgaas: changelog]
Fixes: d7def2040077 ("PCI/PME: Make explicitly non-modular")
Signed-off-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
CC: stable@vger.kernel.org	# v4.9+</pre>
</div>
</content>
</entry>
<entry>
<title>Revert "PCI: pciehp: Add runtime PM support for PCIe hotplug ports"</title>
<updated>2017-02-03T14:53:51+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2017-02-03T14:53:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d98e0929071e7ef63d35c1838b0ad0805ae366dd'/>
<id>d98e0929071e7ef63d35c1838b0ad0805ae366dd</id>
<content type='text'>
This reverts commit 68db9bc814362e7f24371c27d12a4f34477d9356.

Yinghai reported that the following manual hotplug sequence:

  # echo 0 &gt; /sys/bus/pci/slots/8/power
  # echo 1 &gt; /sys/bus/pci/slots/8/power

worked in v4.9, but fails in v4.10-rc1, and that reverting 68db9bc81436
("PCI: pciehp: Add runtime PM support for PCIe hotplug ports") makes it
work again.

Fixes: 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe hotplug ports")
Link: https://lkml.kernel.org/r/CAE9FiQVCMCa7iVyuwp9z6VrY0cE7V_xghuXip28Ft52=8QmTWw@mail.gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193951
Reported-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This reverts commit 68db9bc814362e7f24371c27d12a4f34477d9356.

Yinghai reported that the following manual hotplug sequence:

  # echo 0 &gt; /sys/bus/pci/slots/8/power
  # echo 1 &gt; /sys/bus/pci/slots/8/power

worked in v4.9, but fails in v4.10-rc1, and that reverting 68db9bc81436
("PCI: pciehp: Add runtime PM support for PCIe hotplug ports") makes it
work again.

Fixes: 68db9bc81436 ("PCI: pciehp: Add runtime PM support for PCIe hotplug ports")
Link: https://lkml.kernel.org/r/CAE9FiQVCMCa7iVyuwp9z6VrY0cE7V_xghuXip28Ft52=8QmTWw@mail.gmail.com
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193951
Reported-by: Yinghai Lu &lt;yinghai@kernel.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/MSI: Don't apply affinity if there aren't enough vectors left</title>
<updated>2017-02-02T16:35:46+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2017-01-30T12:15:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dfef358bd1beb4e7b5c94eca944be9cd23dfc752'/>
<id>dfef358bd1beb4e7b5c94eca944be9cd23dfc752</id>
<content type='text'>
Bart reported a problem wіth an out of bounds access in the low-level IRQ
affinity code, which we root caused to the qla2xxx driver assigning all its
MSI-X vectors to the pre and post vectors, and not having any left for the
actually spread IRQs.

Fix this issue by not asking for affinity assignment when there are no
vectors to assign left.

Fixes: 402723ad5c62 ("PCI/MSI: Provide pci_alloc_irq_vectors_affinity()")
Link: https://lkml.kernel.org/r/1485359225.3093.3.camel@sandisk.com
Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Tested-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Bart reported a problem wіth an out of bounds access in the low-level IRQ
affinity code, which we root caused to the qla2xxx driver assigning all its
MSI-X vectors to the pre and post vectors, and not having any left for the
actually spread IRQs.

Fix this issue by not asking for affinity assignment when there are no
vectors to assign left.

Fixes: 402723ad5c62 ("PCI/MSI: Provide pci_alloc_irq_vectors_affinity()")
Link: https://lkml.kernel.org/r/1485359225.3093.3.camel@sandisk.com
Reported-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Tested-by: Bart Van Assche &lt;bart.vanassche@sandisk.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/ASPM: Handle PCI-to-PCIe bridges as roots of PCIe hierarchies</title>
<updated>2017-01-27T21:00:45+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2017-01-27T21:00:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=030305d69fc6963c16003f50d7e8d74b02d0a143'/>
<id>030305d69fc6963c16003f50d7e8d74b02d0a143</id>
<content type='text'>
In a struct pcie_link_state, link-&gt;root points to the pcie_link_state of
the root of the PCIe hierarchy.  For the topmost link, this points to
itself (link-&gt;root = link).  For others, we copy the pointer from the
parent (link-&gt;root = link-&gt;parent-&gt;root).

Previously we recognized that Root Ports originated PCIe hierarchies, but
we treated PCI/PCI-X to PCIe Bridges as being in the middle of the
hierarchy, and when we tried to copy the pointer from link-&gt;parent-&gt;root,
there was no parent, and we dereferenced a NULL pointer:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
  IP: [&lt;ffffffff9e424350&gt;] pcie_aspm_init_link_state+0x170/0x820

Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just
like Root Ports do, so link-&gt;root for these devices should also point to
itself.

Fixes: 51ebfc92b72b ("PCI: Enumerate switches below PCI-to-PCIe bridges")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181
Tested-by: lists@ssl-mail.com
Tested-by: Jayachandran C. &lt;jnair@caviumnetworks.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org	# v4.2+</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In a struct pcie_link_state, link-&gt;root points to the pcie_link_state of
the root of the PCIe hierarchy.  For the topmost link, this points to
itself (link-&gt;root = link).  For others, we copy the pointer from the
parent (link-&gt;root = link-&gt;parent-&gt;root).

Previously we recognized that Root Ports originated PCIe hierarchies, but
we treated PCI/PCI-X to PCIe Bridges as being in the middle of the
hierarchy, and when we tried to copy the pointer from link-&gt;parent-&gt;root,
there was no parent, and we dereferenced a NULL pointer:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000090
  IP: [&lt;ffffffff9e424350&gt;] pcie_aspm_init_link_state+0x170/0x820

Recognize that PCI/PCI-X to PCIe Bridges originate PCIe hierarchies just
like Root Ports do, so link-&gt;root for these devices should also point to
itself.

Fixes: 51ebfc92b72b ("PCI: Enumerate switches below PCI-to-PCIe bridges")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=193411
Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1022181
Tested-by: lists@ssl-mail.com
Tested-by: Jayachandran C. &lt;jnair@caviumnetworks.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org	# v4.2+</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/MSI: pci-xgene-msi: Fix CPU hotplug registration handling</title>
<updated>2017-01-17T14:41:51+00:00</updated>
<author>
<name>Marc Zyngier</name>
<email>marc.zyngier@arm.com</email>
</author>
<published>2017-01-17T14:21:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4d191b1b63c209e37bf27938ef365244d3c41084'/>
<id>4d191b1b63c209e37bf27938ef365244d3c41084</id>
<content type='text'>
The conversion to the new hotplug state machine introduced a regression
where a successful hotplug registration would be treated as an error,
effectively disabling the MSI driver forever.

Fix it by doing the proper check on the return value.

Fixes: 9c248f8896e6 ("PCI/xgene-msi: Convert to hotplug state machine")
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Tested-by: Duc Dang &lt;dhdang@apm.com&gt;
CC: Thomas Gleixner &lt;tglx@linutronix.de&gt;
CC: stable@vger.kernel.org</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The conversion to the new hotplug state machine introduced a regression
where a successful hotplug registration would be treated as an error,
effectively disabling the MSI driver forever.

Fix it by doing the proper check on the return value.

Fixes: 9c248f8896e6 ("PCI/xgene-msi: Convert to hotplug state machine")
Signed-off-by: Marc Zyngier &lt;marc.zyngier@arm.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Tested-by: Duc Dang &lt;dhdang@apm.com&gt;
CC: Thomas Gleixner &lt;tglx@linutronix.de&gt;
CC: stable@vger.kernel.org</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Enumerate switches below PCI-to-PCIe bridges</title>
<updated>2017-01-11T15:11:53+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2017-01-11T15:11:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=51ebfc92b72b4f7dac1ab45683bf56741e454b8c'/>
<id>51ebfc92b72b4f7dac1ab45683bf56741e454b8c</id>
<content type='text'>
A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
interface and a PCI Express secondary interface.  The PCIe interface is a
Downstream Port that originates a Link.  See the "PCI Express to PCI/PCI-X
Bridge Specification", rev 1.0, sections 1.2 and A.6.

The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
the bridge:

  00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
  01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
  02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
  03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]

01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
lspci).  As we traverse a PCIe hierarchy, device connections alternate
between PCIe Links and internal Switch logic.  Previously we did not
recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
Upstream Port *did* have a secondary link.  In fact, it's the other way
around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
on its secondary side.

When we thought 02:00.0 had a secondary link, the pci_scan_slot() -&gt;
only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
was the only possible downstream device.  But 03:00.0 doesn't exist, so we
didn't look for any other devices on bus 03.

Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
to have to do that.

Recognize that PCI-to-PCIe bridges originate links on their secondary
interfaces.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
Fixes: d0751b98dfa3 ("PCI: Add dev-&gt;has_secondary_link to track downstream PCIe links")
Tested-by: Blake Moore &lt;blake.moore@men.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org	# v4.2+</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A PCI-to-PCIe bridge (a "reverse bridge") has a PCI or PCI-X primary
interface and a PCI Express secondary interface.  The PCIe interface is a
Downstream Port that originates a Link.  See the "PCI Express to PCI/PCI-X
Bridge Specification", rev 1.0, sections 1.2 and A.6.

The bug report below involves a PCI-to-PCIe bridge and a PCIe switch below
the bridge:

  00:1e.0 Intel 82801 PCI Bridge to [bus 01-0a]
  01:00.0 Pericom PI7C9X111SL PCIe-to-PCI Reversible Bridge to [bus 02-0a]
  02:00.0 Pericom Device 8608 [PCIe Upstream Port] to [bus 03-0a]
  03:01.0 Pericom Device 8608 [PCIe Downstream Port] to [bus 0a]

01:00.0 is configured as a PCI-to-PCIe bridge (despite the name printed by
lspci).  As we traverse a PCIe hierarchy, device connections alternate
between PCIe Links and internal Switch logic.  Previously we did not
recognize that 01:00.0 had a secondary link, so we thought the 02:00.0
Upstream Port *did* have a secondary link.  In fact, it's the other way
around: 01:00.0 has a secondary link, and 02:00.0 has internal Switch logic
on its secondary side.

When we thought 02:00.0 had a secondary link, the pci_scan_slot() -&gt;
only_one_child() path assumed 02:00.0 could have only one child, so 03:00.0
was the only possible downstream device.  But 03:00.0 doesn't exist, so we
didn't look for any other devices on bus 03.

Booting with "pci=pcie_scan_all" is a workaround, but we don't want users
to have to do that.

Recognize that PCI-to-PCIe bridges originate links on their secondary
interfaces.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=189361
Fixes: d0751b98dfa3 ("PCI: Add dev-&gt;has_secondary_link to track downstream PCIe links")
Tested-by: Blake Moore &lt;blake.moore@men.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
CC: stable@vger.kernel.org	# v4.2+</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: designware: Check for iATU unroll only on platforms that use ATU</title>
<updated>2017-01-10T14:43:24+00:00</updated>
<author>
<name>Murali Karicheri</name>
<email>m-karicheri2@ti.com</email>
</author>
<published>2017-01-04T19:32:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a782b5f986c3fa1cfa7f2b57941200c6a5809242'/>
<id>a782b5f986c3fa1cfa7f2b57941200c6a5809242</id>
<content type='text'>
Previously we checked for iATU unroll support by reading PCIE_ATU_VIEWPORT
even on platforms, e.g., Keystone, that do not have ATU ports.  This can
cause bad behavior such as asynchronous external aborts:

  OF: PCI:   MEM 0x60000000..0x6fffffff -&gt; 0x60000000
  Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
  pgd = c0003000
  [00000000] *pgd=80000800004003, *pmd=00000000
  Internal error: : 1211 [#1] PREEMPT SMP ARM
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-00009-g6ff59d2-dirty #7
  Hardware name: Keystone
  task: eb878000 task.stack: eb866000
  PC is at dw_pcie_setup_rc+0x24/0x380
  LR is at ks_pcie_host_init+0x10/0x170

Move the dw_pcie_iatu_unroll_enabled() check so we only call it on
platforms that do not use the ATU.  These platforms supply their own
-&gt;rd_other_conf() and -&gt;wr_other_conf() methods.

[bhelgaas: changelog]
Fixes: a0601a470537 ("PCI: designware: Add iATU Unroll feature")
Fixes: 416379f9ebde ("PCI: designware: Check for iATU unroll support after initializing host")
Tested-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Murali Karicheri &lt;m-karicheri2@ti.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-By: Joao Pinto &lt;jpinto@synopsys.com&gt;
CC: stable@vger.kernel.org	# v4.9+</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously we checked for iATU unroll support by reading PCIE_ATU_VIEWPORT
even on platforms, e.g., Keystone, that do not have ATU ports.  This can
cause bad behavior such as asynchronous external aborts:

  OF: PCI:   MEM 0x60000000..0x6fffffff -&gt; 0x60000000
  Unhandled fault: asynchronous external abort (0x1211) at 0x00000000
  pgd = c0003000
  [00000000] *pgd=80000800004003, *pmd=00000000
  Internal error: : 1211 [#1] PREEMPT SMP ARM
  Modules linked in:
  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-00009-g6ff59d2-dirty #7
  Hardware name: Keystone
  task: eb878000 task.stack: eb866000
  PC is at dw_pcie_setup_rc+0x24/0x380
  LR is at ks_pcie_host_init+0x10/0x170

Move the dw_pcie_iatu_unroll_enabled() check so we only call it on
platforms that do not use the ATU.  These platforms supply their own
-&gt;rd_other_conf() and -&gt;wr_other_conf() methods.

[bhelgaas: changelog]
Fixes: a0601a470537 ("PCI: designware: Add iATU Unroll feature")
Fixes: 416379f9ebde ("PCI: designware: Check for iATU unroll support after initializing host")
Tested-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;
Signed-off-by: Murali Karicheri &lt;m-karicheri2@ti.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-By: Joao Pinto &lt;jpinto@synopsys.com&gt;
CC: stable@vger.kernel.org	# v4.9+</pre>
</div>
</content>
</entry>
</feed>
