PCI: Disable broken FLR on MediaTek MT7925

PATCH Applied Jose Ignacio Tornos Martinez 5 participants 7 messages May 22 – Jun 9 PCI

Share & tools

Jose Ignacio Tornos Martinez

author

2026-05-22 07:06 UTC #0 lore raw

PATCH v4 1/1 PCI: Disable broken FLR on MediaTek MT7925

The MediaTek MT7925 WiFi device advertises FLR capability, but it does not work correctly. This manifests in VFIO passthrough scenarios: normal VM operation works fine, including clean shutdown/reboot. However, when the VM terminates uncleanly (crash, force-off), VFIO attempts to reset the device before it can be assigned to another VM. Because FLR is broken, the reset fails preventing reuse.

This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms. The MT7922 issue manifests as config read failures (returning ~0) after FLR. The MT7925 shows different behavior: config reads work correctly after FLR, but firmware communication fails.

First VM start with MT7925 works fine:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:

    20260106153120

After force reset or VM crash, when VFIO attempts FLR to reset the device for reassignment, firmware initialization fails:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout mt7925e 0000:08:00.0: Failed to get patch semaphore [Repeats with increasing sequence numbers 2-10]
mt7925e 0000:08:00.0: hardware init failed

The driver cannot acquire the patch semaphore needed for firmware initialization, indicating that FLR does not properly reset the firmware state. The device remains in this broken state until physical power cycle.

Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset, which successfully resets the device and allows reinitialization for VFIO passthrough reuse.

Signed-off-by Jose Ignacio Tornos Martinez <[email protected]>

---
v4: Improved commit message with specific dmesg evidence showing firmware
initialization failure after FLR (Bjorn Helgaas feedback)
v2: https://lore.kernel.org/all/[email protected]/

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

drivers/pci/quirks.c +2 -0

index 000000000000..111111111111 100644
@@ -5607,6 +5607,7 @@
  * Intel 82579LM Gigabit Ethernet Controller 0x1502
  * Intel 82579V Gigabit Ethernet Controller 0x1503
  * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
+ * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
  */
 static void quirk_no_flr(struct pci_dev *dev)
 {

@@ -5617,6 +5618,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
 
 /* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
 static void quirk_no_flr_snet(struct pci_dev *dev)

--
2.53.0

[email protected]

AI review

2026-05-22 07:29 UTC #1 lore raw

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The FLR disable quirk for the MediaTek MT7925 is incomplete as it misses the alternative PCI device ID 0x0717. --

commit 05ad422b1a9dbfc144c4f93e78328e8fa0ea98dc
Author: Jose Ignacio Tornos Martinez <[email protected]>

PCI: Disable broken FLR on MediaTek MT7925

This commit disables Function Level Reset (FLR) for the MediaTek MT7925 device by adding a quirk for device ID 0x7925. This prevents the device from becoming unrecoverable after an unclean VM shutdown in VFIO passthrough scenarios.

Quoted 12 lines

drivers/pci/quirks.c +1 -0

index caaed1a01dc02..e49136ac5dbfb 100644
@@ -5605,6 +5605,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x443, quirk_intel_qat_vf_cap);
  * Intel 82579LM Gigabit Ethernet Controller 0x1502
  * Intel 82579V Gigabit Ethernet Controller 0x1503
  * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
+ * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
  */
 static void quirk_no_flr(struct pci_dev *dev)
 {

[ ... ]

drivers/pci/quirks.c DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x17f0, quirk_no_flr); · line 5623

Quoted 5 lines

drivers/pci/quirks.c +1 -0

@@ -5619,6 +5620,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x17f0, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);

[Severity: High]
This isn't a bug introduced by this patch, but the FLR disable quirk for the MT7925 appears to be missing an alternative device ID.

Looking at the MT7925 PCI driver, it explicitly binds to two device IDs:

drivers/net/wireless/mediatek/mt76/mt7925/pci.c:mt7925_pci_device_table[] = {
        { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x7925),
                .driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
        { PCI_DEVICE(PCI_VENDOR_ID_MEDIATEK, 0x0717),
                .driver_data = (kernel_ulong_t)MT7925_FIRMWARE_WM },
        { },
};

Since both IDs represent the same hardware family and share the same firmware, could device ID 0x0717 exhibit the exact same broken FLR behavior?

Should 0x0717 be added to the quirk list to prevent it from being permanently bricked during VM crash recovery?

Signature · 1 line

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

[email protected]

Reviewed-by Manivannan Sadhasivam on v4 1/1

2026-06-09 13:36 UTC #2 lore raw

In reply to Jose Ignacio Tornos Martinez

Quoted 30 lines · Jose Ignacio Tornos Martinez

