>> > >> > Patch itself looks simple. Before we review it further could you provide >> > more details on the exact usecase or some background of this. >> >> The discussion on this topic originated on mailing list of Barebox >> project(which borrows very heavily from Linux designs). Barebox >> operates on two device tree blobs, one is used for its internal >> initialization, whereas second one is passed to Linux kernel when >> booting it. The problem I was trying to solve was to make possible to >> specify in the first DT blob what data would be used for MAC address >> fixup of the second DT blob(the one passed to Linux). >> >> My first approach was to implement a very limited DT code, however in >> discussing it the consensus was that porting 'nvmem' subsystem from >> the kernel and using for the same purpose would be a better approach. >> First pass adoption of that subsystem revealed that there were two >> use-cases that current design didn't allow us to handle: >> >> - Depending on the version i.MX SoC MAC address data stored in ROM >> would have different layout so as a possible solution to that I >> implemented "composite" driver(patch #3) >> >> - On i.MX28, part of the MAC address is hard-coded in >> arch/arm/mach-mxs/mach-mxs.c and only a portion of it is read from >> ROM, this patch in combination with the aforementioned one should >> allow us to encode all needed info in DT. >> >> Ideally, since all of the above is as applicable to Linux as it is to >> Barebox it would be good for BB not to invent its own custom 'nvmem' >> flavor, so hence me trying to start a conversation about adding this >> upstream. > > If the only use-case is to store the MAC address, why not using the > local-mac-address property directly?
I don't think I understand what you mean, could you give me an example of how I'd use local-mac-address property for that use case? AFAIK, local-mac-address is just an array of bytes embedded into device tree, how would it get populated with data from OTP memory of SoC?
