From: Ben Warren <biggerbadderben@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Add mechanisms for CPU and board-specific Ethernet initialization
Date: Tue, 24 Jun 2008 16:05:36 -0700 [thread overview]
Message-ID: <48617DC0.8010707@gmail.com> (raw)
In-Reply-To: <20080624223248.GA18929@game.jcrosoft.org>
Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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.
>
>
Sorry, I don't follow.
regards,
Ben
next prev parent reply other threads:[~2008-06-24 23:05 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
2008-06-24 23:05 ` Ben Warren [this message]
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=48617DC0.8010707@gmail.com \
--to=biggerbadderben@gmail.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