The MediaTek MT7925 WiFi device advertises FLR capability, but it does not work correctly. This manifests in VFIO passthrough scenarios: normal VM operation works fine, including clean shutdown/reboot. However, when the VM terminates uncleanly (crash, force-off), VFIO attempts to reset the device before it can be assigned to another VM. Because FLR is broken, the reset fails preventing reuse.
This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms. The MT7922 issue manifests as config read failures (returning ~0) after FLR. The MT7925 shows different behavior: config reads work correctly after FLR, but firmware communication fails.
First VM start with MT7925 works fine:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
    20260106153120
After force reset or VM crash, when VFIO attempts FLR to reset the device for reassignment, firmware initialization fails:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout mt7925e 0000:08:00.0: Failed to get patch semaphore [Repeats with increasing sequence numbers 2-10]
mt7925e 0000:08:00.0: hardware init failed
The driver cannot acquire the patch semaphore needed for firmware initialization, indicating that FLR does not properly reset the firmware state. The device remains in this broken state until physical power cycle.

Quoted 5 lines

Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset, which successfully resets the device and allows reinitialization for VFIO passthrough reuse.
Signed-off-by Jose Ignacio Tornos Martinez <[email protected]>

Reviewed-by Manivannan Sadhasivam <[email protected]>

- Mani

Quoted 29 lines

---
v4: Improved commit message with specific dmesg evidence showing firmware
initialization failure after FLR (Bjorn Helgaas feedback)
v2: https://lore.kernel.org/all/[email protected]/

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

drivers/pci/quirks.c +2 -1

index 000000000000..111111111111 100644
@@ -5607,6 +5607,7 @@
  * Intel 82579LM Gigabit Ethernet Controller 0x1502
  * Intel 82579V Gigabit Ethernet Controller 0x1503
  * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
+ * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
  */
 static void quirk_no_flr(struct pci_dev *dev)
 {

@@ -5617,6 +5618,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
 
 /* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
 static void quirk_no_flr_snet(struct pci_dev *dev)
--

Quoted 4 lines

2.53.0

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

Bjorn Helgaas

2026-06-09 14:39 UTC #3 lore raw

[cc list trimmed]

Quoted 32 lines · On Tue, Jun 09, 2026 at 06:36:38AM -0700, [email protected] wrote:

Quoted 30 lines · Jose Ignacio Tornos Martinez
The MediaTek MT7925 WiFi device advertises FLR capability, but it does not work correctly. This manifests in VFIO passthrough scenarios: normal VM operation works fine, including clean shutdown/reboot. However, when the VM terminates uncleanly (crash, force-off), VFIO attempts to reset the device before it can be assigned to another VM. Because FLR is broken, the reset fails preventing reuse.
This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms. The MT7922 issue manifests as config read failures (returning ~0) after FLR. The MT7925 shows different behavior: config reads work correctly after FLR, but firmware communication fails.
First VM start with MT7925 works fine:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
    20260106153120
After force reset or VM crash, when VFIO attempts FLR to reset the device for reassignment, firmware initialization fails:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout mt7925e 0000:08:00.0: Failed to get patch semaphore [Repeats with increasing sequence numbers 2-10]
mt7925e 0000:08:00.0: hardware init failed
The driver cannot acquire the patch semaphore needed for firmware initialization, indicating that FLR does not properly reset the firmware state. The device remains in this broken state until physical power cycle.

Quoted 7 lines

Quoted 5 lines
Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset, which successfully resets the device and allows reinitialization for VFIO passthrough reuse.
Signed-off-by Jose Ignacio Tornos Martinez <[email protected]>
Reviewed-by Manivannan Sadhasivam <[email protected]>

Just FYI, b4 complains:

NOTE: some trailers ignored due to from/email mismatches:
! Trailer: Reviewed-by: Manivannan Sadhasivam <[email protected]>
Msg From: [email protected] <[email protected]>

I applied your R-b manually.

Bjorn Helgaas

Applied

2026-06-09 14:45 UTC #4 lore raw

In reply to Jose Ignacio Tornos Martinez

[cc->to: Alex]

Quoted 30 lines · Jose Ignacio Tornos Martinez

The MediaTek MT7925 WiFi device advertises FLR capability, but it does not work correctly. This manifests in VFIO passthrough scenarios: normal VM operation works fine, including clean shutdown/reboot. However, when the VM terminates uncleanly (crash, force-off), VFIO attempts to reset the device before it can be assigned to another VM. Because FLR is broken, the reset fails preventing reuse.
This is similar to its predecessor MT7922 (see commit 81f64e925c29 ("PCI:
Avoid FLR for Mediatek MT7922 WiFi")), but with different symptoms. The MT7922 issue manifests as config read failures (returning ~0) after FLR. The MT7925 shows different behavior: config reads work correctly after FLR, but firmware communication fails.
First VM start with MT7925 works fine:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: WM Firmware Version: ____000000, Build Time:
    20260106153120
After force reset or VM crash, when VFIO attempts FLR to reset the device for reassignment, firmware initialization fails:
mt7925e 0000:08:00.0: ASIC revision: 79250000
mt7925e 0000:08:00.0: Message 00000010 (seq 1) timeout mt7925e 0000:08:00.0: Failed to get patch semaphore [Repeats with increasing sequence numbers 2-10]
mt7925e 0000:08:00.0: hardware init failed
The driver cannot acquire the patch semaphore needed for firmware initialization, indicating that FLR does not properly reset the firmware state. The device remains in this broken state until physical power cycle.

Quoted 5 lines

Disable FLR for MT7925 so the PCI core falls back to Secondary Bus Reset, which successfully resets the device and allows reinitialization for VFIO passthrough reuse.
Signed-off-by Jose Ignacio Tornos Martinez <[email protected]>

Applied to pci/virtualization for v7.2, thanks!

Alex, are you OK with this? The v2 conversation talks about SBR also being broken, but maybe that turned out to be a red herring?

https://lore.kernel.org/linux-pci/[email protected]/t/#u

Quoted 31 lines

---
v4: Improved commit message with specific dmesg evidence showing firmware
initialization failure after FLR (Bjorn Helgaas feedback)
v2: https://lore.kernel.org/all/[email protected]/

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

drivers/pci/quirks.c +2 -1

index 000000000000..111111111111 100644
@@ -5607,6 +5607,7 @@
  * Intel 82579LM Gigabit Ethernet Controller 0x1502
  * Intel 82579V Gigabit Ethernet Controller 0x1503
  * Mediatek MT7922 802.11ax PCI Express Wireless Network Adapter
+ * Mediatek MT7925 802.11be PCI Express Wireless Network Adapter
  */
 static void quirk_no_flr(struct pci_dev *dev)
 {

@@ -5617,6 +5618,7 @@ DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x7901, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1502, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_INTEL, 0x1503, quirk_no_flr);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x0616, quirk_no_flr);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_MEDIATEK, 0x7925, quirk_no_flr);
 
 /* FLR may cause the SolidRun SNET DPU (rev 0x1) to hang */
 static void quirk_no_flr_snet(struct pci_dev *dev)
