[PATCH v3 0/2] spi: qcom-geni: Add shutdown and panic notifier support

[PATCH v3 0/2] spi: qcom-geni: Add shutdown and panic notifier support

[Praveen Talari]

On VM-based platforms, if an SPI DMA transfer is in progress when the
guest is torn down (via reboot/shutdown or a panic/crash), the DMA
engine can keep issuing transactions to IOVAs that have already been
invalidated as part of teardown. The SMMU then raises context faults,
which can affect other VMs sharing the same SMMU instance and obscure
the real root cause of the crash.

This series adds two independent quiesce paths for the GENI SPI
controller so that any in-progress transfer is stopped and the DMA
engine is left idle before the IOVA mappings are torn down:

- Patch 1 adds a platform shutdown() callback that suspends the SPI
  controller (via spi_controller_suspend()) on a normal
  reboot/shutdown path, where sleeping is safe.

- Patch 2 registers a panic notifier that cancels/aborts the
  in-flight command and resets the TX/RX DMA FSMs (or terminates the
  GPI DMA channels) when the kernel panics, covering the crash path
  as well. The notifier bails out early if the device is not
  runtime-active or has no active command, and otherwise uses
  readl_poll_timeout_atomic() to poll status registers directly
  instead of waiting on completions/IRQs like the regular
  error-handling path does, since panic notifiers run with IRQs and
  preemption disabled. The notifier is registered before
  devm_spi_register_controller() so a panic during child device
  probing is still handled.

Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
---
Changes in v3:
- Rebased on linux-next tip (next-20260817).
- Link to v2: https://patch.msgid.link/20260818-add-shutdown-and-panic-notifier-for-spi-v2-0-eb25d56634a0@oss.qualcomm.com

Changes in v2:
- Patch 2: instead of just disabling the SPI IRQ (or suspending the
  controller, which is unsafe in panic context), actively cancel/abort
  the in-flight command and reset the TX/RX DMA FSMs (or terminate the
  GPI DMA channels) using atomic-safe register polling
  (readl_poll_timeout_atomic()), so the DMA engine is actually left
  idle rather than just having its completion interrupt masked.
- Patch 2: skip the quiesce sequence entirely if the device is not
  runtime-active (pm_runtime_active()) or if there's no active GENI
  command, to avoid touching registers on a clock-gated SE.
- Patch 2: register the panic notifier before
  devm_spi_register_controller() so a panic during child SPI device
  probing is still caught.
- Link to v1: https://patch.msgid.link/20260805-add-shutdown-and-panic-notifier-for-spi-v1-0-b5db170d491e@oss.qualcomm.com

---
Praveen Talari (2):
      spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot
      spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic

 drivers/spi/spi-geni-qcom.c | 78 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 77 insertions(+), 1 deletion(-)
---
base-commit: e6664f2b33db9b6811eb4cec109f06cb2b4f458d
change-id: 20260804-add-shutdown-and-panic-notifier-for-spi-fa732be7c7dd

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

[PATCH v3 1/2] spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot

[Praveen Talari]

During system reboot, an active SPI transfer can leave the GENI Serial
Engine in an indeterminate state. On VM-based platforms, if a DMA
transfer is in progress when the VM is shut down, the SMMU can raise
context faults as the DMA engine continues to access IOVAs that have
already been invalidated during VM teardown.

Add a shutdown callback to suspend the SPI controller and abort any
in-progress transfer, ensuring the DMA engine is idle and all IOVA
mappings are retired before the system resets.

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

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index 6c57f8309a3b..c65c1788325d 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -1066,6 +1066,13 @@ static int spi_geni_target_abort(struct spi_controller *spi)
 	return 0;
 }
 
