Some operations (such as reading several megabytes of data from a flash)
can take several seconds or more. Users may want to cancel such
operations. Allow them to do so now that we have a way to recover.

Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
---

 drivers/spi/spi-zynqmp-gqspi.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/spi/spi-zynqmp-gqspi.c b/drivers/spi/spi-zynqmp-gqspi.c
index cf47466ec982..fa4bff73324e 100644
--- a/drivers/spi/spi-zynqmp-gqspi.c
+++ b/drivers/spi/spi-zynqmp-gqspi.c
@@ -1062,14 +1062,24 @@ static int zynqmp_qspi_wait(struct zynqmp_qspi *xqspi, unsigned long timeout)
 {
 	int ret;
 
-	ret = wait_for_completion_timeout(&xqspi->data_completion, timeout);
-	if (ret)
+	/* Only allow interrupting if we can reset the device */
+	if (xqspi->reset)
+		ret = wait_for_completion_interruptible_timeout(&xqspi->data_completion,
+								timeout);
+	else
+		ret = wait_for_completion_timeout(&xqspi->data_completion,
+						  timeout);
+	if (ret > 0)
 		return 0;
-	dev_err(xqspi->dev, "Operation timed out\n");
+
+	if (!ret) {
+		dev_err(xqspi->dev, "Operation timed out\n");
+		ret = -ETIMEDOUT;
+	}
 
 	/* Attempt to recover as best we can */
 	zynqmp_qspi_init_hw(xqspi);
-	return -ETIMEDOUT;
+	return ret;
 }
 
 /**
-- 
2.35.1.1320.gc452695387.dirty

Hello Sean,

On 16/01/2025 at 17:55:20 -05, Sean Anderson <sean.anderson@linux.dev> wrote:

> Some operations (such as reading several megabytes of data from a flash)
> can take several seconds or more. Users may want to cancel such
> operations. Allow them to do so now that we have a way to recover.

I fully agree with the observation, I tried myself interrupting too long
transfers with another spi controller:

e0205d6203c2c ("spi: atmel: Prevent false timeouts on long transfers")

But there were issues reported, so we limited the signals to SIGKILLs:

1ca2761a77349 ("spi: atmel: Do not cancel a transfer upon any signal")

But jffs2 plays with sigkills, so for spi memories it does not work
well, we had to revert:

890188d2d7e4a ("spi: atmel: Prevent spi transfers from being killed")

Same thing was also observed on Zynq7000:

26cfc0dbe43aa ("spi: spi-zynq-qspi: use wait_for_completion_timeout to make zynq_qspi_exec_mem_op not interruptible")

I would however hint to use a specific helper for deriving your timeouts
if you play with spi memories, because it is interesting to adapt the
values nevertheless:

d8e4ebf870187 ("spi: Create a helper to derive adaptive timeouts")

Thanks,
Miquèl

On 1/17/25 03:41, Miquel Raynal wrote:
> Hello Sean,
> 
> On 16/01/2025 at 17:55:20 -05, Sean Anderson <sean.anderson@linux.dev> wrote:
> 
>> Some operations (such as reading several megabytes of data from a flash)
>> can take several seconds or more. Users may want to cancel such
>> operations. Allow them to do so now that we have a way to recover.
> 
> I fully agree with the observation, I tried myself interrupting too long
> transfers with another spi controller:
> 
> e0205d6203c2c ("spi: atmel: Prevent false timeouts on long transfers")
> 
> But there were issues reported, so we limited the signals to SIGKILLs:
> 
> 1ca2761a77349 ("spi: atmel: Do not cancel a transfer upon any signal")
> 
> But jffs2 plays with sigkills, so for spi memories it does not work
> well, we had to revert:
> 
> 890188d2d7e4a ("spi: atmel: Prevent spi transfers from being killed")
> 
> Same thing was also observed on Zynq7000:
> 
> 26cfc0dbe43aa ("spi: spi-zynq-qspi: use wait_for_completion_timeout to make zynq_qspi_exec_mem_op not interruptible")
> 
> I would however hint to use a specific helper for deriving your timeouts
> if you play with spi memories, because it is interesting to adapt the
> values nevertheless:
> 
> d8e4ebf870187 ("spi: Create a helper to derive adaptive timeouts")

Hm, ok. I wasn't sure whether this was allowed, but I saw a lot of
interruptable users under drivers/spi.

I guess I'll drop this patch for v2.

--Sean