[PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

When two Ethernet MAC addresses are fused, the first MAC address
is incremented by one and used for the second MAC address. This
causes the second fused MAC address to be ignored. Change this
so that the second fused MAC address will be used.
Keep the old behavior if there isn't any second Ethernet MAC
defined and only the first MAC address is fused but not the
second. In this case use the fused MAC address incremented by
one, for the second MAC address.

Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>
---
Cc: Marek Vasut <marex@nabladev.com>
Cc: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Sam Protsenko <semen.protsenko@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Cc: u-boot@dh-electronics.com
---
 board/dhelectronics/common/dh_imx.c               |  4 ++--
 board/dhelectronics/common/dh_imx.h               |  3 ++-
 board/dhelectronics/dh_imx6/dh_imx6.c             |  2 +-
 board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c | 13 ++++++++++---
 4 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/board/dhelectronics/common/dh_imx.c b/board/dhelectronics/common/dh_imx.c
index 3d6487dd0d8..308cdb5b002 100644
--- a/board/dhelectronics/common/dh_imx.c
+++ b/board/dhelectronics/common/dh_imx.c
@@ -10,13 +10,13 @@
 #include <net.h>
 #include "dh_imx.h"
 
-int dh_imx_get_mac_from_fuse(unsigned char *enetaddr)
+int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr)
 {
 	/*
 	 * If IIM fuses contain valid MAC address, use it.
 	 * The IIM MAC address fuses are NOT programmed by default.
 	 */
-	imx_get_mac_from_fuse(0, enetaddr);
+	imx_get_mac_from_fuse(dev_id, enetaddr);
 	if (!is_valid_ethaddr(enetaddr))
 		return -EINVAL;
 
diff --git a/board/dhelectronics/common/dh_imx.h b/board/dhelectronics/common/dh_imx.h
index 284f8637fb8..cb51a2f6eb2 100644
--- a/board/dhelectronics/common/dh_imx.h
+++ b/board/dhelectronics/common/dh_imx.h
@@ -6,7 +6,8 @@
 /*
  * dh_imx_get_mac_from_fuse - Get MAC address from fuse and write it to env
  *
+ * @dev_id: index of MAC address in fuse (starts with 0)
  * @enetaddr: buffer where address is to be stored
  * Return: 0 if OK, other value on error
  */
-int dh_imx_get_mac_from_fuse(unsigned char *enetaddr);
+int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr);
diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c b/board/dhelectronics/dh_imx6/dh_imx6.c
index 234824b38c2..5806a03ed17 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6.c
@@ -94,7 +94,7 @@ int dh_setup_mac_address(struct eeprom_id_page *eip)
 	if (dh_get_mac_is_enabled("ethernet0"))
 		return 0;
 
-	if (!dh_imx_get_mac_from_fuse(enetaddr))
+	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
 		goto out;
 
 	if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
diff --git a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
index 5c35a5bf447..60d1e05b77f 100644
--- a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
+++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
@@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct eeprom_id_page *eip)
 	if (dh_get_mac_is_enabled("ethernet0"))
 		return 0;
 
-	if (!dh_imx_get_mac_from_fuse(enetaddr))
+	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
 		goto out;
 
 	if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr, sizeof(enetaddr), eip))
@@ -75,8 +75,8 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
 	if (dh_get_mac_is_enabled("ethernet1"))
 		return 0;
 
-	if (!dh_imx_get_mac_from_fuse(enetaddr))
-		goto increment_out;
+	if (!dh_imx_get_mac_from_fuse(1, enetaddr))
+		goto out;
 
 	if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr, sizeof(enetaddr), eip))
 		goto out;
@@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
 	if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
 		goto increment_out;
 
+	/*
+	 * If only the first MAC address is fused but not the second, use the
+	 * fused MAC address incremented by one, for the second MAC address.
+	 */
+	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
+		goto increment_out;
+
 	return -ENXIO;
 
 increment_out:
-- 
2.30.2

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Peng Fan (OSS)]

Hi Christoph,

> Subject: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC
> also from fuse
> 
> When two Ethernet MAC addresses are fused, the first MAC address is
> incremented by one and used for the second MAC address. This causes
> the second fused MAC address to be ignored. Change this so that the
> second fused MAC address will be used.

I may miss something, would you please help explain a bit on why
the second fused mac address is ignored?

