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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Polling MMIO registers and issuing flush reads on a disconnected PCIe link will trigger Master Aborts, escalating to AER errors and kernel panics on strict architectures.
--

--- Patch [1]: [PATCH v13] PCI: Add device-specific reset for Qualcomm devices ---
commit 8de0dab811e2555e876d5163ff0092117c834bb3
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Add device-specific reset for Qualcomm devices

This commit adds device-specific reset methods for certain Qualcomm PCIe
devices (WCN6855/WCN7850 WLAN cards and SDX62/SDX65 modems) that lack
working reset methods for VFIO passthrough. It implements hardware reset
sequences using BAR-space registers via SoC global reset and MHI SoC reset
mechanisms.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index b09f27f7846fc..c3799e6c58584 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
[ ... ]
> @@ -4227,6 +4228,118 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
[ ... ]
> +static int reset_qualcomm_wlan(struct pci_dev *pdev, bool probe)
> +{
[ ... ]
> +	val |= QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;
> +	iowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
> +	ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
> +
> +	msleep(10);
> +
> +	val &= ~QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V;
> +	iowrite32(val, bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
> +	ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
> +
> +	msleep(10);
> +
> +	ret = read_poll_timeout(ioread32, val,
> +				!PCI_POSSIBLE_ERROR(val),
> +				20 * USEC_PER_MSEC,
> +				5 * USEC_PER_SEC, false,
> +				bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);

[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?

[ ... ]
> +static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
> +{
[ ... ]
> +	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
> +	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);

[Severity: High]
Could this immediate ioread32 flush read also trigger a fatal Master Abort if
the link drops instantly after writing the MHI SoC reset request?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260721081301.205374-1-jtornosm@redhat.com?part=1