[PATCH v15 0/2] PCI: Add device-specific reset for Qualcomm devices

[PATCH v15 0/2] PCI: Add device-specific reset for Qualcomm devices

[Jose Ignacio Tornos Martinez]

Some Qualcomm PCIe devices (WCN6855, WCN7850 WLAN; SDX62/SDX65 modems)
lack working reset methods for VFIO passthrough scenarios. These devices
have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
broken bus reset.

Standard reset methods were already disabled for these devices by commit
6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi,
SDX62/SDX65 modems") because they were not working (quirk_no_bus_reset).

VFIO attempts to reset devices on every reassignment:
- For the listed modems, without a proper reset capability, these devices
never successfully initialize even on first VM assignment.
- For the listed WLAN devices, without a working reset method, the attempt
fails. On clean VM shutdown, the guest driver properly deinitializes the
device via .shutdown/.remove callbacks, leaving it in a usable state despite
the failed reset. However, on unclean VM termination (crash, force-off), the
guest driver callbacks are not triggered, the device remains in an undefined
state (DMA active, interrupts enabled, etc.), and without a working reset it
cannot be reused.

Add device-specific reset methods using BAR-space hardware reset registers
that exist in these devices:

  Patch 1: SDX62/SDX65 modem reset via MHI SoC reset
  Patch 2: WCN6855/WCN7850 WLAN reset via SoC global reset

These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios, allowing
to enforce isolation between successive passthrough users.

Testing shows stable operation over 100+ VM crash/reset cycles. Device-
specific reset is position #1 in the reset hierarchy, so these devices
will use hardware reset as their primary reset method.

Jose Ignacio Tornos Martinez (2):
  PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems
  PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

 drivers/pci/quirks.c | 116 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 116 insertions(+)

---
v15: Address Bjorn Helgaas feedback:
  - Explain the relationship with 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
    WCN6855/WCN7850 WiFi, SDX62/SDX65 modems") and previous status.
  - No code changes from v14, only commit message clarifications (Mani's
    Reviewed-by and Alex's Acked-by retained)
v14: https://lore.kernel.org/all/20260917071651.14174-1-jtornosm@redhat.com/

--
2.54.0

[PATCH v15 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[Jose Ignacio Tornos Martinez]

Qualcomm SDX62/SDX65 5G modems (17cb:0308) lack working reset methods for
VFIO passthrough scenarios. These devices have no FLR capability, advertise
NoSoftRst+ (blocking PM reset), and have broken bus reset.

Standard reset methods were already disabled for these devices by commit
6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi,
SDX62/SDX65 modems") because they were not working (quirk_no_bus_reset).

VFIO attempts to reset devices on every reassignment. Without a proper
reset capability, these devices never successfully initialize even on first
VM assignment.

Add a device-specific reset method using BAR-space hardware reset registers
that exist in these devices.

SDX62/SDX65 modem devices use MHI SoC reset via BAR0 (sequence from MHI
driver: mhi_soc_reset(), mhi_pci_reset_prepare()):
- Write reset request to offset 0xb0
- Wait 2 seconds for reset completion

These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios, allowing
to enforce isolation between successive passthrough users.

Testing shows stable operation over 109 VM crash/reset cycles. Device-
specific reset is position #1 in the reset hierarchy, so these Qualcomm
devices will use hardware reset as their primary reset method.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Alex Williamson <alex@shazbot.org>
---
v15: Address Bjorn Helgaas feedback:
    - Explain the relationship with 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
    WCN6855/WCN7850 WiFi, SDX62/SDX65 modems") and previous status.
    - No code changes from v14, only commit message clarification (Mani's
    Reviewed-by and Alex's Acked-by retained)
v14: https://lore.kernel.org/all/20260917071651.14174-2-jtornosm@redhat.com/

 drivers/pci/quirks.c | 40 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 40 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index de9bbccda21f..e72af7d2c775 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -4230,6 +4230,45 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }
 
+#define MHI_SOC_RESET_REQ_OFFSET		0xb0
+#define MHI_SOC_RESET_REQ			BIT(0)
+
+/*
+ * Qualcomm modem device-specific reset using MHI SoC reset via BAR0
+ * register.
+ */
+static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
+{
+	void __iomem *bar;
+	u16 cmd;
+
+	if (probe)
+		return 0;
+
+	if (pdev->current_state != PCI_D0)
+		return -EINVAL;
+
+	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+	bar = pci_iomap(pdev, 0, 0);
+	if (!bar) {
+		pci_write_config_word(pdev, PCI_COMMAND, cmd);
+		return -ENODEV;
+	}
+
+	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
+	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
+
+	/* Be sure device reset has been executed */
+	msleep(2000);
+
+	pci_iounmap(pdev, bar);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+	return 0;
+}
+
 static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82599_SFP_VF,
 		 reset_intel_82599_sfp_virtfn },
@@ -4245,6 +4284,7 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 		reset_chelsio_generic_dev },
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
+	{ PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */
 	{ 0 }
 };
 
