bcm53xx: MR32: read mac-address from eeprom

Meraki wrote the ethernet MAC-address of the device
onto the eeprom (AT24C64) at the fixed location 0x66
to 0x6C. Let's fetch it from there.

Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

diff --git a/target/linux/bcm53xx/base-files/etc/board.d/02_network b/target/linux/bcm53xx/base-files/etc/board.d/02_network
index 1daaa6ba007075e36f849da96b13cd98f275f770..e02286027fc7623a5c56590ee220cfa35356a50b 100644 (file)
--- a/target/linux/bcm53xx/base-files/etc/board.d/02_network
+++ b/target/linux/bcm53xx/base-files/etc/board.d/02_network
@@ -94,10 +94,6 @@ bcm53xx_setup_macs()
                # As vendor doesn't use eth0 its MAC may be missing. Use one from eth2.
                et2macaddr="$(nvram get et2macaddr)"
                ;;
-       meraki,mr32)
-               # The MAC is stored on an AT24C64 eeprom and not on the nvram
-               et2macaddr=$(get_mac_binary "/sys/bus/i2c/devices/0-0050/eeprom" 0x66)
-               ;;
        esac
 
        [ -n "$et2macaddr" ] && ucidef_set_interface_macaddr "lan" "$et2macaddr"

diff --git a/target/linux/bcm53xx/patches-5.10/099-net-bcma-handle-deferred-probe.patch b/target/linux/bcm53xx/patches-5.10/099-net-bcma-handle-deferred-probe.patch
new file mode 100644 (file)
index 0000000..db2d985
--- /dev/null
+++ b/target/linux/bcm53xx/patches-5.10/099-net-bcma-handle-deferred-probe.patch
@@ -0,0 +1,46 @@
+From 029497e66bdc762e001880e4c85a91f35a54b1e2 Mon Sep 17 00:00:00 2001
+From: Christian Lamparter <chunkeey@gmail.com>
+Date: Sun, 19 Sep 2021 13:57:25 +0200
+Subject: net: bgmac-bcma: handle deferred probe error due to mac-address
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Due to the inclusion of nvmem handling into the mac-address getter
+function of_get_mac_address() by
+commit d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
+it is now possible to get a -EPROBE_DEFER return code. Which did cause
+bgmac to assign a random ethernet address.
+
+This exact issue happened on my Meraki MR32. The nvmem provider is
+an EEPROM (at24c64) which gets instantiated once the module
+driver is loaded... This happens once the filesystem becomes available.
+
+With this patch, bgmac_probe() will propagate the -EPROBE_DEFER error.
+Then the driver subsystem will reschedule the probe at a later time.
+
+Cc: Petr Štetiar <ynezz@true.cz>
+Cc: Michael Walle <michael@walle.cc>
+Fixes: d01f449c008a ("of_net: add NVMEM support to of_get_mac_address")
+Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+---
+ drivers/net/ethernet/broadcom/bgmac-bcma.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma.c b/drivers/net/ethernet/broadcom/bgmac-bcma.c
+index 85fa0ab7201c7..9513cfb5ba58c 100644
+--- a/drivers/net/ethernet/broadcom/bgmac-bcma.c
++++ b/drivers/net/ethernet/broadcom/bgmac-bcma.c
+@@ -129,6 +129,8 @@ static int bgmac_probe(struct bcma_device *core)
+       bcma_set_drvdata(core, bgmac);
+ 
+       err = of_get_mac_address(bgmac->dev->of_node, bgmac->net_dev->dev_addr);
++      if (err == -EPROBE_DEFER)
++              return err;
+ 
+       /* If no MAC address assigned via device tree, check SPROM */
+       if (err) {
+-- 
+cgit 1.2.3-1.el7
+