Thanks,
Peng.
> Keep the old behavior if there isn't any second Ethernet MAC defined
> and only the first MAC address is fused but not the second. In this case
> use the fused MAC address incremented by one, for the second MAC
> address.
> 
> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-
> electronics.com>
> ---
> Cc: Marek Vasut <marex@nabladev.com>
> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
> Cc: Peng Fan <peng.fan@nxp.com>
> Cc: Sam Protsenko <semen.protsenko@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Cc: u-boot@dh-electronics.com
> ---
>  board/dhelectronics/common/dh_imx.c               |  4 ++--
>  board/dhelectronics/common/dh_imx.h               |  3 ++-
>  board/dhelectronics/dh_imx6/dh_imx6.c             |  2 +-
>  board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c | 13
> ++++++++++---
>  4 files changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/board/dhelectronics/common/dh_imx.c
> b/board/dhelectronics/common/dh_imx.c
> index 3d6487dd0d8..308cdb5b002 100644
> --- a/board/dhelectronics/common/dh_imx.c
> +++ b/board/dhelectronics/common/dh_imx.c
> @@ -10,13 +10,13 @@
>  #include <net.h>
>  #include "dh_imx.h"
> 
> -int dh_imx_get_mac_from_fuse(unsigned char *enetaddr)
> +int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr)
>  {
>  	/*
>  	 * If IIM fuses contain valid MAC address, use it.
>  	 * The IIM MAC address fuses are NOT programmed by default.
>  	 */
> -	imx_get_mac_from_fuse(0, enetaddr);
> +	imx_get_mac_from_fuse(dev_id, enetaddr);
>  	if (!is_valid_ethaddr(enetaddr))
>  		return -EINVAL;
> 
> diff --git a/board/dhelectronics/common/dh_imx.h
> b/board/dhelectronics/common/dh_imx.h
> index 284f8637fb8..cb51a2f6eb2 100644
> --- a/board/dhelectronics/common/dh_imx.h
> +++ b/board/dhelectronics/common/dh_imx.h
> @@ -6,7 +6,8 @@
>  /*
>   * dh_imx_get_mac_from_fuse - Get MAC address from fuse and write
> it to env
>   *
> + * @dev_id: index of MAC address in fuse (starts with 0)
>   * @enetaddr: buffer where address is to be stored
>   * Return: 0 if OK, other value on error
>   */
> -int dh_imx_get_mac_from_fuse(unsigned char *enetaddr);
> +int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr);
> diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c
> b/board/dhelectronics/dh_imx6/dh_imx6.c
> index 234824b38c2..5806a03ed17 100644
> --- a/board/dhelectronics/dh_imx6/dh_imx6.c
> +++ b/board/dhelectronics/dh_imx6/dh_imx6.c
> @@ -94,7 +94,7 @@ int dh_setup_mac_address(struct
> eeprom_id_page *eip)
>  	if (dh_get_mac_is_enabled("ethernet0"))
>  		return 0;
> 
> -	if (!dh_imx_get_mac_from_fuse(enetaddr))
> +	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>  		goto out;
> 
>  	if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0")) diff --git
> a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> index 5c35a5bf447..60d1e05b77f 100644
> --- a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> @@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct
> eeprom_id_page *eip)
>  	if (dh_get_mac_is_enabled("ethernet0"))
>  		return 0;
> 
> -	if (!dh_imx_get_mac_from_fuse(enetaddr))
> +	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>  		goto out;
> 
>  	if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr,
> sizeof(enetaddr), eip)) @@ -75,8 +75,8 @@ static int
> dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>  	if (dh_get_mac_is_enabled("ethernet1"))
>  		return 0;
> 
> -	if (!dh_imx_get_mac_from_fuse(enetaddr))
> -		goto increment_out;
> +	if (!dh_imx_get_mac_from_fuse(1, enetaddr))
> +		goto out;
> 
>  	if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr,
> sizeof(enetaddr), eip))
>  		goto out;
> @@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct
> eeprom_id_page *eip)
>  	if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
>  		goto increment_out;
> 
> +	/*
> +	 * If only the first MAC address is fused but not the second, use
> the
> +	 * fused MAC address incremented by one, for the second MAC
> address.
> +	 */
> +	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
> +		goto increment_out;
> +
>  	return -ENXIO;
> 
>  increment_out:
> --
> 2.30.2

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Peng Fan (OSS) <peng.fan@oss.nxp.com>
Sent: Friday, March 20, 2026 2:42 PM
> 
> Hi Christoph,
> 
>> Subject: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC
>> also from fuse
>>
>> When two Ethernet MAC addresses are fused, the first MAC address is
>> incremented by one and used for the second MAC address. This causes
>> the second fused MAC address to be ignored. Change this so that the
>> second fused MAC address will be used.
> 
> I may miss something, would you please help explain a bit on why
> the second fused mac address is ignored?

Hi Peng Fan,

Would the following be more understandable:

Currently, the board specific code evaluates only the first Ethernet
MAC address fuse, regardless of whether the first or second MAC
address is requested. When the function for determine the second
Ethernet MAC address is looking for the fused MAC address, it only
reads the first MAC address fuse and increment it by one to set
the second Ethernet MAC address. That is not the expected behavior
when two MAC addresses are fused, because this causes the second
fused MAC address to be ignored. Change this so that the second
fused MAC address will be used.

Thanks and regards
Christoph

