On Tue, 2015-03-10 at 12:26 +0100, Jonas Gorski wrote:
> 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.
OK, thanks for the comments Jonas, will fix.
>
> > ++
> > ++ 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
