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

[PATCH v4 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 ready GPIO is intentionally made optional and is requested only
when target mode is enabled. This preserves existing behaviour for
systems that do not require the signal and avoids regressions on
deployed platforms where the GPIO is already controlled from userspace.
Targets without a ready GPIO continue to operate unchanged by using
devm_gpiod_get_optional().

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
Changes in v4:
- Used devm_gpiod_get_optional() instead of
  devm_gpiod_get_index_optional(), since a single GPIO is requested.
- Dropped the redundant mas->ready_gpio NULL checks before
  gpiod_set_value(), since it already handles a NULL descriptor.
- Renamed target_gpio to ready_gpio to match the property name.
- Link to v3: https://patch.msgid.link/20260818-use_gpio_to_notify_master_of_spi_target_activity-v3-0-e1c9e0dabbda@oss.qualcomm.com

Changes in v3:
- Rebased on linux-next tip.
- Link to v2: https://patch.msgid.link/20260817-use_gpio_to_notify_master_of_spi_target_activity-v2-0-94d1eff3175f@oss.qualcomm.com

Changes in v2:
- Used ready-gpio instead of target-gpio.
- Updated commit text.
- Link to v1: https://patch.msgid.link/20260806-use_gpio_to_notify_master_of_spi_target_activity-v1-0-c363a9b5df69@oss.qualcomm.com

---
Praveen Talari (2):
      spi: dt-bindings: Document ready-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: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
change-id: 20260729-use_gpio_to_notify_master_of_spi_target_activity-5f62a9e14875

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

[PATCH v4 1/2] spi: dt-bindings: Document ready-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 ready-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..33eddb395a0a 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
 
+  ready-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:
+  ready-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..8d1c78701657 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
 
+  ready-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:
+  ready-gpios: [ spi-slave ]
+
 unevaluatedProperties: false
 
 examples:

-- 
2.34.1

Re: [PATCH v4 1/2] spi: dt-bindings: Document ready-gpios property

[Krzysztof Kozlowski]

On Mon, Aug 24, 2026 at 07:55:59PM +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 ready-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(+)

Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

[PATCH v4 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 ready 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 ready GPIO is intentionally made optional and is requested only
when target mode is enabled. This preserves existing behaviour for
systems that do not require the signal and avoids regressions on
deployed platforms where the GPIO is already controlled from userspace.
Targets without a ready GPIO continue to operate unchanged by using
devm_gpiod_get_optional().

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 6c57f8309a3b..fcf5c3f057b8 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -10,6 +10,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>
@@ -115,6 +116,7 @@ struct spi_geni_master {
 	struct dma_chan *rx;
 	int cur_xfer_mode;
 	const struct geni_spi_desc *dev_data;
+	struct gpio_desc *ready_gpio;
 };
 
 static void spi_slv_setup(struct spi_geni_master *mas)
@@ -173,6 +175,9 @@ static void handle_se_timeout(struct spi_controller *spi)
 	xfer = mas->cur_xfer;
 	mas->cur_xfer = NULL;
 
+	if (spi->target)
+		gpiod_set_value(mas->ready_gpio, 0);
+
 	/* The controller doesn't support the Cancel commnand in target mode */
 	if (!spi->target) {
 		reinit_completion(&mas->cancel_done);
@@ -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)
+				gpiod_set_value(mas->ready_gpio, 1);
 			ret = 1;
+		}
+
 		return ret;
 	}
 	return setup_gsi_xfer(xfer, mas, slv, spi);
@@ -981,6 +990,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)
+					gpiod_set_value(mas->ready_gpio, 0);
 				/*
 				 * If this happens, then a CMD_DONE came before all the
 				 * Tx buffer bytes were sent out. This is unusual, log
@@ -1027,6 +1038,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)
+				gpiod_set_value(mas->ready_gpio, 0);
 		}
 	}
 
@@ -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->ready_gpio = devm_gpiod_get_optional(dev, "ready",
+							  GPIOD_OUT_LOW);
+		if (IS_ERR(mas->ready_gpio)) {
+			dev_err(dev, "Failed to request GPIO: %ld\n",
+				PTR_ERR(mas->ready_gpio));
+			mas->ready_gpio = NULL;
+		}
+	}
 
 	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_set_autosuspend_delay(&pdev->dev, 250);

-- 
2.34.1

Re: [PATCH v4 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 4 potential issue(s) to consider:
- [High] The driver masks errors from `devm_gpiod_get_optional()`, breaking probe deferral when the GPIO provider is not yet loaded.
- [High] A race condition between starting the hardware transfer and asserting `ready_gpio` can leave the ready signal permanently stuck high.
- [High] The `ready_gpio` signaling is completely bypassed when the SPI controller operates in GSI DMA mode (`GENI_GPI_DMA`), causing the SPI master to hang indefinitely.
- [Medium] The driver manipulates `ready_gpio` in hardirq context without checking if the provided GPIO can sleep.
--

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

spi: qcom-geni: Use GPIO to notify master of SPI target activity

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.
This adds support for an optional ready GPIO that is asserted when a target
transfer begins and deasserted when the transfer completes.

> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> --- 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)
> +				gpiod_set_value(mas->ready_gpio, 1);
>  			ret = 1;
> +		}
> +
>  		return ret;
>  	}

[Severity: High]
Does this introduce a race condition with the interrupt handler that could
leave the ready GPIO permanently asserted?

In setup_se_xfer(), the transfer is started and the mas->lock is dropped.
If the master clocks the transfer immediately, it could complete and trigger
geni_spi_isr() before we reach the GPIO assertion here in
spi_geni_transfer_one().

The interrupt handler would deassert the GPIO on completion, but then this
function would unconditionally assert it again, leaving it stuck high.

[Severity: High]
Are we missing the ready signal assertion when the controller operates in
GSI DMA mode?

If the hardware is configured to use GENI_GPI_DMA, spi_geni_transfer_one()
routes the transfer to setup_gsi_xfer() directly below, which bypasses the
ready_gpio assertion entirely. 

Looking at setup_gsi_xfer(), it doesn't appear to assert the ready signal
before initiating DMA, and the completion callback spi_gsi_callback_result()
does not deassert it.

>  	return setup_gsi_xfer(xfer, mas, slv, spi);
>  }
[ ... ]
> @@ -981,6 +990,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)
> +					gpiod_set_value(mas->ready_gpio, 0);

[Severity: Medium]
Will this cause a 'sleeping in atomic context' splat if the ready GPIO is
backed by a sleeping controller?

Since geni_spi_isr() runs in hardirq context, gpiod_set_value() could sleep
if the GPIO provider is an I2C or SPI expander. Should we verify
!gpiod_cansleep() during probe before using it here?

>  				/*
>  				 * If this happens, then a CMD_DONE came before all the
>  				 * Tx buffer bytes were sent out. This is unusual, log
[ ... ]
> @@ -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->ready_gpio = devm_gpiod_get_optional(dev, "ready",
> +							  GPIOD_OUT_LOW);
> +		if (IS_ERR(mas->ready_gpio)) {
> +			dev_err(dev, "Failed to request GPIO: %ld\n",
> +				PTR_ERR(mas->ready_gpio));
> +			mas->ready_gpio = NULL;
> +		}
> +	}

[Severity: High]
Does overwriting mas->ready_gpio with NULL break probe deferral?

If devm_gpiod_get_optional() returns -EPROBE_DEFER because the GPIO
controller isn't loaded yet, this error is masked and the SPI driver will
successfully probe but permanently operate without the required readiness
signaling.

>  
>  	pm_runtime_use_autosuspend(&pdev->dev);
>  	pm_runtime_set_autosuspend_delay(&pdev->dev, 250);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260824-use_gpio_to_notify_master_of_spi_target_activity-v4-0-fde2ebf043db@oss.qualcomm.com?part=2

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

[Mark Brown]

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

On Mon, Aug 24, 2026 at 07:56:00PM +0530, 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.

> +	if (spi->target) {
>  		spi->target_abort = spi_geni_target_abort;
> +		mas->ready_gpio = devm_gpiod_get_optional(dev, "ready",
> +							  GPIOD_OUT_LOW);
> +		if (IS_ERR(mas->ready_gpio)) {
> +			dev_err(dev, "Failed to request GPIO: %ld\n",
> +				PTR_ERR(mas->ready_gpio));
> +			mas->ready_gpio = NULL;

I'll apply this since it probably doesn't actually matter but this is
broken for probe deferral, and might cause issues if the system really
does have a GPIO but it fails for some reason.  It's better to just
handle all errors as errors, _optional() already returns NULL if the
GPIO is genuintely missing.

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

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

[Mark Brown]

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

On Thu, Sep 24, 2026 at 11:41:14PM +0100, Mark Brown wrote:
> On Mon, Aug 24, 2026 at 07:56:00PM +0530, 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.

> I'll apply this since it probably doesn't actually matter but this is
> broken for probe deferral, and might cause issues if the system really
> does have a GPIO but it fails for some reason.  It's better to just
> handle all errors as errors, _optional() already returns NULL if the
> GPIO is genuintely missing.

Actually no, it needs a rebase anyway - please resend against for-7.4.

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