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: > > > 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
Attachment:
signature.asc
Description: PGP signature
