All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.