Re: [PATCHv2] i2c-mpc: Correct I2C reset procedure

[Joakim Tjernlund <Joakim.Tjernlund@infinera.com>]

On Wed, 2017-06-21 at 23:59 +0200, Wolfram Sang wrote:
> > Toggling 9x even means you could then write something somewhere
> > which in case of a PMIC can be really dangerous.
> 
> I am partly wrong here because you send a START beforehand. And devices
> are required to reset their state machine when they detect a START (I2C
> Specs 3.1.10, Note 4). So, it *shouldn't* be dangerous. If all devices
> follow that rule, that is...
> 
> However, you can only send START when SDA is not stuck. And still, this
> whole toggling is to reanimate a stuck SDA. So, it still looks to me
> that it doesn't make sense to have START & STOP around the toggling and
> rather have a single STOP before you try toggling.
> 
> Makes sense?

STOP must be last so the bus is released, this was one of the problems the patch fixed as
next transfer would find the bus busy and the went into fixup again.

In general you cannot known if the slave stuck in somewhere in READ/WRITE or
some other state. Stuck is probably the wrong word here, not in sync is a better description.

If you are afraid the slave won't see the the STARTs why would it see any STOPs?
Take this case:
> So, for the write case, I'd think a single STOP before toggling should
> do. Toggling 9x even means you could then write something somewhere
> which in case of a PMIC can be really dangerous.
Why would a STOP do anything here? The device is not listening until you get to
end of the byte where it will listen to NACK, STOP or START. 

The best way to get the slaves attention is the send the 9 clocks with a START,
if possible, in each clock. That will get the slaves attention and place the slave
in START state, then you finish with a STOP so all devices, including any masters, 
sees that the bus is free.

   Jocke