+static void spi_geni_shutdown(struct platform_device *pdev)
+{
+	struct spi_controller *spi = platform_get_drvdata(pdev);
+
+	spi_controller_suspend(spi);
+}
+
 static int spi_geni_probe(struct platform_device *pdev)
 {
 	int ret, irq;
@@ -1241,7 +1248,8 @@ static const struct of_device_id spi_geni_dt_match[] = {
 MODULE_DEVICE_TABLE(of, spi_geni_dt_match);
 
 static struct platform_driver spi_geni_driver = {
-	.probe  = spi_geni_probe,
+	.probe    = spi_geni_probe,
+	.shutdown = spi_geni_shutdown,
 	.driver = {
 		.name = "geni_spi",
 		.pm = pm_ptr(&spi_geni_pm_ops),

-- 
2.34.1

Re: [PATCH v3 1/2] spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot

[Mukesh Savaliya]

On 8/18/2026 6:58 PM, Praveen Talari wrote:
> During system reboot, an active SPI transfer can leave the GENI Serial
> Engine in an indeterminate state. On VM-based platforms, if a DMA
> transfer is in progress when the VM is shut down, the SMMU can raise
> context faults as the DMA engine continues to access IOVAs that have
> already been invalidated during VM teardown.
> 
> Add a shutdown callback to suspend the SPI controller and abort any
> in-progress transfer, ensuring the DMA engine is idle and all IOVA
> mappings are retired before the system resets.
> 
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>

Re: [PATCH v3 1/2] spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot

[Jyothi Kumar Seerapu]

On 8/18/2026 6:58 PM, Praveen Talari wrote:
> During system reboot, an active SPI transfer can leave the GENI Serial
> Engine in an indeterminate state. On VM-based platforms, if a DMA
> transfer is in progress when the VM is shut down, the SMMU can raise
> context faults as the DMA engine continues to access IOVAs that have
> already been invalidated during VM teardown.
> 
> Add a shutdown callback to suspend the SPI controller and abort any
> in-progress transfer, ensuring the DMA engine is idle and all IOVA
> mappings are retired before the system resets.
> 
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
>   drivers/spi/spi-geni-qcom.c | 10 +++++++++-
>   1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index 6c57f8309a3b..c65c1788325d 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -1066,6 +1066,13 @@ static int spi_geni_target_abort(struct spi_controller *spi)
>   	return 0;
>   }
>   
> +static void spi_geni_shutdown(struct platform_device *pdev)
> +{
> +	struct spi_controller *spi = platform_get_drvdata(pdev);
> +
> +	spi_controller_suspend(spi);
Hi Praveen,

Don't we also need to power off the SE resources here (e.g. via 
pm_runtime_force_suspend(), like spi_geni_suspend() does)? As-is, 
spi_controller_suspend() only stops the message queue — it doesn't 
quiesce the hardware/clocks.

Thanks,
JyothiKumar
> +}
> +
>   static int spi_geni_probe(struct platform_device *pdev)
>   {
>   	int ret, irq;
> @@ -1241,7 +1248,8 @@ static const struct of_device_id spi_geni_dt_match[] = {
>   MODULE_DEVICE_TABLE(of, spi_geni_dt_match);
>   
>   static struct platform_driver spi_geni_driver = {
> -	.probe  = spi_geni_probe,
> +	.probe    = spi_geni_probe,
> +	.shutdown = spi_geni_shutdown,
>   	.driver = {
>   		.name = "geni_spi",
>   		.pm = pm_ptr(&spi_geni_pm_ops),
> 

Re: [PATCH v3 1/2] spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot

[Praveen Talari]

Hi Jyothi

On 21-08-2026 15:59, Jyothi Kumar Seerapu wrote:
>
>
> On 8/18/2026 6:58 PM, Praveen Talari wrote:
>> During system reboot, an active SPI transfer can leave the GENI Serial
>> Engine in an indeterminate state. On VM-based platforms, if a DMA
>> transfer is in progress when the VM is shut down, the SMMU can raise
>> context faults as the DMA engine continues to access IOVAs that have
>> already been invalidated during VM teardown.
>>
>> Add a shutdown callback to suspend the SPI controller and abort any
>> in-progress transfer, ensuring the DMA engine is idle and all IOVA
>> mappings are retired before the system resets.
>>
>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>> ---
>>   drivers/spi/spi-geni-qcom.c | 10 +++++++++-
>>   1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
>> index 6c57f8309a3b..c65c1788325d 100644
>> --- a/drivers/spi/spi-geni-qcom.c
>> +++ b/drivers/spi/spi-geni-qcom.c
>> @@ -1066,6 +1066,13 @@ static int spi_geni_target_abort(struct 
>> spi_controller *spi)
>>       return 0;
>>   }
>>   +static void spi_geni_shutdown(struct platform_device *pdev)
>> +{
>> +    struct spi_controller *spi = platform_get_drvdata(pdev);
>> +
>> +    spi_controller_suspend(spi);
> Hi Praveen,
>
> Don't we also need to power off the SE resources here (e.g. via 
> pm_runtime_force_suspend(), like spi_geni_suspend() does)? As-is, 
> spi_controller_suspend() only stops the message queue — it doesn't 
> quiesce the hardware/clocks.
The primary goal of this shutdown callback is to ensure that any 
in-progress transfer is aborted before VM/system teardown, preventing 
DMA transactions from accessing IOVAs after they have been invalidated.

In this path, spi_controller_suspend() invokes the controller's suspend 
callback, which aborts any active transfer and drains the message queue. 
The issue being addressed here is not related to runtime power 
management state or resource leakage, but rather ensuring that the 
transfer engine is quiesced before reboot.


Thanks,

Praveen Kumar

>
> Thanks,
> JyothiKumar
>> +}
>> +
>>   static int spi_geni_probe(struct platform_device *pdev)
>>   {
>>       int ret, irq;
>> @@ -1241,7 +1248,8 @@ static const struct of_device_id 
>> spi_geni_dt_match[] = {
>>   MODULE_DEVICE_TABLE(of, spi_geni_dt_match);
>>     static struct platform_driver spi_geni_driver = {
>> -    .probe  = spi_geni_probe,
>> +    .probe    = spi_geni_probe,
>> +    .shutdown = spi_geni_shutdown,
>>       .driver = {
>>           .name = "geni_spi",
>>           .pm = pm_ptr(&spi_geni_pm_ops),
>>
>

[PATCH v3 2/2] spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic

[Praveen Talari]

When a VM crashes with an active SPI DMA transfer in progress, the
SMMU raises context faults as the DMA engine continues to access
IOVAs that are invalidated when the VM's memory context is torn down.
These faults can affect other VMs sharing the same SMMU instance and
obscure the root cause of the crash.

Register a panic notifier that cancels (or aborts, if cancel doesn't
complete) the in-flight command and resets the TX/RX DMA FSMs, so the
DMA engine stops issuing transactions against invalidated IOVAs
before the system halts. For GPI DMA mode, the DMA channels are
terminated directly via dmaengine_terminate_async().

The notifier bails out early if the device is not runtime-active or
if there's no active GENI command, avoiding unnecessary register
accesses while the SE is clock-gated or idle.

Since panic notifiers run with IRQs and preemption disabled,
completion-based waits used by the regular error-handling path
(handle_se_timeout()) cannot be reused here. Instead, the relevant
status registers are polled directly with
readl_poll_timeout_atomic(), which is safe to call in this context.

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

diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
index c65c1788325d..f272bd0cb640 100644
--- a/drivers/spi/spi-geni-qcom.c
+++ b/drivers/spi/spi-geni-qcom.c
@@ -12,8 +12,10 @@
 #include <linux/dma/qcom-gpi-dma.h>
 #include <linux/interrupt.h>
 #include <linux/io.h>
+#include <linux/iopoll.h>
 #include <linux/log2.h>
 #include <linux/module.h>
+#include <linux/panic_notifier.h>
 #include <linux/platform_device.h>
 #include <linux/pm_opp.h>
 #include <linux/pm_runtime.h>
@@ -115,6 +117,7 @@ struct spi_geni_master {
 	struct dma_chan *rx;
 	int cur_xfer_mode;
 	const struct geni_spi_desc *dev_data;
+	struct notifier_block panic_nb;
 };
 
 static void spi_slv_setup(struct spi_geni_master *mas)
@@ -1073,6 +1076,62 @@ static void spi_geni_shutdown(struct platform_device *pdev)
 	spi_controller_suspend(spi);
 }
 
+static int spi_geni_panic_notifier(struct notifier_block *nb,
+				   unsigned long action, void *data)
+{
+	struct spi_geni_master *mas = container_of(nb, struct spi_geni_master, panic_nb);
+	struct spi_controller *spi = dev_get_drvdata(mas->dev);
+	struct geni_se *se = &mas->se;
+	u32 val;
+
+	if (!pm_runtime_active(mas->dev))
+		return NOTIFY_OK;
+
+	if (mas->cur_xfer_mode == GENI_GPI_DMA) {
+		dmaengine_terminate_async(mas->tx);
+		dmaengine_terminate_async(mas->rx);
+		return NOTIFY_OK;
+	}
+
+	if (!(readl_relaxed(se->base + SE_GENI_STATUS) & M_GENI_CMD_ACTIVE))
+		return NOTIFY_OK;
+
+	if (!spi->target) {
+		geni_se_cancel_m_cmd(se);
+		if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, val,
+					       val & M_CMD_CANCEL_EN, 10, 50000)) {
+			writel_relaxed(M_CMD_CANCEL_EN, se->base + SE_GENI_M_IRQ_CLEAR);
+			return NOTIFY_OK;
+		}
+	}
+
+	geni_se_abort_m_cmd(se);
+	if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, val,
+				       val & M_CMD_ABORT_EN, 10, 50000))
+		writel_relaxed(M_CMD_ABORT_EN, se->base + SE_GENI_M_IRQ_CLEAR);
+
+	if (mas->cur_xfer_mode == GENI_SE_DMA) {
+		writel_relaxed(1, se->base + SE_DMA_TX_FSM_RST);
+		readl_poll_timeout_atomic(se->base + SE_DMA_TX_IRQ_STAT, val,
+					  val & TX_RESET_DONE, 10, 50000);
+		writel_relaxed(val, se->base + SE_DMA_TX_IRQ_CLR);
+
+		writel_relaxed(1, se->base + SE_DMA_RX_FSM_RST);
+		readl_poll_timeout_atomic(se->base + SE_DMA_RX_IRQ_STAT, val,
+					  val & RX_RESET_DONE, 10, 50000);
+		writel_relaxed(val, se->base + SE_DMA_RX_IRQ_CLR);
+	}
+
+	return NOTIFY_OK;
+}
+
+static void spi_geni_unregister_notifiers(void *data)
+{
+	struct spi_geni_master *mas = data;
+
+	atomic_notifier_chain_unregister(&panic_notifier_list, &mas->panic_nb);
+}
+
 static int spi_geni_probe(struct platform_device *pdev)
 {
 	int ret, irq;
@@ -1161,6 +1220,15 @@ static int spi_geni_probe(struct platform_device *pdev)
 	if (ret)
 		return ret;
 
+	mas->panic_nb.notifier_call = spi_geni_panic_notifier;
+	ret = atomic_notifier_chain_register(&panic_notifier_list, &mas->panic_nb);
+	if (ret)
+		return ret;
+
+	ret = devm_add_action_or_reset(dev, spi_geni_unregister_notifiers, mas);
+	if (ret)
+		return ret;
+
 	return devm_spi_register_controller(dev, spi);
 }
 

-- 
2.34.1

Re: [PATCH v3 2/2] spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic

[Mukesh Savaliya]

On 8/18/2026 6:58 PM, Praveen Talari wrote:
[...]

> +static int spi_geni_panic_notifier(struct notifier_block *nb,
> +				   unsigned long action, void *data)
> +{
> +	struct spi_geni_master *mas = container_of(nb, struct spi_geni_master, panic_nb);
> +	struct spi_controller *spi = dev_get_drvdata(mas->dev);
> +	struct geni_se *se = &mas->se;
> +	u32 val;
> +
> +	if (!pm_runtime_active(mas->dev))

Not completely sure, but why not NOTIFY_DONE ? we haven't handled 
anything here.

> +		return NOTIFY_OK;
> +
> +	if (mas->cur_xfer_mode == GENI_GPI_DMA) {
> +		dmaengine_terminate_async(mas->tx);
> +		dmaengine_terminate_async(mas->rx);
> +		return NOTIFY_OK;
> +	}
> +
> +	if (!(readl_relaxed(se->base + SE_GENI_STATUS) & M_GENI_CMD_ACTIVE))
Shouldn't this be under FIFO mode check  ? As i can see SE DMA mode and 
GPI mode conditions present but not for FIFO.

> +		return NOTIFY_OK;
> +
> +	if (!spi->target) {
> +		geni_se_cancel_m_cmd(se);
> +		if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, val,
> +					       val & M_CMD_CANCEL_EN, 10, 50000)) {
> +			writel_relaxed(M_CMD_CANCEL_EN, se->base + SE_GENI_M_IRQ_CLEAR);
> +			return NOTIFY_OK;
> +		}
> +	}
> +
> +	geni_se_abort_m_cmd(se);

why abort is done directly for target device and not for master ?
shouldn't be combined with cancel failure ?
> +	if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, val,
> +				       val & M_CMD_ABORT_EN, 10, 50000))
> +		writel_relaxed(M_CMD_ABORT_EN, se->base + SE_GENI_M_IRQ_CLEAR);
> +
> +	if (mas->cur_xfer_mode == GENI_SE_DMA) {
> +		writel_relaxed(1, se->base + SE_DMA_TX_FSM_RST);
> +		readl_poll_timeout_atomic(se->base + SE_DMA_TX_IRQ_STAT, val,
> +					  val & TX_RESET_DONE, 10, 50000);
> +		writel_relaxed(val, se->base + SE_DMA_TX_IRQ_CLR);
> +
> +		writel_relaxed(1, se->base + SE_DMA_RX_FSM_RST);
> +		readl_poll_timeout_atomic(se->base + SE_DMA_RX_IRQ_STAT, val,
> +					  val & RX_RESET_DONE, 10, 50000);
May be good to declar macro for 10usec and 50msec ? Multiple places it's 
being used.> +		writel_relaxed(val, se->base + SE_DMA_RX_IRQ_CLR);
> +	}
> +
> +	return NOTIFY_OK;
> +}
> +[...]

