On Fri, Jun 07, 2013 at 03:01:34PM +0200, Christian Ruppert wrote: > Hi Andy, > > I like your patch and I just did some testing on it. Unluckily, it > doesn't solve the lock-up problem. > > I haven't investigated any further but I suspect that on top of the > cases I observed when debugging this (interrupts after initialisation of > dev, easy to prove) there are more obscure cases in which interrupts are > generated in an unexpected manner after errors. The interrupt-driven > transfer state machine of the driver implicitly relies on the fact that > all updates of dev which are related to the same transfer are performed > between the mutex_lock and mutex_unlock calls in i2c_dw_xfer. Thus, I > decided it was safer to disable the block before releasing the mutex > when I wrote my patch. > > That said, I think the sequencing at transfer initialisation is more > logical with your patch and I wonder if it is still worth applying. Any > other opinions on this? Ping. There are: [V2] i2c: designware: fix race between subsequent xfers [RFC] i2c-designware-core: disable adapter before fill dev structure What is the consensus of those two patches?
Attachment:
signature.asc
Description: Digital signature
