[PATCH linux dev-4.13 0/2] Fix SBEFIFO chardev read behaviour

[Andrew Jeffery]

Hello,

read() on the SBEFIFO chardevs is currently unusuable as it will always return
-EAGAIN on a read subsequent to the EOT flag being observed. This breaks reads
using short buffers as we now have no way to know when we have received the
entire message. This is made infinitely worse by the protocol, which as
defined, means we cannot know how much data must be read, and therefore all
buffers are effectively short*.

These two patches help by at least returning 0 for a read subsequent to one
which drains the last byte from the transfer buffer. A read subsequent to one
returning 0 will then return -EAGAIN if necessary, under the expectation that a
write() has been issued.

This is a work-around until BenH gets his alternative SBEFIFO implementation in
shape.

* This is true to a point - it recently came to light that we can expect any
  FFDC to be at a maximum 8K in size, and the maximum size of the transfer is
  defined as:

  * The requested response size, plus
  * The status "header", plus
  * Up to 8K of FFDC

Andrew Jeffery (2):
  fsi: sbefifo: Unpack !sbefifo_xfr_rsp_pending(client) test
  fsi: sbefifo: Return 0 on read() to indicate end of response

 drivers/fsi/fsi-sbefifo.c | 48 +++++++++++++++++++++++++++++++--------
 1 file changed, 38 insertions(+), 10 deletions(-)

-- 
2.17.0