[PATCH 0/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity

[PATCH 0/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity

[Praveen Talari]

When operating in SPI target mode, the GENI controller relies on an
external GPIO to notify the SPI master about the target's active state.

Add support for an optional device GPIO that is asserted when a target
transfer begins and deasserted when the transfer completes, is aborted,
or hits a timeout. This allows the target to explicitly signal its
availability to the master and ensures the GPIO is released in all error
and completion paths, preventing the master from observing a stale or
incorrect target-ready indication.

The GPIO is optional and requested only when target mode is enabled,
using devm_gpiod_get_index_optional() so targets without this signal
continue to work unchanged.

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
Praveen Talari (2):
      dt-bindings: spi: qcom-geni: Document device-gpios property
      spi: qcom-geni: Use GPIO to notify master of SPI target activity

 .../bindings/spi/qcom,sa8255p-geni-spi.yaml        |  9 ++++++++
 .../bindings/spi/qcom,spi-geni-qcom.yaml           |  9 ++++++++
 drivers/spi/spi-geni-qcom.c                        | 25 ++++++++++++++++++++--
 3 files changed, 41 insertions(+), 2 deletions(-)
---
base-commit: 78bc8af4affb9a732504eb22eeac7d1e50883853
change-id: 20260729-use_gpio_to_notify_master_of_spi_target_activity-5f62a9e14875

Best regards,
--  
Praveen Talari <praveen.talari@oss.qualcomm.com>

[PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Praveen Talari]

When operating in SPI target (slave) mode, the GENI SPI controller can
use an external GPIO to notify the SPI master about the target's
active state.

Document the optional device-gpios property for the qcom,spi-geni-qcom
and qcom,sa8255p-geni-spi bindings, restricted to spi-slave nodes.

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
 Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml | 9 +++++++++
 Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml    | 9 +++++++++
 2 files changed, 18 insertions(+)

diff --git a/Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml b/Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml
index 6552303a4f52..aa75cd6dab13 100644
--- a/Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml
@@ -39,6 +39,12 @@ properties:
       - const: power
       - const: perf
 
+  device-gpios:
+    description:
+      GPIO used by the SPI target to notify the SPI master when it is
+      ready to service a transfer. Only applicable in target (slave) mode.
+    maxItems: 1
+
 required:
   - compatible
   - reg
@@ -46,6 +52,9 @@ required:
   - power-domains
   - power-domain-names
 
+dependencies:
+  device-gpios: [ spi-slave ]
+
 allOf:
   - $ref: /schemas/spi/spi-controller.yaml#
 
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
index edf399681d7a..d97f928e206c 100644
--- a/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml
@@ -67,6 +67,12 @@ properties:
   reg:
     maxItems: 1
 
+  device-gpios:
+    description:
+      GPIO used by the SPI target to notify the SPI master when it is
+      ready to service a transfer. Only applicable in target (slave) mode.
+    maxItems: 1
+
 required:
   - compatible
   - clocks
@@ -74,6 +80,9 @@ required:
   - interrupts
   - reg
 
+dependencies:
+  device-gpios: [ spi-slave ]
+
 unevaluatedProperties: false
 
 examples:

-- 
2.34.1

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 551 bytes --]

On Thu, Aug 06, 2026 at 03:43:44PM +0530, Praveen Talari wrote:
> When operating in SPI target (slave) mode, the GENI SPI controller can
> use an external GPIO to notify the SPI master about the target's
> active state.

Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Praveen Talari]

HI Mark

On 06-08-2026 22:17, Mark Brown wrote:
> On Thu, Aug 06, 2026 at 03:43:44PM +0530, Praveen Talari wrote:
>> When operating in SPI target (slave) mode, the GENI SPI controller can
>> use an external GPIO to notify the SPI master about the target's
>> active state.
> Please submit patches using subject lines reflecting the style for the
> subsystem, this makes it easier for people to identify relevant patches.
> Look at what existing commits in the area you're changing are doing and
> make sure your subject lines visually resemble what they're doing.
> There's no need to resubmit to fix this alone.
Sure, will update in next patch.

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On Thu, Aug 06, 2026 at 03:43:44PM +0530, Praveen Talari wrote:
> When operating in SPI target (slave) mode, the GENI SPI controller can
> use an external GPIO to notify the SPI master about the target's
> active state.

