On Tue, 2016-02-02 at 17:14 -0800, Andrey Smirnov wrote: > On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@xxxxxxxxxxxxxx> wrote: > > The way imx28 works in the kernel is to just store the extension in the > > OCOTP. The OUI is determined from the board's compatible property and a > > hard coded table in the kernel. See arch/arm/mach-mxs/mach-mxs.c > > > > While, IMHO, the hard coded table is ugly, and should have died long > > ago, there are board that don't have the entire mac burned into OCOTP. > > It seems like neither of these bindings could support a board like this. > > > > What if you created a 'nvmem' provider whose only job is to take a > blob from DT, a phandle to another 'nvmem' provider and to return the > combined data from both sources. Wouldn't it work for the use-case you > are describing? Not sure what it would look like, example? One thing about the imx28 OCOTP is that the entire MAC isn't in the OCOTP. The OUI part comes from "elsewhere". In the current kernel, that elsewhere is a hardcoded /board/compatible to OUI mapping. What I did was use the mac-address property to store the OUI. I think that makes a lot more sense. Actually, storing the whole MAC in the ocotp would have made a lot more sense! But it's one time programmable and that's the way all the boards were made. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
