[U-Boot] [PATCH 04/20] arm/km: add kmnusa board support

[Holger Brunck]

On 06/12/2012 01:50 PM, Prafulla Wadaskar wrote:
> 
> 
>> -----Original Message-----
>> From: Holger Brunck [mailto:holger.brunck at keymile.com]
>> Sent: 12 June 2012 17:13
>> To: Prafulla Wadaskar
>> Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de;
>> Gerlando Falauto
>> Subject: Re: [PATCH 04/20] arm/km: add kmnusa board support
>>
>> On 06/12/2012 01:09 PM, Prafulla Wadaskar wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Holger Brunck [mailto:holger.brunck at keymile.com]
>>>> Sent: 12 June 2012 16:07
>>>> To: Prafulla Wadaskar
>>>> Cc: Valentin Longchamp; prafulla at mavell.com; u-boot at lists.denx.de;
>>>> Gerlando Falauto
>>>> Subject: Re: [PATCH 04/20] arm/km: add kmnusa board support
>>>>
>>>> On 06/12/2012 11:57 AM, Prafulla Wadaskar wrote:
>>>>>>>>  board/keymile/km_arm/km_arm.c     |    9 +-
>>>>>>>>  boards.cfg                        |    1 +
>>>>>>>>  include/configs/km/km_arm.h       |   44 +++++-
>>>>>>>>  include/configs/km_kirkwood.h     |   67 +++++++--
>>>>>>>>  6 files changed, 392 insertions(+), 24 deletions(-)
>>>>>>>>  create mode 100644 board/keymile/km_arm/128M16-1.cfg
>>>>>>>>
>>>>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>>>>> index 0445539..aa11268 100644
>>>>>>>> --- a/MAINTAINERS
>>>>>>>> +++ b/MAINTAINERS
>>>>>>>> @@ -738,6 +738,7 @@ Sergey Lapin <slapin at ossfans.org>
>>>>>>>>  Valentin Longchamp <valentin.longchamp at keymile.com>
>>>>>>>>
>>>>>>>>       km_kirkwood     ARM926EJS (Kirkwood SoC)
>>>>>>>> +     kmnusa          ARM926EJS (Kirkwood SoC)
>>>>>>>
>>>>>>> Again.... I would like to suggest to separate out new boards
>>>>>> addition, bugfixes/updates specific to km_*boards and generic
>>>> kirkwood
>>>>>> specific patches.
>>>>>>>
>>>>>>> It's always faster to merger small patch series that big one.
>>>>>>>
>>>>>>
>>>>>> Yes ok, but was has this to do with this patch? What is meant to
>> be
>>>>>> kirkwood
>>>>>> specific? This is all board related code.
>>>>>
>>>>> I agree, let's separate out -
>>>>> 1. bugfix/updates patch series to current code
>>>>> 2. "Kirkwood specific" means the changes to the Kirkwood related
>>>> file that may affects other boards, for ex
>>>> arch/arm/cpu/arm926ejs/mach-kirkwood/*
>>>>> 3. Additional board supports
>>>>>
>>>>> And if possible these patches should be independent so that can be
>>>> pulled independently
>>>>>
>>>>
>>>> the only patch in the serie which modifies common Kirkwood related
>>>> files are:
>>>> [PATCH 03/20] arm/kirkwood: protect the ENV_SPI #defines
>>>>
>>>> Do you want me to send this one seperately? I can do that. So then
>> we
>>>> resend
>>>> again a new patch serie I guess...
>>>
>>> It would be a great you can split 20 patches in to smaller patch
>> series as per above suggestion.
>>>
>>
>> Again, the only patch wich is common Kirkwood related is the above
>> mentioned
>> patch. I can extract this one if you want me to.
> 
> Yes, extract this and send it as standalone
> 

ok done.

>>
>> All others are  somehow interconnected and therefore it makes sense to
>> have it
>> in one patch serie.
> 
> Send one patch series which are related to updates/fixes to already supported code.
> 
> Then send anther patch series for addition of new boards, mention the dependency if any.
> 

Sorry but this does not make sense to me, why should we provide independent
patch series which are in the end not independent?

Why is it important to first add updates for old boards and then add new boards?
This causes a lot of work for rebasing and retesting for an already well tested
patch serie. Can't we focus on your precise inputs to the real code and not on
the sequence of the patches?

Best regards
Holger