>> Keep the old behavior if there isn't any second Ethernet MAC defined
>> and only the first MAC address is fused but not the second. In this case
>> use the fused MAC address incremented by one, for the second MAC
>> address.
>>
>> Signed-off-by: Christoph Niedermaier <cniedermaier@dh-
>> electronics.com>
>> ---
>> Cc: Marek Vasut <marex@nabladev.com>
>> Cc: Patrice Chotard <patrice.chotard@foss.st.com>
>> Cc: Peng Fan <peng.fan@nxp.com>
>> Cc: Sam Protsenko <semen.protsenko@linaro.org>
>> Cc: Tom Rini <trini@konsulko.com>
>> Cc: u-boot@dh-electronics.com
>> ---
>>  board/dhelectronics/common/dh_imx.c               |  4 ++--
>>  board/dhelectronics/common/dh_imx.h               |  3 ++-
>>  board/dhelectronics/dh_imx6/dh_imx6.c             |  2 +-
>>  board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c | 13
>> ++++++++++---
>>  4 files changed, 15 insertions(+), 7 deletions(-)
>>
>> diff --git a/board/dhelectronics/common/dh_imx.c
>> b/board/dhelectronics/common/dh_imx.c
>> index 3d6487dd0d8..308cdb5b002 100644
>> --- a/board/dhelectronics/common/dh_imx.c
>> +++ b/board/dhelectronics/common/dh_imx.c
>> @@ -10,13 +10,13 @@
>>  #include <net.h>
>>  #include "dh_imx.h"
>>
>> -int dh_imx_get_mac_from_fuse(unsigned char *enetaddr)
>> +int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr)
>>  {
>>       /*
>>        * If IIM fuses contain valid MAC address, use it.
>>        * The IIM MAC address fuses are NOT programmed by default.
>>        */
>> -     imx_get_mac_from_fuse(0, enetaddr);
>> +     imx_get_mac_from_fuse(dev_id, enetaddr);
>>       if (!is_valid_ethaddr(enetaddr))
>>               return -EINVAL;
>>
>> diff --git a/board/dhelectronics/common/dh_imx.h
>> b/board/dhelectronics/common/dh_imx.h
>> index 284f8637fb8..cb51a2f6eb2 100644
>> --- a/board/dhelectronics/common/dh_imx.h
>> +++ b/board/dhelectronics/common/dh_imx.h
>> @@ -6,7 +6,8 @@
>>  /*
>>   * dh_imx_get_mac_from_fuse - Get MAC address from fuse and write
>> it to env
>>   *
>> + * @dev_id: index of MAC address in fuse (starts with 0)
>>   * @enetaddr: buffer where address is to be stored
>>   * Return: 0 if OK, other value on error
>>   */
>> -int dh_imx_get_mac_from_fuse(unsigned char *enetaddr);
>> +int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr);
>> diff --git a/board/dhelectronics/dh_imx6/dh_imx6.c
>> b/board/dhelectronics/dh_imx6/dh_imx6.c
>> index 234824b38c2..5806a03ed17 100644
>> --- a/board/dhelectronics/dh_imx6/dh_imx6.c
>> +++ b/board/dhelectronics/dh_imx6/dh_imx6.c
>> @@ -94,7 +94,7 @@ int dh_setup_mac_address(struct
>> eeprom_id_page *eip)
>>       if (dh_get_mac_is_enabled("ethernet0"))
>>               return 0;
>>
>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>               goto out;
>>
>>       if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0")) diff --git
>> a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>> b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>> index 5c35a5bf447..60d1e05b77f 100644
>> --- a/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>> @@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct
>> eeprom_id_page *eip)
>>       if (dh_get_mac_is_enabled("ethernet0"))
>>               return 0;
>>
>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>               goto out;
>>
>>       if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr,
>> sizeof(enetaddr), eip)) @@ -75,8 +75,8 @@ static int
>> dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>       if (dh_get_mac_is_enabled("ethernet1"))
>>               return 0;
>>
>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>> -             goto increment_out;
>> +     if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>> +             goto out;
>>
>>       if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr,
>> sizeof(enetaddr), eip))
>>               goto out;
>> @@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct
>> eeprom_id_page *eip)
>>       if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
>>               goto increment_out;
>>
>> +     /*
>> +      * If only the first MAC address is fused but not the second, use
>> the
>> +      * fused MAC address incremented by one, for the second MAC
>> address.
>> +      */
>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>> +             goto increment_out;
>> +
>>       return -ENXIO;
>>
>>  increment_out:

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Peng Fan]

On Fri, Mar 20, 2026 at 11:29:18AM +0100, Christoph Niedermaier wrote:
>When two Ethernet MAC addresses are fused, the first MAC address
>is incremented by one and used for the second MAC address. This
>causes the second fused MAC address to be ignored. Change this
>so that the second fused MAC address will be used.
>Keep the old behavior if there isn't any second Ethernet MAC
>defined and only the first MAC address is fused but not the
>second. In this case use the fused MAC address incremented by
>one, for the second MAC address.
>
>Signed-off-by: Christoph Niedermaier <cniedermaier@dh-electronics.com>

Reviewed-by: Peng Fan <peng.fan@nxp.com>

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Marek Vasut]

On 3/20/26 11:29 AM, Christoph Niedermaier wrote:

[...]

> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
> @@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct eeprom_id_page *eip)
>   	if (dh_get_mac_is_enabled("ethernet0"))
>   		return 0;
>   
> -	if (!dh_imx_get_mac_from_fuse(enetaddr))
> +	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>   		goto out;
>   
>   	if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr, sizeof(enetaddr), eip))
> @@ -75,8 +75,8 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>   	if (dh_get_mac_is_enabled("ethernet1"))
>   		return 0;
>   
> -	if (!dh_imx_get_mac_from_fuse(enetaddr))
> -		goto increment_out;
> +	if (!dh_imx_get_mac_from_fuse(1, enetaddr))
> +		goto out;

The ordering in this and next hunk seems bogus.

If read from the (new/second) fuse slot 1 fails, the code should attempt 
to use fuse slot 0 content incremented by 1, just like it did before ...

"
if (!dh_imx_get_mac_from_fuse(1, enetaddr))
   goto out;
if (!dh_imx_get_mac_from_fuse(0, enetaddr))
   goto increment_out;
"

