Re: [PATCH wireless-next] wifi: mt76: fix of_get_mac_address error handling
Thorsten Leemhuis <[email protected]> Tue, 30 Jun 2026 14:17:25 +0200
| Newsgroups | dev.linux.lists.regressions,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-mediatek,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless |
|---|---|
| Message-ID | <[email protected]> |
On 6/19/26 03:50, Rosen Penev wrote: > On Thu Jun 18, 2026 at 4:51 PM PDT, Klara Modin wrote: >> On 2026-06-18 16:01:45 -0700, Rosen Penev wrote: >>> On Thu, Jun 18, 2026 at 2:47 PM Klara Modin <[email protected]> wrote: >>>> On 2026-04-26 22:17:46 -0700, Rosen Penev wrote: >>>>> Check return value instead of is_valid_ether_addr. The latter is handled >>>>> by the former. >>>>> >>>>> Signed-off-by: Rosen Penev <[email protected]> >>>>> [...] >>>>>>>> Recently I have started to see randomized MAC-addresses on my x86 laptop >>>> with a MT7922 and the above message printed in the kernel log. I have >>>> CONFIG_OF turned on, but since this is an ACPI system the device is not >>>> described by any device tree and the earlier of_get_mac_address() likely >>>> fails with -ENODEV. Looking at the !CONFIG_OF stub for >>>> of_get_mac_address it always returns -ENODEV, meaning this will always >>>> randomize the mac in that case too. >> >>> IIRC, the normal device_get_mac_address supports nvmem now. Does that >>> fix your use case? >> >> I tried this: >> [...] >> but I still get a random MAC. > Then the original patch should be reverted. Unfortunate that it doesn't > workq Happens, no worries, but seems nobody submitted such a revert yet since you posted that. Unless I'm missing something -- if so, please do not hesitate to tell me! But if no revert is in the works, could you please submit one, given that it was your change that cause the problem? Side note: Tobias (now CCed) ran into the same problem, too: https://lore.kernel.org/all/[email protected]/ Makes me wonder if more people are affected by this and if we should try to mainline the revert rather sooner than later. Ciao, Thorsten >>>> >>>> Reverting this patch fixes the issue and the correct MAC address is >>>> used. I'm not sure if there is any case where of_get_mac_addres() could >>>> fail in a way that results in a valid MAC address but it seems unlikely >>>> to me. >>>> >>>> Regards, >>>> Klara Modin > >