-- 
2.54.0

Re: [PATCH v15 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] pci: restoring PCI_COMMAND enables memory decode with 0-initialized BARs
--

commit 760a69f51b8830cd55e316a784f0c3e65a321b72
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

This commit introduces a device-specific hardware reset mechanism for Qualcomm 
SDX62/SDX65 modems. It uses a sequence of writes to BAR0 MHI SoC reset 
registers to properly initialize the devices for VFIO passthrough.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index de9bbccda21fd..e72af7d2c7755 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
[ ... ]
> @@ -4230,6 +4230,45 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
[ ... ]
> +static int reset_qualcomm_modem(struct pci_dev *pdev, bool probe)
> +{
> +	void __iomem *bar;
> +	u16 cmd;
> +
> +	if (probe)
> +		return 0;
> +
> +	if (pdev->current_state != PCI_D0)
> +		return -EINVAL;
> +
> +	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
> +	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
> +
> +	bar = pci_iomap(pdev, 0, 0);
> +	if (!bar) {
> +		pci_write_config_word(pdev, PCI_COMMAND, cmd);
> +		return -ENODEV;
> +	}
> +
> +	iowrite32(MHI_SOC_RESET_REQ, bar + MHI_SOC_RESET_REQ_OFFSET);
> +	ioread32(bar + MHI_SOC_RESET_REQ_OFFSET);
> +
> +	/* Be sure device reset has been executed */
> +	msleep(2000);
> +
> +	pci_iounmap(pdev, bar);
> +	pci_write_config_word(pdev, PCI_COMMAND, cmd);

[Severity: High]
Could restoring PCI_COMMAND here cause a system address conflict?

If the saved cmd originally had the PCI_COMMAND_MEMORY bit set (for example,
when called from a path like Xen PCIBACK's pcistub_reset_device_state),
writing it back immediately enables memory decode. Because the hardware reset
has just occurred, the device's BARs will have been cleared to 0.

Does this create a risk of silent memory corruption by allowing the device to
claim physical address 0 before the PCI core has a chance to restore the BARs
properly in pci_restore_config_space()?

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

Re: [PATCH v15 1/2] PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems

[Jose Ignacio Tornos Martinez]

> [Severity: High]
> Could restoring PCI_COMMAND here cause a system address conflict?
>
> If the saved cmd originally had the PCI_COMMAND_MEMORY bit set (for example,
> when called from a path like Xen PCIBACK's pcistub_reset_device_state),
> writing it back immediately enables memory decode. Because the hardware reset
> has just occurred, the device's BARs will have been cleared to 0.
>
> Does this create a risk of silent memory corruption by allowing the device to
> claim physical address 0 before the PCI core has a chance to restore the BARs
> properly in pci_restore_config_space()?

The MHI SoC reset is a device-internal reset that resets the device's
firmware logic, not a PCIe fundamental reset. PCI config space
(including BARs) is maintained across this type of reset, so BARs
are not cleared to 0. The PCI_COMMAND save/restore just enables
memory access for the reset operation.

[PATCH v15 2/2] PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

[Jose Ignacio Tornos Martinez]

Qualcomm WCN6855 (17cb:1103) and WCN7850 (17cb:1107) WLAN devices lack
working reset methods for VFIO passthrough scenarios. These devices have no
FLR capability, advertise NoSoftRst+ (blocking PM reset), and have broken
bus reset.

Standard reset methods were already disabled for these devices by commit
6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi,
SDX62/SDX65 modems") because they were not working (quirk_no_bus_reset).

Resets of this device always failed prior to this commit, so VFIO on
the host could not enforce isolation between successive passthrough
users.

If a guest driver deinitialized the device, it may have been functional
if passed through to a subsequent guest, despite the lack of isolation.
Otherwise the device may have been left in an undefined state (e.g., DMA
and interrupts active) and unusable.

Add a device-specific reset method using BAR-space hardware reset
registers that exist in these devices.

WCN6855/WCN7850 WLAN devices use SoC global reset via BAR0 (sequence from
ath11k/ath12k driver: ath11k_pci_soc_global_reset(), ath11k_pci_sw_reset(),
ath11k_mhi_set_mhictrl_reset()):
- Write/clear reset bit at offset 0x3008
- Wait for PCIe link recovery (up to 5 seconds)
- Clear MHI controller SYSERR status at offset 0x38

These are true hardware reset mechanisms (not power management or firmware
error recovery), providing proper device reset for VFIO scenarios.

Testing shows stable operation over 100+ VM crash/reset cycles, compared
to previous approaches that failed after ~30 cycles. Device-specific reset
is position #1 in the reset hierarchy, so these Qualcomm devices will use
hardware reset as their primary reset method.

Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Acked-by: Alex Williamson <alex@shazbot.org>
---
v15: Address Bjorn Helgaas feedback:
  - Explain the relationship with 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
    WCN6855/WCN7850 WiFi, SDX62/SDX65 modems") and previous status.
  - Emphasize isolation.
  - No code changes from v14, only commit message clarification (Mani's
    Reviewed-by and Alex's Acked-by retained)
v14: https://lore.kernel.org/all/20260917071651.14174-3-jtornosm@redhat.com/

 drivers/pci/quirks.c | 76 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 76 insertions(+)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index e72af7d2c775..e800dd517614 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -22,6 +22,7 @@
 #include <linux/isa-dma.h> /* isa_dma_bridge_buggy */
 #include <linux/init.h>
 #include <linux/iommu.h>
+#include <linux/iopoll.h>
 #include <linux/delay.h>
 #include <linux/acpi.h>
 #include <linux/dmi.h>
@@ -4230,6 +4231,79 @@ static int reset_hinic_vf_dev(struct pci_dev *pdev, bool probe)
 	return 0;
 }
 
+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET	0x3008
+#define QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET_V	BIT(0)
+#define QUALCOMM_WLAN_MHICTRL			0x38
+#define QUALCOMM_WLAN_MHICTRL_RESET_MASK	0x2
+
+/*
+ * Qualcomm WLAN device-specific reset using SoC global reset via BAR0
+ * registers.
+ */
+static int reset_qualcomm_wlan(struct pci_dev *pdev, bool probe)
+{
+	void __iomem *bar;
+	u32 val;
+	u16 cmd;
+	int ret;
+
+	if (probe)
+		return 0;
+
+	if (pdev->current_state != PCI_D0)
+		return -EINVAL;
+
+	pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd | PCI_COMMAND_MEMORY);
+
+	bar = pci_iomap(pdev, 0, 0);
+	if (!bar) {
+		pci_write_config_word(pdev, PCI_COMMAND, cmd);
+		return -ENODEV;
+	}
+
+	val = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);
+	if (PCI_POSSIBLE_ERROR(val)) {
+		ret = -ENODEV;
+		goto out_restore;
+	}
+	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);
+	if (ret) {
+		pci_err(pdev, "PCIe link failed to recover after reset\n");
+		goto out_restore;
+	}
+
+	/* After SOC_GLOBAL_RESET, MHISTATUS may still have SYSERR bit set
+	 * and thus need to set MHICTRL_RESET to clear SYSERR.
+	 */
+	iowrite32(QUALCOMM_WLAN_MHICTRL_RESET_MASK, bar + QUALCOMM_WLAN_MHICTRL);
+	ioread32(bar + QUALCOMM_WLAN_MHICTRL);
+
+	msleep(10);
+
+out_restore:
+	pci_iounmap(pdev, bar);
+	pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+	return ret;
+}
+
 #define MHI_SOC_RESET_REQ_OFFSET		0xb0
 #define MHI_SOC_RESET_REQ			BIT(0)
 