>   	if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr, sizeof(enetaddr), eip))
>   		goto out;
> @@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>   	if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
>   		goto increment_out;
>   
> +	/*
> +	 * If only the first MAC address is fused but not the second, use the
> +	 * fused MAC address incremented by one, for the second MAC address.
> +	 */
> +	if (!dh_imx_get_mac_from_fuse(0, enetaddr))
> +		goto increment_out;
... this part would then be unnecessary.

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex@nabladev.com>
Sent: Friday, March 20, 2026 7:22 PM
> On 3/20/26 11:29 AM, Christoph Niedermaier wrote:
> 
> [...]
> 
>> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>> @@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct eeprom_id_page *eip)
>>       if (dh_get_mac_is_enabled("ethernet0"))
>>               return 0;
>>
>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>               goto out;
>>
>>       if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr, sizeof(enetaddr), eip))
>> @@ -75,8 +75,8 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>       if (dh_get_mac_is_enabled("ethernet1"))
>>               return 0;
>>
>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>> -             goto increment_out;
>> +     if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>> +             goto out;
> 
> The ordering in this and next hunk seems bogus.
> 
> If read from the (new/second) fuse slot 1 fails, the code should attempt
> to use fuse slot 0 content incremented by 1, just like it did before ...
> 
> "
> if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>    goto out;
> if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>    goto increment_out;
> "
> 
>>       if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr, sizeof(enetaddr), eip))
>>               goto out;
>> @@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>       if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
>>               goto increment_out;
>>
>> +     /*
>> +      * If only the first MAC address is fused but not the second, use the
>> +      * fused MAC address incremented by one, for the second MAC address.
>> +      */
>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>> +             goto increment_out;
> ... this part would then be unnecessary.

That's how it's supposed to be. The two MAC addresses should be assigned the same
priority order and be as independent of each other as possible to avoid confusion.
Sources associated with the second MAC address therefore have a higher priority
than those associated with the first MAC address in the fuses. Using the fuse of
the first MAC address incremented by one as a fallback is the last resort if no
address is found for the second MAC address after the priority order has been
checked.


Regards
Christoph

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Marek Vasut]

On 3/21/26 9:55 PM, Christoph Niedermaier wrote:
> From: Marek Vasut <marex@nabladev.com>
> Sent: Friday, March 20, 2026 7:22 PM
>> On 3/20/26 11:29 AM, Christoph Niedermaier wrote:
>>
>> [...]
>>
>>> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>>> @@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct eeprom_id_page *eip)
>>>        if (dh_get_mac_is_enabled("ethernet0"))
>>>                return 0;
>>>
>>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>>                goto out;
>>>
>>>        if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr, sizeof(enetaddr), eip))
>>> @@ -75,8 +75,8 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>>        if (dh_get_mac_is_enabled("ethernet1"))
>>>                return 0;
>>>
>>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>>> -             goto increment_out;
>>> +     if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>>> +             goto out;
>>
>> The ordering in this and next hunk seems bogus.
>>
>> If read from the (new/second) fuse slot 1 fails, the code should attempt
>> to use fuse slot 0 content incremented by 1, just like it did before ...
>>
>> "
>> if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>>     goto out;
>> if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>     goto increment_out;
>> "
>>
>>>        if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr, sizeof(enetaddr), eip))
>>>                goto out;
>>> @@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>>        if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
>>>                goto increment_out;
>>>
>>> +     /*
>>> +      * If only the first MAC address is fused but not the second, use the
>>> +      * fused MAC address incremented by one, for the second MAC address.
>>> +      */
>>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>> +             goto increment_out;
>> ... this part would then be unnecessary.
> 
> That's how it's supposed to be. The two MAC addresses should be assigned the same
> priority order and be as independent of each other as possible to avoid confusion.
> Sources associated with the second MAC address therefore have a higher priority
> than those associated with the first MAC address in the fuses. Using the fuse of
> the first MAC address incremented by one as a fallback is the last resort if no
> address is found for the second MAC address after the priority order has been
> checked.
The priority is this:
- ENV -- because user can override the content, and user override is 
highest prio
- Device not enabled in DT, do nothing
- Fuses, (newly first fuse block 1 , then) fuse block 0 -- because 
in-SoC fuses always have to take precedence over the external EEPROM
- EEPROM, first block 1, then block 0 -- because this is what is usually 
programmed out of factory, anything higher priority is up to the user

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex@nabladev.com>
Sent: Sunday, March 22, 2026 12:41 AM
> On 3/21/26 9:55 PM, Christoph Niedermaier wrote:
>> From: Marek Vasut <marex@nabladev.com>
>> Sent: Friday, March 20, 2026 7:22 PM
>>> On 3/20/26 11:29 AM, Christoph Niedermaier wrote:
>>>
>>> [...]
>>>
>>>> +++ b/board/dhelectronics/dh_imx8mp/imx8mp_dhcom_pdk2.c
>>>> @@ -50,7 +50,7 @@ static int dh_imx8_setup_ethaddr(struct eeprom_id_page *eip)
>>>>        if (dh_get_mac_is_enabled("ethernet0"))
>>>>                return 0;
>>>>
>>>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>>>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>>>                goto out;
>>>>
>>>>        if (!dh_get_value_from_eeprom_buffer(DH_MAC0, enetaddr, sizeof(enetaddr), eip))
>>>> @@ -75,8 +75,8 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>>>        if (dh_get_mac_is_enabled("ethernet1"))
>>>>                return 0;
>>>>
>>>> -     if (!dh_imx_get_mac_from_fuse(enetaddr))
>>>> -             goto increment_out;
>>>> +     if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>>>> +             goto out;
>>>
>>> The ordering in this and next hunk seems bogus.
>>>
>>> If read from the (new/second) fuse slot 1 fails, the code should attempt
>>> to use fuse slot 0 content incremented by 1, just like it did before ...
>>>
>>> "
>>> if (!dh_imx_get_mac_from_fuse(1, enetaddr))
>>>     goto out;
>>> if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>>     goto increment_out;
>>> "
>>>
>>>>        if (!dh_get_value_from_eeprom_buffer(DH_MAC1, enetaddr, sizeof(enetaddr), eip))
>>>>                goto out;
>>>> @@ -92,6 +92,13 @@ static int dh_imx8_setup_eth1addr(struct eeprom_id_page *eip)
>>>>        if (!dh_get_mac_from_eeprom(enetaddr, "eeprom0"))
>>>>                goto increment_out;
>>>>
>>>> +     /*
>>>> +      * If only the first MAC address is fused but not the second, use the
>>>> +      * fused MAC address incremented by one, for the second MAC address.
>>>> +      */
>>>> +     if (!dh_imx_get_mac_from_fuse(0, enetaddr))
>>>> +             goto increment_out;
>>> ... this part would then be unnecessary.
>>
>> That's how it's supposed to be. The two MAC addresses should be assigned the same
>> priority order and be as independent of each other as possible to avoid confusion.
>> Sources associated with the second MAC address therefore have a higher priority
>> than those associated with the first MAC address in the fuses. Using the fuse of
>> the first MAC address incremented by one as a fallback is the last resort if no
>> address is found for the second MAC address after the priority order has been
>> checked.
> The priority is this:
> - ENV -- because user can override the content, and user override is
> highest prio
> - Device not enabled in DT, do nothing
> - Fuses, (newly first fuse block 1 , then) fuse block 0 -- because
> in-SoC fuses always have to take precedence over the external EEPROM
> - EEPROM, first block 1, then block 0 -- because this is what is usually
> programmed out of factory, anything higher priority is up to the user

