On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent <ra...@themaw.net> wrote: > After a vendor firmware install the values seen in nvram for et0macaddr > and et1macaddr are that of nvram macaddr and nvram macaddr+1. > > So set them that way here too. > > Signed-off-by: Ian Kent <ra...@themaw.net> > --- > ...53xx-deal-with-R8000-mac-address-settings.patch | 83 > ++++++++++++++++++++ > ...53xx-deal-with-R8000-mac-address-settings.patch | 83 > ++++++++++++++++++++ > 2 files changed, 166 insertions(+) > create mode 100644 > target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch > create mode 100644 > target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch > > diff --git > a/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch > > b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch > new file mode 100644 > index 0000000..a476405 > --- /dev/null > +++ > b/target/linux/bcm53xx/patches-3.14/114-bcm53xx-deal-with-R8000-mac-address-settings.patch > @@ -0,0 +1,83 @@ > +bcm53xx: deal with R8000 mac address settings > + > +The R8000 ends up with et0macaddr and et1macaddr nvram values being all > +zeros with the et*mdcport and et*phyaddr set to the expected values. > + > +The values seen in the nvram after a vendor firmware install are > +et0macaddr and et2macaddr set to the value of macaddr and et1macaddr > +set to macaddr+1. > + > +But after an nvram erase only et2macaddr has a value, so if et0macaddr > +is all zeros use et2macaddr to set et0macaddr and et1macaddr. > + > +Signed-off-by: Ian Kent <ra...@themaw.net> > +--- a/drivers/misc/bcm47xx-sprom.c > ++++ b/drivers/misc/bcm47xx-sprom.c > +@@ -734,6 +734,24 @@ static void bcm47xx_sprom_fill_path_r11( > + } > + } > + > ++static bool bcm47xx_is_zero_mac(u8 *mac) > ++{ > ++ bool res = 1; > ++ int i; > ++ > ++ if (!mac) > ++ goto out; > ++ > ++ for (i = 5; i >= 0; i--) { > ++ if (mac[i]) { > ++ res = 0; > ++ break; > ++ } > ++ } > ++out: > ++ return res; > ++} > ++ > + static bool bcm47xx_is_valid_mac(u8 *mac) > + { > + return mac && !(mac[0] == 0x00 && mac[1] == 0x90 && mac[2] == 0x4c); > +@@ -780,6 +798,42 @@ static void bcm47xx_sprom_fill_ethernet( > + nvram_read_macaddr(fill, "il0macaddr", sprom->il0mac); > + > + /* > ++ * The R8000 ends up with et0macaddr and et1macaddr nvram values > ++ * being all zeros with the et*mdcport and et*phyaddr set to the > ++ * expected values. The values seen in the nvram after a vendor > ++ * firmware install are et0macaddr set to the value of macaddr > ++ * and et1macaddr set to macaddr+1. But after an nvram erase only > ++ * et2macaddr has a value, so if et0macaddr is all zeros use > ++ * et2macaddr to set et0macaddr and et1macaddr. > ++ * > ++ * Note: il0macaddr is also the same as macaddr following a vendor > ++ * install and the key doesn't exist at all after an nvram erase, > ++ * so sprom->il0mac may need to cwbe calculated as well. > ++ */ > ++ if (bcm47xx_is_zero_mac(sprom->et0mac)) {
sprom->et0mac is u16 aligned, so you can replace this with is_zero_ether_addr(). > ++ struct bcm47xx_sprom_fill fill_no_prefix; > ++ u8 mac[6]; and if you make mac aligned to u16, then you can drop the reimplementation completely. > ++ > ++ memcpy(&fill_no_prefix, fill, sizeof(fill_no_prefix)); > ++ fill_no_prefix.prefix = NULL; > ++ > ++ nvram_read_macaddr(&fill_no_prefix, "et2macaddr", mac); > ++ > ++ if (bcm47xx_is_valid_mac(mac) && !bcm47xx_is_zero_mac(mac)) { and use it here, too. > ++ int err; > ++ > ++ ether_addr_copy(sprom->et0mac, mac); And this will produce alignment issues anyway if mac isn't aligned to u16. > ++ > ++ err = bcm47xx_increase_mac_addr(mac, 1); > ++ if (!err) { > ++ ether_addr_copy(sprom->et1mac, mac); > ++ /* don't change mac_addr_used so below > ++ * will behave as expected, if needed */ > ++ } > ++ } > ++ } > ++ > ++ /* > + * The address prefix 00:90:4C is used by Broadcom in their initial > + * configuration. When a mac address with the prefix 00:90:4C is used > + * all devices from the same series are sharing the same mac address. Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel