From: Matt Porter <mporter@mvista.com>
To: benh@kernel.crashing.org
Cc: msokolov@ivan.Harhan.ORG, linuxppc-dev@lists.linuxppc.org,
"Mark A. Greer" <mgreer@mvista.com>
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Wed, 27 Mar 2002 07:15:27 -0700 [thread overview]
Message-ID: <20020327071527.A2510@home.com> (raw)
In-Reply-To: <20020326215235.21322@mailhost.mipsys.com>; from benh@kernel.crashing.org on Tue, Mar 26, 2002 at 10:52:35PM +0100
On Tue, Mar 26, 2002 at 10:52:35PM +0100, benh@kernel.crashing.org wrote:
>
> >
> >It would set a very bad example if it is implemented. In your proposal the
> >records containing the GT-64260 Ethernet information have no indication
> >in them
> >whatsoever that they are for GT-64260 and not some other Ethernet. If
> you make
> >the gt64260_eth driver call a function to grab all bi_recs of this kind, the
> >next engineer who designs a board with other hard-wired Ethernet
> interfaces on
> >it besides the GT-64260 (like an MPC8260 + GT-64260 system) will be simply
> >stuck out of luck as the gt64260_eth driver will unceremoniously grab all
> >records for all Ethernets and there will be no way to tell which MAC address
> >belongs to each Ethernet.
>
> Yah, this is why BI_DEV_TYPE should be GT64260_xxxx
>
> We have several choices here for the design, I'm not sure which is best, so
> please speak up:
>
> When dealing with combo-chips like the GT or PPC 4xx/8xx etc..., we can
> either:
>
> - define one BI_DEV_TYPE per chip (BI_DEV_TYPE_GT64260, ...). The actual
> device within the GT64260 (ethernet in our case) is referenced via the
> BI_DEV_CLASS (ethernet), BI_DEV_ID beeing optionally there in case a
> given device in the chip exist in more than one instance.
>
> - define one BI_DEV_TYPE per chip (same as above), and define a BI_DEV_ID
> containing both function and the index (for example 'ETH0') thus we don't
> need BI_DEV_CLASS.
>
> - define a specific BI_DEV_TYPE for each function (that is
> BI_DEV_TYPE_GT64260_ETH), BI_DEV_ID is only an index.
>
> I tend to prefer solution 2)
Since device macro cells are commonly used across different chips,
it might be wise to orient the records around the device macro
rather than the SoC it is implemented in. For example, there
are tens of 405 variants plus a similar future of 440 variants
that all share the EMAC macro device and corresponding driver.
A single BI_DEV_TYPE_IBM_EMAC would be most appropriate. Mot
has a similar scheme with the many 825x/826x variants sharing
the same ethernet macro. Marvell probably will use the same
eth macro in any forthcoming chips since they already share the
same eth macro between their MIPS and PPC offerings.
Regards,
--
Matt Porter
MontaVista Software, Inc.
mporter@mvista.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-03-27 14:15 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-03-27 2:37 EV-64260-BP & GT64260 bi_recs Michael Sokolov
2002-03-26 21:52 ` benh
2002-03-27 14:15 ` Matt Porter [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2002-03-27 20:09 Michael Sokolov
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 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] <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=20020327071527.A2510@home.com \
--to=mporter@mvista.com \
--cc=benh@kernel.crashing.org \
--cc=linuxppc-dev@lists.linuxppc.org \
--cc=mgreer@mvista.com \
--cc=msokolov@ivan.Harhan.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).