Re: [RFC 1/2] misc: Add MAC address mapper "driver"

[Trent Piepho <tpiepho@kymetacorp.com>]

On Tue, 2016-02-02 at 17:14 -0800, Andrey Smirnov wrote:
> On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@kymetacorp.com> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox