wifi: mt76: mt7925: false-positive hard rfkill on MSI Vector A16 HX (MS-15MM)

Sun Aug 9 12:02:34 PDT 2026

Hi,

Since v6.16, mt7925 Wi-Fi is unusable on the MSI Vector A16 HX A8WHG
laptop (board MS-15MM): the interface is reported as rfkill
"Hard blocked: yes" on every boot, and the block cannot be lifted from
software. Windows on the same machine works normally. I have traced
this to a false-positive hardware-rfkill report on this platform and
verified experimentally that the radio is actually functional.

Hardware
--------
- Laptop: MSI Vector A16 HX A8WHG (DMI: sys_vendor "Micro-Star
  International Co., Ltd.", product "Vector A16 HX A8WHG", board
  "MS-15MM"), BIOS E15MMAMS.104 (07/28/2025), EC 15MMIMS1.101
- WLAN: MEDIATEK MT7925 [14c3:7925], subsystem Foxconn [105b:e138]
- Kernel: 6.18.42 (also reproduced by other users on Arch/Fedora/Mint
  kernels >= 6.16; kernels of the 6.12 LTS era are NOT affected)
- Firmware: linux-firmware 20260622, WM firmware build 20260605184805,
  HW/SW version 0x8a108a10

Symptom
-------
- mt7925e probes fine, firmware loads fine.
- As soon as the interface is brought up, rfkill flips to
  "Hard blocked: yes" and the interface is taken down. The block
  persists for the rest of the session.
- NetworkManager logs "Wi-Fi now disabled by radio killswitch" ~1 s
  after activating the device.

Analysis
--------
Commit e54b870212c0 ("wifi: mt76: mt7925: add rfkill_poll for hardware
rfkill", first in v6.16) added:

  __mt7925_start():
      if (phy->chip_cap & MT792x_CHIP_CAP_WF_RF_PIN_CTRL_EVT_EN)
          wiphy_rfkill_start_polling(mphy->hw->wiphy);

  mt7925_rfkill_poll():
      ret = mt7925_mcu_wf_rf_pin_ctrl(phy);   /* MCU_UNI_CMD(RADIO_STATUS) */
      wiphy_rfkill_set_hw_state(hw->wiphy, ret == 0);

On this platform the firmware advertises
MT792x_CHIP_CAP_WF_RF_PIN_CTRL_EVT_EN, and the RADIO_STATUS query
always returns 0 ("RF pin asserted"), so the wiphy is hard-blocked as
soon as polling starts. However, the pin state appears to be a board
wiring/EC defect on this MSI model, not a real kill switch: the radio
demonstrably works, and there is no airplane-mode state that can clear
it (toggling the airplane key, BIOS reset, EC reset, cold boot, and a
Windows full shutdown were all tried by various users without effect).

Experimental verification (on 6.18.42)
--------------------------------------
1. Fresh "modprobe mt7925e" with the interface left down:
   rfkill shows "Hard blocked: no".
2. "ip link set wlan0 up": rfkill flips to "Hard blocked: yes" the
   moment polling starts. Scans return nothing because mac80211
   immediately downs the interface.
3. With a one-line test patch disabling the poll registration in
   __mt7925_start() (rebuilt mt7925-common only, same kernel, same
   firmware): the interface comes up, "iw dev wlan0 scan" returns 19
   BSSs, and NetworkManager can connect normally. The radio is fully
   functional despite the firmware reporting the RF pin as asserted.

So on this platform the new hardware-rfkill support faithfully reports
a bogus pin state and disables a working radio. The Windows MediaTek
driver evidently ignores this pin on this machine, and kernels < 6.16
worked for the same reason.

Community reports of what appears to be the same issue (multiple users,
multiple distros, since around Dec 2025):
- https://discuss.cachyos.org/t/new-laptop-with-mt7925-wifi-adapter-being-hard-blocked-rfkill/23872
- https://discuss.cachyos.org/t/getting-wifi-to-work-on-msi-vector-a16-hx-a8whg/27772
- https://forum-en.msi.com/index.php?threads/wifi-hard-blocked-on-msi-vector-a16-hx-a8whg-linux-ubuntu-24-04-acpi-bios-bug.418090/

(One user in the second thread reported to linux-mediatek earlier this
year; I'm adding the root-cause analysis above.)

Possible fixes
--------------
Would a DMI-based quirk (or a PCI subsystem-vendor/-device based one,
[105b:e138] on this board) that skips wiphy_rfkill_start_polling() on
affected platforms be acceptable? Alternatively the poll result could
be cross-checked before hard-blocking (e.g. ignore a pin that is
asserted from cold boot and never changes state), or a module parameter
could allow affected users to opt out.

I'm happy to test patches on this hardware and to provide any further
debugging output (full dmesg, MCU traces, ACPI tables — note this
BIOS also has duplicate \_SB.PCI0.GPPA/WLAN power objects that ACPICA
rejects with AE_ALREADY_EXISTS at table load; that turned out to be
unrelated to the rfkill issue, but I can share the tables if useful).

Raw data
--------

lspci -nnk:

  05:00.0 Network controller [0280]: MEDIATEK Corp. MT7925 802.11be
          160MHz 2x2 PCIe Wireless Network Adapter [Filogic 360] [14c3:7925]
          Subsystem: Foxconn International, Inc. Device [105b:e138]
          Kernel driver in use: mt7925e

Driver probe (dmesg):

  mt7925e 0000:05:00.0: ASIC revision: 79250000
  mt7925e 0000:05:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260605184651a
  mt7925e 0000:05:00.0: WM Firmware Version: ____000000, Build Time:
20260605184805

Typical boot (journal):

  NetworkManager: rfkill1: found Wi-Fi radio killswitch
    (at /sys/devices/pci0000:00/0000:00:03.2/0000:05:00.0/ieee80211/phy0/rfkill1)
    (driver mt7925e)
  NetworkManager: manager: rfkill: Wi-Fi now disabled by radio killswitch
  wpa_supplicant: rfkill: WLAN hard blocked

Experiment, unpatched 6.18.42 (phy index varies across module reloads):

  # modprobe -r mt7925e && modprobe mt7925e     # interface left down
  # rfkill list
  2: phy1: Wireless LAN
          Soft blocked: no
          Hard blocked: no
  # ip link set wlan0 up && iw dev wlan0 scan   # scan returns nothing
  # rfkill list
  2: phy1: Wireless LAN
          Soft blocked: no
          Hard blocked: yes

Experiment, same kernel/firmware with the test change below:

  # ip link set wlan0 up && iw dev wlan0 scan | grep -c '^BSS'
  19
  # rfkill list
  3: phy2: Wireless LAN
          Soft blocked: no
          Hard blocked: no                      # stays unblocked; NM
connects fine

Test change used for step 3 (diagnostic only, not proposed as the fix):

  --- a/drivers/net/wireless/mediatek/mt76/mt7925/main.c
  +++ b/drivers/net/wireless/mediatek/mt76/mt7925/main.c
  @@ __mt7925_start()
  - if (phy->chip_cap & MT792x_CHIP_CAP_WF_RF_PIN_CTRL_EVT_EN)
  + if (0 && (phy->chip_cap & MT792x_CHIP_CAP_WF_RF_PIN_CTRL_EVT_EN))
    wiphy_rfkill_start_polling(mphy->hw->wiphy);

Thanks,
Jason Zeng