[U-Boot] [PATCH] ARM: Kirkwood: Add support for OpenRD-Client & OpenRD-Ultimate

[Tanmay Upadhyay]

On 06/11/2010 12:33 AM, Prafulla Wadaskar wrote:
>
>
>    
>> -----Original Message-----
>> From: Simon Kagstrom [mailto:simon.kagstrom at netinsight.net]
>> Sent: Thursday, June 10, 2010 3:56 PM
>> To: Tanmay Upadhyay
>> Cc: Prafulla Wadaskar; u-boot at lists.denx.de
>> Subject: Re: [PATCH] ARM: Kirkwood: Add support for
>> OpenRD-Client&  OpenRD-Ultimate
>>
>> On Thu, 10 Jun 2010 15:08:00 +0530
>> Tanmay Upadhyay<tanmay.upadhyay at einfochips.com>  wrote:
>>
>>      
>>>>> +#define MACH_TYPE_OPENRD_ULTIMATE      2884
>>>>>
>>>>>            
>>>> I don't think this file is supposed to be edited in
>>>>          
>> patches, but rather
>>      
>>>> synched from arm-linux by Wolfgang from time to time.
>>>>          
>>> Sorry, I didn't know about that. However, as the number is already
>>> registered, is that ok to have it here?
>>>        
>> Probably Wolfgang or Tom Rix (the ARM maintainer) can synch it if you
>> ask them to.
>>      
> Tom Does this frequently, Hi Tom, can you pls do the needful?
>    
Tom has synched it, but unfortunately the code for ultimate hasn't been 
in yet. It's stuck somewhere 
http://lists.infradead.org/pipermail/linux-arm-kernel/2010-June/017535.html.

Shall I wait for this patch to get into the kernel before I send mine 
for u-boot? Otherwise my patch won't get compiled. However, I can send 
my patch for review. I have operd.h, openrd_base.h, openrd_client.h & 
openrd_ultimate.h in 'include/configs' as suggested.

Please suggest.

Thanks,

Tanmay
>    
>>      
>>> I agree with you. But auto-generated 'config.h' file includes
>>> <board_name.h>. So there has to be one for each board.
>>>        
> Yes, This is correct approach, lets have three files for three boards (like other added)
> Abstract common part in openrd.h and include it in respective board config header files.
>
>    
>> However, there
>>      
>>> could be one 'openrd.h'  in the configs and three board
>>>        
>> specific files
>>      
>>> include it. This will increase the number of files, but
>>>        
>> would decrease
>>      
>>> LOC. What do you think?
>>>        
> As suggested above, let's keep code clean and simple.
> Adding new board support in future to the same family will keep on increasing code complexity.
> I prefer adding few files instead of modifying existing.
> Secondly kwimage.cfg in your port may have common settings for all three board which may not be the case always.
> And file parsing does not support conditional code for this file.
>
> So I suggest, you should keep common code under openrd.c/h, and board specific in<board_name>.c/h
> Even I don't mind keeping existing openrd_base board support as it is and adding new board support for two other boards.
>
> Regards..
> Prafulla . .
>
>
> Email Scanned for Virus&  Dangerous Content by : www.CleanMailGateway.com
>
> ____________________________________________________________________________________
> Disclaimer: This e-mail message and all attachments transmitted with it are intended solely for the use of the addressee and may contain legally privileged and confidential information. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately by replying to this message and please delete it from your computer. Any views expressed in this message are those of the individual sender unless otherwise stated.Company has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email.
> ____________________________________________________________________________________
>
>