All of lore.kernel.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Timur Tabi <timur@freescale.com>
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 17:42:51 +0200	[thread overview]
Message-ID: <f7b7186d108fee941496ea15fd902474@kernel.crashing.org> (raw)
In-Reply-To: <46812F19.1070302@freescale.com>

>> 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.

Hrm I phrased it incorrectly I suppose, I meant something just
like the patch you propose below :-)

> Unfortunately, I don't see how I can fix these problems.

You cannot fix it but you can sometimes detect it.  Not all
that important anyway.

>>> 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.

It is not safe since you might happen upon a network device without
"mac-address" property (since the device hasn't been used at boot in
a real OF, or the firmware knows no mac address at all, etc.) and no
"local-mac-address" either -- but it _does_ have an "address", and
it can have an "address" with the correct semantics, not the broken
stuff.

It's not very likely for this happens, sure :-)

>>> 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.

Thanks!


Segher

  reply	other threads:[~2007-06-26 15:42 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
2007-06-26 15:42             ` Segher Boessenkool [this message]
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=f7b7186d108fee941496ea15fd902474@kernel.crashing.org \
    --to=segher@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 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.