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

[Jose Ignacio Tornos Martinez]

Hello Bjorn,

Thank you for the feedback.

> How do we know the device is an "undefined state"?  Does it just not
> respond to config accesses?  Is there something in dmesg that shows
> the problem?
> I suppose it's similar to 81f64e925c29 ("PCI: Avoid FLR for Mediatek
> MT7922 WiFi")?
> I guess I'm just looking for some text more specific than "undefined
> state".
You're right, "undefined state" is too vague.
I can prepare v4 with what I've seen is happening . The
symptoms are similar to MT7922 but not identical:
  **First VM start (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/VM crash (FLR attempted, firmware communication broken):**
    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 10 times with increasing seq numbers)
    mt7925e 0000:08:00.0: hardware init failed
Unlike MT7922 which shows config read failures, MT7925e config reads work
correctly after FLR (lspci shows all capabilities). However, firmware
communication is broken - the driver cannot acquire the patch semaphore
needed for firmware initialization. The device remains broken until
physical power cycle.
Secondary Bus Reset (fallback after quirk_no_flr) successfully resets the
device and allows reinitialization.

> Can we get any of the MediaTek folks to comment on this:
> https://sashiko.dev/#/patchset/20260508145153.717641-1-jtornosm@xxxxxxxxxx?part=1
>
> Sashiko suggested that Device ID 0x0717 might have the same FLR
> problem.
I don't have that device to confirm the same behavior. I'll wait for
MediaTek maintainers (now CC'd) to confirm whether 0x0717 exhibits the
same FLR issue. If confirmed, I can add it in a follow-up patch or the
next version.

Thanks

Best regards
José Ignacio