mirror of
https://github.com/openwrt/openwrt.git
synced 2026-10-13 17:38:48 +04:00
Hauke Mehrtens
ed545519ee
Both bmips ethernet drivers call of_get_mac_address() and throw the
return value away. They then decide from the contents of an
uninitialised stack buffer whether a MAC address was found, and fall
back to eth_hw_addr_random() when it does not look valid. An
-EPROBE_DEFER is therefore turned into a random MAC address instead of
into a retry.
This did not matter while fixed-layout NVMEM cells were parsed
synchronously by the NVMEM core. Linux 6.12.104 picks up 751cc1534316
("nvmem: layouts: Add fixed-layout driver"), which drops the
"fixed-layout" entry from of_nvmem_layout_skip_table and turns it into
an ordinary NVMEM layout bus driver: nvmem_register() now only creates
the layout device and sets nvmem->layout, and the cells show up later,
when fixed_layout_probe() runs. Until then
nvmem_layout_module_get_optional() sees no bound driver and
of_nvmem_cell_get() returns -EPROBE_DEFER.
That window is hit on every boot rather than occasionally, because it
is link order and not a race. nvmem_init() is a subsys_initcall, but
the layout driver is a device_initcall and drivers/Makefile places
nvmem/ after both mtd/ and net/. The flash therefore registers its
NVMEM device first, the ethernet driver probes next and defers, and
only afterwards does the fixed-layout driver bind and add the cells.
28 bmips boards take their MAC address from a "fixed-layout" node and
bmips has no base-files fallback, so all of them would come up with a
random MAC address that changes on every boot. Propagate -EPROBE_DEFER
so that the probe is retried once the cell exists, the same way this
was already fixed for lantiq in 50e7e5c80d ("lantiq: xrx200: handle
EPROBE_DEFER for MAC address").
Fixes: 91a52f22a1 ("treewide: backport support for nvmem on non platform devices")
Fixes: 1c552eb44d ("bmips: add basic BCM6358 ethernet support")
Assisted-by: Claude:claude-opus-5
Link: https://github.com/openwrt/openwrt/pull/24808
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>