Re: [PATCH v3 2/2] spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic

[Praveen Talari]

Hi Mukesh

On 20-08-2026 01:02, Mukesh Savaliya wrote:
>
>
> On 8/18/2026 6:58 PM, Praveen Talari wrote:
> [...]
>
>> +static int spi_geni_panic_notifier(struct notifier_block *nb,
>> +                   unsigned long action, void *data)
>> +{
>> +    struct spi_geni_master *mas = container_of(nb, struct 
>> spi_geni_master, panic_nb);
>> +    struct spi_controller *spi = dev_get_drvdata(mas->dev);
>> +    struct geni_se *se = &mas->se;
>> +    u32 val;
>> +
>> +    if (!pm_runtime_active(mas->dev))
>
> Not completely sure, but why not NOTIFY_DONE ? we haven't handled 
> anything here.
My intention was to treat this as a successful no-op since no action is 
required when the device is runtime suspended.
>
>> +        return NOTIFY_OK;
>> +
>> +    if (mas->cur_xfer_mode == GENI_GPI_DMA) {
>> +        dmaengine_terminate_async(mas->tx);
>> +        dmaengine_terminate_async(mas->rx);
>> +        return NOTIFY_OK;
>> +    }
>> +
>> +    if (!(readl_relaxed(se->base + SE_GENI_STATUS) & 
>> M_GENI_CMD_ACTIVE))
> Shouldn't this be under FIFO mode check  ? As i can see SE DMA mode 
> and GPI mode conditions present but not for FIFO.
This code path is shared between FIFO and SE_DMA modes. The DMA reset 
sequence below is only required when the transfer is operating in DMA mode.
>
>> +        return NOTIFY_OK;
>> +
>> +    if (!spi->target) {
>> +        geni_se_cancel_m_cmd(se);
>> +        if (!readl_poll_timeout_atomic(se->base + 
>> SE_GENI_M_IRQ_STATUS, val,
>> +                           val & M_CMD_CANCEL_EN, 10, 50000)) {
>> +            writel_relaxed(M_CMD_CANCEL_EN, se->base + 
>> SE_GENI_M_IRQ_CLEAR);
>> +            return NOTIFY_OK;
>> +        }
>> +    }
>> +
>> +    geni_se_abort_m_cmd(se);
>
> why abort is done directly for target device and not for master ?
> shouldn't be combined with cancel failure ?

The target doesn't support cancel.

>> +    if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, 
>> val,
>> +                       val & M_CMD_ABORT_EN, 10, 50000))
>> +        writel_relaxed(M_CMD_ABORT_EN, se->base + SE_GENI_M_IRQ_CLEAR);
>> +
>> +    if (mas->cur_xfer_mode == GENI_SE_DMA) {
>> +        writel_relaxed(1, se->base + SE_DMA_TX_FSM_RST);
>> +        readl_poll_timeout_atomic(se->base + SE_DMA_TX_IRQ_STAT, val,
>> +                      val & TX_RESET_DONE, 10, 50000);
>> +        writel_relaxed(val, se->base + SE_DMA_TX_IRQ_CLR);
>> +
>> +        writel_relaxed(1, se->base + SE_DMA_RX_FSM_RST);
>> +        readl_poll_timeout_atomic(se->base + SE_DMA_RX_IRQ_STAT, val,
>> +                      val & RX_RESET_DONE, 10, 50000);
> May be good to declar macro for 10usec and 50msec ? Multiple places 
> it's being used.> +        writel_relaxed(val, se->base + 
> SE_DMA_RX_IRQ_CLR);

