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: Tue, 26 Jun 2007 10:22:01 -0500 [thread overview]
Message-ID: <46812F19.1070302@freescale.com> (raw)
In-Reply-To: <b50d825c36a92dc2e16f486455e0623d@kernel.crashing.org>
Segher Boessenkool wrote:
> Yeah, that's fine. I just meant the current kernel (before
> .25) could detect you are using a uboot that won't work after
> .25 anymore, and shout at the user. Would save you some bug
> reports ;-)
I don't think that's possible. I'm only updating the DTS files, not the kernel, because
the kernel has already been updated. Any 2.6.21 or later kernel will work with any U-Boot
and any DTS. The only time we're going to run into a problem is if someone updates the
DTS but does *not* update U-Boot. In this case, U-Boot won't find what it's looking for.
Some U-Boots will even panic in these cases. Not only that, but older U-Boots don't
even check the version number of the device tree they're parsing, and they'll just fail
silently when they get a version they don't understand. Unfortunately, I don't see how I
can fix these problems.
>> 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".
>
> Well you should remove the "address" thing, it is _not_ safe.
Checking for 'address' after finding no match on 'mac-address' and 'local-mac-address' is
safe, because if that's the only property that has a valid MAC address, I want to use it.
As long as there are people out there using U-Boot 1.1.x, we'll need to keep that code
around.
>> 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.
>
> Yeah exactly.
Ok, I will submit a patch to do that.
--
Timur Tabi
Linux Kernel Developer @ Freescale
next prev parent reply other threads:[~2007-06-26 15:22 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
2007-06-26 7:40 ` Segher Boessenkool
2007-06-26 15:22 ` Timur Tabi [this message]
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=46812F19.1070302@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.