@@ -4285,6 +4359,8 @@ static const struct pci_dev_reset_methods pci_dev_reset_methods[] = {
 	{ PCI_VENDOR_ID_HUAWEI, PCI_DEVICE_ID_HINIC_VF,
 		reset_hinic_vf_dev },
 	{ PCI_VENDOR_ID_QCOM, 0x0308, reset_qualcomm_modem }, /* SDX62/SDX65 modems */
+	{ PCI_VENDOR_ID_QCOM, 0x1103, reset_qualcomm_wlan },  /* WCN6855 WLAN */
+	{ PCI_VENDOR_ID_QCOM, 0x1107, reset_qualcomm_wlan },  /* WCN7850 WLAN */
 	{ 0 }
 };
 
-- 
2.54.0

Re: [PATCH v15 2/2] PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] pci: out-of-bounds MMIO read in reset_qualcomm_wlan due to unverified BAR length
--

commit 0bf7ebc364dec72a7a29e6f1e5602ff74fc3a191
Author: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>

PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

Qualcomm WCN6855 and WCN7850 WLAN devices lack working reset methods for
VFIO passthrough scenarios. This commit adds a device-specific reset method
using BAR-space hardware reset registers that exist in these devices.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index e72af7d2c7755..e800dd517614e 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c

[ ... ]

