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)

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