SPI target mode currently lacks a mechanism to gracefully abort ongoing
transfers when the client or core needs to cancel active transactions.

Implement spi_geni_target_abort() to handle aborting SPI target
operations when the client and core want to cancel ongoing transfers.
This provides a mechanism for graceful termination of active SPI
transactions in target mode.

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
v1->v2
- Removed unused param from time out handlers.
---
 drivers/spi/spi-geni-qcom.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 5077dc041e3a..43ce47f2454c 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -1003,6 +1003,17 @@ static irqreturn_t geni_spi_isr(int irq, void *data)
 	return IRQ_HANDLED;
 }
 
+static int spi_geni_target_abort(struct spi_controller *spi)
+{
+	if (!spi->cur_msg)
+		return 0;
+
+	handle_se_timeout(spi);
+	spi_finalize_current_transfer(spi);
+
+	return 0;
+}
+
 static int spi_geni_probe(struct platform_device *pdev)
 {
 	int ret, irq;
@@ -1076,6 +1087,9 @@ static int spi_geni_probe(struct platform_device *pdev)
 	init_completion(&mas->rx_reset_done);
 	spin_lock_init(&mas->lock);
 
+	if (spi->target)
+		spi->target_abort = spi_geni_target_abort;
+
 	ret = geni_icc_get(&mas->se, NULL);
 	if (ret)
 		return ret;
-- 
2.34.1

On 2/4/26 5:28 PM, Praveen Talari wrote:
> SPI target mode currently lacks a mechanism to gracefully abort ongoing
> transfers when the client or core needs to cancel active transactions.
> 
> Implement spi_geni_target_abort() to handle aborting SPI target
> operations when the client and core want to cancel ongoing transfers.
> This provides a mechanism for graceful termination of active SPI
> transactions in target mode.
> 
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---


> v1->v2
> - Removed unused param from time out handlers.
> ---
>  drivers/spi/spi-geni-qcom.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 5077dc041e3a..43ce47f2454c 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -1003,6 +1003,17 @@ static irqreturn_t geni_spi_isr(int irq, void *data)
>  	return IRQ_HANDLED;
>  }
>  
> +static int spi_geni_target_abort(struct spi_controller *spi)
> +{
> +	if (!spi->cur_msg)
> +		return 0;
> +
> +	handle_se_timeout(spi);
> +	spi_finalize_current_transfer(spi);
> +
> +	return 0;
> +}
> +
>  static int spi_geni_probe(struct platform_device *pdev)
>  {
>  	int ret, irq;
> @@ -1076,6 +1087,9 @@ static int spi_geni_probe(struct platform_device *pdev)
>  	init_completion(&mas->rx_reset_done);
>  	spin_lock_init(&mas->lock);
>  
> +	if (spi->target)
> +		spi->target_abort = spi_geni_target_abort;

The same check is made in core:

spi_target_abort()
-> spi_controller_is_target()

So I'm assuming the intention was to allow assigning the func pointer
indiscriminately. Other drivers seem to do it both ways.

Mark, any specific preference?

Konrad

On Wed, Feb 04, 2026 at 05:41:46PM +0100, Konrad Dybcio wrote:
> On 2/4/26 5:28 PM, Praveen Talari wrote:

> > +	if (spi->target)
> > +		spi->target_abort = spi_geni_target_abort;

> The same check is made in core:

> spi_target_abort()
> -> spi_controller_is_target()

> So I'm assuming the intention was to allow assigning the func pointer
> indiscriminately. Other drivers seem to do it both ways.

> Mark, any specific preference?

Not really TBH, it's redundant in the driver but if the people working
on the driver find having the check there saves them having to check
that the core does the right thing that's fine.  It's not like this is a
fast path.

On 2/4/26 5:57 PM, Mark Brown wrote:
> On Wed, Feb 04, 2026 at 05:41:46PM +0100, Konrad Dybcio wrote:
>> On 2/4/26 5:28 PM, Praveen Talari wrote:
> 
>>> +	if (spi->target)
>>> +		spi->target_abort = spi_geni_target_abort;
> 
>> The same check is made in core:
> 
>> spi_target_abort()
>> -> spi_controller_is_target()
> 
>> So I'm assuming the intention was to allow assigning the func pointer
>> indiscriminately. Other drivers seem to do it both ways.
> 
>> Mark, any specific preference?
> 
> Not really TBH, it's redundant in the driver but if the people working
> on the driver find having the check there saves them having to check
> that the core does the right thing that's fine.  It's not like this is a
> fast path.

Thanks

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>

Konrad