> +static int reset_qualcomm_wlan(struct pci_dev *pdev, bool probe)
> +{
> +	void __iomem *bar;
> +	u32 val;
> +	u16 cmd;
> +	int ret;

[ ... ]

> +	bar = pci_iomap(pdev, 0, 0);
> +	if (!bar) {
> +		pci_write_config_word(pdev, PCI_COMMAND, cmd);
> +		return -ENODEV;
> +	}
> +
> +	val = ioread32(bar + QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET);

[Severity: Medium]
Could this lead to an out-of-bounds MMIO read if the device's BAR 0 is
shorter than 0x300C?

The code unconditionally accesses offset 0x3008
(QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET) here without verifying if the mapped
memory region is large enough. If an untrusted hardware actor or a spoofed
device exposes a smaller BAR 0 (e.g., 4KB), this access could exceed the
mapped memory boundary and cause a kernel panic due to a page fault.

Would it be safer to verify that pci_resource_len(pdev, 0) is at least
large enough to contain this offset before mapping and reading it?

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

Re: [PATCH v15 2/2] PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN

[Jose Ignacio Tornos Martinez]

> [Severity: Medium]
> Could this lead to an out-of-bounds MMIO read if the device's BAR 0 is
> shorter than 0x300C?
>
> The code unconditionally accesses offset 0x3008
> (QUALCOMM_WLAN_PCIE_SOC_GLOBAL_RESET) here without verifying if the mapped
> memory region is large enough. If an untrusted hardware actor or a spoofed
> device exposes a smaller BAR 0 (e.g., 4KB), this access could exceed the
> mapped memory boundary and cause a kernel panic due to a page fault.
>
> Would it be safer to verify that pci_resource_len(pdev, 0) is at least
> large enough to contain this offset before mapping and reading it?

These are device-specific resets matched by PCI vendor/device ID, so
the BAR0 layout is known and fixed for these devices. The BAR0 size
for these Qualcomm WLAN devices is well above 0x300C.

Re: [PATCH v15 0/2] PCI: Add device-specific reset for Qualcomm devices

[Bjorn Helgaas]

On Mon, Oct 05, 2026 at 12:54:34PM +0200, Jose Ignacio Tornos Martinez wrote:
> Some Qualcomm PCIe devices (WCN6855, WCN7850 WLAN; SDX62/SDX65 modems)
> lack working reset methods for VFIO passthrough scenarios. These devices
> have no FLR capability, advertise NoSoftRst+ (blocking PM reset), and have
> broken bus reset.
> 
> Standard reset methods were already disabled for these devices by commit
> 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm WCN6855/WCN7850 WiFi,
> SDX62/SDX65 modems") because they were not working (quirk_no_bus_reset).
> 
> VFIO attempts to reset devices on every reassignment:
> - For the listed modems, without a proper reset capability, these devices
> never successfully initialize even on first VM assignment.
> - For the listed WLAN devices, without a working reset method, the attempt
> fails. On clean VM shutdown, the guest driver properly deinitializes the
> device via .shutdown/.remove callbacks, leaving it in a usable state despite
> the failed reset. However, on unclean VM termination (crash, force-off), the
> guest driver callbacks are not triggered, the device remains in an undefined
> state (DMA active, interrupts enabled, etc.), and without a working reset it
> cannot be reused.
> 
> Add device-specific reset methods using BAR-space hardware reset registers
> that exist in these devices:
> 
>   Patch 1: SDX62/SDX65 modem reset via MHI SoC reset
>   Patch 2: WCN6855/WCN7850 WLAN reset via SoC global reset
> 
> These are true hardware reset mechanisms (not power management or firmware
> error recovery), providing proper device reset for VFIO scenarios, allowing
> to enforce isolation between successive passthrough users.
> 
> Testing shows stable operation over 100+ VM crash/reset cycles. Device-
> specific reset is position #1 in the reset hierarchy, so these devices
> will use hardware reset as their primary reset method.
> 
> Jose Ignacio Tornos Martinez (2):
>   PCI: Add device-specific reset for Qualcomm SDX62/SDX65 modems
>   PCI: Add device-specific reset for Qualcomm WCN6855/WCN7850 WLAN
> 
>  drivers/pci/quirks.c | 116 +++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 116 insertions(+)

Applied to pci/reset for v7.4, thanks!

> ---
> v15: Address Bjorn Helgaas feedback:
>   - Explain the relationship with 6a4f64c3a3ad ("PCI: Avoid SBR for Qualcomm
>     WCN6855/WCN7850 WiFi, SDX62/SDX65 modems") and previous status.
>   - No code changes from v14, only commit message clarifications (Mani's
>     Reviewed-by and Alex's Acked-by retained)
> v14: https://lore.kernel.org/all/20260917071651.14174-1-jtornosm@redhat.com/
> 
> --
> 2.54.0
>