FAILED: patch "[PATCH] i2c: xiic: Try re-initialization on bus busy timeout" failed to apply to 5.10-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x 1d4a1adbed2582444aaf97671858b7d12915bd05
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024100218-unlovable-upon-1c43@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
1d4a1adbed25 ("i2c: xiic: Try re-initialization on bus busy timeout") ee1691d0ae10 ("i2c: xiic: improve error message when transfer fails to start") d663d93bb47e ("i2c: xiic: xiic_xfer(): Fix runtime PM leak on error path") 294b29f15469 ("i2c: xiic: Fix RX IRQ busy check")c119e7d00c91 ("i2c: xiic: Fix broken locking on tx_msg")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 1d4a1adbed2582444aaf97671858b7d12915bd05 Mon Sep 17 00:00:00 2001
From: Robert Hancock <[email protected]>
Date: Wed, 11 Sep 2024 22:16:53 +0200
Subject: [PATCH] i2c: xiic: Try re-initialization on bus busy timeout
In the event that the I2C bus was powered down when the I2C controller driver loads, or some spurious pulses occur on the I2C bus, it's possible that the controller detects a spurious I2C "start" condition. In this situation it may continue to report the bus is busy indefinitely and block the controller from working.
The "single-master" DT flag can be specified to disable bus busy checks entirely, but this may not be safe to use in situations where other I2C masters may potentially exist.
In the event that the controller reports "bus busy" for too long when starting a transaction, we can try reinitializing the controller to see if the busy condition clears. This allows recovering from this scenario.
drivers/i2c/busses/i2c-xiic.c +26 -15
@@ -843,23 +843,11 @@ static int xiic_bus_busy(struct xiic_i2c *i2c)return (sr &XIIC_SR_BUS_BUSY_MASK ) ? -EBUSY :0 ; } -static int xiic_busy (struct xiic_i2c *i2c) +static int xiic_wait_not_busy (struct xiic_i2c *i2c) {int tries =3 ;int err; -if (i2c->tx_msg || i2c->rx_msg) -return -EBUSY ; - -/* In single master mode bus can only be busy, when in use by this -* driver. If the register indicates bus being busy for some reason we -* should ignore it, since bus will never be released and i2c will be -* stuck forever. -*/ -if (i2c->singlemaster) { -return 0 ; - } -/* for instance if previous transfer was terminated due to TX error * it might be that the bus is on it's way to become available * give it at most 3 ms to wake
@@ -1103,13 +1091,36 @@ static int xiic_start_xfer(struct xiic_i2c *i2c, struct i2c_msg *msgs, int num)mutex_lock (&i2c->lock); - ret =xiic_busy (i2c); -if (ret) { +if (i2c->tx_msg || i2c->rx_msg) {dev_err (i2c->adap.dev.parent,"cannot start a transfer while busy\n" ); + ret = -EBUSY ; goto out; } +/* In single master mode bus can only be busy, when in use by this +* driver. If the register indicates bus being busy for some reason we +* should ignore it, since bus will never be released and i2c will be +* stuck forever. +*/ +if (!i2c->singlemaster) { + ret =xiic_wait_not_busy (i2c); +if (ret) { +/* If the bus is stuck in a busy state, such as due to spurious low +* pulses on the bus causing a false start condition to be detected, +* then try to recover by re-initializing the controller and check +* again if the bus is still busy. +*/ +dev_warn (i2c->adap.dev.parent,"I2C bus busy timeout, reinitializing\n" ); + ret =xiic_reinit (i2c); +if (ret) + goto out; + ret =xiic_wait_not_busy (i2c); +if (ret) + goto out; + } + } + i2c->tx_msg = msgs; i2c->rx_msg =NULL ; i2c->nmsgs = num;