On Wed, Feb 3, 2016 at 10:40 AM, Trent Piepho <tpiepho@xxxxxxxxxxxxxx> 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@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?
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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
