[PATCH linux v3 17/18] drivers/fsi: Add GPIO master functionality

[Christopher Bostic]

On Wed, Oct 12, 2016 at 8:16 PM, Jeremy Kerr <jk at ozlabs.org> wrote:
> Hi Chris,
>
>>>> +static void serial_in(struct fsi_master_gpio *master, struct fsi_gpio_msg *cmd)

>>>> +/*
>>>> + * Store information on master errors so handler can detect and clean
>>>> + * up the bus
>>>> + */
>>>> +static void fsi_master_gpio_error(struct fsi_master_gpio *master, int error)
>>>> +{
>>>> +
>>>> +}
>>>
>>> I know this is a todo, but where are you planning to 'store' this
>>> information? Shouldn't errors just be returned immediately?
>>
>> This is intended to be the entry point for the bus error handling code.
>> I could return the failing rc to the caller right there but ultimately the
>> error handler needs to be invoked somewhere in the call chain
>> anyway.  As it is here the error condition is cleaned up as early as
>> possible.
>>
>> Even if the error is of a master type - such as master
>> time out errors (MTOE) there is still a possibility that the connected
>> slave is in some latched failed state which requires recovery to
>> resume normal bus communications (issue a terminate command
>> to slave, etc...)
>
> OK, makes sense. Would this logic be repeated for all masters? If so, we
> may want the core to manage common error recovery that involves the
> slaves.

Hi Jeremy,

There would be some fsi-master-gpio specifics here to deal with
but there is also a portion of error handling that is standard to all
masters so that would be spelled out in fsi-core.c.  For now, I'm
leaving bus error handling out of the first set.

Thanks
Chris