The SoM is delivered with both MAC addresses coming from DH electronics provided
by EEPROMs. If a customer wants his own MAC, they can fuse the MAC address to
override it permanently, but referring to your suggestion if the customer only
fuse one MAC address the behavior depends on which MAC address is fused.

Fuse only the first MAC address:
- 1. Ethernet: MAC is taken from FUSE 0
- 2. Ethernet: MAC is taken from FUSE 0 + incremented by one

Fuse only the second MAC address:
- 1. Ethernet: MAC is taken from EEPROM
- 2. Ethernet: MAC is taken from FUSE 1

The problem is that we have a customer with SoMs where only the first MAC address
was sequentially fused from a MAC address pool. That means the second MAC address
of the SoM is the same MAC address as the MAC address from the next SoM's first
MAC address. This patch prevents this by setting the MAC addresses independently
of one another. Then for the second MAC address the DH electronics MAC from the
EEPROM is used. In this patch the fallback where the first MAC address incremented
by one is used should not occur on the customer side, as the SoMs are shipped with
MAC addresses in the EEPROMs. If this does occur, however due to an EEPROM read
error or whatever this patch could be improved by a warning message.

Regards
Christoph

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Marek Vasut]

On 3/23/26 11:07 AM, Christoph Niedermaier wrote:

[...]

>> The priority is this:
>> - ENV -- because user can override the content, and user override is
>> highest prio
>> - Device not enabled in DT, do nothing
>> - Fuses, (newly first fuse block 1 , then) fuse block 0 -- because
>> in-SoC fuses always have to take precedence over the external EEPROM
>> - EEPROM, first block 1, then block 0 -- because this is what is usually
>> programmed out of factory, anything higher priority is up to the user
> 
> The SoM is delivered with both MAC addresses coming from DH electronics provided
> by EEPROMs. If a customer wants his own MAC, they can fuse the MAC address to
> override it permanently, but referring to your suggestion if the customer only
> fuse one MAC address the behavior depends on which MAC address is fused.
> 
> Fuse only the first MAC address:
> - 1. Ethernet: MAC is taken from FUSE 0
> - 2. Ethernet: MAC is taken from FUSE 0 + incremented by one
> 
> Fuse only the second MAC address:
> - 1. Ethernet: MAC is taken from EEPROM
> - 2. Ethernet: MAC is taken from FUSE 1
> 
> The problem is that we have a customer with SoMs where only the first MAC address
> was sequentially fused from a MAC address pool. That means the second MAC address
> of the SoM is the same MAC address as the MAC address from the next SoM's first
> MAC address. This patch prevents this by setting the MAC addresses independently
> of one another. Then for the second MAC address the DH electronics MAC from the
> EEPROM is used. In this patch the fallback where the first MAC address incremented
> by one is used should not occur on the customer side, as the SoMs are shipped with
> MAC addresses in the EEPROMs. If this does occur, however due to an EEPROM read
> error or whatever this patch could be improved by a warning message.
I don't understand this last sentence, can you please rephrase ? Keep in 
mind, not all MX8MP DHCOM were populated with both EEPROMs, the rev.100 
only had one EEPROM on them.

As for the rest, it really boils down to the ordering of fallbacks, it 
is either:

A)
fuse1
eeprom1
fuse0+1
eeprom0+1

or

B)
fuse1
fuse0+1
eeprom1
eeprom0+1

The following ordering, which is the ordering introduced by this patch, 
is confusing:

fuse1
eeprom1
eeprom0+1
fuse0+1

