spi/bitbang: reinitialize transfer parameters for every message

This patch fixes the setup_transfer logic to account for the case where
multiple messages to different SPI devices are in the queue simultaneously.
With the current logic, the second message in the queue will end up
using the transfer parameters for the previous message in the queue.

The fix is to reinitialize the transfer parameters for each message
rather than only once on the first message.

Signed-off-by: Brian Niebuhr <bniebuhr@efjohnson.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>

drivers/spi/spi_bitbang.c

@@ -259,7 +259,6 @@ static void bitbang_work(struct work_struct *work)
 	struct spi_bitbang	*bitbang =
 		container_of(work, struct spi_bitbang, work);
 	unsigned long		flags;
-	int			do_setup = -1;
 	int			(*setup_transfer)(struct spi_device *,
 					struct spi_transfer *);
 
@@ -275,6 +274,7 @@ static void bitbang_work(struct work_struct *work)
 		unsigned		tmp;
 		unsigned		cs_change;
 		int			status;
+		int			do_setup = -1;
 
 		m = container_of(bitbang->queue.next, struct spi_message,
 				queue);
@@ -307,6 +307,8 @@ static void bitbang_work(struct work_struct *work)
 				status = setup_transfer(spi, t);
 				if (status < 0)
 					break;
+				if (do_setup == -1)
+					do_setup = 0;
 			}
 
 			/* set up default clock polarity, and activate chip;
@@ -367,11 +369,6 @@ static void bitbang_work(struct work_struct *work)
 		m->status = status;
 		m->complete(m->context);
 
-		/* restore speed and wordsize if it was overridden */
-		if (do_setup == 1)
-			setup_transfer(spi, NULL);
-		do_setup = 0;
-
 		/* normally deactivate chipselect ... unless no error and
 		 * cs_change has hinted that the next message will probably
 		 * be for this chip too.