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 <eunb.song@xxxxxxxxxxx > <mailto:eunb.song@xxxxxxxxxxx>> > > 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 Daney -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