--

2.53.0

Jose Ignacio Tornos Martinez

author

2026-06-09 15:33 UTC #5 lore raw

Hello Bjorn,

Quoted 4 lines

Alex, are you OK with this? The v2 conversation talks about SBR also being broken, but maybe that turned out to be a red herring?
https://lore.kernel.org/linux-pci/[email protected]/t/#u

Alex can answer better, but to clarify: SBR works correctly for MT7925e. The confusion in v2 was because I initially grouped MT7925e together with Qualcomm devices (WCN6855, WCN7850, SDX modems) to try to fix their reset issues. Alex suggested testing SBR for all of them, which revealed they have different issues:
- MT7925e: FLR advertised but broken, SBR works fine (this patch - quirk_no_flr)
- Qualcomm devices: No FLR capability, SBR is broken (separate series with quirk_no_bus_reset + device-specific reset)
So I split them into separate patches since the root causes are different. This fix for MT7925e (quirk_no_flr) removes the broken FLR and allows the working SBR to be used.

Thanks

Best regards
Jose Ignacio

Alex Williamson

2026-06-09 16:44 UTC #6 lore raw

Quoted 7 lines · On Tue, 9 Jun 2026 17:33:33 +0200 Jose Ignacio Tornos Martinez…

Hello Bjorn,
Quoted 4 lines
Alex, are you OK with this? The v2 conversation talks about SBR also being broken, but maybe that turned out to be a red herring?
https://lore.kernel.org/linux-pci/[email protected]/t/#u

Quoted 11 lines

Alex can answer better, but to clarify: SBR works correctly for MT7925e. The confusion in v2 was because I initially grouped MT7925e together with Qualcomm devices (WCN6855, WCN7850, SDX modems) to try to fix their reset issues. Alex suggested testing SBR for all of them, which revealed they have different issues:
- MT7925e: FLR advertised but broken, SBR works fine (this patch - quirk_no_flr)
- Qualcomm devices: No FLR capability, SBR is broken (separate series with quirk_no_bus_reset + device-specific reset)
So I split them into separate patches since the root causes are different. This fix for MT7925e (quirk_no_flr) removes the broken FLR and allows the working SBR to be used.

Yes, this patch follows our standard practice of quirking out known broken reset mechanisms and the qcom devices are now handled in a different series. I'm ok with this. Thanks,

Alex