From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tom <Tom.Rix@windriver.com>
Date: Thu, 05 Nov 2009 17:33:59 -0600
Subject: [U-Boot] [PATCH 1/2] ARM Conditionally compile board LED
	functions
In-Reply-To: <20091105224328.27F1B3F6EC@gemini.denx.de>
References: <1257292804-10612-1-git-send-email-Tom.Rix@windriver.com>
	<1257292804-10612-2-git-send-email-Tom.Rix@windriver.com>
	<20091105202420.0842A3F6EC@gemini.denx.de>
	<4AF339E1.9060809@windriver.com>
	<20091105224328.27F1B3F6EC@gemini.denx.de>
Message-ID: <4AF360E7.1090906@windriver.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <4AF339E1.9060809@windriver.com> you wrote:
>> The arguments for using weak are getting weak :P
> 
> :-P
> 
>> Using weak is less relevant with the #ifdef's
> 
> But it's the wrong direction your heading. We should get rid of
> #ifdef's, not add new ones.
> 
> With #ifdef's, you have different versions of the code, which
> increases the multitude of configurations that actually need to be
> tested. With weak, you have one version of the code only. 
> 

To use the status led api, you have to define CONFIG_STATUS_LED anyway.
I did not think this added to the configuration space.

>> The benefit now is that boards that use the led functions do
>> not have to define all of them.
> 
> That's just an indication of a broken implementation.
> 
> Normally you would provide the weak functions in a central place,
> where any board configuration which wants can overwrite them, or not.
> 
>> I am open to ideas on how to kill weak off completely.
> 
> You got it wrong.
> 
> We want to kill off the #ifdef's.
> 

My vector is obviously pointing in the wrong direction..

>> Has a general led driver layer ever been proposed ?
>> Something to convert status led for a mixture of #defines and weak
>> symbols to something that had a register function and some
>> file_ops ?
> 
> We use status LEDs on many boards, without real issues. It's only AT91
> which suffers from this mess.
> 

I withdraw this patch.
I will rethink this and come up with something better.

Tom

> Best regards,
> 
> Wolfgang Denk
>