On Thu, Jun 22, 2017 at 08:40:25AM +0000, Joakim Tjernlund wrote:

On Wed, 2017-06-21 at 23:59 +0200, Wolfram Sang wrote:

quoted

quoted

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.

Yes, agreed. STOP must be last.

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.

I think those are two different issues. The bus can be stuck, namely
when SCL or SDA is stuck low. We can't do anything about SCL other than
HW reset, but for SDA we can try the toggling. For the device not in
sync, I wonder how you detect this on bus driver level? If SCL and SDA
are high, the device may still be out-of-sync but the bus will look free
to the master. Or?

If you are afraid the slave won't see the the STARTs why would it see
any STOPs?

Sure, it won't. I can't recall I was afraid of that. Maybe I was not
clear what procedure I was proposing:

1) bus is in unkown condition -> send STOP
	a) good case: bus free, all devices wait for START again
	b) bad case: SDA stuck low, you can't send STOP

2) SDA is stuck low -> toggle SCL up to 9 times
	a) good case: SDA is released again, send STOP
	b) bad case: no SDA release, HW reset needed

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. 

And this is a key question, I think: A device should listen to STOP or
START always (Specs 3.1.10 Note 4). Do you really have a device that
doesn't follow this?

Don't get me wrong: I know that there always can be devices out there
which do not follow the spec. I'd really love to know if you have one.
I'd even like to buy one for testing.

But it might be an option to consider this device simply broken. If the
solution for this device might mean that other devices get a write to a
random location, then there is simply more risk than gain.

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.

Even if I consider there are devices which do not react to START/STOP in
the middle of a byte and need it to be fully transferred, I still can't
see what a START gains you here. Because it won't react as we just said.
After an additional cycle (up to 9 of them), it might react to a STOP
then. That I see. And I think I agree of sending a STOP after each of
these up to 9 cycles. But I wonder about the start. Note also, that
START + STOP (void message) is considered illegal in the standard (Specs
3.1.10 Note 5), although most devices will likely handle it.

That's how it looks to me currently. Did I miss something?

Regards,

   Wolfram