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

[Andrey Smirnov]

On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho at kymetacorp.com> wrote:
> 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.
>

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?

Andrey