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

[Manivannan Sadhasivam]

On Wed, Jul 22, 2026 at 01:28:13PM +0200, Jose Ignacio Tornos Martinez wrote:
> > [Severity: High]
> > Will this sequence of ioread32 flush reads and
> > read_poll_timeout trigger Master Aborts on architectures
> > with strict error handling?
> >
> > The SoC global reset explicitly drops the device PCIe link.
> > Performing ioread32 flush reads immediately after asserting
> > the reset, and then actively polling the disconnected MMIO
> > space with read_poll_timeout while the link recovers, can
> > result in Unsupported Request errors.
> >
> > On strict platforms like ARM64 or x86 servers with APEI/GHES
> > Firmware First error handling, these can escalate to fatal
> > Uncorrectable Errors and cause a host kernel panic when a
> > guest VM exits.
> >
> > Should this avoid MMIO flush reads during these reset
> > sequences and instead use fixed delays to safely bridge the
> > link-down period?
> 
> The SoC global reset at 0x3008 does not immediately drop the
> PCIe link. The flush reads execute while the device is still
> responsive - the actual reset takes effect during the
> subsequent msleep. The ath11k/ath12k drivers perform the same
> register accesses during this reset sequence, including on
> ARM64 Qualcomm platforms, without issues.
> 

Yes, Qcom devices supporting SoC reset have a mechanism to keep the PCIe link
alive (in L0/L1) when the reset gets triggered in the device. So the register
access is available throughout the reset cycle.

- Mani

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