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

[Eddie James]

On 05/14/2018 06:09 PM, Andrew Jeffery wrote:
> Hi Eddie,
>
> On Tue, 15 May 2018, at 07:57, Eddie James wrote:
>>
>> 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 for testing. What errors are you sometimes seeing? I need some more info to reproduce and understand what might be going wrong.

Any of EIO, ENODATA, and EBADMSG from the OCC driver. All I did was 
power the system on, and would see the errors most of the time when the 
host attempted to set the OCCs active.

Thanks,
Eddie

>
> Cheers,
>
> Andrew
>