Mark A. Greer [off-list ref] wrote:
I like what Michael has done but want to add more and change the
BI_GT64260_ETH_CFG to a more generic BI_ETH_CFG.
I disagree. I don't see how a generic BI_ETH_CFG is possible. See how I've
implemented BI_GT64260_ETH_CFG in arch/ppc/kernel/setup.c:parse_bootinfo: it
injects the information from this record directly into the gt64260_eth driver,
which is where this information is needed.
Next when someone wants to do the same for, say, 8260 Ethernet, they'll have to
add BI_8260_ETH_CFG or whatever. I don't see any other way: what if I built a
board with an 8260 CPU and a GT-64260 attached to the 60x bus coming out of the
8260 (such a board was in the works at SBS before I left) and both 8260 and GT
Ethernets are used? What will parse_bootinfo() do with a BI_ETH_CFG then? Is it
going to inject the MAC address into the 8260 Ethernet driver, into the GT
Ethernet driver, or where? How do you make sure that each Ethernet interface
gets the MAC address that belongs to it?
MS
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
Michael Sokolov wrote:
Mark A. Greer [off-list ref] wrote:
quoted
I like what Michael has done but want to add more and change the
BI_GT64260_ETH_CFG to a more generic BI_ETH_CFG.
I disagree. I don't see how a generic BI_ETH_CFG is possible. See how I've
implemented BI_GT64260_ETH_CFG in arch/ppc/kernel/setup.c:parse_bootinfo: it
injects the information from this record directly into the gt64260_eth driver,
which is where this information is needed.
My point is that "you way" would change to a more generic way for all enet driver.
The BI_ETH_CFG has already been shot down so we don't need to worry about it
anyway.
Next when someone wants to do the same for, say, 8260 Ethernet, they'll have to
add BI_8260_ETH_CFG or whatever. I don't see any other way: what if I built a
board with an 8260 CPU and a GT-64260 attached to the 60x bus coming out of the
8260 (such a board was in the works at SBS before I left) and both 8260 and GT
Ethernets are used? What will parse_bootinfo() do with a BI_ETH_CFG then? Is it
going to inject the MAC address into the 8260 Ethernet driver, into the GT
Ethernet driver, or where? How do you make sure that each Ethernet interface
gets the MAC address that belongs to it?
This is a good point and this is an issue with any generic ethernet bi_rec
scheme. At this point, I'm back to preferring what you've done since...well...its
done and I don't see anyone else caring much about this for other drivers.
Mark
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
I disagree. I don't see how a generic BI_ETH_CFG is possible. See how I've
implemented BI_GT64260_ETH_CFG in arch/ppc/kernel/setup.c:parse_bootinfo: it
injects the information from this record directly into the gt64260_eth
driver,
which is where this information is needed.
This is the wrong approach. What we should do instead is have the gt eth
driver
do some kind of find_bi_rec(BI_GT64260_ETH_CFG). setup.c doesn't have to be
changed each time a new birec is added, and your approach seem wrong if
that driver ever becomes a module.
What I have not yet decided regarding what to do of birec's in 2.5.
That is either providing some structure to them so they represent devices
with all the mapping & routing information needed (flexible enough to
accomodate
most embedded needs), that is some kind of lightweight device-tree, or if
we just
stay to what we have now (minus bd_t), that is everybody defines it's own
set of
bi_recs.
I've started writing a draft of what the first option could be last year, I'll
see if I can still find it and post it for you guys to fight over some
material ;)
The _important_ point however is that the common arch code and the common
CPU code mustn't have to care (or be modified) when a bi_rec is added and
then later used by whatever driver you want to pass it to.
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/