Let me review and update.


Thanks,

Praveen Talari

>> +    }
>> +
>> +    return NOTIFY_OK;
>> +}
>> +[...]

Re: [PATCH v3 2/2] spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic

[Jyothi Kumar Seerapu]

On 8/18/2026 6:58 PM, Praveen Talari wrote:
> When a VM crashes with an active SPI DMA transfer in progress, the
> SMMU raises context faults as the DMA engine continues to access
> IOVAs that are invalidated when the VM's memory context is torn down.
> These faults can affect other VMs sharing the same SMMU instance and
> obscure the root cause of the crash.
> 
> Register a panic notifier that cancels (or aborts, if cancel doesn't
> complete) the in-flight command and resets the TX/RX DMA FSMs, so the
> DMA engine stops issuing transactions against invalidated IOVAs
> before the system halts. For GPI DMA mode, the DMA channels are
> terminated directly via dmaengine_terminate_async().
> 
> The notifier bails out early if the device is not runtime-active or
> if there's no active GENI command, avoiding unnecessary register
> accesses while the SE is clock-gated or idle.
> 
> Since panic notifiers run with IRQs and preemption disabled,
> completion-based waits used by the regular error-handling path
> (handle_se_timeout()) cannot be reused here. Instead, the relevant
> status registers are polled directly with
> readl_poll_timeout_atomic(), which is safe to call in this context.
> 
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
>   drivers/spi/spi-geni-qcom.c | 68 +++++++++++++++++++++++++++++++++++++++++++++
>   1 file changed, 68 insertions(+)
> 
> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
> index c65c1788325d..f272bd0cb640 100644
> --- a/drivers/spi/spi-geni-qcom.c
> +++ b/drivers/spi/spi-geni-qcom.c
> @@ -12,8 +12,10 @@
>   #include <linux/dma/qcom-gpi-dma.h>
>   #include <linux/interrupt.h>
>   #include <linux/io.h>
> +#include <linux/iopoll.h>
>   #include <linux/log2.h>
>   #include <linux/module.h>
> +#include <linux/panic_notifier.h>
>   #include <linux/platform_device.h>
>   #include <linux/pm_opp.h>
>   #include <linux/pm_runtime.h>
> @@ -115,6 +117,7 @@ struct spi_geni_master {
>   	struct dma_chan *rx;
>   	int cur_xfer_mode;
>   	const struct geni_spi_desc *dev_data;
> +	struct notifier_block panic_nb;
>   };
>   
>   static void spi_slv_setup(struct spi_geni_master *mas)
> @@ -1073,6 +1076,62 @@ static void spi_geni_shutdown(struct platform_device *pdev)
>   	spi_controller_suspend(spi);
>   }
>   
> +static int spi_geni_panic_notifier(struct notifier_block *nb,
> +				   unsigned long action, void *data)
> +{
> +	struct spi_geni_master *mas = container_of(nb, struct spi_geni_master, panic_nb);
> +	struct spi_controller *spi = dev_get_drvdata(mas->dev);
> +	struct geni_se *se = &mas->se;
> +	u32 val;
> +
> +	if (!pm_runtime_active(mas->dev))
> +		return NOTIFY_OK;
> +
> +	if (mas->cur_xfer_mode == GENI_GPI_DMA) {
> +		dmaengine_terminate_async(mas->tx);
> +		dmaengine_terminate_async(mas->rx);
> +		return NOTIFY_OK;
> +	}
> +
> +	if (!(readl_relaxed(se->base + SE_GENI_STATUS) & M_GENI_CMD_ACTIVE))
> +		return NOTIFY_OK;
> +
> +	if (!spi->target) {
> +		geni_se_cancel_m_cmd(se);
> +		if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, val,
> +					       val & M_CMD_CANCEL_EN, 10, 50000)) {
> +			writel_relaxed(M_CMD_CANCEL_EN, se->base + SE_GENI_M_IRQ_CLEAR);
> +			return NOTIFY_OK;
Looks like a successful cancel here returns NOTIFY_OK directly, skipping 
the FSM reset block below it entirely. Is that the correct expectation 
?> +		}
> +	}
> +
> +	geni_se_abort_m_cmd(se);
> +	if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, val,
> +				       val & M_CMD_ABORT_EN, 10, 50000))
> +		writel_relaxed(M_CMD_ABORT_EN, se->base + SE_GENI_M_IRQ_CLEAR);
> +
> +	if (mas->cur_xfer_mode == GENI_SE_DMA) {
> +		writel_relaxed(1, se->base + SE_DMA_TX_FSM_RST);
> +		readl_poll_timeout_atomic(se->base + SE_DMA_TX_IRQ_STAT, val,
> +					  val & TX_RESET_DONE, 10, 50000);
> +		writel_relaxed(val, se->base + SE_DMA_TX_IRQ_CLR);
> +
> +		writel_relaxed(1, se->base + SE_DMA_RX_FSM_RST);
> +		readl_poll_timeout_atomic(se->base + SE_DMA_RX_IRQ_STAT, val,
> +					  val & RX_RESET_DONE, 10, 50000);
> +		writel_relaxed(val, se->base + SE_DMA_RX_IRQ_CLR);
> +	}
> +
> +	return NOTIFY_OK;
> +}
> +
> +static void spi_geni_unregister_notifiers(void *data)
> +{
> +	struct spi_geni_master *mas = data;
> +
> +	atomic_notifier_chain_unregister(&panic_notifier_list, &mas->panic_nb);
> +}
> +
>   static int spi_geni_probe(struct platform_device *pdev)
>   {
>   	int ret, irq;
> @@ -1161,6 +1220,15 @@ static int spi_geni_probe(struct platform_device *pdev)
>   	if (ret)
>   		return ret;
>   
> +	mas->panic_nb.notifier_call = spi_geni_panic_notifier;
> +	ret = atomic_notifier_chain_register(&panic_notifier_list, &mas->panic_nb);
> +	if (ret)
> +		return ret;
> +
> +	ret = devm_add_action_or_reset(dev, spi_geni_unregister_notifiers, mas);
> +	if (ret)
> +		return ret;
> +
>   	return devm_spi_register_controller(dev, spi);
>   }
>   
> 

