| Message ID | 1397385910-28368-1-git-send-email-alexanders83@web.de (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 1676014ef974ce71a854e7f415e2bb52feb24868 |
| Headers | show |
On Sun, Apr 13, 2014 at 12:45:10PM +0200, Alexander Stein wrote: > atmel_spi_lock does a spin_lock_irqsave, so we need to renable the > interrupts when we want to schedule. > > Signed-off-by: Alexander Stein <alexanders83@web.de> > --- > I'm not sure what the lock is actually good for, so I kept it and release > it when we are about to schedule, thus reenabling interrupts. Applied, thanks - I don't fully understand the locking either and this is definitely a conservative fix.
diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index 5d7b07f..ae22f3d 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -1130,8 +1130,11 @@ static int atmel_spi_one_transfer(struct spi_master *master, atmel_spi_next_xfer_pio(master, xfer); } + /* interrupts are disabled, so free the lock for schedule */ + atmel_spi_unlock(as); ret = wait_for_completion_timeout(&as->xfer_completion, SPI_DMA_TIMEOUT); + atmel_spi_lock(as); if (WARN_ON(ret == 0)) { dev_err(&spi->dev, "spi trasfer timeout, err %d\n", ret);
atmel_spi_lock does a spin_lock_irqsave, so we need to renable the interrupts when we want to schedule. Signed-off-by: Alexander Stein <alexanders83@web.de> --- I'm not sure what the lock is actually good for, so I kept it and release it when we are about to schedule, thus reenabling interrupts. drivers/spi/spi-atmel.c | 3 +++ 1 file changed, 3 insertions(+)