[PATCH 02/16] i.MX: ocotp: Add provisions for storing multiple MAC addresses

Andrey Smirnov andrew.smirnov at gmail.com
Tue Dec 6 06:48:16 PST 2016

Hi Stefan,

On Mon, Dec 5, 2016 at 7:14 AM, Stefan Lengfeld <s.lengfeld at phytec.de> wrote:
> Hi Andrey,
> a similiar patch was posted some days ago to support two MAC addresses for the
> i.MX6 UltraLite. See
>     http://lists.infradead.org/pipermail/barebox/2016-November/028628.html

I did see that patch go through, however since the title of it is
"arm: imx6: ocotp: Added support for the i.MX6UL" I didn't look into
it any further.

> Your approach uses an extra device attribute  'mac_idx' to select the meaning
> of the device attribute 'mac_addr': Whether it points to the MAC0 or MAC1.
> I find it less error prone and confusing to use two seperate device attributes
> 'mac_addr' and 'mac_addr1' for MAC0 and MAC1. So you don't have to check the
> value of 'mac_idx before reading or writing the MAC addresses.

Can't say that I necessarily agree with you assessment. There's no
need to check 'mac_idx' if it is written every time as a part of MAC
address assignment operation. The reason I chose the approach that I
did was mainly because it allowed to both have backwards compatibility
with the old naming scheme and avoid having variable naming
inconsistency (as you see in your example where one variable has a
numerical suffix and the other doesn't) which I was concerned would be
make scripting it more clunky than necessary.

Anyway, I don't think I am impartial enough to make a good judge of
merits of both approaches, so I'll let Sascha decide which way he
wants to go.

Andrey Smirnov

More information about the barebox mailing list