diff mbox

spi: spi-ti-qspi: Suspend the queue before removing the device

Message ID 1463486227-6110-1-git-send-email-x0248073@ti.com (mailing list archive)
State Accepted
Commit 3ac066e2227cb272c097f34475247fa0a6cdd2ff
Headers show

Commit Message

Jean-Jacques Hiblot May 17, 2016, 11:57 a.m. UTC
From: Jean-Jacques Hiblot <jjhiblot@ti.com>

Before disabling the pm_runtime, we must ensure that there is no transfer
in progress nor will a new one be started. Otherwise the message pump will
fail and in the end, the process requesting the transfer will be stuck.
This behavior has been observed when transferring data from a SPI flash
with dd while removing the module on a DRA7x-evm.

Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
---
 drivers/spi/spi-ti-qspi.c | 7 +++++++
 1 file changed, 7 insertions(+)

Comments

Jean-Jacques Hiblot May 31, 2016, 2:45 p.m. UTC | #1
gentle ping.

Any objection to fix this particular issue in this way ? Should it be 
fixed at the core level ?

Thanks,

Jean-Jacques


On 17/05/2016 13:57, Jean-Jacques Hiblot wrote:
> From: Jean-Jacques Hiblot <jjhiblot@ti.com>
>
> Before disabling the pm_runtime, we must ensure that there is no transfer
> in progress nor will a new one be started. Otherwise the message pump will
> fail and in the end, the process requesting the transfer will be stuck.
> This behavior has been observed when transferring data from a SPI flash
> with dd while removing the module on a DRA7x-evm.
>
> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com>
> ---
>   drivers/spi/spi-ti-qspi.c | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
> index 443f664..29ea8d2 100644
> --- a/drivers/spi/spi-ti-qspi.c
> +++ b/drivers/spi/spi-ti-qspi.c
> @@ -646,6 +646,13 @@ free_master:
>   
>   static int ti_qspi_remove(struct platform_device *pdev)
>   {
> +	struct ti_qspi *qspi = platform_get_drvdata(pdev);
> +	int rc;
> +
> +	rc = spi_master_suspend(qspi->master);
> +	if (rc)
> +		return rc;
> +
>   	pm_runtime_put_sync(&pdev->dev);
>   	pm_runtime_disable(&pdev->dev);
>   

--
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
Mark Brown May 31, 2016, 3:18 p.m. UTC | #2
On Tue, May 31, 2016 at 04:45:53PM +0200, Jean-Jacques Hiblot wrote:
> gentle ping.
> 
> Any objection to fix this particular issue in this way ? Should it be fixed
> at the core level ?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.
Sending content free pings just adds to the mail volume (if they are
seen at all) and if something has gone wrong you'll have to resend the
patches anyway.

In this case you've never sent me the patch so I've not seen it.

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.
Jean-Jacques Hiblot May 31, 2016, 3:33 p.m. UTC | #3
On 31/05/2016 17:18, Mark Brown wrote:
> On Tue, May 31, 2016 at 04:45:53PM +0200, Jean-Jacques Hiblot wrote:
>> gentle ping.
>>
>> Any objection to fix this particular issue in this way ? Should it be fixed
>> at the core level ?
> Please don't send content free pings and please allow a reasonable time
> for review.  People get busy, go on holiday, attend conferences and so
> on so unless there is some reason for urgency (like critical bug fixes)
> please allow at least a couple of weeks for review.  If there have been
> review comments then people may be waiting for those to be addressed.
> Sending content free pings just adds to the mail volume (if they are
> seen at all) and if something has gone wrong you'll have to resend the
> patches anyway.
>
> In this case you've never sent me the patch so I've not seen it.
I had just noticed that I forgot to add you in the loop. That's actually 
the reason why I sent the ping, not to push you.

Jean-Jacques
>
> Please don't top post, reply in line with needed context.  This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.

--
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
Mark Brown May 31, 2016, 3:37 p.m. UTC | #4
On Tue, May 31, 2016 at 05:33:23PM +0200, Jean-Jacques Hiblot wrote:
> On 31/05/2016 17:18, Mark Brown wrote:

> > In this case you've never sent me the patch so I've not seen it.

> I had just noticed that I forgot to add you in the loop. That's actually the
> reason why I sent the ping, not to push you.

I can't apply patches that are quoted in replies to other messages,
please send the patch again.
diff mbox

Patch

diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 443f664..29ea8d2 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -646,6 +646,13 @@  free_master:
 
 static int ti_qspi_remove(struct platform_device *pdev)
 {
+	struct ti_qspi *qspi = platform_get_drvdata(pdev);
+	int rc;
+
+	rc = spi_master_suspend(qspi->master);
+	if (rc)
+		return rc;
+
 	pm_runtime_put_sync(&pdev->dev);
 	pm_runtime_disable(&pdev->dev);