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>

On Tue, 18 Aug 2026 18:58:06 +0530, Praveen Talari wrote:
> spi: qcom-geni: Add shutdown and panic notifier support
> 
> 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.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-7.4

Thanks!

[1/2] spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot
      https://git.kernel.org/broonie/spi/c/3958b39fa5b7
[2/2] spi: qcom-geni: Add panic notifier to cancel and reset DMA during panic
      https://git.kernel.org/broonie/spi/c/b7b192e58f35

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark