linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: rmk+kernel@arm.linux.org.uk (Russell King)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 9/9] I2C: mv64xxx: fix race between FSM/interrupt and process context
Date: Thu, 16 May 2013 21:39:12 +0100	[thread overview]
Message-ID: <E1Ud4xE-0004KB-2T@rmk-PC.arm.linux.org.uk> (raw)
In-Reply-To: <20130516202921.GW18614@n2100.arm.linux.org.uk>

Asking for a multi-part message to be handled by this driver is racy; it
has been observed that the following sequence is possible with this
driver:

	- send start
	- send address + write
	- send data
	- send (repeated) start
	- send address + write
	- send (repeated) start
	- send address + read
	- unrecoverable bus hang (except by system reset)

The problem is that the interrupt handling sees the next event after the
first repeated start is sent - the IFLG bit is set in the register even
though INTEN is disabled.

Let's fix this by moving all of the message processing into interrupt
context, rather than having it partly in IRQ and partly in process
context.  This allows us to move immediately to the next message in the
interrupt handler and get on with the transfer, rather than incuring a
couple of scheduling switches to get the next message.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
 drivers/i2c/busses/i2c-mv64xxx.c |   54 ++++++++++++++++++++++++--------------
 1 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/busses/i2c-mv64xxx.c b/drivers/i2c/busses/i2c-mv64xxx.c
