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>
This commit is contained in:
Brian Niebuhr 2010-07-02 15:30:17 +00:00 committed by Grant Likely
parent 3c8e1a84fd
commit b8f2e7bb6c

View File

@ -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.