> Document the optional device-gpios property for the qcom,spi-geni-qcom
> and qcom,sa8255p-geni-spi bindings, restricted to spi-slave nodes.

This seems a lot like the ready-gpios property we have for some other
drivers?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Praveen Talari]

Hi Mark,

On 06-08-2026 23:05, Mark Brown wrote:
> On Thu, Aug 06, 2026 at 03:43:44PM +0530, Praveen Talari wrote:
>> When operating in SPI target (slave) mode, the GENI SPI controller can
>> use an external GPIO to notify the SPI master about the target's
>> active state.
>> Document the optional device-gpios property for the qcom,spi-geni-qcom
>> and qcom,sa8255p-geni-spi bindings, restricted to spi-slave nodes.
> This seems a lot like the ready-gpios property we have for some other
> drivers?
Yes, you're right. The intention was the same when I added this property.

Would you prefer that I use the ready-gpios property instead?

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 375 bytes --]

On Thu, Aug 06, 2026 at 11:47:46PM +0530, Praveen Talari wrote:
> On 06-08-2026 23:05, Mark Brown wrote:

> > This seems a lot like the ready-gpios property we have for some other
> > drivers?

> Yes, you're right. The intention was the same when I added this property.

> Would you prefer that I use the ready-gpios property instead?

Yes, we should have a consistent name.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Mukesh Savaliya]

On 8/6/2026 3:43 PM, Praveen Talari wrote:
> When operating in SPI target (slave) mode, the GENI SPI controller can
> use an external GPIO to notify the SPI master about the target's
> active state.
> 

Is this active state meaning target is in ready state to communicate 
with master controller ?

When will it set this gpio ? can you describe little ?

> Document the optional device-gpios property for the qcom,spi-geni-qcom
seems bit generic name, it should describe the signal purpose, not the 
device. Something like handshake-gpios OR ready-gpios ?
> and qcom,sa8255p-geni-spi bindings, restricted to spi-slave nodes.
> 
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
>   Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml | 9 +++++++++
>   Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml    | 9 +++++++++
>   2 files changed, 18 insertions(+)

[...]

Re: [PATCH 1/2] dt-bindings: spi: qcom-geni: Document device-gpios property

[Praveen Talari]

Hi Mukesh,

On 06-08-2026 23:45, Mukesh Savaliya wrote:
>
>
> On 8/6/2026 3:43 PM, Praveen Talari wrote:
>> When operating in SPI target (slave) mode, the GENI SPI controller can
>> use an external GPIO to notify the SPI master about the target's
>> active state.
>>
>
> Is this active state meaning target is in ready state to communicate 
> with master controller ?
Yes, you are right.
>
> When will it set this gpio ? can you describe little ?
I have already described the behaviour in the driver change.
Is additional explanation required in the DT binding as well?
>
>> Document the optional device-gpios property for the qcom,spi-geni-qcom
> seems bit generic name, it should describe the signal purpose, not the 
> device. Something like handshake-gpios OR ready-gpios ?
As mark pointed, there is already ready-gpios so i use this.
>> and qcom,sa8255p-geni-spi bindings, restricted to spi-slave nodes.
>>
>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/spi/qcom,sa8255p-geni-spi.yaml | 9 
>> +++++++++
>> Documentation/devicetree/bindings/spi/qcom,spi-geni-qcom.yaml | 9 
>> +++++++++
>>   2 files changed, 18 insertions(+)
>
> [...]

