Re: Re: I2C: Fix i2c fail problem when a process is terminated by asignal on octeon in 3.8

From: 송은봉
Date: Tue Feb 26 2013 - 18:15:49 EST



>If the wait is not interruptible, I think you will not be able to 'kill
>-9' a userspace process blocked here.

As your words. the process will not be killed immediately, but after timeout(2 jiffies) it will be killed.
I think that delay is acceptable.


------- Original Message -------
Sender : David Daney<ddaney@xxxxxxxxxxxxxxxxxx>
Date : 2013-02-27 08:07 (GMT+09:00)
Title : Re: I2C: Fix i2c fail problem when a process is terminated by a signal on octeon in 3.8

On 02/26/2013 12:54 PM, 송은봉 wrote:
> I've been debugging the abnormal operation of i2c on octeon.
> If a process is terminated by signal in the middle of i2c operation,
> next i2c read operation which is done by another process was failed.
> So i changed to ignore signal in the middle of i2c operation.
> After that the problem was not reproduced.
>

This is a known issue. However I don't think the solution you have is
correct...

> Signed-off-by: EunBong Song > >
>
> diff -up drivers/i2c/busses/i2c-octeon.c{.orig,}
> --- drivers/i2c/busses/i2c-octeon.c.orig 2013-02-21 08:09:03.168018843 -0800
> +++ drivers/i2c/busses/i2c-octeon.c 2013-02-21 08:09:38.344018898 -0800
> @@ -183,7 +183,7 @@ static irqreturn_t octeon_i2c_isr(int ir
> struct octeon_i2c *i2c = dev_id;
>
> octeon_i2c_int_disable(i2c);
> - wake_up_interruptible(&i2c->queue);
> + wake_up(&i2c->queue);
>
> return IRQ_HANDLED;
> }
> @@ -206,7 +206,7 @@ static int octeon_i2c_wait(struct octeon
>
> octeon_i2c_int_enable(i2c);
>
> - result = wait_event_interruptible_timeout(i2c->queue,
> + result = wait_event_timeout(i2c->queue,

If the wait is not interruptible, I think you will not be able to 'kill
-9' a userspace process blocked here.

> octeon_i2c_test_iflg(i2c),
> i2c->adap.timeout);
>

The real solution is to move processing of the I2C protocol to a kernel
thread and communicate between the this thread and userspace via a
command queue mechanism, much like the way it is done in the mmc/host
driver infrastructure.

David DaneyN떑꿩ìr¸›y鉉싕b²XФ푤vØ^–)頻{.nÇ+돴¥Š{±묎çzX㎍썳變}©옽Æ zÚ&j:+v돣¾«묎çzZ+€Ê+zf"·hš닱~넮녬iÿ鎬z¹®wⅱ¸?솳鈺Ú&¢)刪f뷌^j푹y§m끷@A«a뛴ÿ 0띠h®å’i