<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/pci, branch v4.12.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>PCI/MSI: Ignore affinity if pre/post vector count is more than min_vecs</title>
<updated>2017-07-27T22:10:09+00:00</updated>
<author>
<name>Michael Hernandez</name>
<email>michael.hernandez@cavium.com</email>
</author>
<published>2017-05-18T17:47:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07c79fd97e00a90e26554798c61f45e2db30fc5d'/>
<id>07c79fd97e00a90e26554798c61f45e2db30fc5d</id>
<content type='text'>
commit 6f9a22bc5775d231ab8fbe2c2f3c88e45e3e7c28 upstream.

min_vecs is the minimum amount of vectors needed to operate in MSI-X mode
which may just include the vectors that don't need affinity.

Disabling affinity settings causes the qla2xxx driver scsi_add_host() to fail
when blk_mq is enabled as the blk_mq_pci_map_queues() expects affinity masks
on each vector.

Fixes: dfef358bd1be ("PCI/MSI: Don't apply affinity if there aren't enough vectors left")
Signed-off-by: Michael Hernandez &lt;michael.hernandez@cavium.com&gt;
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@cavium.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&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 6f9a22bc5775d231ab8fbe2c2f3c88e45e3e7c28 upstream.

min_vecs is the minimum amount of vectors needed to operate in MSI-X mode
which may just include the vectors that don't need affinity.

Disabling affinity settings causes the qla2xxx driver scsi_add_host() to fail
when blk_mq is enabled as the blk_mq_pci_map_queues() expects affinity masks
on each vector.

Fixes: dfef358bd1be ("PCI/MSI: Don't apply affinity if there aren't enough vectors left")
Signed-off-by: Michael Hernandez &lt;michael.hernandez@cavium.com&gt;
Signed-off-by: Himanshu Madhani &lt;himanshu.madhani@cavium.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/PM: Restore the status of PCI devices across hibernation</title>
<updated>2017-07-27T22:10:09+00:00</updated>
<author>
<name>Chen Yu</name>
<email>yu.c.chen@intel.com</email>
</author>
<published>2017-05-25T08:49:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c1ead164ebc2795c4a6b9778e4c697be5f2297ec'/>
<id>c1ead164ebc2795c4a6b9778e4c697be5f2297ec</id>
<content type='text'>
commit e60514bd4485c0c7c5a7cf779b200ce0b95c70d6 upstream.

Currently we saw a lot of "No irq handler" errors during hibernation, which
caused the system hang finally:

  ata4.00: qc timeout (cmd 0xec)
  ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
  ata4.00: revalidation failed (errno=-5)
  ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
  do_IRQ: 31.151 No irq handler for vector

According to above logs, there is an interrupt triggered and it is
dispatched to CPU31 with a vector number 151, but there is no handler for
it, thus this IRQ will not get acked and will cause an IRQ flood which
kills the system.  To be more specific, the 31.151 is an interrupt from the
AHCI host controller.

After some investigation, the reason why this issue is triggered is because
the thaw_noirq() function does not restore the MSI/MSI-X settings across
hibernation.

The scenario is illustrated below:

  1. Before hibernation, IRQ 34 is the handler for the AHCI device, which
     is bound to CPU31.

  2. Hibernation starts, the AHCI device is put into low power state.

  3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to
     the last alive one - CPU0.

  4. After the snapshot has been created, all the nonboot CPUs are brought
     up again; IRQ 34 remains bound to CPU0.

  5. AHCI devices are put into D0.

  6. The snapshot is written to the disk.

The issue is triggered in step 6.  The AHCI interrupt should be delivered
to CPU0, however it is delivered to the original CPU31 instead, which
causes the "No irq handler" issue.

Ying Huang has provided a clue that, in step 3 it is possible that writing
to the register might not take effect as the PCI devices have been
suspended.

In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but
in fact it is not.  In __pci_write_msi_msg(), if the device is already in
low power state, the low level MSI message entry will not be updated but
cached.  During the device restore process after a normal suspend/resume,
pci_restore_msi_state() writes the cached MSI back to the hardware.

But this is not the case for hibernation.  pci_restore_msi_state() is not
currently called in pci_pm_thaw_noirq(), although pci_save_state() has
saved the necessary PCI cached information in pci_pm_freeze_noirq().

