Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Improper downgrade of legitimate I2C timeout error to debug, masking a severe delay bug --
commit d09d3a7f57c0692be5183e8fc8dc35c1ad33aa93 Author: Dmitry Guzman <[email protected]> i2c: nomadik: change print level for fault messages to debug i2c-nomadik driver prints error message on every faulted message. This is not a good practice, because in I2C a fault not always is an error, sometimes it is the expected result. > diff --git a/drivers/i2c/busses/i2c-nomadik.c > b/drivers/i2c/busses/i2c-nomadik.c > index a3cef4b66190a..9c7658148bd45 100644 > --- a/drivers/i2c/busses/i2c-nomadik.c > +++ b/drivers/i2c/busses/i2c-nomadik.c > @@ -627,7 +627,7 @@ static int write_i2c(struct nmk_i2c_dev *priv, u16 flags) > > if (!xfer_done) { > /* Controller timed out */ > - dev_err(&priv->adev->dev, "write to slave 0x%x timed out\n", > + dev_dbg(&priv->adev->dev, "write to slave 0x%x timed out\n", [Severity: Medium] Does this change mask a severe delay bug? If i2cdetect is printing this timeout message for every probed address as noted in the commit message, doesn't it mean nmk_i2c_wait_xfer_done() called by write_i2c() is genuinely exhausting its waitqueue timeout for each missing device? When i2cdetect probes empty addresses, the controller appears to be nacking the transfer but failing to fire the expected error interrupt. This would result in i2cdetect stalling for the full timeout duration on every missing address (e.g., around a 24 seconds total delay for the bus scan). Could this underlying driver or hardware flaw with missing interrupts be fixed rather than suppressing the timeout warning? > priv->cli.slave_adr); > status = -ETIMEDOUT; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=5