Re: [PATCH v3 2/2] spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic

[Praveen Talari]

Hi Jyothi,

Thank you for review.

On 21-08-2026 16:19, Jyothi Kumar Seerapu wrote:
>
>
> On 8/18/2026 6:58 PM, Praveen Talari wrote:
>> When a VM crashes with an active SPI DMA transfer in progress, the
>> SMMU raises context faults as the DMA engine continues to access
>> IOVAs that are invalidated when the VM's memory context is torn down.
>> These faults can affect other VMs sharing the same SMMU instance and
>> obscure the root cause of the crash.
>>
>> Register a panic notifier that cancels (or aborts, if cancel doesn't
>> complete) the in-flight command and resets the TX/RX DMA FSMs, so the
>> DMA engine stops issuing transactions against invalidated IOVAs
>> before the system halts. For GPI DMA mode, the DMA channels are
>> terminated directly via dmaengine_terminate_async().
>>
>> The notifier bails out early if the device is not runtime-active or
>> if there's no active GENI command, avoiding unnecessary register
>> accesses while the SE is clock-gated or idle.
>>
>> Since panic notifiers run with IRQs and preemption disabled,
>> completion-based waits used by the regular error-handling path
>> (handle_se_timeout()) cannot be reused here. Instead, the relevant
>> status registers are polled directly with
>> readl_poll_timeout_atomic(), which is safe to call in this context.
>>
>> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
>> ---
>>   drivers/spi/spi-geni-qcom.c | 68 
>> +++++++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 68 insertions(+)
>>
>> diff --git a/drivers/spi/spi-geni-qcom.c b/drivers/spi/spi-geni-qcom.c
>> index c65c1788325d..f272bd0cb640 100644
>> --- a/drivers/spi/spi-geni-qcom.c
>> +++ b/drivers/spi/spi-geni-qcom.c
>> @@ -12,8 +12,10 @@
>>   #include <linux/dma/qcom-gpi-dma.h>
>>   #include <linux/interrupt.h>
>>   #include <linux/io.h>
>> +#include <linux/iopoll.h>
>>   #include <linux/log2.h>
>>   #include <linux/module.h>
>> +#include <linux/panic_notifier.h>
>>   #include <linux/platform_device.h>
>>   #include <linux/pm_opp.h>
>>   #include <linux/pm_runtime.h>
>> @@ -115,6 +117,7 @@ struct spi_geni_master {
>>       struct dma_chan *rx;
>>       int cur_xfer_mode;
>>       const struct geni_spi_desc *dev_data;
>> +    struct notifier_block panic_nb;
>>   };
>>     static void spi_slv_setup(struct spi_geni_master *mas)
>> @@ -1073,6 +1076,62 @@ static void spi_geni_shutdown(struct 
>> platform_device *pdev)
>>       spi_controller_suspend(spi);
>>   }
>>   +static int spi_geni_panic_notifier(struct notifier_block *nb,
>> +                   unsigned long action, void *data)
>> +{
>> +    struct spi_geni_master *mas = container_of(nb, struct 
>> spi_geni_master, panic_nb);
>> +    struct spi_controller *spi = dev_get_drvdata(mas->dev);
>> +    struct geni_se *se = &mas->se;
>> +    u32 val;
>> +
>> +    if (!pm_runtime_active(mas->dev))
>> +        return NOTIFY_OK;
>> +
>> +    if (mas->cur_xfer_mode == GENI_GPI_DMA) {
>> +        dmaengine_terminate_async(mas->tx);
>> +        dmaengine_terminate_async(mas->rx);
>> +        return NOTIFY_OK;
>> +    }
>> +
>> +    if (!(readl_relaxed(se->base + SE_GENI_STATUS) & 
>> M_GENI_CMD_ACTIVE))
>> +        return NOTIFY_OK;
>> +
>> +    if (!spi->target) {
>> +        geni_se_cancel_m_cmd(se);
>> +        if (!readl_poll_timeout_atomic(se->base + 
>> SE_GENI_M_IRQ_STATUS, val,
>> +                           val & M_CMD_CANCEL_EN, 10, 50000)) {
>> +            writel_relaxed(M_CMD_CANCEL_EN, se->base + 
>> SE_GENI_M_IRQ_CLEAR);
>> +            return NOTIFY_OK;
> Looks like a successful cancel here returns NOTIFY_OK directly, 
> skipping the FSM reset block below it entirely. Is that the correct 
> expectation ?> +        }

If the cancel operation succeeds, an FSM reset is not required. If it 
fails, the driver proceeds with an abort sequence followed by an FSM reset.


Thanks,

Praveen Talari

>> +    }
>> +
>> +    geni_se_abort_m_cmd(se);
>> +    if (!readl_poll_timeout_atomic(se->base + SE_GENI_M_IRQ_STATUS, 
>> val,
>> +                       val & M_CMD_ABORT_EN, 10, 50000))
>> +        writel_relaxed(M_CMD_ABORT_EN, se->base + SE_GENI_M_IRQ_CLEAR);
>> +
>> +    if (mas->cur_xfer_mode == GENI_SE_DMA) {
>> +        writel_relaxed(1, se->base + SE_DMA_TX_FSM_RST);
>> +        readl_poll_timeout_atomic(se->base + SE_DMA_TX_IRQ_STAT, val,
>> +                      val & TX_RESET_DONE, 10, 50000);
>> +        writel_relaxed(val, se->base + SE_DMA_TX_IRQ_CLR);
>> +
>> +        writel_relaxed(1, se->base + SE_DMA_RX_FSM_RST);
>> +        readl_poll_timeout_atomic(se->base + SE_DMA_RX_IRQ_STAT, val,
>> +                      val & RX_RESET_DONE, 10, 50000);
>> +        writel_relaxed(val, se->base + SE_DMA_RX_IRQ_CLR);
>> +    }
>> +
>> +    return NOTIFY_OK;
>> +}
>> +
>> +static void spi_geni_unregister_notifiers(void *data)
>> +{
>> +    struct spi_geni_master *mas = data;
>> +
>> +    atomic_notifier_chain_unregister(&panic_notifier_list, 
>> &mas->panic_nb);
>> +}
>> +
>>   static int spi_geni_probe(struct platform_device *pdev)
>>   {
>>       int ret, irq;
>> @@ -1161,6 +1220,15 @@ static int spi_geni_probe(struct 
>> platform_device *pdev)
>>       if (ret)
>>           return ret;
>>   +    mas->panic_nb.notifier_call = spi_geni_panic_notifier;
>> +    ret = atomic_notifier_chain_register(&panic_notifier_list, 
>> &mas->panic_nb);
>> +    if (ret)
>> +        return ret;
>> +
>> +    ret = devm_add_action_or_reset(dev, 
>> spi_geni_unregister_notifiers, mas);
>> +    if (ret)
>> +        return ret;
>> +
>>       return devm_spi_register_controller(dev, spi);
>>   }
>>
>