public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Ben Warren <biggerbadderben@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH 2/2] AVR32: ATNGW100 board support
Date: Thu, 10 Jan 2008 12:36:20 -0500	[thread overview]
Message-ID: <47865794.4040803@gmail.com> (raw)
In-Reply-To: <200801101805.30186.sr@denx.de>

Stefan Roese wrote:
> On Thursday 10 January 2008, Ben Warren wrote:
>   
>> I'm not crazy about /net/eth.c calling board-specific ethernet
>> initialization routines - it should be calling the driver
>> initialization.  This file is enough of a mess as it is, and adding a
>> new entry for each board only makes it worse.  Since there's precedent,
>> though, consider this
>>
>> Acked-by:  Ben Warren <biggerbadderben@gmail.com>
>>
>>
>> In the next release (not the one finishing in a week), what do you think
>> about this:
>>
>> #if defined(CONFIG_BOARD_ETH_INIT)
>> 	board_eth_initialize(bis)
>> #endif
>>     
>
> Or even better, using an empty baord_eth_initialize() function with the weak 
> attribute. We get rid of this #ifdef this way.
>
>   
>> Moving Ethernet initialization in general to the board (not just Atmel
>> boards) would go a long way towards cleaning up the current mess and
>> would provide more scalability and flexibility.
>>
>> Thoughts?
>>     
>
> How about if the board/platform code could add eth_init functions to a 
> function-list. eth.c could then just call all functions in the list.
>   
I was initially thinking about each board defining an array of Ethernet 
device structures, including device indices, PHY addresses, PHY info 
etc. that init code would step through.  Something like this (made-up 
pseudo-code):

eth_devices eth_dev[] = {
	{

        	.type = TSEC;
		.index = 0;
		.phy = {
			.type = PHY_AUTO_DETECT;
			.address = 0x2
		}
	},
	{
		.type = TSEC;
		.index = 1;
		.phy = {
			.type = PHY_FIXED_1000_FULL;
		}
	},
	{
		.type = ULI526x; /* PCI device */
	},
	NULL_DEVICE
};

	

but a function list might be better.  Something to think about for the 
next release.

regards,
Ben

  reply	other threads:[~2008-01-10 17:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-10  8:24 [U-Boot-Users] [PATCH 0/2] AVR32 patches for next merge window Haavard Skinnemoen
2008-01-10  8:24 ` [U-Boot-Users] [PATCH 1/2] AVR32: Initialize ipaddr, loadaddr and bootfile at startup Haavard Skinnemoen
2008-01-10  8:24   ` [U-Boot-Users] [PATCH 2/2] AVR32: ATNGW100 board support Haavard Skinnemoen
2008-01-10  8:33     ` Haavard Skinnemoen
2008-01-10 16:53     ` Ben Warren
2008-01-10 17:05       ` Stefan Roese
2008-01-10 17:36         ` Ben Warren [this message]
2008-01-10 17:28       ` Haavard Skinnemoen
2008-01-10 22:41     ` Wolfgang Denk
2008-01-11  9:15       ` Haavard Skinnemoen

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=47865794.4040803@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