On 6/26/20 2:13 PM, Raviteja Narayanam wrote:
Hi,
[...]
>> @@ -703,23 +704,24 @@ static int xiic_xfer(struct i2c_adapter *adap, struct
>> i2c_msg *msgs, int num)
>> err = xiic_start_xfer(i2c, msgs, num);
>> if (err < 0) {
>> dev_err(adap->dev.parent, "Error xiic_start_xfer\n");
>> - goto out;
>> + return err;
>> }
>>
>> - if (wait_event_timeout(i2c->wait, (i2c->state == STATE_ERROR) ||
>> - (i2c->state == STATE_DONE), HZ)) {
>> - mutex_lock(&i2c->lock);
>> - err = (i2c->state == STATE_DONE) ? num : -EIO;
>> - goto out;
>> - } else {
>> - mutex_lock(&i2c->lock);
>> + err = wait_for_completion_interruptible_timeout(&i2c->completion,
>> + XIIC_I2C_TIMEOUT);
>
> This is causing random lock up of bus. Since it is "interruptible" API, once we enter Ctrl+C,
> It is coming out of wait state, the message pointers are made NULL and the ongoing transaction is not completed.
> Can use " wait_for_completion_timeout" API in place of this.
>
>> + mutex_lock(&i2c->lock);
So in case this is interrupted, we would have to somehow reset the
controller ? What sort of lockups do you see exactly ? Can you share
some sort of test case, so I can replicate it ?
Thanks
[...]
