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

[Andrey Smirnov]

On Wed, Dec 7, 2016 at 11:13 AM, Sascha Hauer <s.hauer at pengutronix.de> wrote:
> On Wed, Dec 07, 2016 at 09:51:05AM +0100, Stefan Lengfeld wrote:
>> Hi Andrey,
>>
>> > 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.
>>
>> In the light of the Vybrid also supports two MAC addresses your patch title
>>
>>     i.MX: ocotp: Add provisions for storing multiple MAC addresses
>>
>> is better, since it is more generic.
>>
>> > > 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.
>>
>> hmm, I find it more convenient use
>>
>>     bootloader$ ocotp0.mac_addr=22:33:44:55:66:77
>>     bootloader$ ocotp0.mac_addr1=22:33:44:AA:AA:AA
>>
>> than
>>
>>     bootloader$ ocotp0.mac_idx=0
>>     bootloader$ ocotp0.mac_addr=22:33:44:55:66:77
>>     bootloader$ ocotp0.mac_idx=1
>>     bootloader$ ocotp0.mac_addr=22:33:44:AA:AA:AA
>>
>> The same goes for reading the MAC addresses. The first one is more obvious,
>> because the meaning of the variable "mac_addr" does not depend on another
>> variable "mac_idx".
>
> I agree here.
>
>>
>> Maybe we can settle on a different approach to avoid the inconsistent variable
>> names "mac_addr" and "mac_addr1":
>
> How about always registering mac_addr0 with mac_addr as alias? Then we
> have consistent variable naming and still the backward compatible
> standard mac address.

That'd definetly would be even better way to go if we want to preserve
backwards compatibility. It might be a bit confusing UI wise to have
"ocotp0.mac_addr0", "ocotp0.mac_addr1" and "ocotp0.mac_addr" at the
same time, though.

I don't really have a any preference for either way.

Thanks,
Andrey