Restore the PCI status for the device during hibernation.  Otherwise the
status might be lost across hibernation (for example, settings for MSI,
MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation.

Suggested-by: Ying Huang &lt;ying.huang@intel.com&gt;
Suggested-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Chen Yu &lt;yu.c.chen@intel.com&gt;
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Rui Zhang &lt;rui.zhang@intel.com&gt;
Cc: Ying Huang &lt;ying.huang@intel.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 e60514bd4485c0c7c5a7cf779b200ce0b95c70d6 upstream.

Currently we saw a lot of "No irq handler" errors during hibernation, which
caused the system hang finally:

  ata4.00: qc timeout (cmd 0xec)
  ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
  ata4.00: revalidation failed (errno=-5)
  ata4: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
  do_IRQ: 31.151 No irq handler for vector

According to above logs, there is an interrupt triggered and it is
dispatched to CPU31 with a vector number 151, but there is no handler for
it, thus this IRQ will not get acked and will cause an IRQ flood which
kills the system.  To be more specific, the 31.151 is an interrupt from the
AHCI host controller.

After some investigation, the reason why this issue is triggered is because
the thaw_noirq() function does not restore the MSI/MSI-X settings across
hibernation.

The scenario is illustrated below:

  1. Before hibernation, IRQ 34 is the handler for the AHCI device, which
     is bound to CPU31.

  2. Hibernation starts, the AHCI device is put into low power state.

  3. All the nonboot CPUs are put offline, so IRQ 34 has to be migrated to
     the last alive one - CPU0.

  4. After the snapshot has been created, all the nonboot CPUs are brought
     up again; IRQ 34 remains bound to CPU0.

  5. AHCI devices are put into D0.

  6. The snapshot is written to the disk.

The issue is triggered in step 6.  The AHCI interrupt should be delivered
to CPU0, however it is delivered to the original CPU31 instead, which
causes the "No irq handler" issue.

Ying Huang has provided a clue that, in step 3 it is possible that writing
to the register might not take effect as the PCI devices have been
suspended.

In step 3, the IRQ 34 affinity should be modified from CPU31 to CPU0, but
in fact it is not.  In __pci_write_msi_msg(), if the device is already in
low power state, the low level MSI message entry will not be updated but
cached.  During the device restore process after a normal suspend/resume,
pci_restore_msi_state() writes the cached MSI back to the hardware.

But this is not the case for hibernation.  pci_restore_msi_state() is not
currently called in pci_pm_thaw_noirq(), although pci_save_state() has
saved the necessary PCI cached information in pci_pm_freeze_noirq().

Restore the PCI status for the device during hibernation.  Otherwise the
status might be lost across hibernation (for example, settings for MSI,
MSI-X, ATS, ACS, IOV, etc.), which might cause problems during hibernation.

Suggested-by: Ying Huang &lt;ying.huang@intel.com&gt;
Suggested-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Chen Yu &lt;yu.c.chen@intel.com&gt;
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Cc: Len Brown &lt;len.brown@intel.com&gt;
Cc: Dan Williams &lt;dan.j.williams@intel.com&gt;
Cc: Rui Zhang &lt;rui.zhang@intel.com&gt;
Cc: Ying Huang &lt;ying.huang@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: rockchip: Use normal register bank for config accessors</title>
<updated>2017-07-27T22:10:09+00:00</updated>
<author>
<name>Shawn Lin</name>
<email>shawn.lin@rock-chips.com</email>
</author>
<published>2017-07-03T09:21:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=18fc66a885ebda727239742139524146fbaefb34'/>
<id>18fc66a885ebda727239742139524146fbaefb34</id>
<content type='text'>
commit dc8cca5ef25ac4cb0dfc37467521a759767ff361 upstream.

Rockchip's RC has two banks of registers for the root port: a normal bank
that is strictly compatible with the PCIe spec, and a privileged bank that
can be used to change RO bits of root port registers.

When probing the RC driver, we use the privileged bank to do some basic
setup work as some RO bits are hw-inited to wrong value.  But we didn't
change to the normal bank after probing the driver.

This leads to a serious problem when the PME code tries to clear the PME
status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA.  Per
PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C.  So the PME code
is doing the right thing to clear the PME status but we find the RC doesn't
clear it but actually setting it to one.  So finally the system trap in
pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever.  This issue
can be reproduced by booting kernel with pci=nomsi.

Use the normal register bank for the PCI config accessors.  The privileged
bank is used only internally by this driver.

Fixes: e77f847d ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Jeffy Chen &lt;jeffy.chen@rock-chips.com&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&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 dc8cca5ef25ac4cb0dfc37467521a759767ff361 upstream.

Rockchip's RC has two banks of registers for the root port: a normal bank
that is strictly compatible with the PCIe spec, and a privileged bank that
can be used to change RO bits of root port registers.

When probing the RC driver, we use the privileged bank to do some basic
setup work as some RO bits are hw-inited to wrong value.  But we didn't
change to the normal bank after probing the driver.

This leads to a serious problem when the PME code tries to clear the PME
status by writing PCI_EXP_RTSTA_PME to the register of PCI_EXP_RTSTA.  Per
PCIe 3.0 spec, section 7.8.14, the PME status bit is RW1C.  So the PME code
is doing the right thing to clear the PME status but we find the RC doesn't
clear it but actually setting it to one.  So finally the system trap in
pcie_pme_work_fn() as PCI_EXP_RTSTA_PME is true now forever.  This issue
can be reproduced by booting kernel with pci=nomsi.

Use the normal register bank for the PCI config accessors.  The privileged
bank is used only internally by this driver.

Fixes: e77f847d ("PCI: rockchip: Add Rockchip PCIe controller support")
Signed-off-by: Shawn Lin &lt;shawn.lin@rock-chips.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: Jeffy Chen &lt;jeffy.chen@rock-chips.com&gt;
Cc: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: vmd: Move SRCU cleanup after bus, child device removal</title>
<updated>2017-07-27T22:10:09+00:00</updated>
<author>
<name>Jon Derrick</name>
<email>jonathan.derrick@intel.com</email>
</author>
<published>2017-06-22T15:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2e09bcd1732da525da98c4f419cb79a65564e637'/>
<id>2e09bcd1732da525da98c4f419cb79a65564e637</id>
<content type='text'>
commit 0cb259c47a4df466d641c1f07ae3eccaa9ba3ccb upstream.

Recent __call_srcu() changes have exposed that we need to cleanup SRCU
structures after pci_stop_root_bus() calls into vmd_msi_free().

Fixes: 3906b91844d6 ("PCI: vmd: Use SRCU as a local RCU to prevent delaying global RCU")
Signed-off-by: Jon Derrick &lt;jonathan.derrick@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Keith Busch &lt;keith.busch@intel.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 0cb259c47a4df466d641c1f07ae3eccaa9ba3ccb upstream.

Recent __call_srcu() changes have exposed that we need to cleanup SRCU
structures after pci_stop_root_bus() calls into vmd_msi_free().

Fixes: 3906b91844d6 ("PCI: vmd: Use SRCU as a local RCU to prevent delaying global RCU")
Signed-off-by: Jon Derrick &lt;jonathan.derrick@intel.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Keith Busch &lt;keith.busch@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: endpoint: Select CRC32 to fix test build error</title>
<updated>2017-06-12T20:46:13+00:00</updated>
<author>
<name>Randy Dunlap</name>
<email>rdunlap@infradead.org</email>
</author>
<published>2017-06-12T20:43:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=98dbf5af4fdd142f6184dbb4e4164a8d1850d526'/>
<id>98dbf5af4fdd142f6184dbb4e4164a8d1850d526</id>
<content type='text'>
The PCI endpoint test driver uses crc32_le() so it should select
CRC32.  Fixes this build error (when CRC32=m):

  drivers/built-in.o: In function `pci_epf_test_cmd_handler':
  pci-epf-test.c:(.text+0x2d98d): undefined reference to `crc32_le'

Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI")
Reported-by: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The PCI endpoint test driver uses crc32_le() so it should select
CRC32.  Fixes this build error (when CRC32=m):

  drivers/built-in.o: In function `pci_epf_test_cmd_handler':
  pci-epf-test.c:(.text+0x2d98d): undefined reference to `crc32_le'

Fixes: 349e7a85b25f ("PCI: endpoint: functions: Add an EP function to test PCI")
Reported-by: kbuild test robot &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Kishon Vijay Abraham I &lt;kishon@ti.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: Make error code types consistent in pci_{read,write}_config_*</title>
<updated>2017-05-26T21:38:50+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2017-05-23T19:36:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=449e2f9e95d803961635d725f6482e5e995b7554'/>
<id>449e2f9e95d803961635d725f6482e5e995b7554</id>
<content type='text'>
Callers normally treat the config space accessors as returning PCBIOS_*
error codes, not Linux error codes (or they don't look at them at all).  We
have pcibios_err_to_errno() in case the error code needs to be translated.

Fixes: 4b1038834739 ("PCI: Don't attempt config access to disconnected devices")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Keith Busch &lt;keith.busch@intel.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Callers normally treat the config space accessors as returning PCBIOS_*
error codes, not Linux error codes (or they don't look at them at all).  We
have pcibios_err_to_errno() in case the error code needs to be translated.

Fixes: 4b1038834739 ("PCI: Don't attempt config access to disconnected devices")
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Keith Busch &lt;keith.busch@intel.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>PCI/PM: Add needs_resume flag to avoid suspend complete optimization</title>
<updated>2017-05-23T19:18:17+00:00</updated>
<author>
<name>Imre Deak</name>
<email>imre.deak@intel.com</email>
</author>
<published>2017-05-23T19:18:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4d071c3238987325b9e50e33051a40d1cce311cc'/>
<id>4d071c3238987325b9e50e33051a40d1cce311cc</id>
<content type='text'>
Some drivers - like i915 - may not support the system suspend direct
complete optimization due to differences in their runtime and system
suspend sequence.  Add a flag that when set resumes the device before
calling the driver's system suspend handlers which effectively disables
the optimization.

Needed by a future patch fixing suspend/resume on i915.

Suggested by Rafael.

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&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</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some drivers - like i915 - may not support the system suspend direct
complete optimization due to differences in their runtime and system
suspend sequence.  Add a flag that when set resumes the device before
calling the driver's system suspend handlers which effectively disables
the optimization.

Needed by a future patch fixing suspend/resume on i915.

Suggested by Rafael.

Signed-off-by: Imre Deak &lt;imre.deak@intel.com&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</pre>
</div>
</content>
</entry>
<entry>
<title>PCI: imx6: Fix config read timeout handling</title>
<updated>2017-05-22T22:06:30+00:00</updated>
<author>
<name>Lucas Stach</name>
<email>l.stach@pengutronix.de</email>
</author>
<published>2017-05-22T22:06:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=415b6185c541dc0a21457ff307cdb61950a6eb9f'/>
<id>415b6185c541dc0a21457ff307cdb61950a6eb9f</id>
<content type='text'>
Commit cc7b0d495589 ("PCI: designware: Update PCI config space remap
function") made PCI configuration requests non-posted, which means we now
get a synchronous abort when the CFG space read to probe for downstream
devices times out.

Synchronous aborts need to be handled differently from the async aborts we
were getting before, in particular the PC needs to be advanced when
resolving the abort.  This is mostly a copy of what other PCI drivers do on
ARM to handle those aborts.

[bhelgaas: changelog, "Fixes"]
Fixes: cc7b0d495589 ("PCI: designware: Update PCI config space remap function")
Tested-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Tested-by: Peter Senna Tschudin &lt;peter.senna@collabora.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Richard Zhu &lt;hongxing.zhu@nxp.com&gt;</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit cc7b0d495589 ("PCI: designware: Update PCI config space remap
function") made PCI configuration requests non-posted, which means we now
get a synchronous abort when the CFG space read to probe for downstream
devices times out.

Synchronous aborts need to be handled differently from the async aborts we
were getting before, in particular the PC needs to be advanced when
resolving the abort.  This is mostly a copy of what other PCI drivers do on
ARM to handle those aborts.

[bhelgaas: changelog, "Fixes"]
Fixes: cc7b0d495589 ("PCI: designware: Update PCI config space remap function")
Tested-by: Fabio Estevam &lt;fabio.estevam@nxp.com&gt;
Tested-by: Peter Senna Tschudin &lt;peter.senna@collabora.com&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Richard Zhu &lt;hongxing.zhu@nxp.com&gt;</pre>
</div>
</content>
</entry>
<entry>
<title>switchtec: Fix minor bug with partition ID register</title>
<updated>2017-05-22T21:52:30+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2017-05-22T21:52:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9871e9bb5cf6ff0b51457ca74c270c5c5230b224'/>
<id>9871e9bb5cf6ff0b51457ca74c270c5c5230b224</id>
<content type='text'>
When a switch endpoint is configured without NTB, the mmio_ntb registers
will read all zeros.  However, in corner case configurations where the
partition ID is not zero and NTB is not enabled, the code will have the
wrong partition ID and this causes the driver to use the wrong set of
drivers.  To fix this we simply take the partition ID from the system info
region.

Reported-by: Dingbao Chen &lt;dingbao.chen@microsemi.com&gt;
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When a switch endpoint is configured without NTB, the mmio_ntb registers
will read all zeros.  However, in corner case configurations where the
partition ID is not zero and NTB is not enabled, the code will have the
wrong partition ID and this causes the driver to use the wrong set of
drivers.  To fix this we simply take the partition ID from the system info
region.

Reported-by: Dingbao Chen &lt;dingbao.chen@microsemi.com&gt;
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>switchtec: Use new cdev_device_add() helper function</title>
<updated>2017-05-22T21:52:24+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2017-05-22T21:52:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e40cf640b8f632091a30ef0b030c83546f07c902'/>
<id>e40cf640b8f632091a30ef0b030c83546f07c902</id>
<content type='text'>
Convert from "cdev_add() + device_add()" to cdev_device_add(), and from
"device_del() + cdev_del()" to cdev_device_del().

[bhelgaas: changelog]
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Convert from "cdev_add() + device_add()" to cdev_device_add(), and from
"device_del() + cdev_del()" to cdev_device_del().

[bhelgaas: changelog]
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
