4243fa0bad
Asking for a multi-part message to be handled by this driver is racy; it has been observed that the following sequence is possible with this driver: - send start - send address + write - send data - send (repeated) start - send address + write - send (repeated) start - send address + read - unrecoverable bus hang (except by system reset) The problem is that the interrupt handling sees the next event after the first repeated start is sent - the IFLG bit is set in the register even though INTEN is disabled. Let's fix this by moving all of the message processing into interrupt context, rather than having it partly in IRQ and partly in process context. This allows us to move immediately to the next message in the interrupt handler and get on with the transfer, rather than incuring a couple of scheduling switches to get the next message. Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Acked-by: Mark A. Greer <mgreer@animalcreek.com> Signed-off-by: Wolfram Sang <wsa@the-dreams.de> |
||
|---|---|---|
| .. | ||
| algos | ||
| busses | ||
| muxes | ||
| i2c-boardinfo.c | ||
| i2c-core.c | ||
| i2c-core.h | ||
| i2c-dev.c | ||
| i2c-mux.c | ||
| i2c-smbus.c | ||
| i2c-stub.c | ||
| Kconfig | ||
| Makefile | ||