From: Andrey Smirnov <andrew.smirnov@gmail.com>
To: Trent Piepho <tpiepho@kymetacorp.com>
Cc: "barebox@lists.infradead.org" <barebox@lists.infradead.org>
Subject: Re: [RFC 1/2] misc: Add MAC address mapper "driver"
Date: Tue, 2 Feb 2016 17:14:31 -0800 [thread overview]
Message-ID: <CAHQ1cqGaR3h9DchcYPkTNvUqDN=dR1aDW+dXCNnS_E_2Gr+7Yg@mail.gmail.com> (raw)
In-Reply-To: <1454354334.18531.16.camel@rtred1test09.kymeta.local>
On Mon, Feb 1, 2016 at 11:18 AM, Trent Piepho <tpiepho@kymetacorp.com> 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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2016-02-03 1:14 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
2016-02-03 1:14 ` Andrey Smirnov [this message]
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='CAHQ1cqGaR3h9DchcYPkTNvUqDN=dR1aDW+dXCNnS_E_2Gr+7Yg@mail.gmail.com' \
--to=andrew.smirnov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=tpiepho@kymetacorp.com \
/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