On Fri, Sep 08, 2023 at 12:16:47PM +0200, Gerald Loacker wrote: > It may happen that an i2c transfer is requested by a callback although > there is an other i2c transfer running. In this case do not interrupt the > transfer and return with an error. > > Signed-off-by: Gerald Loacker <[email protected]> > --- > drivers/i2c/busses/i2c-rockchip.c | 14 +++++++++++++- > 1 file changed, 13 insertions(+), 1 deletion(-) > > diff --git a/drivers/i2c/busses/i2c-rockchip.c > b/drivers/i2c/busses/i2c-rockchip.c > index 1bca3e9913..a869b9d0b7 100644 > --- a/drivers/i2c/busses/i2c-rockchip.c > +++ b/drivers/i2c/busses/i2c-rockchip.c > @@ -369,7 +369,19 @@ static int rockchip_i2c_xfer(struct i2c_adapter > *adapter, struct i2c_msg *msgs, > { > struct rk_i2c *i2c = to_rk_i2c(adapter); > struct device *dev = &adapter->dev; > - int i, ret = 0; > + struct i2c_regs *regs = i2c->regs; > + int i, ret = 0, val; > + > + val = readl(®s->con); > + if (val & I2C_CON_EN) { > + val = readl(®s->con); > + if (val & I2C_IPD_ALL_CLEAN) { > + dev_dbg(dev, > + "i2c_xfer: %d messages dropped due to pending > interrupts\n", > + nmsgs); > + return -EAGAIN; > + } > + }
Can you have a look how this can happen? Normally this should only happen if you have a heartbeat LED behind a I2C GPIO expander or some other unusual setup. Adding a dump_stack() next to the dev_dbg() call might give a clue. Let's see how this really happens, but generally I think we should find another solution for this, either on I2C core level or by replacing the readl_poll_timeout() with a variant that doesn't allow running in the background, i.e. one which uses is_timeout_non_interruptible() rather than is_timeout(). Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
