From: Wolfgang Denk <wd@denx.de>
To: Tom Rini <trini@kernel.crashing.org>
Cc: "Mark A. Greer" <mgreer@mvista.com>,
linux-galileo@source.mvista.com, linuxppc-dev@lists.linuxppc.org
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Wed, 20 Mar 2002 00:46:57 +0100 [thread overview]
Message-ID: <20020319234702.CA8AA109F3@denx.denx.de> (raw)
In-Reply-To: Your message of "Tue, 19 Mar 2002 16:16:28 MST." <20020319231628.GQ3762@opus.bloom.county>
In message <20020319231628.GQ3762@opus.bloom.county> you wrote:
>
> I sort-of remember this too. For 2.4 I'm not sure if it's better to
> have a massive ammount of compile time options or not. Either way we'd
What sort of compile time options? I don't want to have MAC addresses
built into the kernel images!
> need to change the driver to handle multiple enets, yes?
Only some, like the 8xx. Other configurations run just fine with
several ethernet interfaces.
> > BTW: the structure should probably be extended by one entry for the
> > interface (eth0, eth1, etc...).
>
> Forcing ethX is a bad idea I think, but we do need a way of saying all
> of this applies to *this* enet device.
Right, probably an index is all we need.
> Yes, but we're speaking in terms of GT-64260, which has ns1655x and it's
> own, but I'm not as clear about having 'em both on. But, does 8xx not
> allow for reading of what things are currently set at now or must it be
> specified?
But isn't this the whole idea behind the new interface - to allow
certain things to be done just ONCE, in ONE place, and not again and
again and again in several instances of the same code, with good
chances that at least one instance is buggy?
Of course I can retrieve this information in some CPU and eventually
board dependend way somehow - but why should I bother to implement
this code when the information is already available?
With the same argiment we could drop the MEMSIZE record - the kernel
can detect the memory size as well. Not that I think that would be a
good idea...
And BTW: I'm not talking about 8xx systems only.
> > You are wrong. We'll switch faster than you seem to think.
>
> I know you'll switch when it's all set and working.
Then, or before :-)
> There's a time and place for everything, and it's called the development
> line. Big rewrites/changes are supposed to be done there and maybe
> backported.
Ummm... someone called 2.5 "fs-eating-non-compiling-crap, so ignore
that for a few months". Guess who?
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"I say we take off; nuke the site from orbit. It's the only way to be
sure." - Corporal Hicks, in "Aliens"
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next parent reply other threads:[~2002-03-19 23:46 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020319231628.GQ3762@opus.bloom.county>
2002-03-19 23:46 ` Wolfgang Denk [this message]
2002-03-27 20:09 EV-64260-BP & GT64260 bi_recs Michael Sokolov
-- strict thread matches above, loose matches on Subject: below --
2002-03-27 18:53 Michael Sokolov
2002-03-27 19:37 ` benh
2002-03-27 18:34 Michael Sokolov
2002-03-27 18:32 Michael Sokolov
2002-03-27 18:46 ` benh
2002-03-27 18:03 Michael Sokolov
2002-03-27 16:16 ` Mark A. Greer
2002-03-27 16:24 ` Mark A. Greer
2002-03-27 18:40 ` benh
2002-03-27 18:02 ` Mark A. Greer
2002-03-27 18:06 ` Mark A. Greer
2002-03-27 17:32 Michael Sokolov
2002-03-27 15:46 ` Mark A. Greer
2002-03-27 17:48 ` benh
2002-03-27 15:59 ` Mark A. Greer
2002-03-27 2:37 Michael Sokolov
2002-03-26 21:52 ` benh
2002-03-27 14:15 ` Matt Porter
2002-03-27 15:10 ` Mark A. Greer
2002-03-27 15:15 ` Mark A. Greer
2002-03-27 17:47 ` benh
2002-03-28 9:14 ` Geert Uytterhoeven
2002-03-27 1:35 Michael Sokolov
2002-03-26 23:48 ` Mark A. Greer
2002-03-24 16:02 Michael Sokolov
2002-03-21 2:13 Michael Sokolov
2002-03-21 6:39 ` Dan Malek
2002-03-31 8:32 ` Paul Mackerras
2002-04-01 18:39 ` Dan Malek
2002-04-02 5:32 ` Paul Mackerras
2002-04-02 16:33 ` Tom Rini
2002-04-02 17:29 ` Dan Malek
2002-04-02 14:42 ` Armin
2002-04-02 20:12 ` Tom Rini
2002-04-02 21:02 ` Dan Malek
2002-04-03 0:21 ` Tom Rini
[not found] <dan@embeddededge.com>
[not found] ` <3C98DA15.50302@embeddededge.com>
2002-03-21 1:11 ` Murray Jensen
2002-03-21 6:50 ` Dan Malek
2002-03-21 11:05 ` Murray Jensen
2002-03-21 1:10 Michael Sokolov
2002-03-21 0:57 Michael Sokolov
2002-03-21 6:58 ` Dan Malek
2002-03-21 0:47 Michael Sokolov
[not found] <3C98B189.78A92DFE@mvista.com>
2002-03-20 18:12 ` Wolfgang Denk
[not found] ` <3C98DB49.2C3A2F79@mvista.com>
2002-03-23 3:49 ` Val Henson
2002-03-20 17:11 Michael Sokolov
2002-03-20 18:06 ` Wolfgang Denk
2002-03-20 17:04 Michael Sokolov
2002-03-20 17:25 ` Tom Rini
2002-03-21 20:36 ` Troy Benjegerdes
2002-03-21 19:17 ` Mark A. Greer
2002-03-21 21:36 ` Jim Potter
[not found] <20020320164025.31626@mailhost.mipsys.com>
2002-03-20 16:59 ` Wolfgang Denk
[not found] <20020320155551.GD3762@opus.bloom.county>
2002-03-20 16:18 ` Wolfgang Denk
[not found] <20020320150119.GB3762@opus.bloom.county>
2002-03-20 15:43 ` Wolfgang Denk
2002-03-20 1:02 Michael Sokolov
2002-03-20 0:43 Michael Sokolov
2002-03-19 23:00 ` Mark A. Greer
2002-03-20 7:55 ` Wolfgang Denk
2002-03-20 13:19 ` benh
2002-03-20 15:30 ` Michael Sokolov
2002-03-20 16:19 ` Tom Rini
2002-03-20 16:58 ` benh
2002-03-23 4:01 ` Val Henson
2002-03-23 13:07 ` Murray Jensen
2002-03-24 12:22 ` Benjamin Herrenschmidt
2002-03-24 12:20 ` Benjamin Herrenschmidt
2002-03-24 19:09 ` Val Henson
2002-03-24 16:46 ` Benjamin Herrenschmidt
2002-03-25 8:51 ` Geert Uytterhoeven
2002-03-24 18:16 ` Benjamin Herrenschmidt
2002-03-26 2:16 ` Val Henson
2002-03-26 10:05 ` Benjamin Herrenschmidt
2002-03-24 19:38 ` Geert Uytterhoeven
2002-03-24 16:55 ` Benjamin Herrenschmidt
2002-03-24 17:18 ` Benjamin Herrenschmidt
2002-03-25 0:44 ` Murray Jensen
2002-03-25 22:05 ` Val Henson
2002-03-26 3:21 ` Val Henson
2002-03-26 4:14 ` Murray Jensen
2002-03-26 10:14 ` benh
2002-03-26 12:05 ` Gabriel Paubert
2002-03-26 12:18 ` benh
2002-03-26 23:24 ` Mark A. Greer
2002-03-26 21:40 ` benh
2002-03-27 15:13 ` Mark A. Greer
[not found] <20020320000500.GV3762@opus.bloom.county>
2002-03-20 0:28 ` Wolfgang Denk
[not found] <20020319235815.GU3762@opus.bloom.county>
2002-03-20 0:24 ` Wolfgang Denk
[not found] <3C97A9C1.EBA150B6@mvista.com>
2002-03-19 23:36 ` Wolfgang Denk
[not found] <20020319224420.GO3762@opus.bloom.county>
2002-03-19 23:00 ` Wolfgang Denk
2002-03-20 0:03 ` Gabriel Paubert
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=20020319234702.CA8AA109F3@denx.denx.de \
--to=wd@denx.de \
--cc=linux-galileo@source.mvista.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mgreer@mvista.com \
--cc=trini@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).