Re: [REGRESSION] mt7925e: fails to read EEPROM MAC on 7.2-rc2, falls back to random MAC (worked on 7.1-rc7 and 7.0.x)

Confirmed -- the patch fixes it.

I applied [email protected] on top of 7.2-rc2 and
booted it on my x86 Strix Halo (MT7925 RZ717, non-OF PCIe card). With the
patch, the "Invalid MAC address, using random address" line is gone and the
adapter comes up with its real EEPROM MAC (ac:f2:3c:35:31:15). Stock 7.2-rc2
without the patch reproduces the random-MAC behaviour on the same hardware.

Tested-by: Brent Paine <[email protected]>

Brent

On Mon, Jul 6, 2026 at 10:21 AM Thorsten Leemhuis
<[email protected]> wrote:
>
>
>
> On 7/6/26 15:35, B X wrote:
> > B X <[email protected]>
> > 8:12 AM (1 hour ago)
> > to linux-wireless, nbd, lorenzo, ryder.lee, shayne.chen, sean.wang,
> > regressions, Brent
> >
> > Hi,
> >
> > Reporting a regression in the mt7925e driver: on Linux 7.2.0-rc2 the adapter
> > fails to read its stored (EEPROM/efuse) MAC address and substitutes a random
> > one. The same hardware read its real MAC correctly on every earlier kernel,
> > including the immediately-preceding boot one day earlier on 7.0.0-22.
>
> Sounds a lot like it's the problem "wifi: mt76: fix MAC address for non
> OF pcie cards" aims to fix:
> https://lore.kernel.org/all/[email protected]/
>
> Would be great if you could confirm.
>
> Ciao, Thorsten
>
> > Verified with Claude Code when my ATT fiber kept failing to pin IP on
> > my Halo Strix
> >
> > Hardware
> > --------
> > MediaTek MT7925 (RZ717) Wi-Fi 7 160MHz
> > PCI ID: [14c3:0717], driver mt7925e
> > Platform: AMD "Strix Halo" (Ryzen AI Max) mini-PC
> > linux-firmware: 20260319.git217ca6e4
> >
> > Symptom (kernel 7.2.0-rc2, 2026-07-06)
> > --------------------------------------
> >   mt7925e 0000:c3:00.0: enabling device (0000 -> 0002)
> >   mt7925e 0000:c3:00.0: ASIC revision: 79250000
> >   mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> >   mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time:
> > 20260106153120
> >   mt7925e 0000:c3:00.0: Invalid MAC address, using random address
> > 12:1f:34:c6:57:04
> >   mt7925e 0000:c3:00.0 wlp195s0: renamed from wlan0
> >
> > The driver then brings the interface up with the random MAC 12:1f:34:c6:57:04.
> >
> > Last known good (kernel 7.0.0-22, 2026-07-05, same machine, no MAC override)
> > ----------------------------------------------------------------------------
> >   mt7925e 0000:c3:00.0: ASIC revision: 79250000
> >   mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> >   mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time:
> > 20260106153120
> >   ...
> >   wlp195s0: authenticate with <ap> (local address=ac:f2:3c:35:31:15)
> >
> > i.e. the real MAC ac:f2:3c:35:31:15 was read straight off the adapter. Note
> > the firmware init lines (ASIC revision, HW/SW Version, WM Firmware Version,
> > build times) are byte-identical between the good and bad boots -- only the
> > kernel differs, and only the MAC read fails. This rules out a firmware or
> > bad-NVRAM cause: the same silicon read the MAC correctly ~24h earlier.
> >
> > Regression range
> > ----------------
> > Confirmed good on: 7.0.0, 7.0.0-22, 7.0.0-27, 7.1.0-rc7 (dozens of boots,
> > journal-verified, no "Invalid MAC address" line on any of them).
> > First and only bad boot: 7.2.0-rc2.
> >
> > So the regression landed between 7.1-rc7 and 7.2-rc2. I have not bisected to
> > the exact commit yet, but I can -- the machine builds kernels quickly -- if a
> > bisect would help pin it down.
> >
> > Not reboot-type dependent: on the good kernels (7.0.0-22 / 7.0.0-27) the
> > correct MAC was read reliably across both warm/clean reboots and cold/hard
> > power cycles. The failure does not correlate with reboot type or chip power
> > state -- it correlates only with the kernel version (7.2-rc2).
> >
> > Impact
> > ------
> > The substituted MAC is random per boot, changing the adapter's L2 identity.
> > This breaks router-side DHCP reservations / fixed-IP allocations keyed on MAC:
> > the host stops receiving its pinned address and lands on an arbitrary lease.
> > Any MT7925 user relying on MAC-based address pinning is affected. Current
> > workaround here is forcing the real MAC via NetworkManager cloned-mac-address.
> >
> > #regzbot introduced: v7.1..v7.2-rc2
> >
> >
> >
> > Thanks,
> >
> >
> > Brent Paine, AWS, CCNP
> >
> > git bkpaine1
> > Medium bkpaine1
> >
> >
> > On Mon, Jul 6, 2026 at 8:12 AM B X <[email protected]> wrote:
> >>
> >> Hi,
> >>
> >> Reporting a regression in the mt7925e driver: on Linux 7.2.0-rc2 the adapter
> >> fails to read its stored (EEPROM/efuse) MAC address and substitutes a random
> >> one. The same hardware read its real MAC correctly on every earlier kernel,
> >> including the immediately-preceding boot one day earlier on 7.0.0-22.
> >>
> >> Verified with Claude Code when my ATT fiber kept failing to pin IP on my Halo Strix
> >>
> >> Hardware
> >> --------
> >> MediaTek MT7925 (RZ717) Wi-Fi 7 160MHz
> >> PCI ID: [14c3:0717], driver mt7925e
> >> Platform: AMD "Strix Halo" (Ryzen AI Max) mini-PC
> >> linux-firmware: 20260319.git217ca6e4
> >>
> >> Symptom (kernel 7.2.0-rc2, 2026-07-06)
> >> --------------------------------------
> >>   mt7925e 0000:c3:00.0: enabling device (0000 -> 0002)
> >>   mt7925e 0000:c3:00.0: ASIC revision: 79250000
> >>   mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> >>   mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120
> >>   mt7925e 0000:c3:00.0: Invalid MAC address, using random address 12:1f:34:c6:57:04
> >>   mt7925e 0000:c3:00.0 wlp195s0: renamed from wlan0
> >>
> >> The driver then brings the interface up with the random MAC 12:1f:34:c6:57:04.
> >>
> >> Last known good (kernel 7.0.0-22, 2026-07-05, same machine, no MAC override)
> >> ----------------------------------------------------------------------------
> >>   mt7925e 0000:c3:00.0: ASIC revision: 79250000
> >>   mt7925e 0000:c3:00.0: HW/SW Version: 0x8a108a10, Build Time: 20260106153007a
> >>   mt7925e 0000:c3:00.0: WM Firmware Version: ____000000, Build Time: 20260106153120
> >>   ...
> >>   wlp195s0: authenticate with <ap> (local address=ac:f2:3c:35:31:15)
> >>
> >> i.e. the real MAC ac:f2:3c:35:31:15 was read straight off the adapter. Note
> >> the firmware init lines (ASIC revision, HW/SW Version, WM Firmware Version,
> >> build times) are byte-identical between the good and bad boots -- only the
> >> kernel differs, and only the MAC read fails. This rules out a firmware or
> >> bad-NVRAM cause: the same silicon read the MAC correctly ~24h earlier.
> >>
> >> Regression range
> >> ----------------
> >> Confirmed good on: 7.0.0, 7.0.0-22, 7.0.0-27, 7.1.0-rc7 (dozens of boots,
> >> journal-verified, no "Invalid MAC address" line on any of them).
> >> First and only bad boot: 7.2.0-rc2.
> >>
> >> So the regression landed between 7.1-rc7 and 7.2-rc2. I have not bisected to
> >> the exact commit yet, but I can -- the machine builds kernels quickly -- if a
> >> bisect would help pin it down.
> >>
> >> Not reboot-type dependent: on the good kernels (7.0.0-22 / 7.0.0-27) the
> >> correct MAC was read reliably across both warm/clean reboots and cold/hard
> >> power cycles. The failure does not correlate with reboot type or chip power
> >> state -- it correlates only with the kernel version (7.2-rc2).
> >>
> >> Impact
> >> ------
> >> The substituted MAC is random per boot, changing the adapter's L2 identity.
> >> This breaks router-side DHCP reservations / fixed-IP allocations keyed on MAC:
> >> the host stops receiving its pinned address and lands on an arbitrary lease.
> >> Any MT7925 user relying on MAC-based address pinning is affected. Current
> >> workaround here is forcing the real MAC via NetworkManager cloned-mac-address.
> >>
> >> #regzbot introduced: v7.1..v7.2-rc2
> >>
> >>
> >>
> >> Thanks,
> >>
> >>
> >> Brent Paine, AWS, CCNP
> >>
> >> git bkpaine1
> >> Medium bkpaine1
>