[PATCH v9] PCI: Add device-specific reset for Qualcomm devices

[Manivannan Sadhasivam]

On Tue, Jun 23, 2026 at 02:56:35PM +0200, Jose Ignacio Tornos Martinez wrote:
> Hi Mani and Alex,
> 
> Thank you both for the guidance. 
> 
> 
> I think your insight about the BAR-space reset mechanisms is a much better
> approach to have a "real" reset. With that, I've implemented device-specific
> reset functions based on the driver code Mani referenced:
> 
> WCN6855/WCN7850 WiFi (reset_qualcomm_wifi):
> - Uses SoC global reset via BAR0 offset 0x3008
> - Follows the sequence from ath11k_pci_soc_global_reset() /
>   ath12k_pci_soc_global_reset() / ath11k_pci_sw_reset()
> - Set reset bit → 10ms delay → clear reset bit → 10ms delay → verify link
>   recovery (up to 5s)
> - Includes MHI controller reset cleanup (offset 0x38) to clear SYSERR after SoC
>   reset
> - Both WCN6855 and WCN7850 share identical register offsets and reset sequence
> 
> SDX62/SDX65 modems (reset_qualcomm_modem):
> - Uses MHI SoC reset via BAR0 offset 0xb0
> - Follows the sequence from mhi_soc_reset() / mhi_pci_reset_prepare()
> - Write reset request → 2s delay for reset completion
> 
> All implementations follow Alex's pattern: save command register ->
> enable memory decode -> ioremap BAR -> perform reset sequence ->
> iounmap -> restore command.
> Testing results: The implementation shows successful reset behavior for both
> WiFi and modem devices in VFIO passthrough scenarios.
> 

Cool!

> 
> Regarding the approach (quirks.c vs dedicated VFIO driver):
> 
> Mani, I understand your concern about potential conflicts with the native
> drivers. I want to make sure I implement this correctly. Could you clarify
> when you envision the conflict occurring? 
> From what I can see, the native drivers call their reset functions directly
> without using pci_try_reset_function(), so the device-specific reset in
> quirks.c could be enough, but I may be missing some error recovery paths or
> other scenarios.
> 

MHI driver is calling pci_try_reset_function():

$ git grep -r pci_try_reset_function drivers/bus/mhi
drivers/bus/mhi/host/pci_generic.c:     err = pci_try_reset_function(pdev);

So I was worried that it could create conflict. But looking more, I
understood that it won't create any conflict, but just an additional SoC reset:

  pci_try_reset_function()
    -> pci_dev_save_and_disable()
      -> mhi_pci_reset_prepare()
         -> mhi_soc_reset()         <- First reset 
    -> __pci_reset_function_locked()
      -> pci_dev_specific_reset()   <- Second reset

But this additional SoC reset wouldn't cause any issue to the device due to the
2s delay, but the total recovery delay would compound to 4s now.

And that also should be fine as this path gets triggered only when the device
dies during the recovery work (very rare).

So you can implement the reset in quirks.c with device_specific reset.

- Mani

-- 
மணிவண்ணன் சதாசிவம்