[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 at 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