index 7457ef5..a2e4633 100644
--- a/drivers/i2c/busses/i2c-mv64xxx.c
+++ b/drivers/i2c/busses/i2c-mv64xxx.c
@@ -86,6 +86,8 @@ enum {
 };
 
 struct mv64xxx_i2c_data {
+	struct i2c_msg		*msgs;
+	int			num_msgs;
 	int			irq;
 	u32			state;
 	u32			action;
@@ -194,7 +196,7 @@ mv64xxx_i2c_fsm(struct mv64xxx_i2c_data *drv_data, u32 status)
 		if ((drv_data->bytes_left == 0)
 				|| (drv_data->aborting
 					&& (drv_data->byte_posn != 0))) {
-			if (drv_data->send_stop) {
+			if (drv_data->send_stop || drv_data->aborting) {
 				drv_data->action = MV64XXX_I2C_ACTION_SEND_STOP;
 				drv_data->state = MV64XXX_I2C_STATE_IDLE;
 			} else {
@@ -271,12 +273,25 @@ mv64xxx_i2c_do_action(struct mv64xxx_i2c_data *drv_data)
 {
 	switch(drv_data->action) {
 	case MV64XXX_I2C_ACTION_SEND_RESTART:
+		/* We should only get here if we have further messages */
+		BUG_ON(drv_data->num_msgs == 0);
+
 		drv_data->cntl_bits |= MV64XXX_I2C_REG_CONTROL_START;
-		drv_data->cntl_bits &= ~MV64XXX_I2C_REG_CONTROL_INTEN;
 		writel(drv_data->cntl_bits,
 			drv_data->reg_base + MV64XXX_I2C_REG_CONTROL);
-		drv_data->block = 0;
-		wake_up(&drv_data->waitq);
+
+		drv_data->msgs++;
+		drv_data->num_msgs--;
+
+		/* Setup for the next message */
+		mv64xxx_i2c_prepare_for_io(drv_data, drv_data->msgs);
+
+		/*
+		 * We're never at the start of the message here, and by this
+		 * time it's already too late to do any protocol mangling.
+		 * Thankfully, do not advertise support for that feature.
+		 */
+		drv_data->send_stop = drv_data->num_msgs == 1;
 		break;
 
 	case MV64XXX_I2C_ACTION_CONTINUE:
@@ -412,20 +427,15 @@ mv64xxx_i2c_wait_for_completion(struct mv64xxx_i2c_data *drv_data)
 
 static int
 mv64xxx_i2c_execute_msg(struct mv64xxx_i2c_data *drv_data, struct i2c_msg *msg,
-				int is_first, int is_last)
+				int is_last)
 {
 	unsigned long	flags;
 
 	spin_lock_irqsave(&drv_data->lock, flags);
 	mv64xxx_i2c_prepare_for_io(drv_data, msg);
 
-	if (is_first) {
-		drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
-		drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
-	} else {
-		drv_data->action = MV64XXX_I2C_ACTION_SEND_ADDR_1;
-		drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_ADDR_1_ACK;
-	}
+	drv_data->action = MV64XXX_I2C_ACTION_SEND_START;
+	drv_data->state = MV64XXX_I2C_STATE_WAITING_FOR_START_COND;
 
 	drv_data->send_stop = is_last;
 	drv_data->block = 1;
@@ -453,16 +463,20 @@ static int
 mv64xxx_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[], int num)
 {
 	struct mv64xxx_i2c_data *drv_data = i2c_get_adapdata(adap);
-	int	i, rc;
+	int rc, ret = num;
 
-	for (i = 0; i < num; i++) {
-		rc = mv64xxx_i2c_execute_msg(drv_data, &msgs[i],
-						i == 0, i + 1 == num);
-		if (rc < 0)
-			return rc;
-	}
+	BUG_ON(drv_data->msgs != NULL);
+	drv_data->msgs = msgs;
+	drv_data->num_msgs = num;
+
+	rc = mv64xxx_i2c_execute_msg(drv_data, &msgs[0], num == 1);
+	if (rc < 0)
+		ret = rc;
+
+	drv_data->num_msgs = 0;
+	drv_data->msgs = NULL;
 
-	return num;
+	return ret;
 }
 
 static const struct i2c_algorithm mv64xxx_i2c_algo = {
-- 
1.7.4.4

  parent reply	other threads:[~2013-05-16 20:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-16 20:29 [PATCH 0/9] Fix Marvell mv63xxx I2C driver Russell King - ARM Linux
2013-05-16 20:30 ` [PATCH 1/9] I2C: mv64xxx: work around signals causing I2C transactions to be aborted Russell King
2013-05-17  6:37   ` Jean-Francois Moine
2013-05-17  8:31     ` Russell King - ARM Linux
2013-05-17 12:17   ` Wolfram Sang
2013-05-17 17:06   ` Mark A. Greer
2013-05-16 20:32 ` [PATCH 2/9] I2C: mv64xxx: use return value from mv64xxx_i2c_map_regs() Russell King
2013-05-16 20:33 ` [PATCH 3/9] I2C: mv64xxx: use devm_ioremap_resource() Russell King
2013-05-17  9:23   ` Jean-Francois Moine
2013-05-17  9:34     ` Russell King - ARM Linux
2013-05-16 20:34 ` [PATCH 4/9] I2C: mv64xxx: use devm_clk_get() to avoid missing clk_put() Russell King
2013-05-16 20:35 ` [PATCH 5/9] I2C: mv64xxx: use devm_kzalloc() Russell King
2013-05-16 20:36 ` [PATCH 6/9] I2C: mv64xxx: fix error handling for request_irq() Russell King
2013-05-16 20:37 ` [PATCH 7/9] I2C: mv64xxx: remove I2C_M_NOSTART code Russell King
2013-05-22 19:05   ` Mark Brown
2013-05-16 20:38 ` [PATCH 8/9] I2C: mv64xxx: move mv64xxx_i2c_prepare_for_io() Russell King
2013-05-16 20:39 ` Russell King [this message]
2013-05-17  9:51   ` [PATCH 9/9] I2C: mv64xxx: fix race between FSM/interrupt and process context Wolfram Sang
2013-05-17 10:00     ` Russell King - ARM Linux
2013-05-17 12:15       ` Wolfram Sang
2013-06-05 21:48 ` [PATCH 0/9] Fix Marvell mv63xxx I2C driver Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E1Ud4xE-0004KB-2T@rmk-PC.arm.linux.org.uk \
    --to=rmk+kernel@arm.linux.org.uk \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).