Re: [PATCH v4 0/3] hw/i2c: smbus: Reset fixes

[Philippe Mathieu-Daudé]

Hi Joe,

On 20/2/24 22:11, Joe Komlodi wrote:
> Changelog:
> This series adds some resets for SMBus and for the I2C core. Along with
> it, we make SMBus slave error printing a little more helpful.
>
> These reset issues were very infrequent, they would maybe occur in 1 out
> of hundreds of resets in our testing, but the way they happen is pretty
> straightforward.
>
> Basically as long as a reset happens in the middle of a transaction, the
> state of the old transaction would still partially be there after the
> reset. Once a new transaction comes in, the partial stale state can
> cause the new transaction to incorrectly fail.
Sorry for jumping late, at v4. I'm a bit confused by this series.

- AFAICT there is no in-band or RESET line with I2C, but
  the AN10216 document mentions:

  I2C Bus recovery

  • Typical case is when masters fails when doing a read
    operation in a slave
  • SDA line is then non usable anymore because of the
    “Slave-Transmitter” mode.
  • Methods to recover the SDA line are:
    – Reset the slave device (assuming the device has a
      Reset pin)
    – Use a bus recovery sequence to leave the “Slave-
      Transmitter” mode
  • Bus recovery sequence is done as following:
    1 - Send 9 clock pulses on SCL line
    2 - Ask the master to keep SDA High until the “Slave-
        Transmitter” releases the SDA line to perform the
        ACK operation
    3 - Keeping SDA High during the ACK means that the
        “Master-Receiver” does not acknowledge the previous
        byte receive
    4 - The “Slave-Transmitter” then goes in an idle state
    5 - The master then sends a STOP command initializing
        completely the bus

- For SMBus Specification Version 2.0:

  3.1.4.2 Power-on reset

  SMBus devices detect a power-on event in one of three ways:
  • By detecting that power is being applied to the device,
  • By an external reset signal that is being asserted or
  • For self-powered or always powered devices, by detecting
    that the SMBus is active (clock and data lines have gone
    high after being low for more than 2 1/2 seconds).

Questions:

- Is the first patch "hw/i2c: core: Add reset" really for
  I2C? Otherwise we could expand smbus form i2cbus, and have
  this reset only for smbus.

- Should we model the "I2C bus recovery sequence" before
  triggering reset?

- Shouldn't we model the smbus 2.5s timeout before triggering
  the reset?

Thanks,

Phil.