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

[Trent Piepho]

On Mon, 2016-02-01 at 11:10 +0100, Sascha Hauer wrote:
> On Sun, Jan 31, 2016 at 09:57:13PM -0800, Andrey Smirnov wrote:
> > Add Barebox specific device tree provisions to allow specifying MAC
> > addresses for network interfaces via device tree.
> > 
> > +
> > +Child node's required properties:
> > +* ``network-interface``: phandle corresponding to network interface
> > +* ``mac-location``: a pair of phandle to 'cdev' containing MAC address
> > +  and offset withing that 'cdev'
> > +
> > +Example::
> > +
> > +  mac-address-map {
> > +	compatible = "barebox,mac-address-map";
> > +	nic at 0 {
> > +		network-interface = <&fec>;
> > +		mac-location = <&ocotp 0x88>;
> > +	};
> > +  };
> 
> I wonder if the correct way to do this wouldn't be nvmem, see
> Documentation/devicetree/bindings/nvmem/nvmem.txt in the Kernel.
> This would mandate a binding like:
> 
> 	ocotp {
> 		mac1: mac at 88 {
> 			reg = <0x88 0x6>;
> 		};
> 	};
> 
> 	&fec {
> 		nvmem-cells = <&mac1>;
> 		nvmem-cell-names = "mac-address";
> 	};

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.

If you look at Documentation/devicetree/bindings/c6x/dscr.txt, there is
already a binding for a different system of loading a MAC from OCOTP:
- ti,dscr-mac-fuse-regs
    MAC addresses are contained in two registers. Each element of a MAC address
    is contained in a single byte. This property has two tuples. Each tuple has
    a register offset and four cells representing bytes in the register from
    most significant to least. The value of these four cells is the MAC byte
    index (1-6) of the byte within the register. A value of 0 means the byte
    is unused in the MAC address.

For a board I did some time ago I reused this property but extended it
slightly to allow N tuples instead of just 2.  Example for above:

        &fec {
                mac-fuse-regs = <0x88 0x01020304
                                 0x8c 0x05060000>;
        };

Example for mxs style partial mac in OCOTP:
        &fec {
                /* OUI is not in OCOTP, just extension */
                mac-address = <0x11 0x22 0x33 0 0 0>; 

                mac-fuse-regs = <0x00 0x00040506>;
        };

Example for two controllers that share an OUI:
        &fec1 {
                mac-fuse-regs = <0x00 0x00010203   /* OUI */
                                 0x80 0x00040506>; /* Extension */
        };
        &fec2 {
                mac-fuse-regs = <0x00 0x00010203   /* OUI */
                                 0x84 0x00040506>; /* Extension */
        };

This doesn't allow the MAC to come from an EEPROM.  I think it would be
nice if the same system could support chips with OCOTP and also EEPROMS
or other storage systems.