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

[Eddie James]

On 05/14/2018 01:18 AM, Andrew Jeffery wrote:
> 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.

Thanks Andrew, I haven't dug into the diffs too much but I just tested 
the series and it appears to have made the in-kernel API less reliable. 
I'm getting some errors when attempting to use the OCC driver.

Thanks,
Eddie

>
> 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(-)
>