However, there might be cases where rcar_i2c_probe() is called, but
the I2C hardware is *not* in reset state. E.g. if just the Linux
operating system was re-started by a supervisor. But the hardware didn't
get a reset. For cases like this make sure that the I2C hardware
interrupts are cleared properly before devm_request_irq() is called.
This is inspired by rcar_i2c_init().
Signed-off-by: Dirk Behme <dirk.behme@xxxxxxxxxxxx>
---
drivers/i2c/busses/i2c-rcar.c | 6 ++++++
1 file changed, 6 insertions(+)
Notes: This is untested. Does this make sense and is acceptable?
This might be testable by shutting down Linux to e.g.
suspend to RAM. And then, instead of resume, re-start
(cold start) the kernel. So that probe() is called and
uses a non-reset I2C peripheral.
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 828aa2ea0fe4..5f46955167c4 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -1183,6 +1183,12 @@ static int rcar_i2c_probe(struct platform_device *pdev)
ret = platform_get_irq(pdev, 0);
if (ret < 0)
goto out_pm_put;
+
+ /* reset master mode */
+ rcar_i2c_write(priv, ICMIER, 0);
+ rcar_i2c_write(priv, ICMCR, MDBS);
+ rcar_i2c_write(priv, ICMSR, 0);
+
priv->irq = ret;
ret = devm_request_irq(dev, priv->irq, irqhandler, irqflags, dev_name(dev), priv);
if (ret < 0) {
--
2.28.0
