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

Reviewed-by: Manivannan Sadhasivam <mani@xxxxxxxxxx>

- 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@xxxxxxxxxx/
>
>  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
>
>
>

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