[PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

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

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 <jtornosm@redhat.com>
---
v4: Improved commit message with specific dmesg evidence showing firmware
  initialization failure after FLR (Bjorn Helgaas feedback)
v2: https://lore.kernel.org/all/20260521061205.12727-1-jtornosm@redhat.com/

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

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 000000000000..111111111111 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -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

Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[sashiko-bot]

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 <jtornosm@redhat.com>

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.

> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index caaed1a01dc02..e49136ac5dbfb 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -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)
>  {

[ ... ]

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

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

Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[manisadhasivam.linux]

On Fri, 22 May 2026 09:06:46 +0200, Jose Ignacio Tornos Martinez
<jtornosm@redhat.com> said:
> 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 <jtornosm@redhat.com>

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

- Mani

> ---
> v4: Improved commit message with specific dmesg evidence showing firmware
>   initialization failure after FLR (Bjorn Helgaas feedback)
> v2: https://lore.kernel.org/all/20260521061205.12727-1-jtornosm@redhat.com/
>
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 000000000000..111111111111 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -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
>
>
>

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

Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[Bjorn Helgaas]

[cc list trimmed]

On Tue, Jun 09, 2026 at 06:36:38AM -0700, manisadhasivam.linux@gmail.com wrote:
> On Fri, 22 May 2026 09:06:46 +0200, Jose Ignacio Tornos Martinez
> <jtornosm@redhat.com> said:
> > 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 <jtornosm@redhat.com>
> 
> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

Just FYI, b4 complains:

  NOTE: some trailers ignored due to from/email mismatches:
      ! Trailer: Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
       Msg From: manisadhasivam.linux@gmail.com <manisadhasivam.linux@gmail.com>

I applied your R-b manually.

Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[Bjorn Helgaas]

[cc->to: Alex]

On Fri, May 22, 2026 at 09:06:46AM +0200, Jose Ignacio Tornos Martinez wrote:
> 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 <jtornosm@redhat.com>

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/20260508145153.717641-1-jtornosm@redhat.com/t/#u

> ---
> v4: Improved commit message with specific dmesg evidence showing firmware
>   initialization failure after FLR (Bjorn Helgaas feedback)
> v2: https://lore.kernel.org/all/20260521061205.12727-1-jtornosm@redhat.com/
> 
>  drivers/pci/quirks.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 000000000000..111111111111 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -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
> 

Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[Jose Ignacio Tornos Martinez]

Hello Bjorn,


> 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/20260508145153.717641-1-jtornosm@redhat.com/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

Re: [PATCH v4] PCI: Disable broken FLR on MediaTek MT7925

[Alex Williamson]

On Tue,  9 Jun 2026 17:33:33 +0200
Jose Ignacio Tornos Martinez <jtornosm@redhat.com> wrote:

> Hello Bjorn,
> 
> 
> > 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/20260508145153.717641-1-jtornosm@redhat.com/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.

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