i2c: stm32f7: fix a race in slave mode with arbitration loss irq
authorFabrice Gasnier <fabrice.gasnier@st.com>
Tue, 1 Oct 2019 08:51:09 +0000 (10:51 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 10 Nov 2019 10:27:32 +0000 (11:27 +0100)
commit86fd9e339ab4fc48a86479e115798ccdd6af576a
tree26df8e0d15e89b8d0e9a7cc125216f4e94663a68
parentd746ce649556795b09d721d34821d38c68400921
i2c: stm32f7: fix a race in slave mode with arbitration loss irq

[ Upstream commit 6d6b0d0d5afc8c4c84b08261260ba11dfa5206f2 ]

When in slave mode, an arbitration loss (ARLO) may be detected before the
slave had a chance to detect the stop condition (STOPF in ISR).
This is seen when two master + slave adapters switch their roles. It
provokes the i2c bus to be stuck, busy as SCL line is stretched.
- the I2C_SLAVE_STOP event is never generated due to STOPF flag is set but
  don't generate an irq (race with ARLO irq, STOPIE is masked). STOPF flag
  remains set until next master xfer (e.g. when STOPIE irq get unmasked).
  In this case, completion is generated too early: immediately upon new
  transfer request (then it doesn't send all data).
- Some data get stuck in TXDR register. As a consequence, the controller
  stretches the SCL line: the bus gets busy until a future master transfer
  triggers the bus busy / recovery mechanism (this can take time... and
  may never happen at all)

So choice is to let the STOPF being detected by the slave isr handler,
to properly handle this stop condition. E.g. don't mask IRQs in error
handler, when the slave is running.

Fixes: 60d609f30de2 ("i2c: i2c-stm32f7: Add slave support")
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
Reviewed-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/i2c/busses/i2c-stm32f7.c