On Tue, Mar 08, 2016 at 11:28:21PM +0100, Maxime Ripard wrote: > Hi, > > On Mon, Mar 07, 2016 at 08:07:41PM -0800, Andrey Smirnov wrote: > > >> > > > >> > 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, > > Well, yeah, but the nvmem-blob is also just an array of bytes embedded > into the DT, right? > > > how would it get populated with data from OTP memory of SoC? > > In the bootloader, or Linux, read the OTP, patch the DT to add that > node, done.
This series is a try to put the information how the MAC address can be found (might be board specific) into the DT to not have board specific hacks in the kernel/bootloader. 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 |
