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

[Christoph Niedermaier <cniedermaier@dh-electronics.com>]

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