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
next prev parent 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.