<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/pci/switch, branch v4.14.263</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.263'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-04-24T06:00:27+00:00</updated>
<entry>
<title>PCI/switchtec: Fix init_completion race condition with poll_wait()</title>
<updated>2020-04-24T06:00:27+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2020-03-21T11:25:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=16a55efd94e6e36fc2cf347e22848d9895868118'/>
<id>urn:sha1:16a55efd94e6e36fc2cf347e22848d9895868118</id>
<content type='text'>
[ Upstream commit efbdc769601f4d50018bf7ca50fc9f7c67392ece ]

The call to init_completion() in mrpc_queue_cmd() can theoretically
race with the call to poll_wait() in switchtec_dev_poll().

  poll()			write()
    switchtec_dev_poll()   	  switchtec_dev_write()
      poll_wait(&amp;s-&gt;comp.wait);      mrpc_queue_cmd()
			               init_completion(&amp;s-&gt;comp)
				         init_waitqueue_head(&amp;s-&gt;comp.wait)

To my knowledge, no one has hit this bug.

Fix this by using reinit_completion() instead of init_completion() in
mrpc_queue_cmd().

Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")

Reported-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Peter Zijlstra (Intel) &lt;peterz@infradead.org&gt;
Acked-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Link: https://lkml.kernel.org/r/20200313183608.2646-1-logang@deltatee.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI/switchtec: Fix vep_vector_number ioread width</title>
<updated>2020-02-14T21:32:21+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2020-01-06T19:03:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=b642fb092de14eb6ed760f5fb7ceb160ec6bee98'/>
<id>urn:sha1:b642fb092de14eb6ed760f5fb7ceb160ec6bee98</id>
<content type='text'>
commit 9375646b4cf03aee81bc6c305aa18cc80b682796 upstream.

vep_vector_number is actually a 16 bit register which should be read with
ioread16() instead of ioread32().

Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")
Link: https://lore.kernel.org/r/20200106190337.2428-3-logang@deltatee.com
Reported-by: Doug Meyer &lt;dmeyer@gigaio.com&gt;
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>switchtec: Remove immediate status check after submitting MRPC command</title>
<updated>2020-01-27T13:46:07+00:00</updated>
<author>
<name>Kelvin Cao</name>
<email>kelvin.cao@microchip.com</email>
</author>
<published>2018-12-10T09:12:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=336384d871a9797a620063158c3d80988ea0cc47'/>
<id>urn:sha1:336384d871a9797a620063158c3d80988ea0cc47</id>
<content type='text'>
[ Upstream commit 526180408b815aa7b96fd48bd23cdd33ef04e38e ]

After submitting a Firmware Download MRPC command, Switchtec firmware will
delay Management EP BAR MemRd TLP responses by more than 10ms.  This is a
firmware limitation.  Delayed MemRd completions are a problem for systems
with a low Completion Timeout (CTO).

The current driver checks the MRPC status immediately after submitting an
MRPC command, which results in a delayed MemRd completion that may cause a
Completion Timeout.

Remove the immediate status check and rely on the check after receiving an
interrupt or timing out.

This is only a software workaround to the READ issue and a proper fix of
this should be done in firmware.

Fixes: 080b47def5e5 ("MicroSemi Switchtec management interface driver")
Signed-off-by: Kelvin Cao &lt;kelvin.cao@microchip.com&gt;
Signed-off-by: Wesley Sheng &lt;wesley.sheng@microchip.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>PCI/switchtec: Read all 64 bits of part_event_bitmap</title>
<updated>2020-01-12T11:12:02+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2019-09-10T19:58:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e9eae4143c33ebe33aa2e195c2863c6e1bf3f8cd'/>
<id>urn:sha1:e9eae4143c33ebe33aa2e195c2863c6e1bf3f8cd</id>
<content type='text'>
commit 6acdf7e19b37cb3a9258603d0eab315079c19c5e upstream.

The part_event_bitmap register is 64 bits wide, so read it with ioread64()
instead of the 32-bit ioread32().

Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Link: https://lore.kernel.org/r/20190910195833.3891-1-logang@deltatee.com
Reported-by: Doug Meyer &lt;dmeyer@gigaio.com&gt;
Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Cc: stable@vger.kernel.org	# v4.12+
Cc: Kelvin Cao &lt;Kelvin.Cao@microchip.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>switchtec: Fix SWITCHTEC_IOCTL_EVENT_IDX_ALL flags overwrite</title>
<updated>2019-02-12T18:46:04+00:00</updated>
<author>
<name>Joey Zhang</name>
<email>joey.zhang@microchip.com</email>
</author>
<published>2018-12-10T09:12:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cf96f234ef4f3ad6b43c968c77c307271537692a'/>
<id>urn:sha1:cf96f234ef4f3ad6b43c968c77c307271537692a</id>
<content type='text'>
[ Upstream commit e4a7dca5de625018b29417ecc39dc5037d9a5a36 ]

In the ioctl_event_ctl() SWITCHTEC_IOCTL_EVENT_IDX_ALL case, we call
event_ctl() several times with the same "ctl" struct.  Each call clobbers
ctl.flags, which leads to the problem that we may not actually enable or
disable all events as the user requested.

Preserve the event flag value with a temporary variable.

Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
Signed-off-by: Joey Zhang &lt;joey.zhang@microchip.com&gt;
Signed-off-by: Wesley Sheng &lt;wesley.sheng@microchip.com&gt;
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>switchtec: Fix Spectre v1 vulnerability</title>
<updated>2018-09-19T20:43:37+00:00</updated>
<author>
<name>Gustavo A. R. Silva</name>
<email>gustavo@embeddedor.com</email>
</author>
<published>2018-08-16T19:06:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0fad94cf10165084189bc160cc48f8004ea11ee8'/>
<id>urn:sha1:0fad94cf10165084189bc160cc48f8004ea11ee8</id>
<content type='text'>
commit 46feb6b495f7628a6dbf36c4e6d80faf378372d4 upstream.

p.port can is indirectly controlled by user-space, hence leading to
a potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

  drivers/pci/switch/switchtec.c:912 ioctl_port_to_pff() warn: potential spectre issue 'pcfg-&gt;dsp_pff_inst_id' [r]

Fix this by sanitizing p.port before using it to index
pcfg-&gt;dsp_pff_inst_id

Notice that given that speculation windows are large, the policy is to kill
the speculation on the first load and not worry if it can be completed with
a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&amp;m=152449131114778&amp;w=2

Signed-off-by: Gustavo A. R. Silva &lt;gustavo@embeddedor.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Acked-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Merge branch 'pci/switchtec' into next</title>
<updated>2017-07-02T23:51:10+00:00</updated>
<author>
<name>Bjorn Helgaas</name>
<email>bhelgaas@google.com</email>
</author>
<published>2017-07-02T23:51:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c781f85bc1958391e2d305fe6f52c90de0adb92e'/>
<id>urn:sha1:c781f85bc1958391e2d305fe6f52c90de0adb92e</id>
<content type='text'>
* pci/switchtec:
  switchtec: Add device IDs for additional Switchtec products
  switchtec: Add "running" status flag to fw partition info ioctl
</content>
</entry>
<entry>
<title>switchtec: Add device IDs for additional Switchtec products</title>
<updated>2017-06-27T23:25:06+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2017-06-15T20:12:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=393958d0d9ba2b9fd77e39ce764aa10b2e56b701'/>
<id>urn:sha1:393958d0d9ba2b9fd77e39ce764aa10b2e56b701</id>
<content type='text'>
The switchtec driver also supports the PAX, PFXL and PFXI products which
have the same management interface.

Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kurt Schwemmer &lt;kurt.schwemmer@microsemi.com&gt;</content>
</entry>
<entry>
<title>switchtec: Add "running" status flag to fw partition info ioctl</title>
<updated>2017-06-27T23:23:14+00:00</updated>
<author>
<name>Logan Gunthorpe</name>
<email>logang@deltatee.com</email>
</author>
<published>2017-06-15T20:12:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=079e3bc588465f6216bfc5ad61540b5db4616598'/>
<id>urn:sha1:079e3bc588465f6216bfc5ad61540b5db4616598</id>
<content type='text'>
This flag lets userspace know which firmware partitions are currently in
use as opposed to just active.  "Active" means they will be in use for the
next reboot, whereas "running" means they are currently in use.

If an old kernel is in use, or the firmware doesn't support these fields,
the new flag will not be set in the output.

Signed-off-by: Logan Gunthorpe &lt;logang@deltatee.com&gt;
Signed-off-by: Bjorn Helgaas &lt;bhelgaas@google.com&gt;
Reviewed-by: Kurt Schwemmer &lt;kurt.schwemmer@microsemi.com&gt;</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.radix-linux.su/kernel/linux.git/commit/?id=9871e9bb5cf6ff0b51457ca74c270c5c5230b224'/>
<id>urn:sha1: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>
</entry>
</feed>
