From: "Mark A. Greer" <mgreer@mvista•com>
To: Matt Porter <mporter@mvista•com>
Cc: benh@kernel•crashing.org, msokolov@ivan•Harhan.ORG,
linuxppc-dev@lists•linuxppc.org
Subject: Re: EV-64260-BP & GT64260 bi_recs
Date: Wed, 27 Mar 2002 10:10:51 -0500 [thread overview]
Message-ID: <3CA1E0FB.EC5935DB@mvista.com> (raw)
In-Reply-To: 20020327071527.A2510@home.com
Matt Porter wrote:
> 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
>
<snip>
> >
> > 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
<snip>
All good points. Given Matt's comments, I think sol'n 3) may be the best.
Comments?
Here's the next iteration using Ben's sol'n 3)
I also adde NULL termination to the overall bi_rec and to each nested one so the
parsing code can stop when a NULL is hit whether its a nested one or not
(therefore we can never have a valid tag with value 0). I also adjusted the size
of the BI_STRUCTS to include the 4 byte NULL terminator. I also fixed an error on
the length of the BI_MAC_ADDR (was 25, should be 28 to count padding).
Mark
--
Example for ev64260:
--------------------
[0] tag: BI_CMD_LINE
size: 36 (4 + 4 + 26 chars + 2 pad)
data: "console=ttyS0,115200 ip=on"
pad: 2
[1] tag: BI_MEMSIZE
size: 12
data: 33554432 (32 MB)
[2] tag: BI_GT64260_BASE
size: 12
data: fc000000
[3] tag: BI_STRUCT (embedded enet cltr 0)
size: 68 (12 + 2*12 + 28 + 4 == 68)
data: BI_DEVICE
[3.0] tag: BI_DEV_TYPE
size: 12
data: BI_DEV_TYPE_GT_ETH
[3.2] tag: BI_DEV_ID
size: 12
data: 0 (1st enet device)
[3.3] tag: BI_MAC_ADDR
size: 28
data: aa:bb:cc:dd:ee:ff (ascii)
pad: 3
[3.4] 0x00000000 (NULL Termination of BI_STRUCT)
[4] tag: BI_STRUCT (embedded enet cltr 1)
size: 68 (12 + 2*12 + 28 + 4 == 68)
data: BI_DEVICE
[4.0] tag: BI_DEV_TYPE
size: 12
data: BI_DEV_TYPE_GT_ETH
[4.2] tag: BI_DEV_ID
size: 12
data: 1 (2nd enet device)
[4.3] tag: BI_MAC_ADDR
size: 28
data: gg:hh:ii:jj:kk:ll (ascii)
pad: 3
[4.4] 0x00000000 (NULL Termination of BI_STRUCT)
[5] tag: BI_STRUCT (embedded enet cltr 2)
size: 68 (12 + 2*12 + 28 + 4 == 68)
data: BI_DEVICE
[5.0] tag: BI_DEV_TYPE
size: 12
data: BI_DEV_TYPE_GT_ETH
[5.2] tag: BI_DEV_ID
size: 12
data: 2 (3rd enet device)
[5.3] tag: BI_MAC_ADDR
size: 28
data: mm:nn:oo:pp:qq:rr (ascii)
pad: 3
[5.4] 0x00000000 (NULL Termination of BI_STRUCT)
[6] 0x00000000 (NULL Termination of whole list)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
next prev parent reply other threads:[~2002-03-27 15:10 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
2002-03-27 15:10 ` Mark A. Greer [this message]
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] <20020319224420.GO3762@opus.bloom.county>
2002-03-19 23:00 ` Wolfgang Denk
2002-03-20 0:03 ` Gabriel Paubert
[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
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=3CA1E0FB.EC5935DB@mvista.com \
--to=mgreer@mvista$(echo .)com \
--cc=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-dev@lists$(echo .)linuxppc.org \
--cc=mporter@mvista$(echo .)com \
--cc=msokolov@ivan$(echo .)Harhan.ORG \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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