[OpenWrt-Devel] [PATCH 5/6] bcm53xx: deal with R8000 mac address settings

Ian Kent raven at themaw.net
Tue Mar 10 08:16:38 EDT 2015


On Tue, 2015-03-10 at 12:26 +0100, Jonas Gorski wrote:
> On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent <raven at 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 <raven at 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 <raven at 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 at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



More information about the openwrt-devel mailing list