<feed xmlns='http://www.w3.org/2005/Atom'>
<title>BMC/Intel-BMC/linux.git/drivers/fsi, branch dev-4.10</title>
<subtitle>Intel OpenBMC Linux kernel source tree (mirror)</subtitle>
<id>https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.10</id>
<link rel='self' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/atom?h=dev-4.10'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/'/>
<updated>2017-11-01T04:31:03+00:00</updated>
<entry>
<title>drivers (fsi): occ: Change errno for releasing client during transfer</title>
<updated>2017-11-01T04:31:03+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-31T17:34:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=67fda6b3a8b85e3063fc46fb3262ffb130ba396d'/>
<id>urn:sha1:67fda6b3a8b85e3063fc46fb3262ffb130ba396d</id>
<content type='text'>
Clients were receiving the ECANCELED errno when the client is removed
during a transfer. Use ENODEV instead, as ECANCELED is for AIO ops.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Reviewed-by: Christopher Bostic &lt;cbostic@linux.vnet.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>drivers (fsi): sbefifo: Add timeout for waiting for data</title>
<updated>2017-10-30T23:33:53+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-26T22:34:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=dd174f685f9c4d4e5d5486dd59c5be8ef517ae49'/>
<id>urn:sha1:dd174f685f9c4d4e5d5486dd59c5be8ef517ae49</id>
<content type='text'>
During a transfer, in the event that the SBE isn't running, the driver
will wait for data to appear in the FIFO forever. This doesn't work at
BMC boot time if any transfers are attempted (by OCC driver probing, for
example), as it will just hang the boot. So add a simple timeout
mechanism when the driver reschdules waiting for data to show up in the
FIFO.

Tested on witherspoon by rebooting the BMC successfully with chassis
power on.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>drivers (fsi): sbefifo: Fix xfr deletion in lists</title>
<updated>2017-10-26T20:56:13+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-26T20:15:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=ccbb1cf05ec2ad03d858610396f363ffaef10026'/>
<id>urn:sha1:ccbb1cf05ec2ad03d858610396f363ffaef10026</id>
<content type='text'>
Deleting an element of a list while iterating means that you'll access
recently freed memory when getting the next list element.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>drivers: fsi: sbefifo: Attempt reset request during probe</title>
<updated>2017-10-18T14:01:21+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-17T21:35:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=1af701e56cd6bd5399b517e276d479482b702839'/>
<id>urn:sha1:1af701e56cd6bd5399b517e276d479482b702839</id>
<content type='text'>
If data is found in the FIFO, the driver currently immediately fails
the probe. Instead, try a reset request and poll for it's completion for
a while (this protocol is defined in the SBE FIFO spec, though the
timeout lengths are my own invention).

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>drivers: fsi: sbefifo: Fix memory leak</title>
<updated>2017-10-18T13:25:15+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-17T21:35:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a45f71b3d10d0fac84a28e2bd1cee767e9e111e3'/>
<id>urn:sha1:a45f71b3d10d0fac84a28e2bd1cee767e9e111e3</id>
<content type='text'>
Transfers weren't being cleaned up if they were complete but the user
never finished reading. This is very common.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>drivers: fsi: sbefifo: Fix queued xfrs race condition</title>
<updated>2017-10-18T11:59:58+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-17T21:35:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=303fb643167f19ad8cd9fb966c641161985020de'/>
<id>urn:sha1:303fb643167f19ad8cd9fb966c641161985020de</id>
<content type='text'>
There was a race condition where: sbefifo remove() is called, a transfer
is queued, a client is waiting, and a client is released at the same
time. In this situation, remove() wakes up the client waiter, which
destroys the client's list of transfers. This must be done since in an
error case, we don't know if the transfers are deleted or not. Then,
the client is released. Since it has no transfers, it fails to cancel
the queued transfer. This transfer then wakes up on the timer, where it
attempts to access it's client buffers, which have been freed.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>drivers: fsi: occ: Fix errno for canceling a read operation</title>
<updated>2017-10-13T06:13:09+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-12T15:59:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=703c3c181790b20c48c4d02b9fed901379671fb7'/>
<id>urn:sha1:703c3c181790b20c48c4d02b9fed901379671fb7</id>
<content type='text'>
Should not return -ECANCELED when the device has been removed. Instead,
use -ENODEV.

Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Signed-off-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
</content>
</entry>
<entry>
<title>fsi: occ: Fix client memory management</title>
<updated>2017-10-09T01:52:32+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-06T02:05:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=36f8c81ca9cd67743db75d6b3cb611a7a70140ee'/>
<id>urn:sha1:36f8c81ca9cd67743db75d6b3cb611a7a70140ee</id>
<content type='text'>
Potential for bad memory access in the worker function. Now fixed by
using reference counters.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Acked-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>fsi: occ: Add cancel to remove() and fix probe()</title>
<updated>2017-10-09T01:51:43+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-06T02:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=a00278f9cc43d618fc904c3c26bc561cecbc2c8d'/>
<id>urn:sha1:a00278f9cc43d618fc904c3c26bc561cecbc2c8d</id>
<content type='text'>
Need some data to indicate to clients and the rest of the driver when
the device is being removed, so add a cancel boolean. Fix up both the
probe and remove functions to properly handle failures and prevent
deadlocks.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Reviewed-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
[joel: Use ENODEV instead of ECANCELLED, as it is for cancelled AIO
operations]
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
<entry>
<title>fsi: occ: Poll while receiving "command in progress"</title>
<updated>2017-10-09T01:48:48+00:00</updated>
<author>
<name>Edward A. James</name>
<email>eajames@us.ibm.com</email>
</author>
<published>2017-10-06T02:05:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/BMC/Intel-BMC/linux.git/commit/?id=c6f316cbe540300f7f7b1bac2fe42f2d2a8e6075'/>
<id>urn:sha1:c6f316cbe540300f7f7b1bac2fe42f2d2a8e6075</id>
<content type='text'>
Waiting for OCC to return something other than "command in progress"
should only be done in the worker function, instead of clients repeating
the entire transfer when they receive "command in progress." In this way
clients don't have to check for that return status.

OpenBMC-Staging-Count: 1
Signed-off-by: Edward A. James &lt;eajames@us.ibm.com&gt;
Acked-by: Andrew Jeffery &lt;andrew@aj.id.au&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
</entry>
</feed>
