Message ID | 20150310033033.9542.92162.stgit@perseus.themaw.net |
---|---|
State | Changes Requested |
Delegated to: | Rafał Miłecki |
Headers | show |
On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent <raven@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@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@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
On Tue, 2015-03-10 at 12:26 +0100, Jonas Gorski wrote: > On Tue, Mar 10, 2015 at 4:30 AM, Ian Kent <raven@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@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@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
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@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)) { ++ struct bcm47xx_sprom_fill fill_no_prefix; ++ u8 mac[6]; ++ ++ 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)) { ++ int err; ++ ++ ether_addr_copy(sprom->et0mac, mac); ++ ++ 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. diff --git a/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch b/target/linux/bcm53xx/patches-3.18/114-bcm53xx-deal-with-R8000-mac-address-settings.patch new file mode 100644 index 0000000..a476405 --- /dev/null +++ b/target/linux/bcm53xx/patches-3.18/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@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)) { ++ struct bcm47xx_sprom_fill fill_no_prefix; ++ u8 mac[6]; ++ ++ 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)) { ++ int err; ++ ++ ether_addr_copy(sprom->et0mac, mac); ++ ++ 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.
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@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