So please pick either A) or B) above. I do not see any particular 
advantage of either of the other, except maybe B) improves boot time in 
case both fuse blocks are blown, because it avoids the EEPROM I2C access.

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex@nabladev.com>
Sent: Monday, March 23, 2026 3:59 PM
> On 3/23/26 11:07 AM, Christoph Niedermaier wrote:
> 
> [...]
> 
>>> The priority is this:
>>> - ENV -- because user can override the content, and user override is
>>> highest prio
>>> - Device not enabled in DT, do nothing
>>> - Fuses, (newly first fuse block 1 , then) fuse block 0 -- because
>>> in-SoC fuses always have to take precedence over the external EEPROM
>>> - EEPROM, first block 1, then block 0 -- because this is what is usually
>>> programmed out of factory, anything higher priority is up to the user
>>
>> The SoM is delivered with both MAC addresses coming from DH electronics provided
>> by EEPROMs. If a customer wants his own MAC, they can fuse the MAC address to
>> override it permanently, but referring to your suggestion if the customer only
>> fuse one MAC address the behavior depends on which MAC address is fused.
>>
>> Fuse only the first MAC address:
>> - 1. Ethernet: MAC is taken from FUSE 0
>> - 2. Ethernet: MAC is taken from FUSE 0 + incremented by one
>>
>> Fuse only the second MAC address:
>> - 1. Ethernet: MAC is taken from EEPROM
>> - 2. Ethernet: MAC is taken from FUSE 1
>>
>> The problem is that we have a customer with SoMs where only the first MAC address
>> was sequentially fused from a MAC address pool. That means the second MAC address
>> of the SoM is the same MAC address as the MAC address from the next SoM's first
>> MAC address. This patch prevents this by setting the MAC addresses independently
>> of one another. Then for the second MAC address the DH electronics MAC from the
>> EEPROM is used. In this patch the fallback where the first MAC address incremented
>> by one is used should not occur on the customer side, as the SoMs are shipped with
>> MAC addresses in the EEPROMs. If this does occur, however due to an EEPROM read
>> error or whatever this patch could be improved by a warning message.
> I don't understand this last sentence, can you please rephrase ? Keep in
> mind, not all MX8MP DHCOM were populated with both EEPROMs, the rev.100
> only had one EEPROM on them.

On the rev.100 the amount of populated EEPROM depends on the number of Ethernet
interfaces. One Ethernet interface means on EEPROM is populated and on a SoM
with two Ethernet interfaces two EEPROM are populated. The SoMs with two Ethernet
interfaces, in which only one EEPROM was populated, were prototype configurations.
This is no longer the case in the production series. This fallback can therefore
be removed.
In the last sentence I mean if the EEPROM can't provide a MAC address it is an
indication that something goes wrong and if the MAC address from the first MAC
fuse incremented by one is used a message could be displayed to inform about
that.

> As for the rest, it really boils down to the ordering of fallbacks, it
> is either:
> 
> A)
> fuse1
> eeprom1
> fuse0+1
> eeprom0+1
> 
> or
> 
> B)
> fuse1
> fuse0+1
> eeprom1
> eeprom0+1
> 
> The following ordering, which is the ordering introduced by this patch,
> is confusing:
> 
> fuse1
> eeprom1
> eeprom0+1
> fuse0+1
> 
> So please pick either A) or B) above. I do not see any particular
> advantage of either of the other, except maybe B) improves boot time in
> case both fuse blocks are blown, because it avoids the EEPROM I2C access.

The prevention of I2C access is only a one time effect, because then the
MAC addresses will provided by the environment.

If I remove the eeprom0+1, because it was for prototype configurations,
my preferred order would be:

fuse1
eeprom1
fuse0+1


Regards
Christoph

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Marek Vasut]

On 3/23/26 5:49 PM, Christoph Niedermaier wrote:

[...]

>> As for the rest, it really boils down to the ordering of fallbacks, it
>> is either:
>>
>> A)
>> fuse1
>> eeprom1
>> fuse0+1
>> eeprom0+1
>>
>> or
>>
>> B)
>> fuse1
>> fuse0+1
>> eeprom1
>> eeprom0+1
>>
>> The following ordering, which is the ordering introduced by this patch,
>> is confusing:
>>
>> fuse1
>> eeprom1
>> eeprom0+1
>> fuse0+1
>>
>> So please pick either A) or B) above. I do not see any particular
>> advantage of either of the other, except maybe B) improves boot time in
>> case both fuse blocks are blown, because it avoids the EEPROM I2C access.
> 
> The prevention of I2C access is only a one time effect, because then the
> MAC addresses will provided by the environment.

Which increases the system boot time, which is undesired.

> If I remove the eeprom0+1, because it was for prototype configurations,
> my preferred order would be:
> 
> fuse1
> eeprom1
> fuse0+1
eeprom0 can not be removed, that breaks backward compatibility. And the 
ordering of fuse-eeprom-fuse is confusing and has the boot time increase 
downside of A).

I would say B) is the way to go, it should also cover your requirements, 
keeps the boot time low if both fuse banks are fused (which can be fixed 
even on existing hardware, simply read out eeprom content and fuse it 
into fuse bank 1), and it retains the priority ordering (env, fuse, 
eeprom) without mixing it up.

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex@nabladev.com>
Sent: Monday, March 23, 2026 6:21 PM
> On 3/23/26 5:49 PM, Christoph Niedermaier wrote:
> 
> [...]
> 
>>> As for the rest, it really boils down to the ordering of fallbacks, it
>>> is either:
>>>
>>> A)
>>> fuse1
>>> eeprom1
>>> fuse0+1
>>> eeprom0+1
>>>
>>> or
>>>
>>> B)
>>> fuse1
>>> fuse0+1
>>> eeprom1
>>> eeprom0+1
>>>
>>> The following ordering, which is the ordering introduced by this patch,
>>> is confusing:
>>>
>>> fuse1
>>> eeprom1
>>> eeprom0+1
>>> fuse0+1
>>>
>>> So please pick either A) or B) above. I do not see any particular
>>> advantage of either of the other, except maybe B) improves boot time in
>>> case both fuse blocks are blown, because it avoids the EEPROM I2C access.
>>
>> The prevention of I2C access is only a one time effect, because then the
>> MAC addresses will provided by the environment.
> 
> Which increases the system boot time, which is undesired.

