From: Timur Tabi <timur@freescale.com>
To: Segher Boessenkool <segher@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees
Date: Mon, 25 Jun 2007 11:01:41 -0500 [thread overview]
Message-ID: <467FE6E5.1070403@freescale.com> (raw)
In-Reply-To: <05ae4090f00e42580b7dcbf0619cc0b7@kernel.crashing.org>
Segher Boessenkool wrote:
> Yup, they're both marked for removal so let's just remove them
> at the same time.
As soon as Paul creates a "for-2.6.25" branch, that's when I was planning on doing it.
> Does the kernel provide a warning to users of too-old firmware^Wuboot
> telling them to update btw?
Nope. The current U-Boot code updates mac-address and/or local-mac-address, whichever
ones exist. If neither exists, it doesn't do anything. If both exists, it updates both
with the same value. This makes it DTS-agnostic, so to speak.
The kernel looks at each of the properties and uses the first one that has a valid MAC
address. Again, this is U-Boot- and DTS-agnostic.
Some older U-Boots would panic if the property it looks for didn't exist. Some Linux
drivers would simply not find a MAC address and then fail to load.
In other words, the current U-Boot and Linux code is written to not care what the other
one does. I have no plans to remove the code in the kernel that looks for obsolete
entries (I'm talking about function of_get_mac_address), because it's "safe".
However, now that you mention it, I could update function of_get_mac_address() to display
a warning if it only finds the 'address' property. That property is definitely wrong and
should never be in the DTS or any device tree passed to the kernel.
--
Timur Tabi
Linux Kernel Developer @ Freescale
next prev parent reply other threads:[~2007-06-25 16:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-22 19:33 [PATCH] powerpc: fix MAC address entries for 83xx, 85xx, and 86xx device trees Timur Tabi
2007-06-23 15:50 ` Segher Boessenkool
2007-06-25 12:50 ` Josh Boyer
2007-06-25 15:07 ` Timur Tabi
2007-06-25 15:46 ` Segher Boessenkool
2007-06-25 16:01 ` Timur Tabi [this message]
2007-06-26 7:40 ` Segher Boessenkool
2007-06-26 15:22 ` Timur Tabi
2007-06-26 15:42 ` Segher Boessenkool
2007-06-26 15:58 ` Timur Tabi
2007-06-25 16:19 ` Jon Loeliger
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=467FE6E5.1070403@freescale.com \
--to=timur@freescale.com \
--cc=linuxppc-dev@ozlabs.org \
--cc=segher@kernel.crashing.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.