From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Add mechanisms for CPU and board-specific Ethernet initialization
Date: Wed, 25 Jun 2008 00:32:48 +0200 [thread overview]
Message-ID: <20080624223248.GA18929@game.jcrosoft.org> (raw)
In-Reply-To: <484EA8F6.4030502@gmail.com>
On 09:16 Tue 10 Jun , Ben Warren wrote:
> Shinya Kuribayashi wrote:
> > Stefan Roese wrote:
> >> On Tuesday 10 June 2008, Shinya Kuribayashi wrote:
> >>>>> Shouldn't this be the other way around?
> >>>>>
> >>>>> + if (board_eth_init(bis) < 0)
> >>>>> + eth_eth_init(bis);
> >>>>>
> >>>>> So that the board init routine can "overwrite" the cpu init version.
> >>>> Yeah, I think you're right. If board_eth_init() exists, it gets
> >>>> highest priority.
> >>> Just wondered, does that mean we could only have either cpu_eth_init or
> >>> board_eth_init at a time?
> >>
> >> Not really. board_eth_init() could call cpu_eth_init() if necessary.
> >
> > Hm. What is cpu_eth_init for then? Just
> >
> > board_eth_init(bis);
> >
> > seems to be enough for me. I also wonder where is the best place to have
> > cpu_eth_init?
> >
> The cpu_init() was suggested by Stefan in our original discussion, when
> I only had the board function. His perspective is ppc_4xx, where tons
> of CPUs and boards share the EMAC driver, and he didn't want to modify
> each board. As you'll see in the discussion with JDL, it can probably
> apply to TSEC as well.
> > I'm not going to argue with you, I'm just thinking about my targets. One
> > of my targets has internal ethernet MAC, and its evaluation board has an
> > on-board external PCI NIC. Another target has internal MAC, but doesn't
> > have PCI NIC.
> >
> > I thought it'll be something like
> >
> > cpu_eth_init(bis);
> > board_eth_init(bis);
> >
> The idea is that cpu_eth_init is a default for a CPU family, and
> board_eth_init is a board override, which can of course call cpu_eth_init.
What about a section to declare the netdev?
In this case we can have more than 2 eth and it more generic.
Best Regards,
J.
next prev parent reply other threads:[~2008-06-24 22:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 8:29 [U-Boot-Users] [PATCH] Add mechanisms for CPU and board-specific Ethernet initialization Ben Warren
2008-06-10 9:12 ` Stefan Roese
2008-06-10 13:53 ` Ben Warren
2008-06-10 15:16 ` Shinya Kuribayashi
2008-06-10 15:25 ` Stefan Roese
2008-06-10 15:49 ` Shinya Kuribayashi
2008-06-10 16:16 ` Ben Warren
2008-06-24 22:32 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2008-06-24 23:05 ` Ben Warren
2008-06-25 9:30 ` Haavard Skinnemoen
2008-06-25 9:34 ` Stefan Roese
2008-06-11 0:50 ` Haavard Skinnemoen
2008-06-11 11:30 ` Jerry Van Baren
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=20080624223248.GA18929@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=u-boot@lists.denx.de \
/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