mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Trent Piepho <tpiepho@kymetacorp.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Andrey Smirnov <andrew.smirnov@gmail.com>,
	"barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [RFC 1/2] misc: Add MAC address mapper "driver"
Date: Mon, 1 Feb 2016 19:18:32 +0000	[thread overview]
Message-ID: <1454354334.18531.16.camel@rtred1test09.kymeta.local> (raw)
In-Reply-To: <20160201101007.GA4118@pengutronix.de>

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.

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.
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  reply	other threads:[~2016-02-01 19:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-01  5:57 Andrey Smirnov
2016-02-01  5:57 ` [RFC 2/2] arm/dts: i.MX6: Use generic MAC address mapper Andrey Smirnov
2016-02-01 10:10 ` [RFC 1/2] misc: Add MAC address mapper "driver" Sascha Hauer
2016-02-01 19:18   ` Trent Piepho [this message]
2016-02-03  1:14     ` Andrey Smirnov
2016-02-03 18:40       ` Trent Piepho
2016-02-03 20:16         ` Andrey Smirnov
2016-02-03  1:09   ` Andrey Smirnov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1454354334.18531.16.camel@rtred1test09.kymeta.local \
    --to=tpiepho@kymetacorp.com \
    --cc=andrew.smirnov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox