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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Embedded]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux