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
next prev parent 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