| Message ID | 1467376378-21535-1-git-send-email-christian.gmeiner@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Jul 01, 2016 at 02:32:58PM +0200, Christian Gmeiner wrote: > In some rare cases I see the following 'task blocked' information. It > looks like the PIO transfer has some problems and never succeeds. Make > use of wait_for_completion_timeout(..) to detect this case and > return -ETIMEDOUT. > > v2: remove backtrace from commit message Please do not submit new versions of already applied patches, please submit incremental updates to the existing code. Modifying existing commits creates problems for other users building on top of those commits so it's best practice to only change pubished git commits if absolutely essential. If you're including an inter-version changelog please keep it after the --- as covered in SubmittingPatches.
Hi Mark, 2016-07-01 17:01 GMT+02:00 Mark Brown <broonie@kernel.org>: > On Fri, Jul 01, 2016 at 02:32:58PM +0200, Christian Gmeiner wrote: >> In some rare cases I see the following 'task blocked' information. It >> looks like the PIO transfer has some problems and never succeeds. Make >> use of wait_for_completion_timeout(..) to detect this case and >> return -ETIMEDOUT. >> >> v2: remove backtrace from commit message > > Please do not submit new versions of already applied patches, please > submit incremental updates to the existing code. Modifying existing > commits creates problems for other users building on top of those > commits so it's best practice to only change pubished git commits if > absolutely essential. > I was not aware that the patch was applied already that is why I send out a v2. I normally do not follow any subsystem or linux-next tree to see if a patch of me got applied or not. Normally I get an Acked-by: or Signed-off-by: reply to know about the state of the patch. In case of this patch I got a separate main 'Applied "spi: imx: wait_for_completion_timeout(..) for PIO transfers" to the spi tree' which did not get any attention from me as it was hidden due some gmail filter-to-label rules. In the end I am happy that this patch got applied. Thanks for that and sorry that I have stolen to much time. > If you're including an inter-version changelog please keep it after the > --- as covered in SubmittingPatches. Will do the next time - sorry for that. greets -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c index 50769078..d2b96b1 100644 --- a/drivers/spi/spi-imx.c +++ b/drivers/spi/spi-imx.c @@ -1050,6 +1050,8 @@ static int spi_imx_pio_transfer(struct spi_device *spi, struct spi_transfer *transfer) { struct spi_imx_data *spi_imx = spi_master_get_devdata(spi->master); + unsigned long transfer_timeout; + unsigned long timeout; spi_imx->tx_buf = transfer->tx_buf; spi_imx->rx_buf = transfer->rx_buf; @@ -1062,7 +1064,15 @@ static int spi_imx_pio_transfer(struct spi_device *spi, spi_imx->devtype_data->intctrl(spi_imx, MXC_INT_TE); - wait_for_completion(&spi_imx->xfer_done); + transfer_timeout = spi_imx_calculate_timeout(spi_imx, transfer->len); + + timeout = wait_for_completion_timeout(&spi_imx->xfer_done, + transfer_timeout); + if (!timeout) { + dev_err(&spi->dev, "I/O Error in PIO\n"); + spi_imx->devtype_data->reset(spi_imx); + return -ETIMEDOUT; + } return transfer->len; }
In some rare cases I see the following 'task blocked' information. It looks like the PIO transfer has some problems and never succeeds. Make use of wait_for_completion_timeout(..) to detect this case and return -ETIMEDOUT. v2: remove backtrace from commit message Signed-off-by: Christian Gmeiner <christian.gmeiner@gmail.com> --- drivers/spi/spi-imx.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)