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 <gerald.loacker@xxxxxxxxxxxxxx>
> ---
> 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 |
