The I2C timeout error message doesn't tell us what exactly failed and some
I2C client drivers do not clarify the error either. Adding WARN_ON_ONCE()
results in a stacktrace being dumped into KMSG, which is very useful for
debugging purposes.
Signed-off-by: Dmitry Osipenko <[email protected]>
---
drivers/i2c/busses/i2c-tegra.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index cbc2ad49043e..b2bb19e05248 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1245,7 +1245,7 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
tegra_i2c_mask_irq(i2c_dev, int_mask);
- if (time_left == 0) {
+ if (WARN_ON_ONCE(time_left == 0)) {
dev_err(i2c_dev->dev, "i2c transfer timed out\n");
tegra_i2c_init(i2c_dev, true);
return -ETIMEDOUT;
--
2.25.1
On Mon, Mar 02, 2020 at 08:35:12PM +0300, Dmitry Osipenko wrote:
> The I2C timeout error message doesn't tell us what exactly failed and some
> I2C client drivers do not clarify the error either. Adding WARN_ON_ONCE()
> results in a stacktrace being dumped into KMSG, which is very useful for
> debugging purposes.
This is good for debugging, in deed, yet not good in the generic case.
Timeouts are not an exception on the I2C bus (think of an EEPROM which
is busy during an erase cycle), so it shouldn't be printed at all.
This prinout should rather be dropped or at least be dev_dbg.
10.03.2020 14:37, Wolfram Sang пишет:
> On Mon, Mar 02, 2020 at 08:35:12PM +0300, Dmitry Osipenko wrote:
>> The I2C timeout error message doesn't tell us what exactly failed and some
>> I2C client drivers do not clarify the error either. Adding WARN_ON_ONCE()
>> results in a stacktrace being dumped into KMSG, which is very useful for
>> debugging purposes.
>
> This is good for debugging, in deed, yet not good in the generic case.
> Timeouts are not an exception on the I2C bus (think of an EEPROM which
> is busy during an erase cycle), so it shouldn't be printed at all.
>
> This prinout should rather be dropped or at least be dev_dbg.
Oh, well. I'll keep this debugging applied locally then, it's quite
unfortunate when something fails silently :)
> Oh, well. I'll keep this debugging applied locally then, it's quite
> unfortunate when something fails silently :)
I understand. Still, it depends on the I2C client driver to flag it. For
some devices, this is an error. For some, just one possible state.