public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFC][PATCH 1/1] Add board_eth_init() function
Date: Tue, 25 Mar 2008 11:56:07 -0400	[thread overview]
Message-ID: <47E92097.1000506@ge.com> (raw)
In-Reply-To: <1206459104.7589.226.camel@gentoo-jocke.transmode.se>

Joakim Tjernlund wrote:
> On Tue, 2008-03-25 at 10:57 -0400, Ben Warren wrote:
>> Joakim Tjernlund wrote:
>>> On Tue, 2008-03-25 at 10:22 -0400, Ben Warren wrote:
>>>   
>>>> Stefan Roese wrote:
>>>>     
>>>>> On Saturday 22 March 2008, Ben Warren wrote:

[snip]

>>>>> Using Markus's idea, why not use a cpu (platform) specific *and* a board 
>>>>> specific init function, both with an empty weak alias in the common eth.c 
>>>>> code:
>>>>>
>>>>> 	cpu_eth_init(bis);
>>>>> 	board_eth_init(bis);
>>>>>       
>>>> I thought about this some more, and the problem is that cpu_eth_init() and board_eth_init()
>>>> are mutually exclusive, with board_eth_init() having a higher priority.
>>>> I think the following will work, but would appreciate some feedback.
>>>>
>>>> -----
>>>>
>>>> int board_eth_init(bd_t *bis) __attribute(weak);
>>>> int cpu_eth_init(bd_t *bis) __attribute(weak);
>>>>
>>>> .
>>>> .
>>>> .
>>>>
>>>> if (board_eth_init)
>>>> 	board_eth_init(bis);
>>>> else if (cpu_eth_init)
>>>> 	cpu_eth_init(bis);
>>>>
>>>> -----
>>>>
>>>> This gets rid of the pointless aliases and gives precedence to the board-specific initialization.
>>>>
>>>>
>>>> regards,
>>>> Ben
>>>>     
>>> I think you must enable full relocation, CONFIG_RELOC_FIXUP_WORKS, to
>>> make the "if (board_eth_init)" work. This is just a guess though.
>>>
>>>   Jocke
>>>
>>>   
>> Nothing a little testing can't figure out.
>>
>> thanks,
>> Ben
> 
> You could do too:
> if (!board_eth_init(bis))
>     cpu_eth_init(bis);
> 
>  Jocke

Per an earlier discussion on how weak functions are implemented, these 
are not equivalent.  Functions marked "weak" *without* a weak 
implementation become NULL pointers.  The code
	if (board_eth_init)
		board_eth_init(bis);
	else if (cpu_eth_init)
		cpu_eth_init(bis);
uses that knowledge to see if the weak function board_eth_init() exists 
and then calls it if it does.  If it doesn't exist, it sees if 
cpu_eth_init() exists and calls it if it does.

Your counter proposal assumes that a weak function board_eth_init() 
*does* exist and uses the returned result as the condition of executing 
cpu_eth_init() (assuming it also exists).

If you define a weak function that simply returns failure, your 
alternative is close, but still not the same because an overridden 
(*real*) board_eth_init() could return failure too, in which case it 
will (probably erroneously) execute cpu_eth_init().  Beyond that, if 
cpu_eth_init() doesn't exist (doesn't have a default weak function 
defined), the call to it will go *SPLAT*.

HTH,
gvb

  reply	other threads:[~2008-03-25 15:56 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-22  2:46 [U-Boot-Users] [RFC][PATCH 1/1] Add board_eth_init() function Ben Warren
2008-03-22  5:03 ` Shinya Kuribayashi
     [not found]   ` <f8328f7c0803220505n39c9ddb5sf9c9cf037b8f4665@mail.gmail.com>
2008-03-22 12:07     ` Ben Warren
2008-03-22 15:55   ` Vlad Lungu
2008-03-23  6:19     ` Shinya Kuribayashi
2008-03-26 10:00       ` Haavard Skinnemoen
2008-03-26 11:39         ` Shinya Kuribayashi
2008-03-26 12:41           ` Haavard Skinnemoen
2008-03-26 14:15             ` Ben Warren
2008-03-26 14:27               ` Haavard Skinnemoen
2008-03-22  6:31 ` Stefan Roese
2008-03-22  9:59   ` Wolfgang Denk
2008-03-22 10:14     ` Stefan Roese
2008-03-22 11:35       ` Markus Klotzbücher
2008-03-22 14:01       ` Wolfgang Denk
2008-03-22 15:43         ` Ben Warren
2008-03-25  7:04           ` Stefan Roese
2008-03-25 11:11             ` Ben Warren
2008-03-25 14:22             ` Ben Warren
2008-03-25 14:41               ` Joakim Tjernlund
2008-03-25 14:57                 ` Ben Warren
2008-03-25 15:31                   ` Joakim Tjernlund
2008-03-25 15:56                     ` Jerry Van Baren [this message]
2008-03-25 16:59                       ` Joakim Tjernlund
2008-03-25 14:43               ` Stefan Roese
2008-03-25 16:17               ` Andy Fleming
2008-03-25 16:33                 ` Stefan Roese
2008-03-25 17:04                   ` Andy Fleming
2008-03-25 17:53                     ` Ben Warren
2008-03-26 10:06             ` Haavard Skinnemoen
2008-03-26 10:14               ` Stefan Roese
2008-03-26 10:25                 ` Haavard Skinnemoen
2008-03-26 10:34                   ` Stefan Roese
2008-03-26 11:06                     ` Haavard Skinnemoen
2008-03-26 11:43                       ` Stefan Roese
2008-03-26 12:19                         ` Haavard Skinnemoen
2008-03-26 12:39                           ` Stefan Roese
2008-03-23  0:06 ` [U-Boot-Users] [OT] Using MTD to manipulate CFI flash on PCI boards? David Hawkins

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=47E92097.1000506@ge.com \
    --to=gerald.vanbaren@ge.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