On Wed, Dec 07, 2016 at 11:36:21AM -0800, Andrey Smirnov wrote: > On Wed, Dec 7, 2016 at 11:13 AM, Sascha Hauer <s.hauer@xxxxxxxxxxxxxx> 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. Yes, indeed, this might be confusing, but the fact that mac_addr and mac_addr0 always have the same value should make that clear. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
