From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Timur Tabi <timur@freescale.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: mac-address vs. local-mac-address
Date: Thu, 08 Feb 2007 08:32:36 +1100 [thread overview]
Message-ID: <1170883956.2620.305.camel@localhost.localdomain> (raw)
In-Reply-To: <45CA41F7.6020700@freescale.com>
On Wed, 2007-02-07 at 15:17 -0600, Timur Tabi wrote:
> Hi everyone,
>
> What is the current consensus on using mac-address vs. local-mac-address in the
> device tree? The 1275 spec says this:
>
> "local-mac-address" Standard property name to specify preassigned network address.
> "mac-address" Standard property name to specify network address last used.
>
> I think we need to agree on some interpretation of these statements, and all the
> code should be updated to implement that interpretation.
It's fairly clear:
local-mac-address is what is statically set by the firwmare (comes from
EEPROM, whatever).
mac-address is really only meaningful if your firmware is
"dynamic" (real OF, uboot maybe) and was, for some reason, instructed by
the user to use a different mac address for that boot (if that feature
exist).
It's basically the mac-address that was actually used on that interface
to netboot the kernel I'd say.
> Linux doesn't support that. In some cases, the actual device tree is located on
> a TFTP server, and it's only copied temporarily into RAM by U-Boot. There's no
> way that a Linux driver can update that.
I don't understand what you mean here :-) The linux driver can perfectly
well update the in-memory copy of the device-tree, which would make it
useful in the case of a kexec to a newer kernel.
> On a full-blown OF machine, the firmware does provide APIs for updating the
> device tree, and so we could support mac-address on these machines. But U-Boot
> disappears once the kernel loads, so there is no firmware to call to update the
> device tree.
I don't understand what the firmware device-tree has to do with that...
If uboot is instructed to use a different mac-address than the
"built-in" one, it can perfectly well create that property before
getting to the kernel.
> Therefore, I propose that on systems where the driver cannot update the device
> tree, the mac-address property should be absent from the device tree. U-Boot
> should not add one, and the Linux device drivers should not reference it.
"cannot update the device tree" is what makes little sense to me.
Ben.
next prev parent reply other threads:[~2007-02-07 21:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-07 21:17 mac-address vs. local-mac-address Timur Tabi
2007-02-07 21:32 ` Benjamin Herrenschmidt [this message]
2007-02-07 21:41 ` Kumar Gala
2007-02-07 21:46 ` Timur Tabi
2007-02-07 21:42 ` Timur Tabi
2007-02-07 21:51 ` Kumar Gala
2007-02-07 22:07 ` Timur Tabi
2007-02-07 22:14 ` Kumar Gala
2007-02-07 22:22 ` Timur Tabi
2007-02-07 22:07 ` Benjamin Herrenschmidt
2007-02-07 22:16 ` Timur Tabi
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=1170883956.2620.305.camel@localhost.localdomain \
--to=benh@kernel.crashing.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=timur@freescale.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;
as well as URLs for NNTP newsgroup(s).