[PATCH v2 0/2] Xilinx I2C driver fixes

[Robert Hancock]

On Thu, 2023-11-23 at 11:23 +0530, Shubhrajyoti Datta wrote:
> CAUTION: This email originated from outside of the organization. Do
> not click links or open attachments unless you recognize the sender
> and know the content is safe.
> 
> On Tue, Nov 21, 2023 at 11:42 PM Robert Hancock
> <robert.hancock at calian.com> wrote:
> > 
> > A couple of fixes for the Xilinx I2C driver.
> 
> Thanks for the fix is there a way i can reproduce the issue reported
> here.

For the missed TX NAK problem, we were seeing that with a Xilinx MPSoC
PL I2C controller and an Infineon IRPS5401 PMIC, using the irps5401
kernel driver. However in this application the PMIC is located on a
separate board and the I2C communication is over a cable using TI
P82B96DR cable extender devices. In some cases when the driver would
try to read a register that's not supported by the device during
probing, the device would NAK a register address write but the
controller would go ahead with reading the value anyway. This caused
the PMIC to flag a "CML" fault which the driver initialization falsely
interpreted as meaning a subsequent register read was unsupported. The
visible symptom was that some of the configured min/max thresholds on
the PMIC would randomly be missing from the output of the "sensors"
command.

We haven't seen similar symptoms on more typical setups with the FPGA
and PMIC on the same board. It's possible that the presence of the
cable drivers changes the I2C timing sufficiently to make the issue
manifest. I think the root issue is that the behavior of the IP isn't
really documented/defined in the case where a write command receives a
NAK but additional dynamic start/stop commands have already been queued
in the TX FIFO, so it is better to avoid that case.

For the second issue with the bus busy timeout, it can be likely
reproduced by manually pulling the SDA and SCL lines on the I2C bus to
ground and then initiating a request. Depending on the order in which
this is done, the controller can see a "start" operation with no "stop"
which causes it to think the bus is busy even though SDA and SCL lines
are currently high.

> 
> > 
> > Changed since v1:
> > -Fixed an issue in first patch where an additional message could
> > still have
> > been written to the TX FIFO without waiting for it to empty.
> > 
> > Robert Hancock (2):
> >   i2c: xiic: Wait for TX empty to avoid missed TX NAKs
> >   i2c: xiic: Try re-initialization on bus busy timeout
> > 
> >  drivers/i2c/busses/i2c-xiic.c | 61 +++++++++++++++++++++----------
> > ----
> >  1 file changed, 36 insertions(+), 25 deletions(-)
> > 
> > --
> > 2.42.0
> > 
> >