If a customer sequentially fuse only the first MAC address from a MAC address
pool. Then the second MAC address of the SoM is the same MAC address as the MAC
address from the next SoM's first MAC address. That is very bad. With the A)
it can be avoided, because the second MAC address then is taken from the EEPROM.
If I had to choose between reducing the boot time once and preventing potential
duplicate MAC addresses, I would say that preventing potential duplicate MAC
addresses is the better option. Furthermore, the issue of duplicate MAC addresses
in the system is not a hypothetical scenario, it has already occurred in practice.

>> If I remove the eeprom0+1, because it was for prototype configurations,
>> my preferred order would be:
>>
>> fuse1
>> eeprom1
>> fuse0+1
> eeprom0 can not be removed, that breaks backward compatibility. And the
> ordering of fuse-eeprom-fuse is confusing and has the boot time increase
> downside of A).

For which SoM should backward compatibility be maintained here. There is
no SoM at the customer's site where it is required. For rev.200 the EEPROM
ID page is used, for rev.100 only some internal SoM prototypes with two
Ethernet interfaces had only the first EEPROM populated. It's not worth
keeping that code.

> I would say B) is the way to go, it should also cover your requirements,
> keeps the boot time low if both fuse banks are fused (which can be fixed
> even on existing hardware, simply read out eeprom content and fuse it
> into fuse bank 1), and it retains the priority ordering (env, fuse,
> eeprom) without mixing it up.

The case that only the first MAC address is fused and not the second one is
a special case, but if this happens, with the order A) above you can prevent
duplicate MAC addresses from appearing in the system. In addition, if you want
to fix it, it's dangerous to fuse the second MAC address at the customer's
location, because if something goes wrong during the fusing, the device must
be replaced on-site. This can also be avoided with order A).


Regards
Christoph

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Marek Vasut]

On 3/27/26 11:02 PM, Christoph Niedermaier wrote:
> From: Marek Vasut <marex@nabladev.com>
> Sent: Monday, March 23, 2026 6:21 PM
>> On 3/23/26 5:49 PM, Christoph Niedermaier wrote:
>>
>> [...]
>>
>>>> As for the rest, it really boils down to the ordering of fallbacks, it
>>>> is either:
>>>>
>>>> A)
>>>> fuse1
>>>> eeprom1
>>>> fuse0+1
>>>> eeprom0+1
>>>>
>>>> or
>>>>
>>>> B)
>>>> fuse1
>>>> fuse0+1
>>>> eeprom1
>>>> eeprom0+1
>>>>
>>>> The following ordering, which is the ordering introduced by this patch,
>>>> is confusing:
>>>>
>>>> fuse1
>>>> eeprom1
>>>> eeprom0+1
>>>> fuse0+1
>>>>
>>>> So please pick either A) or B) above. I do not see any particular
>>>> advantage of either of the other, except maybe B) improves boot time in
>>>> case both fuse blocks are blown, because it avoids the EEPROM I2C access.
>>>
>>> The prevention of I2C access is only a one time effect, because then the
>>> MAC addresses will provided by the environment.
>>
>> Which increases the system boot time, which is undesired.
> 
> If a customer sequentially fuse only the first MAC address from a MAC address
> pool. Then the second MAC address of the SoM is the same MAC address as the MAC
> address from the next SoM's first MAC address. That is very bad. With the A)
> it can be avoided, because the second MAC address then is taken from the EEPROM.

This edge case can be fixed on first boot in a boot script. Read out the 
fuse using "setexpr var *addr", detect whether the fuse is empty using 
"if test ...", and if it empty, then populate its content with EEPROM 
content. This saves you one extra I2C operation on every boot afterward.

> If I had to choose between reducing the boot time once and preventing potential
> duplicate MAC addresses, I would say that preventing potential duplicate MAC
> addresses is the better option. Furthermore, the issue of duplicate MAC addresses
> in the system is not a hypothetical scenario, it has already occurred in practice.
> 
>>> If I remove the eeprom0+1, because it was for prototype configurations,
>>> my preferred order would be:
>>>
>>> fuse1
>>> eeprom1
>>> fuse0+1
>> eeprom0 can not be removed, that breaks backward compatibility. And the
>> ordering of fuse-eeprom-fuse is confusing and has the boot time increase
>> downside of A).
> 
> For which SoM should backward compatibility be maintained here. There is
> no SoM at the customer's site where it is required. For rev.200 the EEPROM
> ID page is used, for rev.100 only some internal SoM prototypes with two
> Ethernet interfaces had only the first EEPROM populated. It's not worth
> keeping that code.

So yes, eeprom0 can not be removed, because it also contains the WLP.

>> I would say B) is the way to go, it should also cover your requirements,
>> keeps the boot time low if both fuse banks are fused (which can be fixed
>> even on existing hardware, simply read out eeprom content and fuse it
>> into fuse bank 1), and it retains the priority ordering (env, fuse,
>> eeprom) without mixing it up.
> 
> The case that only the first MAC address is fused and not the second one is
> a special case, but if this happens, with the order A) above you can prevent
> duplicate MAC addresses from appearing in the system. In addition, if you want
> to fix it, it's dangerous to fuse the second MAC address at the customer's
> location, because if something goes wrong during the fusing, the device must
> be replaced on-site. This can also be avoided with order A).
If this is a special case, then please convert it into a common case, so 
the generic code upstream can be kept that, generic.

