Ben Dooks said the following:

On Thu, Dec 03, 2009 at 04:09:57PM +0100, Michael Lawnick wrote:

quoted

Ben Dooks said the following:

quoted

On Tue, May 26, 2009 at 01:30:21PM +0200, Esben Haabendal wrote:

quoted

On Tue, May 19, 2009 at 7:22 AM, Esben Haabendal [off-list ref] wrote:

quoted

This fixes MAL (arbitration lost) bug caused by illegal use of
RSTA (repeated START) after STOP condition generated after last byte
of reads. With this patch, it is possible to do an i2c_transfer() with
additional i2c_msg's following the I2C_M_RD messages.

It still needs to be resolved if it is possible to fix this issue
by removing the STOP condition after reads in a robust way.

Signed-off-by: Esben Haabendal <redacted>
---
?drivers/i2c/busses/i2c-mpc.c | ? ?9 +++++++--
?1 files changed, 7 insertions(+), 2 deletions(-)

Any blockers to get this accepted?

It would be nice to get an ack from someone who can actually test
the driver before getting this merged.
 

What is the state of this patch?
Shouldn't we attack the problem on a more general way by inventing a
Flag I2C_M_RESTART (or better I2C_M_NO_RESTART for backward compatibility)?
This way the client driver is able to decide what it needs. If we do the
choice within adapter, chance is about 50% to be wrong.

The documentation for 'struct i2c_msg' already says the STOP should only
be generated for the last message of the transfer. If STOP is being
generated for a message that isn't the last in the transfer than this
is incorrect behaviour.

Ah, now I see, this is a mpc-only problem of implementation
(automatically generating stop in read function).
I couldn't find the above mentioned specification of STOP/RESTART (seems
I need new glasses) and was worried about whether my own implementation
for OCTEON is correct.

Thank you.
-- 
Michael