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

[Andrey Smirnov <andrew.smirnov@gmail.com>]

On Wed, Feb 3, 2016 at 10:40 AM, Trent Piepho <tpiepho@kymetacorp.com> wrote:
> 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?

I am thinking of something similar to what you describe in "nvmem"
thread. You'd have a software scatter-gather "engine" that would just
take a description of multiple small chunks of memory and represent it
as a continuous property accessible via "nvmem" API. Something like:

mac-address-node {
           compatible = "nvmem-sg"

           composite_mac: mac@0 {
                     reg = <&nvmem1_cell 0x0 0x4
                                 &nvmem2_cell 0x0 0x2
                               >;
           };
 };

So you'd get a 'composite_mac' nvmem-cell that in term is comprised of
4 bytes @ offset 0x0 of "nvmem1_cell" and 2 bytes @ offset 0x0 of
"nvmem2_cell".


>
> 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.
>

From looking at the mach-mxs.c and assuming I didn't miss any
important details (which is a big if), it seems to me that it would
still be possible to cover this use-case by introducing(or extending
'nvmem' driver) an additional "nvmem" compatible entity whose only job
would be is to present data hard coded in its corresponding DT-node
via "nvmem" API.

So, say for example for apf28(OUI_ARMADEUS) you'd have something like:

board-oui-node {
      board_oui_cell: oui_cell@0 {
             immediate-data = [0x00  0x1e 0xac];
      };
};

and then you should be able to use <&board_oui_cell> in the
scatter-gatherer node from above.

Andrey

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox