Thread (22 messages) 22 messages, 8 authors, 2009-12-04

Re: [PATCH v2] i2c-mpc: generate START condition after STOP caused by read i2c_msg

From: Michael Lawnick <hidden>
Date: 2009-12-03 15:10:03
Also in: linux-i2c

Ben Dooks said the following:
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.

Just my 2 Cents.

-- 
Michael
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help