[PATCH 2/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity

[Praveen Talari]

When operating in SPI target mode, the GENI controller relies on an
external GPIO to notify the SPI master about the target's active state.

Add support for an optional device GPIO that is asserted when a target
transfer begins and deasserted when the transfer completes, is aborted,
or hits a timeout. This allows the target to explicitly signal its
availability to the master and ensures the GPIO is released in all error
and completion paths, preventing the master from observing a stale or
incorrect target-ready indication.

The GPIO is optional and requested only when target mode is enabled,
using devm_gpiod_get_index_optional() so targets without this signal
continue to work unchanged.

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
 drivers/spi/spi-geni-qcom.c | 25 +++++++++++++++++++++++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index d262206ed663..ffb8871a55d8 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -8,6 +8,7 @@
 #include <linux/dmaengine.h>
 #include <linux/dma-mapping.h>
 #include <linux/dma/qcom-gpi-dma.h>
+#include <linux/gpio/consumer.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
 #include <linux/log2.h>
@@ -113,6 +114,7 @@ struct spi_geni_master {
 	struct dma_chan *rx;
 	int cur_xfer_mode;
 	const struct geni_spi_desc *dev_data;
+	struct gpio_desc *target_gpio;
 };
 
 static void spi_slv_setup(struct spi_geni_master *mas)
@@ -171,6 +173,9 @@ static void handle_se_timeout(struct spi_controller *spi)
 	xfer = mas->cur_xfer;
 	mas->cur_xfer = NULL;
 
+	if (spi->target && mas->target_gpio)
+		gpiod_set_value(mas->target_gpio, 0);
+
 	/* The controller doesn't support the Cancel commnand in target mode */
 	if (!spi->target) {
 		reinit_completion(&mas->cancel_done);
@@ -928,8 +933,12 @@ static int spi_geni_transfer_one(struct spi_controller *spi,
 	if (mas->cur_xfer_mode == GENI_SE_FIFO || mas->cur_xfer_mode == GENI_SE_DMA) {
 		ret = setup_se_xfer(xfer, mas, slv->mode, spi);
 		/* SPI framework expects +ve ret code to wait for transfer complete */
-		if (!ret)
+		if (!ret) {
+			if (spi->target && mas->target_gpio)
+				gpiod_set_value(mas->target_gpio, 1);
 			ret = 1;
+		}
+
 		return ret;
 	}
 	return setup_gsi_xfer(xfer, mas, slv, spi);
@@ -969,6 +978,8 @@ static irqreturn_t geni_spi_isr(int irq, void *data)
 			if (mas->cur_xfer) {
 				spi_finalize_current_transfer(spi);
 				mas->cur_xfer = NULL;
+				if (spi->target && mas->target_gpio)
+					gpiod_set_value(mas->target_gpio, 0);
 				/*
 				 * If this happens, then a CMD_DONE came before all the
 				 * Tx buffer bytes were sent out. This is unusual, log
@@ -1012,6 +1023,8 @@ static irqreturn_t geni_spi_isr(int irq, void *data)
 		if (!mas->tx_rem_bytes && !mas->rx_rem_bytes && xfer) {
 			spi_finalize_current_transfer(spi);
 			mas->cur_xfer = NULL;
+			if (spi->target && mas->target_gpio)
+				gpiod_set_value(mas->target_gpio, 0);
 		}
 	}
 
@@ -1116,8 +1129,16 @@ static int spi_geni_probe(struct platform_device *pdev)
 	init_completion(&mas->rx_reset_done);
 	spin_lock_init(&mas->lock);
 
-	if (spi->target)
+	if (spi->target) {
 		spi->target_abort = spi_geni_target_abort;
+		mas->target_gpio = devm_gpiod_get_index_optional(dev, "device", 0,
+								 GPIOD_OUT_LOW);
+		if (IS_ERR(mas->target_gpio)) {
+			dev_err(dev, "Failed to request GPIO: %ld\n",
+				PTR_ERR(mas->target_gpio));
+			mas->target_gpio = NULL;
+		}
+	}
 
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, 250);

-- 
2.34.1

Re: [PATCH 2/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The probe function incorrectly handles errors from devm_gpiod_get_index_optional(), breaking probe deferral.
- [High] A race condition between spi_geni_transfer_one() and geni_spi_isr() can leave the target readiness GPIO stuck permanently asserted.
- [Medium] The target readiness GPIO is toggled per spi_transfer rather than per spi_message, causing spurious dropouts mid-transaction.
--

--- Patch [2]: [PATCH 2/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity ---
commit c41b3184af4cdb8d8cf0321da6d2ab29ec44d0c2
Author: Praveen Talari <praveen.talari@oss.qualcomm.com>
spi: qcom-geni: Use GPIO to notify master of SPI target activity

This commit adds support for an optional GPIO to signal target availability
to the SPI master in the GENI SPI controller driver. The GPIO is asserted
when a transfer begins and deasserted upon completion, abort, or timeout.

> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 6566975eb24f2..6083725a20aa4 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c

[ ... ]

> @@ -938,8 +943,12 @@ static int spi_geni_transfer_one(struct spi_controller *spi,
>  	if (mas->cur_xfer_mode == GENI_SE_FIFO || mas->cur_xfer_mode == GENI_SE_DMA) {
>  		ret = setup_se_xfer(xfer, mas, slv->mode, spi);
>  		/* SPI framework expects +ve ret code to wait for transfer complete */
> -		if (!ret)
> +		if (!ret) {
> +			if (spi->target && mas->target_gpio)
> +				gpiod_set_value(mas->target_gpio, 1);

[Severity: High]
Does asserting the GPIO here introduce a race condition?

setup_se_xfer() unlocks mas->lock before returning. If the SPI master
immediately clocks data, the transfer could complete on the hardware and
trigger geni_spi_isr() on another CPU.

geni_spi_isr() would then deassert the GPIO to 0 before this thread
asserts it to 1, leaving the GPIO permanently stuck asserted and breaking
the handshake protocol for subsequent transfers.

[Severity: Medium]
Is the target readiness GPIO toggled per spi_transfer instead of per
spi_message here?

If a multi-transfer message is processed, this will cause the signal to
drop between fragments when geni_spi_isr() sets the GPIO to 0, potentially
causing the master to incorrectly interpret it as a target abort or failure.

>  			ret = 1;
> +		}
> +
>  		return ret;
>  	}

[ ... ]

> @@ -1131,8 +1144,16 @@ static int spi_geni_probe(struct platform_device *pdev)
>  	init_completion(&mas->rx_reset_done);
>  	spin_lock_init(&mas->lock);
>  
> -	if (spi->target)
> +	if (spi->target) {
>  		spi->target_abort = spi_geni_target_abort;
> +		mas->target_gpio = devm_gpiod_get_index_optional(dev, "device", 0,
> +								 GPIOD_OUT_LOW);
> +		if (IS_ERR(mas->target_gpio)) {
> +			dev_err(dev, "Failed to request GPIO: %ld\n",
> +				PTR_ERR(mas->target_gpio));
> +			mas->target_gpio = NULL;
> +		}
> +	}

[Severity: High]
Could this error handling block probe deferral?

If the GPIO provider has not probed yet, devm_gpiod_get_index_optional()
will return -EPROBE_DEFER. By catching this error and setting
mas->target_gpio to NULL, the driver will silently continue without the
requested GPIO instead of deferring the probe.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260806-use_gpio_to_notify_master_of_spi_target_activity-v1-0-c363a9b5df69@oss.qualcomm.com?part=2

Re: [PATCH 2/2] spi: qcom-geni: Use GPIO to notify master of SPI target activity

[Mukesh Savaliya]

On 8/6/2026 3:43 PM, Praveen Talari wrote:
> When operating in SPI target mode, the GENI controller relies on an
> external GPIO to notify the SPI master about the target's active state.
> 
> Add support for an optional device GPIO that is asserted when a target
> transfer begins and deasserted when the transfer completes, is aborted,
> or hits a timeout. This allows the target to explicitly signal its
> availability to the master and ensures the GPIO is released in all error
> and completion paths, preventing the master from observing a stale or
> incorrect target-ready indication.
> 
> The GPIO is optional and requested only when target mode is enabled,
> using devm_gpiod_get_index_optional() so targets without this signal
> continue to work unchanged.

if this is an optional for something like showing target readiness,
why it's required ? if not defined, what mechanism makes it work properly ?

Like does it depend on any timing or sync mechanism if not the GPIO way?

> 
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
>   drivers/spi/spi-geni-qcom.c | 25 +++++++++++++++++++++++--
>   1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c

[...]

> @@ -1116,8 +1129,16 @@ static int spi_geni_probe(struct platform_device *pdev)
>   	init_completion(&mas->rx_reset_done);
>   	spin_lock_init(&mas->lock);
>   
> -	if (spi->target)
> +	if (spi->target) {
>   		spi->target_abort = spi_geni_target_abort;
> +		mas->target_gpio = devm_gpiod_get_index_optional(dev, "device", 0,
> +								 GPIOD_OUT_LOW);
> +		if (IS_ERR(mas->target_gpio)) {
> +			dev_err(dev, "Failed to request GPIO: %ld\n",
> +				PTR_ERR(mas->target_gpio));
> +			mas->target_gpio = NULL;
IIUC, this GPIO is an optional one. if so, please add a comment to let 
go ahead with an error.

Else need to return an error.
> +		}
> +	}
>   
>   	pm_runtime_use_autosuspend(&pdev->dev);
>   	pm_runtime_set_autosuspend_delay(&pdev->dev, 250);
>