On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@xxxxxxxxxxxxxx> 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@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@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
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
