From: Wolfgang Denk <wd@denx.de>
To: Tom Rini <trini@kernel.crashing.org>
Cc: "Mark A. Greer" <mgreer@mvista.com>,
Michael Sokolov <msokolov@ivan.Harhan.ORG>,
linux-galileo@source.mvista.com, linuxppc-dev@lists.linuxppc.org
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Wed, 20 Mar 2002 16:43:18 +0100 [thread overview]
Message-ID: <20020320154323.55F28109F3@denx.denx.de> (raw)
In-Reply-To: Your message of "Wed, 20 Mar 2002 08:01:19 MST." <20020320150119.GB3762@opus.bloom.county>
In message <20020320150119.GB3762@opus.bloom.county> you wrote:
>
> > Has been shot down? When? Where? Why? Am I missing something?
>
> You were CC'ed. One problem with a generic record is that what happens
> when you have multiple drivers (8260 + gt-64260, for example). Also Dan
> Malek pointed out that most of the information (not all) should be up to
> the driver (or userland) to handle.
We talked about problems, yes. But that doesn't usually mean the
whole idea gets dropped, or does it?
I really like to be able to configure the network interface(s) of a
memory-restricted embedded system using the IP-autoconfig feature
just by passing it a "ip=..." command line agument. This saves (1)
the memory for tools like ifconfig etc in the application image and
(2) the need to modify the application when the network config
changes.
> > We need to deal with boards with more than one ethernet interface,
> > which are already active in the firmware (net-booting from redundand
> > interfaces, using separate MAC addresses).
>
> Well, you had a patch awhile ago which allowed for this to be
> configured, yes?
I am not aware of something that looks like an acceptable solution to
me.
> > We added an index field to BI_ETH_CFG, didn't we? The driver would
> > then "know" how to map this...
>
> How would it "know" which ones it can grab? Ben said the driver should
> do something like find_bi_rec(BI_XXX_ETH_CFG), which would presumbly
> return NULL or >= 1 set of bi_recs of BI_XXX_ETH_CFG. Then you get the
> 1st and 2nd GT64260 enet devices, and say the 1st and 2nd 8260 enet
> devices, and whichever drivers registers first gets eth0+eth1 and the
> other eth2+eth3.
...which may be perfectly fine in many situations. If you need a more
selective assignment, there was the proposal to add some index (me)
or "some bytes for driver specific info (e.g., on gt64260, is_rmii)"
(Mark A. Greer) which could be easily used to mark a bi_rec as [not]
acceptable by a certain ethernet driver.
> > We _do_ care, a little for 8xx, very much for 8260, also for 824x and
>
> We also need to fix the drivers for these at the same time. Do we
> actually make use of special 824x enet right now? I think one of the
So far all 824x systems we (DENX) have seen looked like "standard"
PCI devices, using standard device drivers under Linux.
> other problems we'll run into is some of the rough edges of 8xx and 8260
> support...
Right. Some work will be necessary.
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
In an infinite universe all things are possible, including the possi-
bility that the universe does not exist.
- Terry Pratchett, _The Dark Side of the Sun_
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next parent reply other threads:[~2002-03-20 15:43 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020320150119.GB3762@opus.bloom.county>
2002-03-20 15:43 ` 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
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] <20020319231628.GQ3762@opus.bloom.county>
2002-03-19 23:46 ` 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=20020320154323.55F28109F3@denx.denx.de \
--to=wd@denx.de \
--cc=linux-galileo@source.mvista.com \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mgreer@mvista.com \
--cc=msokolov@ivan.Harhan.ORG \
--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).