On Mon, Aug 15, 2011 at 11:03:50PM +0300, Felipe Balbi wrote: > HI, > > On Mon, Aug 15, 2011 at 12:52:36PM -0700, Doug Anderson wrote: > > Felipe, > > > > On Mon, Aug 15, 2011 at 12:17 PM, Felipe Balbi <balbi@xxxxxx> wrote: > > > so due to a FIFO overflow you lock up the whole system ? Can't you e.g. > > > reset the controller and reconfigure it rather than locking up the > > > system ? > > > > Certainly we could try to be more proactive and reset / retry / return > > the error to the client. However, since the only expected situation > > where this BUG_ON should hit is due to a bug in this driver itself > > (AKA: i2c clients shouldn't be able to do anything to cause the BUG_ON > > to hit), that seems like a lot of added complexity. > > so at least just pass an error to the client, but hanging the entire > system seems a bit too much, dont you think ? > > > Also: if there is an arbitrary software bug that causing an overflow > > condition to occur, I'm not sure how stable the system will be. > > Specifically, the i2c controller is used (among other things) to talk > > to the PMU and adjust voltages in the system. If we just sent it a > > random command, I'd rather report the bug right away so we don't get > > hard to find/reproduce failures in other parts of the system. > > that's a good point, I still think that e.g. making a cellphone > unresponsive until a watchdog reset triggers just because you got a FIFO > overflow on the I2C controller is too much. Yes, I would agree on that. BUG() really should be only used for occasions where there's little possiblity the entire system can continue to work. In this case, it seems far more sensible to report this as an error and see what can be done to recover the bus and controller for the next transaction. -- Ben -- 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
