While working on another cleanup series, I stumbled over the fact that
some drivers print an error on I2C or SMBus related timeouts. This is
wrong because it may be an expected state. The client driver on top
knows this, so let's keep error handling on this level and remove the
prinouts from controller drivers.
Looking forward to comments,
Wolfram
Wolfram Sang (18):
i2c: at91-master: remove printout on handled timeouts
i2c: bcm-iproc: remove printout on handled timeouts
i2c: bcm2835: remove printout on handled timeouts
i2c: cadence: remove printout on handled timeouts
i2c: davinci: remove printout on handled timeouts
i2c: i801: remove printout on handled timeouts
i2c: img-scb: remove printout on handled timeouts
i2c: ismt: remove printout on handled timeouts
i2c: nomadik: remove printout on handled timeouts
i2c: omap: remove printout on handled timeouts
i2c: qcom-geni: remove printout on handled timeouts
i2c: qup: remove printout on handled timeouts
i2c: rk3x: remove printout on handled timeouts
i2c: sh_mobile: remove printout on handled timeouts
i2c: st: remove printout on handled timeouts
i2c: tegra: remove printout on handled timeouts
i2c: uniphier-f: remove printout on handled timeouts
i2c: uniphier: remove printout on handled timeouts
drivers/i2c/busses/i2c-at91-master.c | 1 -
drivers/i2c/busses/i2c-bcm-iproc.c | 2 --
drivers/i2c/busses/i2c-bcm2835.c | 1 -
drivers/i2c/busses/i2c-cadence.c | 2 --
drivers/i2c/busses/i2c-davinci.c | 1 -
drivers/i2c/busses/i2c-i801.c | 4 ++--
drivers/i2c/busses/i2c-img-scb.c | 5 +----
drivers/i2c/busses/i2c-ismt.c | 1 -
drivers/i2c/busses/i2c-nomadik.c | 7 ++-----
drivers/i2c/busses/i2c-omap.c | 1 -
drivers/i2c/busses/i2c-qcom-geni.c | 5 +----
drivers/i2c/busses/i2c-qup.c | 4 +---
drivers/i2c/busses/i2c-rk3x.c | 3 ---
drivers/i2c/busses/i2c-sh_mobile.c | 1 -
drivers/i2c/busses/i2c-st.c | 5 +----
drivers/i2c/busses/i2c-tegra.c | 2 --
drivers/i2c/busses/i2c-uniphier-f.c | 1 -
drivers/i2c/busses/i2c-uniphier.c | 4 +---
18 files changed, 9 insertions(+), 41 deletions(-)
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index e905734c26a0..133d02899c6b 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -811,8 +811,6 @@ static int bcm_iproc_i2c_xfer_wait(struct bcm_iproc_i2c_dev *iproc_i2c,
}
if (!time_left && !iproc_i2c->xfer_is_done) {
- dev_err(iproc_i2c->device, "transaction timed out\n");
-
/* flush both TX/RX FIFOs */
val = BIT(M_FIFO_RX_FLUSH_SHIFT) | BIT(M_FIFO_TX_FLUSH_SHIFT);
iproc_i2c_wr_reg(iproc_i2c, M_FIFO_CTRL_OFFSET, val);
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-bcm2835.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-bcm2835.c b/drivers/i2c/busses/i2c-bcm2835.c
index b92de1944221..3045ba82380d 100644
--- a/drivers/i2c/busses/i2c-bcm2835.c
+++ b/drivers/i2c/busses/i2c-bcm2835.c
@@ -370,7 +370,6 @@ static int bcm2835_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
if (!time_left) {
bcm2835_i2c_writel(i2c_dev, BCM2835_I2C_C,
BCM2835_I2C_C_CLEAR);
- dev_err(i2c_dev->dev, "i2c transfer timed out\n");
return -ETIMEDOUT;
}
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Turn all timeout related
printouts to debug level.
Signed-off-by: Wolfram Sang <[email protected]>
---
Here, I did not delete the printout to support checking the termination
process. The other drivers in this series do not have this SMBus
specific termination step.
drivers/i2c/busses/i2c-i801.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 4294c0c63cef..a42b5152f9bd 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -400,7 +400,7 @@ static int i801_check_post(struct i801_priv *priv, int status)
* If the SMBus is still busy, we give up
*/
if (unlikely(status < 0)) {
- dev_err(&priv->pci_dev->dev, "Transaction timeout\n");
+ dev_dbg(&priv->pci_dev->dev, "Transaction timeout\n");
/* try to stop the current command */
dev_dbg(&priv->pci_dev->dev, "Terminating the current operation\n");
outb_p(SMBHSTCNT_KILL, SMBHSTCNT(priv));
@@ -411,7 +411,7 @@ static int i801_check_post(struct i801_priv *priv, int status)
status = inb_p(SMBHSTSTS(priv));
if ((status & SMBHSTSTS_HOST_BUSY) ||
!(status & SMBHSTSTS_FAILED))
- dev_err(&priv->pci_dev->dev,
+ dev_dbg(&priv->pci_dev->dev,
"Failed terminating the transaction\n");
return -ETIMEDOUT;
}
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout and
simplify the logic a little.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-img-scb.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c
index f9d4bfef511c..e0e87185f6bb 100644
--- a/drivers/i2c/busses/i2c-img-scb.c
+++ b/drivers/i2c/busses/i2c-img-scb.c
@@ -1124,11 +1124,8 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg *msgs,
IMG_I2C_TIMEOUT);
del_timer_sync(&i2c->check_timer);
- if (time_left == 0) {
- dev_err(adap->dev.parent, "i2c transfer timed out\n");
+ if (time_left == 0)
i2c->msg_status = -ETIMEDOUT;
- break;
- }
if (i2c->msg_status)
break;
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-ismt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-ismt.c b/drivers/i2c/busses/i2c-ismt.c
index c74985d77b0e..655b5d851c48 100644
--- a/drivers/i2c/busses/i2c-ismt.c
+++ b/drivers/i2c/busses/i2c-ismt.c
@@ -623,7 +623,6 @@ static int ismt_access(struct i2c_adapter *adap, u16 addr,
dma_unmap_single(dev, dma_addr, dma_size, dma_direction);
if (unlikely(!time_left)) {
- dev_err(dev, "completion wait timed out\n");
ret = -ETIMEDOUT;
goto out;
}
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-nomadik.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 4f41a3c7824d..45c6df26fcbf 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
@@ -542,12 +542,9 @@ static int read_i2c(struct nmk_i2c_dev *priv, u16 flags)
xfer_done = nmk_i2c_wait_xfer_done(priv);
- if (!xfer_done) {
- /* Controller timed out */
- dev_err(&priv->adev->dev, "read from slave 0x%x timed out\n",
- priv->cli.slave_adr);
+ if (!xfer_done)
status = -ETIMEDOUT;
- }
+
return status;
}
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-omap.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 42165ef57946..36bebef36740 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -752,7 +752,6 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
}
if (timeout == 0) {
- dev_err(omap->dev, "controller timed out\n");
omap_i2c_reset(omap);
__omap_i2c_init(omap);
return -ETIMEDOUT;
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-rk3x.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
index 086fdf262e7b..8c7367f289d3 100644
--- a/drivers/i2c/busses/i2c-rk3x.c
+++ b/drivers/i2c/busses/i2c-rk3x.c
@@ -1106,9 +1106,6 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
spin_lock_irqsave(&i2c->lock, flags);
if (timeout == 0) {
- dev_err(i2c->dev, "timeout, ipd: 0x%02x, state: %d\n",
- i2c_readl(i2c, REG_IPD), i2c->state);
-
/* Force a STOP condition without interrupt */
i2c_writel(i2c, 0, REG_IEN);
val = i2c_readl(i2c, REG_CON) & REG_CON_TUNING_MASK;
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-sh_mobile.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mobile.c
index c65ac3d7eadc..f86c29737df1 100644
--- a/drivers/i2c/busses/i2c-sh_mobile.c
+++ b/drivers/i2c/busses/i2c-sh_mobile.c
@@ -688,7 +688,6 @@ static int sh_mobile_xfer(struct sh_mobile_i2c_data *pd,
}
if (!time_left) {
- dev_err(pd->dev, "Transfer request timed out\n");
if (pd->dma_direction != DMA_NONE)
sh_mobile_i2c_cleanup_dma(pd, true);
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-uniphier.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier.c b/drivers/i2c/busses/i2c-uniphier.c
index 854ac25b5862..e1b4c80e0285 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -71,10 +71,8 @@ static int uniphier_i2c_xfer_byte(struct i2c_adapter *adap, u32 txdata,
writel(txdata, priv->membase + UNIPHIER_I2C_DTRM);
time_left = wait_for_completion_timeout(&priv->comp, adap->timeout);
- if (unlikely(!time_left)) {
- dev_err(&adap->dev, "transaction timeout\n");
+ if (unlikely(!time_left))
return -ETIMEDOUT;
- }
rxdata = readl(priv->membase + UNIPHIER_I2C_DREC);
if (rxdatap)
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-qup.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
index 598102d16677..c9b43a3c4bd3 100644
--- a/drivers/i2c/busses/i2c-qup.c
+++ b/drivers/i2c/busses/i2c-qup.c
@@ -793,10 +793,8 @@ static int qup_i2c_bam_schedule_desc(struct qup_i2c_dev *qup)
dma_async_issue_pending(qup->brx.dma);
}
- if (!wait_for_completion_timeout(&qup->xfer, qup->xfer_timeout)) {
- dev_err(qup->dev, "normal trans timed out\n");
+ if (!wait_for_completion_timeout(&qup->xfer, qup->xfer_timeout))
ret = -ETIMEDOUT;
- }
if (ret || qup->bus_err || qup->qup_err) {
reinit_completion(&qup->xfer);
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-tegra.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 920d5a8cbf4c..85b31edc558d 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1331,7 +1331,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
dmaengine_terminate_sync(i2c_dev->dma_chan);
if (!time_left && !completion_done(&i2c_dev->dma_complete)) {
- dev_err(i2c_dev->dev, "DMA transfer timed out\n");
tegra_i2c_init(i2c_dev);
return -ETIMEDOUT;
}
@@ -1351,7 +1350,6 @@ static int tegra_i2c_xfer_msg(struct tegra_i2c_dev *i2c_dev,
tegra_i2c_mask_irq(i2c_dev, int_mask);
if (time_left == 0) {
- dev_err(i2c_dev->dev, "I2C transfer timed out\n");
tegra_i2c_init(i2c_dev);
return -ETIMEDOUT;
}
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-st.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-st.c b/drivers/i2c/busses/i2c-st.c
index ce2333408904..dbb93394ff94 100644
--- a/drivers/i2c/busses/i2c-st.c
+++ b/drivers/i2c/busses/i2c-st.c
@@ -689,11 +689,8 @@ static int st_i2c_xfer_msg(struct st_i2c_dev *i2c_dev, struct i2c_msg *msg,
i2c_dev->adap.timeout);
ret = c->result;
- if (!timeout) {
- dev_err(i2c_dev->dev, "Write to slave 0x%x timed out\n",
- c->addr);
+ if (!timeout)
ret = -ETIMEDOUT;
- }
i2c = SSC_I2C_STOPG | SSC_I2C_REPSTRTG;
st_i2c_clr_bits(i2c_dev->base + SSC_I2C, i2c);
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-qcom-geni.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index 11dcfcf13d8b..6054c62cd2ff 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -642,11 +642,8 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
dma_async_issue_pending(gi2c->tx_c);
timeout = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT);
- if (!timeout) {
- dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d addr:0x%x\n",
- gi2c->cur->flags, gi2c->cur->addr);
+ if (!timeout)
gi2c->err = -ETIMEDOUT;
- }
if (gi2c->err) {
ret = gi2c->err;
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-davinci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index 02b3b1160fb0..7ae611120cfa 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -489,7 +489,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
time_left = wait_for_completion_timeout(&dev->cmd_complete,
dev->adapter.timeout);
if (!time_left) {
- dev_err(dev->dev, "controller timed out\n");
i2c_recover_bus(adap);
dev->buf_len = 0;
return -ETIMEDOUT;
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-uniphier-f.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
index dbc91c7c3788..6c3dac2cf568 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -358,7 +358,6 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
spin_unlock_irqrestore(&priv->lock, flags);
if (!time_left) {
- dev_err(&adap->dev, "transaction timeout.\n");
uniphier_fi2c_recover(priv);
return -ETIMEDOUT;
}
--
2.43.0
I2C and SMBus timeouts are not something the user needs to be informed
about on controller level. The client driver may know if that really is
a problem and give more detailed information to the user. The controller
should just pass this information upwards. Remove the printout.
Signed-off-by: Wolfram Sang <[email protected]>
---
drivers/i2c/busses/i2c-cadence.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index 4bb7d6756947..1b0006e3b95c 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -789,8 +789,6 @@ static int cdns_i2c_process_msg(struct cdns_i2c *id, struct i2c_msg *msg,
time_left = wait_for_completion_timeout(&id->xfer_done, msg_timeout);
if (time_left == 0) {
cdns_i2c_master_reset(adap);
- dev_err(id->adap.dev.parent,
- "timeout waiting on completion\n");
return -ETIMEDOUT;
}
--
2.43.0
Hi Wolfram,
On Wed, Apr 10, 2024 at 01:24:20PM +0200, Wolfram Sang wrote:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Turn all timeout related
> printouts to debug level.
>
> Signed-off-by: Wolfram Sang <[email protected]>
> ---
>
> Here, I did not delete the printout to support checking the termination
> process. The other drivers in this series do not have this SMBus
> specific termination step.
>
> drivers/i2c/busses/i2c-i801.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index 4294c0c63cef..a42b5152f9bd 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -400,7 +400,7 @@ static int i801_check_post(struct i801_priv *priv, int status)
> * If the SMBus is still busy, we give up
> */
> if (unlikely(status < 0)) {
> - dev_err(&priv->pci_dev->dev, "Transaction timeout\n");
> + dev_dbg(&priv->pci_dev->dev, "Transaction timeout\n");
why after 5 patches of removing dev_err's, here you are changing
them to dev_dbg?
It's still good, but if we want to be strict, errors should
print errors: as we are returning -ETIMEDOUT, then we are
treating the case as an error and we should print error.
Upwards, then, we can put some more logic and decide whether
-ETIMEDOUT is a real error or not and consequently print a debug
or an error message.
As you did before, I would just remove the printout here.
I will wait a bit for more comments and take patches 1 to 5 so
that I can unburden you a little from them.
Thanks,
Andi
> /* try to stop the current command */
> dev_dbg(&priv->pci_dev->dev, "Terminating the current operation\n");
> outb_p(SMBHSTCNT_KILL, SMBHSTCNT(priv));
> @@ -411,7 +411,7 @@ static int i801_check_post(struct i801_priv *priv, int status)
> status = inb_p(SMBHSTSTS(priv));
> if ((status & SMBHSTSTS_HOST_BUSY) ||
> !(status & SMBHSTSTS_FAILED))
> - dev_err(&priv->pci_dev->dev,
> + dev_dbg(&priv->pci_dev->dev,
> "Failed terminating the transaction\n");
> return -ETIMEDOUT;
> }
> --
> 2.43.0
>
On Wed, Apr 10, 2024 at 01:24:25PM +0200, Wolfram Sang wrote:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Remove the printout.
>
> Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Regards,
Bjorn
> ---
> drivers/i2c/busses/i2c-qcom-geni.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
> index 11dcfcf13d8b..6054c62cd2ff 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -642,11 +642,8 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
> dma_async_issue_pending(gi2c->tx_c);
>
> timeout = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT);
> - if (!timeout) {
> - dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d addr:0x%x\n",
> - gi2c->cur->flags, gi2c->cur->addr);
> + if (!timeout)
> gi2c->err = -ETIMEDOUT;
> - }
>
> if (gi2c->err) {
> ret = gi2c->err;
> --
> 2.43.0
>
On Wed, Apr 10, 2024 at 01:24:26PM +0200, Wolfram Sang wrote:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Remove the printout.
>
> Signed-off-by: Wolfram Sang <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Regards,
Bjorn
> ---
> drivers/i2c/busses/i2c-qup.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-qup.c b/drivers/i2c/busses/i2c-qup.c
> index 598102d16677..c9b43a3c4bd3 100644
> --- a/drivers/i2c/busses/i2c-qup.c
> +++ b/drivers/i2c/busses/i2c-qup.c
> @@ -793,10 +793,8 @@ static int qup_i2c_bam_schedule_desc(struct qup_i2c_dev *qup)
> dma_async_issue_pending(qup->brx.dma);
> }
>
> - if (!wait_for_completion_timeout(&qup->xfer, qup->xfer_timeout)) {
> - dev_err(qup->dev, "normal trans timed out\n");
> + if (!wait_for_completion_timeout(&qup->xfer, qup->xfer_timeout))
> ret = -ETIMEDOUT;
> - }
>
> if (ret || qup->bus_err || qup->qup_err) {
> reinit_completion(&qup->xfer);
> --
> 2.43.0
>
On Wed, Apr 10, 2024 at 02:21:58PM +0200, Andi Shyti wrote:
> Hi Wolfram,
>
> On Wed, Apr 10, 2024 at 01:24:20PM +0200, Wolfram Sang wrote:
> > I2C and SMBus timeouts are not something the user needs to be informed
> > about on controller level. The client driver may know if that really is
> > a problem and give more detailed information to the user. The controller
> > should just pass this information upwards. Turn all timeout related
> > printouts to debug level.
> >
> > Signed-off-by: Wolfram Sang <[email protected]>
> > ---
> >
> > Here, I did not delete the printout to support checking the termination
> > process. The other drivers in this series do not have this SMBus
> > specific termination step.
> >
> > drivers/i2c/busses/i2c-i801.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> > index 4294c0c63cef..a42b5152f9bd 100644
> > --- a/drivers/i2c/busses/i2c-i801.c
> > +++ b/drivers/i2c/busses/i2c-i801.c
> > @@ -400,7 +400,7 @@ static int i801_check_post(struct i801_priv *priv, int status)
> > * If the SMBus is still busy, we give up
> > */
> > if (unlikely(status < 0)) {
> > - dev_err(&priv->pci_dev->dev, "Transaction timeout\n");
> > + dev_dbg(&priv->pci_dev->dev, "Transaction timeout\n");
>
> why after 5 patches of removing dev_err's, here you are changing
> them to dev_dbg?
The reasoning was explained above:
> > Here, I did not delete the printout to support checking the termination
> > process. The other drivers in this series do not have this SMBus
> > specific termination step.
This is also why I converted two calls here to dev_dbg. But read on
first.
> It's still good, but if we want to be strict, errors should
> print errors: as we are returning -ETIMEDOUT, then we are
> treating the case as an error and we should print error.
I strongly disagree. While we use an errno, we don't know if this is a
real error yet. It is more a return value saying that the transfer timed
out. The client driver knows. For some I2C clients this may be an error,
but for an EEPROM this might be an "oh, it might still be erasing a
page, let's try again after some defined delay".
Think of 'i2cdetect': If we printout something in the -ENXIO case (no
device responded to the address), the log file would have more than 100
entries on a typical I2C bus. Although we know that -ENXIO will be the
majority of cases and are fine with it.
> As you did before, I would just remove the printout here.
Maybe we could because there is still the "Terminating the current
operation" string as debug message making the code flow still clear.
> I will wait a bit for more comments and take patches 1 to 5 so
> that I can unburden you a little from them.
The patches have no dependencies. To keep mail traffic low, I suggest
you continue reviewing and I only resend the i801 patch?
Happy hacking,
Wolfram
On 4/10/24 13:24, Wolfram Sang wrote:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Remove the printout.
>
> Signed-off-by: Wolfram Sang <[email protected]>
> ---
> drivers/i2c/busses/i2c-cadence.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
> index 4bb7d6756947..1b0006e3b95c 100644
> --- a/drivers/i2c/busses/i2c-cadence.c
> +++ b/drivers/i2c/busses/i2c-cadence.c
> @@ -789,8 +789,6 @@ static int cdns_i2c_process_msg(struct cdns_i2c *id, struct i2c_msg *msg,
> time_left = wait_for_completion_timeout(&id->xfer_done, msg_timeout);
> if (time_left == 0) {
> cdns_i2c_master_reset(adap);
> - dev_err(id->adap.dev.parent,
> - "timeout waiting on completion\n");
> return -ETIMEDOUT;
> }
>
Acked-by: Michal Simek <[email protected]>
Thanks,
Michal
Hi Wolfram,
On Thu, Apr 11, 2024 at 09:02:52AM +0200, Wolfram Sang wrote:
> On Wed, Apr 10, 2024 at 02:21:58PM +0200, Andi Shyti wrote:
> > On Wed, Apr 10, 2024 at 01:24:20PM +0200, Wolfram Sang wrote:
> > > I2C and SMBus timeouts are not something the user needs to be informed
> > > about on controller level. The client driver may know if that really is
> > > a problem and give more detailed information to the user. The controller
> > > should just pass this information upwards. Turn all timeout related
> > > printouts to debug level.
> > >
> > > Signed-off-by: Wolfram Sang <[email protected]>
> > > ---
> > >
> > > Here, I did not delete the printout to support checking the termination
> > > process. The other drivers in this series do not have this SMBus
> > > specific termination step.
> > >
> > > drivers/i2c/busses/i2c-i801.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> > > index 4294c0c63cef..a42b5152f9bd 100644
> > > --- a/drivers/i2c/busses/i2c-i801.c
> > > +++ b/drivers/i2c/busses/i2c-i801.c
> > > @@ -400,7 +400,7 @@ static int i801_check_post(struct i801_priv *priv, int status)
> > > * If the SMBus is still busy, we give up
> > > */
> > > if (unlikely(status < 0)) {
> > > - dev_err(&priv->pci_dev->dev, "Transaction timeout\n");
> > > + dev_dbg(&priv->pci_dev->dev, "Transaction timeout\n");
> >
> > why after 5 patches of removing dev_err's, here you are changing
> > them to dev_dbg?
>
> The reasoning was explained above:
>
> > > Here, I did not delete the printout to support checking the termination
> > > process. The other drivers in this series do not have this SMBus
> > > specific termination step.
>
> This is also why I converted two calls here to dev_dbg. But read on
> first.
It would make sense if the debug would give some more
information...
> > It's still good, but if we want to be strict, errors should
> > print errors: as we are returning -ETIMEDOUT, then we are
> > treating the case as an error and we should print error.
>
> I strongly disagree. While we use an errno, we don't know if this is a
> real error yet. It is more a return value saying that the transfer timed
> out. The client driver knows. For some I2C clients this may be an error,
> but for an EEPROM this might be an "oh, it might still be erasing a
> page, let's try again after some defined delay".
>
> Think of 'i2cdetect': If we printout something in the -ENXIO case (no
> device responded to the address), the log file would have more than 100
> entries on a typical I2C bus. Although we know that -ENXIO will be the
> majority of cases and are fine with it.
>
> > As you did before, I would just remove the printout here.
>
> Maybe we could because there is still the "Terminating the current
> operation" string as debug message making the code flow still clear.
.. e.g. for me it's not totally right if we do:
dev_dbg("timed out")
return -ETIMEDOUT;
Considering that this might not be a real error I would let the
calling function decide and print. Indeed i801_access() is not
even checking the error but letting the caller of smbus_xfer()
decide.
It would make more sense if we provide more information like:
dev_dbg("Terminating current operation because the bus is busy and we timed out");
Just merged the two consecutive messages (we could still trim it
a bit and reduce dmesg spam).
The second /dev_err/dev_dbg/ in this file to me is fine (even
though it's not really self explaining).
> > I will wait a bit for more comments and take patches 1 to 5 so
> > that I can unburden you a little from them.
>
> The patches have no dependencies. To keep mail traffic low, I suggest
> you continue reviewing and I only resend the i801 patch?
Yeah... I'll wait a few more days and give more time for reviews
and comments. I checked the rest of the series and it's fine.
If you are willing to send a V2 you could send it as reply to
this mail instead of resending everything.
Thanks,
Andi
Am Mittwoch, 10. April 2024, 13:24:27 CEST schrieb Wolfram Sang:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Remove the printout.
>
> Signed-off-by: Wolfram Sang <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c b/drivers/i2c/busses/i2c-rk3x.c
> index 086fdf262e7b..8c7367f289d3 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1106,9 +1106,6 @@ static int rk3x_i2c_xfer_common(struct i2c_adapter *adap,
> spin_lock_irqsave(&i2c->lock, flags);
>
> if (timeout == 0) {
> - dev_err(i2c->dev, "timeout, ipd: 0x%02x, state: %d\n",
> - i2c_readl(i2c, REG_IPD), i2c->state);
> -
> /* Force a STOP condition without interrupt */
> i2c_writel(i2c, 0, REG_IEN);
> val = i2c_readl(i2c, REG_CON) & REG_CON_TUNING_MASK;
>
On Wed, Apr 10, 2024 at 1:25 PM Wolfram Sang
<[email protected]> wrote:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Remove the printout.
>
> Signed-off-by: Wolfram Sang <[email protected]>
Thanks Wolfram,
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
Hello Wolfram,
On 2024-04-10 13:24, Wolfram Sang wrote:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The
> controller
> should just pass this information upwards. Remove the printout.
Maybe it would be good to turn it into a debug message, instead of
simply removing it? Maybe not all client drivers handle it correctly,
in which case having an easy way for debugging would be beneficial.
> Signed-off-by: Wolfram Sang <[email protected]>
> ---
> drivers/i2c/busses/i2c-rk3x.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-rk3x.c
> b/drivers/i2c/busses/i2c-rk3x.c
> index 086fdf262e7b..8c7367f289d3 100644
> --- a/drivers/i2c/busses/i2c-rk3x.c
> +++ b/drivers/i2c/busses/i2c-rk3x.c
> @@ -1106,9 +1106,6 @@ static int rk3x_i2c_xfer_common(struct
> i2c_adapter *adap,
> spin_lock_irqsave(&i2c->lock, flags);
>
> if (timeout == 0) {
> - dev_err(i2c->dev, "timeout, ipd: 0x%02x, state: %d\n",
> - i2c_readl(i2c, REG_IPD), i2c->state);
> -
> /* Force a STOP condition without interrupt */
> i2c_writel(i2c, 0, REG_IEN);
> val = i2c_readl(i2c, REG_CON) & REG_CON_TUNING_MASK;
> Maybe it would be good to turn it into a debug message, instead of
> simply removing it? Maybe not all client drivers handle it correctly,
> in which case having an easy way for debugging would be beneficial.
Hmm, but it still returns -ETIMEDOUT to distinguish cases?
On 2024-04-13 08:38, Wolfram Sang wrote:
>> Maybe it would be good to turn it into a debug message, instead of
>> simply removing it? Maybe not all client drivers handle it correctly,
>> in which case having an easy way for debugging would be beneficial.
>
> Hmm, but it still returns -ETIMEDOUT to distinguish cases?
Sure, but I think that having such an additional debug facility
can only help and save the people from adding temporary printk()s
while debugging.
Hi Dragan,
> Sure, but I think that having such an additional debug facility
> can only help and save the people from adding temporary printk()s
> while debugging.
Mileages, I guess. I like temporary printouts for temporary debug
sessions. This way the upstream source code stays slim. In my experience
with I2C over the years, debugging happens with developers anyhow.
Logfiles from users which help developers create patches are very rare.
And those users are usually capable enough to add debug patches.
Given these experiences (which may be different in other subsystems), I
don't see why we should carry the bloat.
That said, I'll leave the final decision to the driver maintainers.
Happy hacking,
Wolfram
Am Samstag, 13. April 2024, 08:44:41 CEST schrieb Dragan Simic:
> On 2024-04-13 08:38, Wolfram Sang wrote:
> >> Maybe it would be good to turn it into a debug message, instead of
> >> simply removing it? Maybe not all client drivers handle it correctly,
> >> in which case having an easy way for debugging would be beneficial.
> >
> > Hmm, but it still returns -ETIMEDOUT to distinguish cases?
>
> Sure, but I think that having such an additional debug facility
> can only help and save the people from adding temporary printk()s
> while debugging.
Also we're talking about two lines of code, I wouldn't call that bloat ;-)
I was thinking about dev_dbg vs. removal too, but hadn't a clear
favorite.
So essentially Dragan is tipping the scale and I guess dev_dbg might be
the nicer way to go.
Heiko
Hello Wolfram,
On 2024-04-13 09:10, Wolfram Sang wrote:
> Hi Dragan,
>
>> Sure, but I think that having such an additional debug facility
>> can only help and save the people from adding temporary printk()s
>> while debugging.
>
> Mileages, I guess. I like temporary printouts for temporary debug
> sessions. This way the upstream source code stays slim. In my
> experience
> with I2C over the years, debugging happens with developers anyhow.
> Logfiles from users which help developers create patches are very rare.
> And those users are usually capable enough to add debug patches.
> Given these experiences (which may be different in other subsystems), I
> don't see why we should carry the bloat.
Yup, adding some printk()s while debugging is pretty much inevitable,
and having full debugging available would add a lot of code, regardless
of the subsystem.
> That said, I'll leave the final decision to the driver maintainers.
Agreed.
Hello Heiko,
On 2024-04-13 09:58, Heiko Stübner wrote:
> Am Samstag, 13. April 2024, 08:44:41 CEST schrieb Dragan Simic:
>> On 2024-04-13 08:38, Wolfram Sang wrote:
>> >> Maybe it would be good to turn it into a debug message, instead of
>> >> simply removing it? Maybe not all client drivers handle it correctly,
>> >> in which case having an easy way for debugging would be beneficial.
>> >
>> > Hmm, but it still returns -ETIMEDOUT to distinguish cases?
>>
>> Sure, but I think that having such an additional debug facility
>> can only help and save the people from adding temporary printk()s
>> while debugging.
>
> Also we're talking about two lines of code, I wouldn't call that bloat
> ;-)
> I was thinking about dev_dbg vs. removal too, but hadn't a clear
> favorite.
>
> So essentially Dragan is tipping the scale and I guess dev_dbg might be
> the nicer way to go.
Yes, the code for printing the message is already there and it's only
a couple of lines, so it might be a good idea to recycle it. :)
> Also we're talking about two lines of code, I wouldn't call that bloat ;-)
With this patch, yes. But once you allow debug code, it is hard to draw
a line which debug is still okay and which is too fine-grained. And then
you end up with a lot. Over the years, I developed the tendency to try
to have less but meaningful error printouts. But I don't enforce it
strictly because it is too much bike-shedding discussion.
In case of this error printout here, it is just wrong. But, see, it also
came from this tendency I don't like to have printouts for every error.
Hi,
On Sat, Apr 13, 2024 at 04:35:06PM +0200, Wolfram Sang wrote:
> > Also we're talking about two lines of code, I wouldn't call that bloat ;-)
>
> With this patch, yes. But once you allow debug code, it is hard to draw
> a line which debug is still okay and which is too fine-grained. And then
> you end up with a lot. Over the years, I developed the tendency to try
> to have less but meaningful error printouts. But I don't enforce it
> strictly because it is too much bike-shedding discussion.
>
> In case of this error printout here, it is just wrong. But, see, it also
> came from this tendency I don't like to have printouts for every error.
I agree with Wolfram here. Debug messages are OK if they are
providing real useful information to a final product.
Besides, as I explained earlier, the patter:
dev_dbg("timed out")
return -ETIMEDOUT;
(print a debug but return error) doesn't make much sense.
But, I this is all personal preference. So that I can also leave
it to the specific maintainer.
From my side all patches in this series are r-b'ed, except for
patch 6 where there are 3 dev_dbg in a row stating the same
thing.
Thanks Dragan and Heiko for your feedback.
Andi
Hi Wolfram,
On Wed, Apr 10, 2024 at 01:24:14PM +0200, Wolfram Sang wrote:
> While working on another cleanup series, I stumbled over the fact that
> some drivers print an error on I2C or SMBus related timeouts. This is
> wrong because it may be an expected state. The client driver on top
> knows this, so let's keep error handling on this level and remove the
> prinouts from controller drivers.
>
> Looking forward to comments,
>
> Wolfram
Applyed everything but patch 6 in i2c/i2c-host on
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux.git
Thank you,
Andi
Patches applied
===============
[01/18] i2c: at91-master: remove printout on handled timeouts
commit: 74cce8ed33aeac91f397d642901c94520e574f8b
[02/18] i2c: bcm-iproc: remove printout on handled timeouts
commit: 9f98914320f3e332487042aa73bbbfacc1dc9896
[03/18] i2c: bcm2835: remove printout on handled timeouts
commit: ab17612ffb60bf07e4268448e022576d42833bf7
[04/18] i2c: cadence: remove printout on handled timeouts
commit: 7aaff22d3e939c5187512188d7e27eb5e93ae41e
[05/18] i2c: davinci: remove printout on handled timeouts
commit: dc72daa5cdf1c6ffebaef0c6df1f4cdeb15cadd6
[07/18] i2c: img-scb: remove printout on handled timeouts
commit: 3e720ba5e30d6dd1b22e0f8a23f1697d438092b8
[08/18] i2c: ismt: remove printout on handled timeouts
commit: 800a297370161bda70a34cb00eb0fa2f0345b75f
[09/18] i2c: nomadik: remove printout on handled timeouts
commit: 26fbd3025cbce49cb3dd71f3a10239f69546b3c2
[10/18] i2c: omap: remove printout on handled timeouts
commit: d3f24197d8125b2bf75162ec5cc270fd68f894f4
[11/18] i2c: qcom-geni: remove printout on handled timeouts
commit: 4677d9f5c98f1c2825de142de5df08621ea340b3
[12/18] i2c: qup: remove printout on handled timeouts
commit: e28ec7512496848e8a340889c512a0167949dc8f
[13/18] i2c: rk3x: remove printout on handled timeouts
commit: 1cf7a7b3c944f727f34453a132b8899685e32f81
[14/18] i2c: sh_mobile: remove printout on handled timeouts
commit: 31fb960bf8a424c47a5bf4568685e058c9d6f24d
[15/18] i2c: st: remove printout on handled timeouts
commit: bff862e67260f779b2188e4b39c1a9f9989532ee
[16/18] i2c: tegra: remove printout on handled timeouts
commit: 5ea641d9ea5ee1b3536f8b75e658e3bf2c2a548e
[17/18] i2c: uniphier-f: remove printout on handled timeouts
commit: c31bc8e162890cda38d045e73ff0004119ab28e7
[18/18] i2c: uniphier: remove printout on handled timeouts
commit: 507a2da9539cdb839a1a2e57bfcca644bcfe0f03
Wed, Apr 10, 2024 at 01:24:14PM +0200, Wolfram Sang kirjoitti:
> While working on another cleanup series, I stumbled over the fact that
> some drivers print an error on I2C or SMBus related timeouts. This is
> wrong because it may be an expected state. The client driver on top
> knows this, so let's keep error handling on this level and remove the
> prinouts from controller drivers.
>
> Looking forward to comments,
I do not see an equivalent change in I?C core.
IIRC in our case (DW or i801 or iSMT) we often have this message as the only
one that points to the issues (on non-debug level), it will be much harder to
debug for our customers with this going away.
--
With Best Regards,
Andy Shevchenko
Wed, Apr 10, 2024 at 01:24:20PM +0200, Wolfram Sang kirjoitti:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Turn all timeout related
> printouts to debug level.
As I mentioned in reply to cover letter this change does not seem to me right.
If you provide an equivalent dev_err() in the core, I'll be totally fine with
it.
--
With Best Regards,
Andy Shevchenko
Wed, Apr 10, 2024 at 01:24:22PM +0200, Wolfram Sang kirjoitti:
> I2C and SMBus timeouts are not something the user needs to be informed
> about on controller level. The client driver may know if that really is
> a problem and give more detailed information to the user. The controller
> should just pass this information upwards. Remove the printout.
Neither this.
--
With Best Regards,
Andy Shevchenko
Hi Andy,
On Wed, Apr 24, 2024 at 03:08:14AM +0300, Andy Shevchenko wrote:
> Wed, Apr 10, 2024 at 01:24:14PM +0200, Wolfram Sang kirjoitti:
> > While working on another cleanup series, I stumbled over the fact that
> > some drivers print an error on I2C or SMBus related timeouts. This is
> > wrong because it may be an expected state. The client driver on top
> > knows this, so let's keep error handling on this level and remove the
> > prinouts from controller drivers.
> >
> > Looking forward to comments,
>
> I do not see an equivalent change in I²C core.
There shouldn't be. The core neither knows if it is okay or not. The
client driver knows.
> IIRC in our case (DW or i801 or iSMT) we often have this message as the only
Often? How often?
> one that points to the issues (on non-debug level), it will be much harder to
> debug for our customers with this going away.
The proper fix is to print the error in the client driver. Maybe this
needs a helper for client drivers which they can use like:
i2c_report_error(client, retval, flags);
The other thing which is also more helpful IMO is that we have
trace_events for __i2c_transfer. There, you can see what was happening
on the bus before the timeout. It can easily be that, if device X
times out, it was because of the transfer before to device Y which locks
up the bus. A simple "Bus timed out" message will not help you a lot
there.
And, keep in mind the false positives I mentioned in the coverletter.
All the best,
Wolfram
On Wed, Apr 24, 2024 at 12:00 PM Wolfram Sang
<[email protected]> wrote:
> On Wed, Apr 24, 2024 at 03:08:14AM +0300, Andy Shevchenko wrote:
> > Wed, Apr 10, 2024 at 01:24:14PM +0200, Wolfram Sang kirjoitti:
> > > While working on another cleanup series, I stumbled over the fact that
> > > some drivers print an error on I2C or SMBus related timeouts. This is
> > > wrong because it may be an expected state. The client driver on top
> > > knows this, so let's keep error handling on this level and remove the
> > > prinouts from controller drivers.
> > >
> > > Looking forward to comments,
> >
> > I do not see an equivalent change in I²C core.
>
> There shouldn't be. The core neither knows if it is okay or not. The
> client driver knows.
>
> > IIRC in our case (DW or i801 or iSMT) we often have this message as the only
>
> Often? How often?
Once in a couple of months I assume. Last time it was a few weeks ago
that there was a report and they pointed to this very message which
was helpful.
> > one that points to the issues (on non-debug level), it will be much harder to
> > debug for our customers with this going away.
>
> The proper fix is to print the error in the client driver. Maybe this
> needs a helper for client drivers which they can use like:
>
> i2c_report_error(client, retval, flags);
>
> The other thing which is also more helpful IMO is that we have
> trace_events for __i2c_transfer. There, you can see what was happening
> on the bus before the timeout. It can easily be that, if device X
> times out, it was because of the transfer before to device Y which locks
> up the bus. A simple "Bus timed out" message will not help you a lot
> there.
The trace events are good to have, not sure if production kernels have
them enabled, though.
> And, keep in mind the false positives I mentioned in the coverletter.
--
With Best Regards,
Andy Shevchenko
On Wed, Apr 24, 2024 at 3:41 PM Andy Shevchenko
<[email protected]> wrote:
> On Wed, Apr 24, 2024 at 12:00 PM Wolfram Sang
> <[email protected]> wrote:
> > On Wed, Apr 24, 2024 at 03:08:14AM +0300, Andy Shevchenko wrote:
> > > Wed, Apr 10, 2024 at 01:24:14PM +0200, Wolfram Sang kirjoitti:
> > > > While working on another cleanup series, I stumbled over the fact that
> > > > some drivers print an error on I2C or SMBus related timeouts. This is
> > > > wrong because it may be an expected state. The client driver on top
> > > > knows this, so let's keep error handling on this level and remove the
> > > > prinouts from controller drivers.
> > > >
> > > > Looking forward to comments,
> > >
> > > I do not see an equivalent change in I²C core.
> >
> > There shouldn't be. The core neither knows if it is okay or not. The
> > client driver knows.
> >
> > > IIRC in our case (DW or i801 or iSMT) we often have this message as the only
> >
> > Often? How often?
>
> Once in a couple of months I assume. Last time it was a few weeks ago
> that there was a report and they pointed to this very message which
> was helpful.
>
> > > one that points to the issues (on non-debug level), it will be much harder to
> > > debug for our customers with this going away.
> >
> > The proper fix is to print the error in the client driver. Maybe this
> > needs a helper for client drivers which they can use like:
> >
> > i2c_report_error(client, retval, flags);
> >
> > The other thing which is also more helpful IMO is that we have
> > trace_events for __i2c_transfer. There, you can see what was happening
> > on the bus before the timeout. It can easily be that, if device X
> > times out, it was because of the transfer before to device Y which locks
> > up the bus. A simple "Bus timed out" message will not help you a lot
> > there.
>
> The trace events are good to have, not sure if production kernels have
> them enabled, though.
Ah, and to accent on the usefulness of the message that happens before
one thinks about enabling trace events. How usual is that we _expect_
something to fail? Deeper debugging usually happens after we have
noticed the issue. I'm not sure if there is an equivalent to signal
about a problem without expecting it to happen. Is that -ETIMEDOUT
being converted to some message somewhere?
> > And, keep in mind the false positives I mentioned in the coverletter.
--
With Best Regards,
Andy Shevchenko
> about a problem without expecting it to happen. Is that -ETIMEDOUT
> being converted to some message somewhere?
As said initially, the place for that is the client driver, I'd say.