If this special case can not be converted to common case, then add local 
patch to handle that specific device.

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex@nabladev.com>
Sent: Saturday, March 28, 2026 12:12 AM
> On 3/27/26 11:02 PM, Christoph Niedermaier wrote:
>> From: Marek Vasut <marex@nabladev.com>
>> Sent: Monday, March 23, 2026 6:21 PM
>>> On 3/23/26 5:49 PM, Christoph Niedermaier wrote:
>>>
>>> [...]
>>>
>>>>> As for the rest, it really boils down to the ordering of fallbacks, it
>>>>> is either:
>>>>>
>>>>> A)
>>>>> fuse1
>>>>> eeprom1
>>>>> fuse0+1
>>>>> eeprom0+1
>>>>>
>>>>> or
>>>>>
>>>>> B)
>>>>> fuse1
>>>>> fuse0+1
>>>>> eeprom1
>>>>> eeprom0+1
>>>>>
>>>>> The following ordering, which is the ordering introduced by this patch,
>>>>> is confusing:
>>>>>
>>>>> fuse1
>>>>> eeprom1
>>>>> eeprom0+1
>>>>> fuse0+1
>>>>>
>>>>> So please pick either A) or B) above. I do not see any particular
>>>>> advantage of either of the other, except maybe B) improves boot time in
>>>>> case both fuse blocks are blown, because it avoids the EEPROM I2C access.
>>>>
>>>> The prevention of I2C access is only a one time effect, because then the
>>>> MAC addresses will provided by the environment.
>>>
>>> Which increases the system boot time, which is undesired.
>>
>> If a customer sequentially fuse only the first MAC address from a MAC address
>> pool. Then the second MAC address of the SoM is the same MAC address as the MAC
>> address from the next SoM's first MAC address. That is very bad. With the A)
>> it can be avoided, because the second MAC address then is taken from the EEPROM.
> 
> This edge case can be fixed on first boot in a boot script. Read out the
> fuse using "setexpr var *addr", detect whether the fuse is empty using
> "if test ...", and if it empty, then populate its content with EEPROM
> content. This saves you one extra I2C operation on every boot afterward.

With the right order all typical scenarios can be covered and also the
"edge case" is avoided.

>> If I had to choose between reducing the boot time once and preventing potential
>> duplicate MAC addresses, I would say that preventing potential duplicate MAC
>> addresses is the better option. Furthermore, the issue of duplicate MAC addresses
>> in the system is not a hypothetical scenario, it has already occurred in practice.
>>
>>>> If I remove the eeprom0+1, because it was for prototype configurations,
>>>> my preferred order would be:
>>>>
>>>> fuse1
>>>> eeprom1
>>>> fuse0+1
>>> eeprom0 can not be removed, that breaks backward compatibility. And the
>>> ordering of fuse-eeprom-fuse is confusing and has the boot time increase
>>> downside of A).
>>
>> For which SoM should backward compatibility be maintained here. There is
>> no SoM at the customer's site where it is required. For rev.200 the EEPROM
>> ID page is used, for rev.100 only some internal SoM prototypes with two
>> Ethernet interfaces had only the first EEPROM populated. It's not worth
>> keeping that code.
> 
> So yes, eeprom0 can not be removed, because it also contains the WLP.

Will do this in V2.

>>> I would say B) is the way to go, it should also cover your requirements,
>>> keeps the boot time low if both fuse banks are fused (which can be fixed
>>> even on existing hardware, simply read out eeprom content and fuse it
>>> into fuse bank 1), and it retains the priority ordering (env, fuse,
>>> eeprom) without mixing it up.
>>
>> The case that only the first MAC address is fused and not the second one is
>> a special case, but if this happens, with the order A) above you can prevent
>> duplicate MAC addresses from appearing in the system. In addition, if you want
>> to fix it, it's dangerous to fuse the second MAC address at the customer's
>> location, because if something goes wrong during the fusing, the device must
>> be replaced on-site. This can also be avoided with order A).
> If this is a special case, then please convert it into a common case, so
> the generic code upstream can be kept that, generic.
> 
> If this special case can not be converted to common case, then add local
> patch to handle that specific device.

I'll try to implement that in V2.


Regards
Christoph

Re: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Marek Vasut]

On 3/20/26 11:29 AM, Christoph Niedermaier wrote:

[...]

> +int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr)
>   {
>   	/*
>   	 * If IIM fuses contain valid MAC address, use it.
>   	 * The IIM MAC address fuses are NOT programmed by default.
>   	 */
> -	imx_get_mac_from_fuse(0, enetaddr);
> +	imx_get_mac_from_fuse(dev_id, enetaddr);
dh_stm32 uses the second parameter as the ID, so let's be consistent here.

RE: [PATCH] board: dhelectronics: imx: Use second Ethernet MAC also from fuse

[Christoph Niedermaier]

From: Marek Vasut <marex@nabladev.com>
Sent: Monday, March 23, 2026 6:35 PM
> On 3/20/26 11:29 AM, Christoph Niedermaier wrote:
> 
> [...]
> 
>> +int dh_imx_get_mac_from_fuse(int dev_id, unsigned char *enetaddr)
>>   {
>>       /*
>>        * If IIM fuses contain valid MAC address, use it.
>>        * The IIM MAC address fuses are NOT programmed by default.
>>        */
>> -     imx_get_mac_from_fuse(0, enetaddr);
>> +     imx_get_mac_from_fuse(dev_id, enetaddr);
> dh_stm32 uses the second parameter as the ID, so let's be consistent here.

I'll change the parameters in the next version


Regards
Christoph

DH electronics GmbH
_____________________________________________________________________________
Am Anger 8 | 83346 Bergen | Germany | www.dh-electronics.com | Tel: +49 8662 4882 42
Board of Management: Stefan Daxenberger, Helmut Henschke | HRB Traunstein 9602