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

[Praveen Talari <praveen.talari@oss.qualcomm.com>]

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),
>>
>